resources.arsc 为什么不能压缩：APK 里的三种存法

打开一个 APK，把它当 zip 解开，你会看到几十上百个文件。如果把每个文件的「压缩方式」标出来，会发现一个规律：绝大多数文件被压缩了，但总有那么一两个是原样存的，一个字都没压。其中最典型的那个，名字叫 resources.arsc。

很多人第一次注意到它，是在手工改包的时候：想把它压小一点，或者用某个工具重新打包之后包变小了，结果装上去打不开、界面全白、或者所有文字变成英文。查半天找不到原因，最后发现是这张表被压过了。

这篇讲清楚三件事：APK 里的文件有哪几种存法、为什么这张表必须原样存、以及改包时哪几个动作会不小心把它压掉。

一、zip 给每个文件两个选择

zip 这个格式很老，它的设计目标之一就是「既要能压，也要能不压」。所以它给每个文件留了一个字段，写明这个文件用什么方式存。最常用的两个值是：压缩存（日常叫 deflate）和原样存（stored）。

压缩存的意思是：数据先用一套通用算法压过，读的时候要先解开才能用。好处是体积小，代价是每次读都要算一遍。对于「读一次就丢」的内容，这个代价可以忽略；对于「反复随机读」的内容，这个代价就很大。

原样存的意思是：数据一个字都不动，直接放进去。好处是读的时候不需要解压，可以直接按偏移取；代价是体积大。对于已经压过的内容（图片、音频、视频），再压一遍几乎没有收益，所以它们通常选原样存。

关键点在这里：选哪种，不是「越小越好」，而是「这个文件会被怎么读」。这一点决定了 resources.arsc 的命运。

二、resources.arsc 到底是什么

它不是图片，不是文字，不是代码。它是一张表。

一个应用里所有的资源——字符串、颜色、尺寸、图片的位置、布局的名字——在编译之后都会被编成数字编号。而「哪个编号对应哪个东西、在哪个文件里、什么条件下用哪一份」，这些映射关系全部记在 resources.arsc 里。

举个具体的：界面上有一句「确定」。编译之后，这句话不再是一句话，而是一个编号，比如 0x7f0f0012。运行时，应用拿着这个编号去 resources.arsc 里查：哦，这是个字符串，中文版在这里、英文版在那里、大屏版本又不一样。查到之后再去对应的文件里把内容取出来。

这个过程的特点是：查得非常频繁，而且每次只查一小条。一个界面渲染出来，可能要查几百次。每次查的都是一张巨大的表里的一行。这就是「随机访问」：不是从头读到尾，而是随时跳到任意位置取一条。

三、为什么压了就会出事

假设这张表被压缩了。那么应用要查 0x7f0f0012 的时候，它拿到的是一段压缩数据。要查其中第 N 条，它必须先解压——但解压只能从头开始，因为压缩算法是流式的，你不解开前面就不知道后面在哪。

于是每一次查表都变成「解压整个表，再取一条」。一个界面要查几百次，就变成解压几百次。这个代价不是「慢一点」，是「慢到不可用」。

所以系统的资源加载器在遇到「这张表是压缩的」时，通常不会真的去解压几百次。它的处理方式是：要么拒绝加载（包能装但打不开），要么退回到一个极慢的路径（能开但卡死），要么在某些实现里直接读出错位的数据（界面文字全变成另一套）。这三种表现，对应了三种不同的报错方式，但根因是同一个。

这也解释了一个常见现象：为什么「包变小了」和「应用打不开」总是同时出现。因为你把表压了，包当然小了；表压了，当然打不开。

四、除了这张表，还有哪些文件不能压

判断标准只有一条：需要被随机访问、或者需要被直接映射的，就不能压。按这条标准，可以列出一份清单。

这份清单不是教条，不同打包工具的选择会有出入。比如 dex 就有两种流派：压了包小，不压启动快。所以看到别人的包里 dex 是原样存的，不要觉得他做错了——他可能是在为启动速度做取舍。

