APK本质是标准ZIP包，可用C#原生ZipFile直接读取；需以压缩包而非安装包视角处理，避开反编译误区，注意路径合法性、大小写敏感性、目录项过滤及签名块兼容性。
APK本质是zip，用System.IO.Compression.ZipFile就能打开
APK不是黑盒，它就是标准zip包（MIME类型application/vnd.android.package-archive），C#原生ZipFile完全能读，不需要第三方APK解析库。关键在于别把它当“安装包”想，而要当“压缩包”处理。
常见错误是直接用Assembly.LoadFrom或试图反编译classes.dex——那和读assets/或res/无关，纯属跑偏。
- 确保目标APK文件没被系统锁定（比如正在安装中，或被ADB占用）
- 路径必须是完整本地路径，
file://前缀或URI格式会报IOException: Invalid archive - Android 12+签名用APK Signature Scheme v3，但签名块在zip末尾，不影响
ZipFile.OpenRead读取内部文件
读assets/目录要遍历ZipArchive.Entries匹配路径前缀
assets/下文件无结构约束，可能嵌套多层，也可能叫assets/config.json或assets/lua/main.lua。不能硬编码找某一个文件，得靠路径过滤。
示例逻辑：打开ZipArchive后，遍历Entries，用entry.FullName.StartsWith("assets/", StringComparison.OrdinalIgnoreCase)筛选。
-
FullName含正斜杠，且区分大小写——Android打包默认转小写，但某些构建工具（如Unity）可能保留原大小写，建议用OrdinalIgnoreCase - 跳过目录项：
entry.Length == 0 && entry.FullName.EndsWith("/")，否则Open()会抛NotSupportedException - 读二进制内容直接用
entry.Open()返回的Stream，别用ExtractToFile——临时文件IO慢，还可能因权限失败
读res/资源得小心路径和命名规则
res/里的文件名受Android编译约束：只允许小写字母、数字、下划线；res/drawable-hdpi/icon.png这种带密度限定符的路径是合法的，但res/layout/main.xml里的@drawable/icon引用，不等于文件系统里真有res/drawable/icon.png——可能被AAPT2编译进resources.arsc，原始文件已不存在。
所以，直接读res/仅适用于未编译资源（如开发阶段的APK）或明确知道目标文件未被合并/压缩的情况。
- 检查
entry.FullName是否以res/开头，再按需过滤子目录，例如entry.FullName.StartsWith("res/values/") || entry.FullName.StartsWith("res/raw/") - 避免依赖
resources.arsc解析——那是二进制索引表，C#原生没轻量级解析器，强行读只会掉进字节码坑里 - 如果目标是获取字符串、尺寸等资源值，基本不可行；如果是读
res/raw/sound.mp3或res/xml/config.xml，则和assets/一样可靠
注意ZipArchiveMode.Read和异常边界
用ZipFile.OpenRead(path)最省心，它等价于new ZipArchive(stream, ZipArchiveMode.Read)。千万别用ZipArchiveMode.Update或Create——APK签名会立刻失效，且你根本不需要改它。
真实场景里，APK可能损坏、被截断、或用非标准压缩算法（极少见），这些都会让ZipArchive构造失败。
- 捕获
InvalidDataException（签名块破坏、zip头错）和IOException（文件被占用、路径不存在） - 不要假设
ZipArchive可重入：每个ZipArchive实例对应一个Stream，用完必须Dispose()，否则文件句柄泄漏 - Android 14开始限制
adb backup导出APK，但本地文件系统读取不受影响——只要APK文件能被.NET进程访问到，方法就有效
真正麻烦的从来不是读zip，而是后续怎么理解读出来的资源语义。比如res/values/strings.xml是标准XML，但resources.arsc是自定义二进制，没文档、没官方解析器、连AOSP里都靠C++ runtime加载——这时候就得承认：有些东西，C#不该碰。