五、回编工具是怎么决定压不压的

回编的时候，工具要重新把这些文件打成一个 zip。它怎么决定每个文件压不压？

大多数工具的做法是「按后缀猜」。它内部有一张表，写着某些后缀不压，其余压。这张表通常包含图片、音视频、已经压过的格式，以及 resources.arsc 这种特殊文件。

所以正常情况下，你不需要干预。回编出来的包，这张表一定是原样存的。问题出在「不正常」的情况：换了工具、换了参数、手工干预过、或者中途用别的软件重新打过包。

这就引出了下一节：改包流程里，哪几个动作会不小心把它压掉。这四个动作都很常见，而且都不会报错。

五之一、跟着一次界面渲染，看它查了多少次表

抽象讲「高频随机访问」不容易有感觉，跟着一次真实的渲染走一遍就清楚了。

用户点开一个列表页。系统先要找到这个页面的布局，于是查表：这个页面用哪个布局文件。查到之后读布局，布局里写着「这里放一个标题，字号 18，颜色是主题色，文字是那句欢迎语」。这四样东西每一样都是一次查表：字号查一次、颜色查一次、文字查一次、连「标题栏的高度」这种尺寸也要查一次。

布局读完，开始渲染。列表里每一行都是一个条目，每个条目有自己的布局，每个布局又有自己的文字、图标、间距。假设一屏显示八行，每行十个可见元素，那就是八十次查表；这还没算上主题、语言、屏幕密度带来的「按条件选哪一份」的判断，每一次判断又是一次查表。

一屏下来，几百次查表是常态。如果每次查表都要先解压一张几十兆的表，那这个页面根本出不来。这就是为什么这张表必须能直接定位到某一条——不是「快一点」的问题，是「能不能出来」的问题。

把这个过程想清楚之后，你再看到一个包把这张表压了，就能立刻判断出后果：不是慢，是废。而这个判断，比记住一条规则有用得多。

五之二、两种存法的名字，为什么到处看到 stored 和 deflate

如果你去看任何一份 zip 的规范或者工具的帮助文档，会反复看到两个词：stored 和 deflate。这两个词就是「原样存」和「压缩存」的正式叫法。

stored 的字面意思是「被存放」，也就是「存进去什么样，拿出来什么样」。deflate 的字面意思是「放气」，很形象：把数据里多余的气（冗余）挤出去，体积就小了。

这两个词之所以值得记住，是因为你在排查问题时，会在很多地方遇到它们：压缩软件的属性面板、命令行工具的输出、中央目录的字段值、某些日志里的一行。看到 stored 就知道没压，看到 deflate 就知道压了，比去猜一个数字快得多。

另外还有一个值叫「store only」之类的变体，在有的工具里出现，意思和 stored 一样。遇到不认识的词，看它的「压缩后大小是否等于原始大小」就能判断——这个判据是通用的，不依赖术语。

六、四个会把它压掉的动作

第一个动作：用通用压缩软件「重新打包」。有些人为了去掉包里多余的文件，会把 APK 解开，删掉几个，然后用压缩软件重新压成 zip，改后缀为 apk。这一步会把所有文件按压缩软件的默认策略重新压一遍，resources.arsc 通常就被压了。

第二个动作：用另一个打包工具重新封包。不同工具的默认策略不同。A 工具不压这张表，B 工具可能压。你把 A 的产物丢给 B 处理一次，出来就变了。

第三个动作：手工往里塞文件。你想加一张图，于是把 APK 当 zip 打开，拖进去。有些压缩软件在「添加文件」时会对整个包重新压缩，顺手把原来的原样存改成了压缩存。

第四个动作：某些「优化包体积」的脚本。这类脚本的思路是「能压的都压」，它不认识 resources.arsc 的特殊性，一刀切压下去，包小了，应用废了。

这四个动作有个共同点：它们都不会告诉你「我把表压了」。你只会看到包变小了，然后装机，然后打不开。而「包变小了」这件事，在被压缩的目标是图片时是好事，在这张表上是灾难。

七、怎么验证：读一眼中央目录

验证方法很直接：把 APK 当 zip 打开，读这张表的存法字段。如果是 0，就是原样存，正常；如果是 8，就是被压了，有问题。

如果没有工具，也有一个更笨但更可靠的办法：看 size 和 csize 是否相等。相等说明没压（压缩后大小等于原始大小），不等说明压过。这个方法对所有文件都适用，你可以顺手把整包的存法扫一遍，看看有没有别的文件被误压。

扫一遍的价值在于：它能告诉你「这个包是谁打的」。如果一张表被压了，说明这个包不是标准工具出的，可能被人手工处理过。这个信息在你判断「这个包能不能作为基础」时很有用。

八、案例一：换了个压缩软件，包能装但打不开

这是一个很典型的翻车，起因只是想删掉包里几个没用的文件。

一个客户的应用，包里有几段演示视频，客户觉得太大，想删掉。操作的人很自然地想到：把 APK 解开，删掉视频，再压回去。于是他做了解压、删除、压缩、改后缀四步。

装到手机上，安装过程很顺利，进度条走完，提示「应用已安装」。点图标，屏幕黑一下，回到桌面。再点，还是一样。没有报错，没有提示，就是打不开。

排查时第一反应是「删错了文件」。于是把删掉的视频放回去，重新压，还是一样打不开。这时候才有人想到：问题可能不在删了什么，而在「重新压」这个动作本身。

一查存法，果然：resources.arsc 变成了压缩存。原因就是通用压缩软件的默认策略——它不认识这张表，一律压。

正确的做法有两条。第一条：不要用通用压缩软件重打 APK，要改内容就在解包目录里改，然后用回编工具重新出包，它会按正确的策略封包。第二条：如果非要手工重打，必须显式指定这张表不压缩。

修好之后，包比原来小了（视频确实删掉了），也能正常打开。同样是「删掉视频」，区别只在于用哪个工具封包。这个案例说明：在 APK 这种格式上，「压缩」不是无害的操作。

九、案例二：装上了，但界面全是英文

第二个案例更微妙，因为它的表现不像「坏了」，像「改错了」。

一个应用原本是中文界面，改完之后装上去，界面变成了英文。客户第一反应是「你把语言设置改坏了」。但改的人很确定：只动了两张图，没碰任何文字。

排查思路是：先确认语言资源还在不在。解开包一看，中文的字符串文件在，内容也对。那就奇怪了——资源在，为什么显示英文？

再看这张表。发现它是压缩存的。到这里原因就清楚了：表被压了之后，资源加载器读不到正确的映射，于是退回到「只用默认语言」的路径，而默认语言恰好是英文。所以表现不是「打不开」，是「语言错了」。

这个案例的价值在于：同一处损坏，可以有完全不同的表现。前一个案例是打不开，这一个是「能开但内容不对」。如果你只按表现去猜原因，很容易猜错方向——前者会让你怀疑文件完整性，后者会让你怀疑语言配置。

这也说明一件事：报错信息只能缩小范围，不能直接给出原因。真正的定位要靠「检查关键结构」，而不是靠猜。

十、重新封包时，那张表的正确姿势

如果你确实需要手工重新封一个包（比如批量处理、或者工具坏了要应急），有几个必须遵守的点。

第一，明确指定这张表原样存。命令行工具一般都有「指定某些文件不压缩」的参数，写法是把它列进去。不同工具的参数名不一样，但功能都有。

第二，原生库和字体也一起指定。它们虽然不是「必须」，但不压更好——加载时能映射，启动更快。

第三，封完之后一定要验证。不是「看包能不能装」，是「读存法确认对」。因为装得上不代表能用，前面两个案例都装得上。

十之一、往包里加一个文件，正确做法有四步

「我只想加一张图」是改包里最常见的需求，也是最容易把包弄坏的动作之一。因为大多数人加文件的方式，是把它拖进压缩软件的窗口。

正确的做法有四步。第一步，先把包解开到一个目录，不要在压缩软件的界面里直接操作。第二步，把新文件放进对应的目录，注意目录结构和文件名要和原来的一致。第三步，用回编工具重新封包，让它按正确的策略处理存法和顺序。第四步，验证存法、装机、打开看。

这四步里，第三步是关键。因为「封包」这个动作包含了三件你未必知道的事：哪些文件不压缩、文件按什么顺序排、目录结构怎么规范化。这三件事标准工具都会处理，而压缩软件只处理第一件的一半——它会按自己的默认策略压，这个默认策略通常不适合 APK。

如果你非要在压缩软件里直接加文件，至少要注意一点：加完之后不要点「全部重新压缩」之类的选项。有些软件在添加文件时会问「是否重新压缩所有文件」，选「否」，它只会把新文件加进去，不动原有的。这是唯一相对安全的做法，但仍然不如用回编工具。

七之二、中央目录还能告诉你什么

中央目录不只有存法这一个字段，它其实是一份「包的自述」。会读它，你能在不打开任何文件的情况下知道很多事。

它能告诉你文件的顺序。顺序本身不说明对错，但能说明「这个包是怎么被打出来的」：标准工具出的包，通常把索引表和主代码放在前面；压缩软件重打的包，通常按名字排序。看到顺序异常，就该警惕存法也异常。

它能告诉你压缩比。把原始大小和压缩后大小一比，就知道每个文件被压掉多少。如果一个明显是文本的文件压缩比只有百分之三，说明它被当成「已经压过」的文件处理了；反过来，如果一个图片的压缩比高达百分之六十，那多半是它被强行压过——这两种异常都值得看一眼。

它还能告诉你有没有多余的东西。有些包里有上次打包留下的临时文件、有编辑器的备份文件、有重复的资源目录。这些东西不会让包坏掉，但会让包变大，而且在某些情况下会引发资源冲突。扫一遍文件名，能顺手清掉一批。

所以「读中央目录」这件事，成本是十秒，收益是一份关于这个包的体检报告。它不能替代装机验证，但它能在你动手之前就告诉你「这个包值不值得当基础」。

十一、体积和速度，怎么取舍

前面讲的是「必须不压」的情况，这一节讲「可以压，但要不要压」的取舍。

一个文件压不压，本质是一道算术题：压缩省下的体积，值不值得付出每次读取都要解压的代价。不同的文件，答案不一样。

从这张表能看出一个规律：「大而已经压过」的不压，「小而纯文本」的压。这是因为压缩算法的收益主要来自「文本里的重复模式」，而图片视频本身已经是压缩结果，再压只是在压缩随机数据，收益接近零，还白花时间。

十二、dex 那两种流派的取舍

dex 是唯一一个有真实分歧的文件类型，值得单独说。

一派主张压：包小，下载快，用户装的时候少等一会。另一派主张不压：启动时不用解压，直接映射，首帧更快。

这两种做法都对，取决于你的应用更在意什么。如果一个应用是「装一次，天天用」，那启动速度更重要，不压；如果是一个「偶尔打开的查询工具」，那包小更重要，压。

还有一个折中：只把主 dex 不压，其余压。因为主 dex 在启动时第一时间就要读，其余的可能到很晚才用到。这个做法在一些工具里是默认的。

改包的时候，这一项最好不要动。因为原包的取舍是应用方做过的决定，你不知道他为什么这么选。你改了，可能让一个「启动很快」的应用变慢，也可能让一个「包很小」的应用变大。除非你的改动明确要求（比如客户就是要包小），否则保持原样。

十三、APK 里的文件顺序也有讲究

这一节稍微偏一点，但它和「读得快不快」直接相关。

zip 允许文件按任意顺序排列。而系统读一个文件时，是按偏移直接跳的，所以顺序理论上不影响。但实际使用中有个细节：启动时最先要读的几个文件，如果放在包的靠前位置，磁头/闪存的连续读取会更顺。

标准工具通常会把这张表和主 dex 放在靠前的位置，因为它们启动时第一时间要读。如果你手工重封，压缩软件可能按文件名排序，把它们排到中间去，结果就是启动时多几次随机读。

这个差别在小包上感觉不到，在几百兆的包上能测出来。所以「手工重封」这件事，除了存法，顺序也要留意——而这两件事，标准出包链路都会替你处理。

十四、工具是怎么把这件事接走的

回到实际使用。手工处理这些细节，成本很高：要记哪些文件不压、要记顺序、要验存法。而这三件事都是「不做也不会立刻报错」的类型，所以特别容易被跳过。

安卓修改大师智改工坊的做法是把封包这一层完全接走。你改的是内容——换一张图、改一句文案、改一个名称；封包时的存法、顺序、对齐、签名方案，全按正确的策略自动处理。所以你不需要知道 resources.arsc 是什么，也能出一个正确的包。

更实际的一点是：它把「装得上」和「能用」这两件事分开验证。出包四步跑完会给出各自的结果，装机之后会把版本信息读回来。这两道检查合起来，能挡住「包变小了但打不开」这类问题——因为打不开的时候，装机那一步就会失败，而不是等你交付之后被客户发现。

这就是工具在这类细节上的价值：不是让你学会它，是让你不必学会它也不会做错。

十三之二、为什么图片几乎压不动

这一节解释一个很多人好奇的问题：为什么一个两兆的图，压完还是一兆九？

因为图片格式本身就已经是压缩结果。png 用的是无损压缩，jpg 用的是有损压缩，webp 两种都有。它们的设计目标就是把「人能感知不到的部分」去掉，剩下的数据在统计上已经接近随机。而通用压缩算法（deflate）靠的是找重复模式，随机数据里没有重复模式可找，所以压不动。

有一组经验数字可以参考：文本类内容，通用压缩通常能压到原来的三分之一到一半；已经压缩过的图片，通常只能压掉百分之二到百分之五；视频更少。所以「把图片也压一遍」这个动作，收益接近零，而代价是每次读都要解压——纯亏。

这也解释了为什么标准工具会把图片设为不压缩：不是因为它「重要」，而是因为「压了没好处还有坏处」。判断一个文件要不要压，用这个逻辑去想，比背清单更可靠。

十一之二、这张表到底有多大

一个中等复杂度的应用，这张表通常在几百 K 到两三兆之间。听起来不大，但它的「访问密度」极高，所以它的体积不是问题，它的可访问性才是问题。

表的大小主要取决于三件事：资源条目有多少、支持多少种语言、支持多少种屏幕配置。条目多、语言多、配置多，表就大。一个只支持中文、只做手机适配的工具类应用，表可能只有两百 K；一个支持二十种语言、手机平板电视都适配的应用，表能到五兆以上。

这也解释了一个现象：为什么「多语言」的应用更容易在这张表上出问题。因为表越大，压了之后解压的代价越高，出问题的概率越大。同时，多语言应用的默认语言往往是英文，所以表坏了之后的表现常常是「变成英文」而不是「打不开」。

如果你要改一个多语言的应用，建议在动手之前先看一眼这张表有多大。它大的话，你对「不能压」这条规矩要更警惕；它小的话，你至少知道即使出问题，表现可能是「打不开」而不是「文字错乱」——前者容易发现，后者容易漏过去。

十四之二、改包时这一层到底该不该碰

一个很实际的问题：我只是想换一张图，有必要了解这些吗？

有必要，因为「换一张图」这个动作会经过封包这一层，而封包这一层会重新决定所有文件的存法。也就是说，你不碰它，它也在变。区别只在于：用对的工具，它变对；用错的工具，它变错。

所以正确的态度不是「我要学会控制存法」，而是「我要确保我用的工具会正确处理存法」。前者需要你成为专家，后者只需要你选对工具，并且在出问题的时候知道往哪里看。

这也是这篇的定位：它不是教你手工封包，而是让你在遇到「装得上却用不了」的时候，能在三分钟内想到「去看看存法」，而不是花三小时怀疑代码、怀疑密钥、怀疑设备。

十五、五个常见误解

这一节列的说法，都是在实际交流里反复出现的。

误解一：包越小越好

包小是好事，但「小」有代价。把不能压的东西压了，包是小了，应用废了。正确的说法是「在能用的前提下尽量小」，而不是「无条件小」。判断一个包做得好不好，先看能不能用，再看大小。

误解二：压缩率越高越专业

压缩率是压缩算法的输出，不是你的成绩。用最高的压缩率打一个包，可能只是让打包多花三分钟，体积少两百 K，然后启动慢一点。专业的做法是按文件类型分别处理，而不是一律拉满。

误解三：装得上就说明包是好的

安装只检查三件事：包结构完整、签名可验、版本允许。它不检查「表能不能读」「资源能不能取」。所以「装得上」是一个很低的门槛，用它当验收标准，等于没验收。

误解四：这张表是图片索引，删了就能省空间

删了它，应用连「界面上有什么」都不知道，直接打不开。它不是索引的一部分，它是索引本身。有些「精简包」的教程会说删掉某些文件能省空间，但从来不包括这一张。

误解五：所有 zip 工具都一样

差别很大。有的工具默认不压已知的二进制格式，有的工具一刀切；有的工具保留原顺序，有的按名字重排。同一个目录，用两个工具封出来的包，表现可能完全不同。这也是为什么「换个工具试一下」有时能解决问题——但你不该靠试。

十六、给新手的四条

如果只记四句话，记这四句。

十七、为什么值得专门讲一张表

写到这里，可能有人觉得：这不就是「有个文件不能压」吗，值得写这么长？

值得，因为它是「一个约束如何牵动整条链路」的样本。这张表不能压，于是它必须对齐（能映射）；对齐必须在签名之前（签名认布局）；签名必须在最后（签完不能再动布局）。一个约束，牵出了后面三步的顺序。

理解了这个链条，你在遇到任何一个「奇怪的规定」时，会习惯性地问一句：它在保护什么？大多数技术规定的背后，都有一个具体的、可验证的原因。找到那个原因，规定就不再是需要背的条文，而是可以推导的结论。

安卓修改大师智改工坊把这些约束收进了流水线：封包时按类型决定存法，对齐时按页大小定布局，签名时按最低系统版本选方案，四步依次跑完并各自给结果。你只需要说清想改成什么，不必记住这张表叫什么。只需说话，就能让应用变成你想要的样子——这句话背后，是一堆这样的约束被悄悄处理掉了。官网 www.apkeditor.cn，产品介绍页 https://www.apkeditor.cn/ai-version.aspx。

最后留一个动作给还在手工封包的人：下次出包之后，花十秒读一遍中央目录，确认这张表是原样存。这十秒可能什么都不改变，也可能让你避免一次「装得上但打不开」的交付。

一个 APK 里的文件有两种存法：压缩存和原样存。选哪种不看「能不能更小」，而看「这个文件会被怎么读」。resources.arsc 是一张要被高频随机查的表，压了就没法直接定位，所以它必须原样存——这一条约束，往下牵出了对齐、签名、封包顺序一整套规矩。理解了它，你就理解了出包链路为什么是这个样子。

www.apkeditor.cn

十六之二、三个和这张表有关的报错

这张表出问题时，报错信息往往不直接提它。下面三种说法，都可能是它。

第一种：「解析程序包时出现问题」。这个提示通常出现在安装阶段，意思是包的结构读不通。如果它伴随着「包比原来小了不少」，八成是这张表被压了，导致结构里的某个偏移对不上。

第二种：装上之后点开黑屏、闪退、或者立刻回到桌面。这类表现最容易被误判成「代码坏了」，但如果这次改动只碰了图片和文案，代码根本没动，那就要往资源加载上想。

第三种：界面能出来，但文字全是另一种语言、或者图片全是默认占位图。这种表现最像「改错了内容」，实际上往往是「读不到正确的映射」，于是退回到了默认资源。

这三种说法对应三个不同的失败阶段：读结构、读资源、选语言。它们的共同点是都不提这张表的名字。所以排查的时候，不能只看提示原文，要看「这次改了什么」和「包体积有没有异常变化」这两条线索。

十五之二、六条冷知识

第一条：这张表的名字里，arsc 是「android resource」的缩写，前面的 s 是复数资源的意思。名字本身就在说它是「资源的集合」，不是某一个资源。

第二条：同一个应用的不同语言版本，共用同一张表。语言不是分开存的，是表里按「配置」分组存的。所以改一个语言，动的是同一张表里的一组条目。

第三条：这张表可以被单独抽出来看。有些工具能把它反编译成可读的文本，你能看到每个资源的编号、类型、在哪个文件里。这在排查「某个资源到底存不存在」时很有用。

第四条：它的格式在不同系统版本上有过演进，但总体保持向后兼容。这就是为什么一个老包能在新系统上跑——读的人认识旧格式。

第五条：它的对齐要求和它「不能压」是同一件事的两面。不能压，所以数据在文件里是原样的；原样，所以可以被直接映射；映射，就要求起点对齐。三条互相咬着。

第六条：它是最容易被「优化工具」误伤的文件。因为这类工具的判断依据通常是「后缀」和「体积」，而它的后缀不常见、体积又不小，正好落在「值得压一压」的范围里。

把这些串起来看，这张表其实是一个很好的教材：它同时说明了「格式决定用法」「约束决定顺序」「默认值决定成败」三件事。而这三件事，在你之后遇到的每一个技术细节里都会再出现一次。学会从一个具体文件推到一条通用规律，比记住十个「不能压的文件」管用。

还有一个副产品：当你能判断「这个包被人手工动过」之后，你在接一个陌生包的时候会多一层警觉。别人的手工操作，往往不止改了一处——他可能还改过签名、换过图、删过文件。这些痕迹都在结构里，而读结构，比问「这个包是原厂的吗」可靠得多。

这一点，在你接手别人改过的包时尤其重要：先看结构，再谈内容。结构不对，内容再对也用不了。

合规提醒：本文所述操作仅适用于你拥有或已获得授权的应用。代他人修改应用前请取得书面授权，不得用于去除授权校验、绕过付费限制、冒充官方发布等用途；相关行为可能违反《著作权法》《计算机软件保护条例》与《网络安全法》。

一个约束，牵动整条链路。

安卓修改大师智改工坊把改包之后那一串动作收在同一个界面里：说一句话，改完自动回编、对齐、签名，还能装回手机看一眼再交付。官网是 www.apkeditor.cn，产品介绍页 https://www.apkeditor.cn/ai-version.aspx。

十七之二、一个可以自己做的实验

如果想把这篇的内容变成自己的，有一个五分钟就能做完的实验。

找一个你手上的 APK，复制一份。用压缩软件打开副本，把 resources.arsc 那一项删掉再重新加进去（或者干脆用压缩软件「重新压缩全部」一次）。然后把副本装到一台测试机上。

你会看到什么？大概率是装得上、打不开。这个结果本身就是最好的教材——它让你亲眼看到「一个文件的存法」能造成多大的后果。而这个后果，是没有任何提示的。

做完之后，把副本删掉，用原始包重新走一遍正确的流程，确认一切正常。这五分钟买到的，是一个以后再也不会犯的错误，以及一个判断别人的包「有没有被手工动过」的直觉。

实验的时候有一个提醒：一定要用副本，一定不要在原包上操作。原包是你唯一的退路，动了它，你就没有对照的基准了。这条规矩在所有改包场景里都成立，不只是这一个实验。

这六条里，第六条最实用。如果你在用某个「一键优化包体积」的工具，先确认它有没有把这张表排除在外。没有排除的，别用——省下来的那点体积，换不来一次打不开的交付。