对齐那 4 个字节：zipalign 到底在优化什么

出包有四步：回编、对齐、签名、校验。其中「对齐」是最容易被跳过的一步——它不出错的时候没人注意，出错了又常常被当成别的毛病。很多人做了几十个包，也说不清这一步到底在干什么，只知道「不跑它会出问题」。

这篇就只讲这一步。讲清楚四件事：它为什么存在、那 4 个字节是给谁用的、不对齐会付出什么代价、以及为什么它必须排在签名之前。这四件事讲明白之后，你在遇到「包能装但启动慢」「换了工具之后就出问题」这类情况时，会多看一个地方。

一、先把 APK 当成一个 zip 看

APK 的容器格式就是 zip。这一点决定了后面所有讨论的基础：它不是一个整体，它是一堆文件被打包、加了索引之后的产物。

一个 zip 文件在物理上分三段。第一段是每个文件各自的「本地头」，记录这个文件叫什么、多长、用什么方式压缩，紧跟着就是它的数据。第二段是一张「中央目录」，把第一段里每个文件的位置、大小、校验值汇总成一张表，放在文件末尾附近。第三段是「目录结束记录」，指向中央目录的起始位置。

系统读一个 APK 的时候，第一步读的是第三段，拿到中央目录在哪；第二步读中央目录，拿到每个文件的偏移；第三步按偏移直接跳到某个文件的数据开始处。这个过程不需要从头扫一遍，所以它很快。

关键就在「按偏移直接跳」这六个字上。偏移是精确的字节位置，如果某个文件的数据没有落在预期的位置上，读它的人就得先做一次搬移，或者退化成流式读。对齐要解决的，就是这个「落在哪」的问题。

二、那 4 个字节是给谁用的

答案是：给「不能被压缩」的文件用的。

zip 里每个文件可以选两种存法：压缩存（deflate）和不压缩存（stored）。压缩存的文件在使用时必须先解压到内存里，它从哪开始其实不敏感；不压缩存的文件则是「原地使用」，系统会把文件的一部分直接映射进内存，读的时候不复制，只建立映射。

建立映射有个前提：映射的起点必须落在内存页的边界上。而内存页通常是 4KB，不是 4 字节。那为什么工具里写的是 4？

因为 4 是最小公约数。页边界一定是 4 的倍数，所以只要保证偏移是 4 的倍数，向上对齐到页边界时就不会错位。反过来，如果偏移是 3、是 5、是 7，那么这个文件的数据会跨在两个页之间，映射时就得先把前半段搬到一个临时缓冲区——这一次搬移，就是启动时那一点点卡顿的来源。

三、不对齐会发生什么：三件可测的事

第一件是启动变慢。慢多少取决于这个应用有多少未压缩的大文件。一个只有几十个小图的应用，差别在毫秒级，感觉不到；一个带几百兆未压缩资源的应用，差别可以到几百毫秒，用户能感觉到「点下去愣了一下」。

第二件是内存占用变高。因为没法映射，系统只能把文件读进堆里，读完还要留着。同一个应用，对齐的版本可能占 80M，不对齐的版本占 120M。这个差别在中低端设备上会被放大，因为内存本来就不宽裕，读进来的东西会挤掉别的东西，然后触发回收，然后卡。

第三件最隐蔽：某些系统版本上会直接报错。因为映射的起点不合规，读的人可能拒绝这次映射，然后退回到「读不出来」——表现是某个资源加载失败、界面缺一块、或者干脆打不开。这类问题不会在你这台设备上出现，只在特定系统版本和特定机型上出现，所以特别难查。

四、为什么它必须排在签名之前

这是四步顺序里最容易被搞反的一处，也是「先签名再对齐」这种操作会直接把包弄坏的原因。

签名不是往文件末尾追加一段数据那么简单。较新的签名方案会把整个文件切成块、逐块算摘要，然后把摘要和签名一起写进文件里的一个专门区域。这个区域的位置和大小，是算出来的，跟文件当时的字节布局绑死。

如果你签完名再去对齐，对齐会在文件中间插入填充字节。插入一个字节，后面所有内容的偏移都变了；偏移一变，之前算的摘要全部对不上；摘要对不上，校验就失败。表现就是：包看起来完整，装的时候提示签名无效，或者装上之后系统拒绝运行。

所以顺序是死的：先回编出内容，再对齐定布局，最后签名锁结果，然后校验确认。任何试图把对齐放到签名之后的做法，都会把签名破坏掉。

五、那两个参数：-f 和 -p 各在管什么

工具里跑对齐时，参数通常是这么一串：-f 和 -p 再加一个数字。三个部分各自管一件事。

-f 是「强制覆盖」。如果目标文件已经存在，直接覆盖它。没有这个参数，工具遇到同名文件会拒绝执行，然后你会看到「对齐没跑」但其实什么都没发生——这是「假成功」的一种。

-p 是「页对齐」。加上它，工具会按内存页大小（通常 4KB）对齐，而不只是 4 字节。这个参数的意义在于：4 字节对齐只保证「不会跨页错位」，页对齐保证「每个文件都从页的开头开始」，映射时的效率更高。

最后那个数字是「对齐的倍数」，一般写 4。有些新设备的内存页是 16KB，这种设备上如果还按 4KB 对齐，某些大文件仍然会跨页，所以要按更大的倍数对齐。

这三个部分里，-p 最容易被漏。漏了它，包照样能装、照样能跑，所以你不会发现有问题——只是启动比理想状态慢一点，内存比理想状态高一点。这就是「对齐这一步不出错时没人注意」的原因：它的收益是隐性的，它的错误也是隐性的。

六、怎么验证它真的对齐了

对齐有一个专门的检查模式，跑一次就出结论，不需要人眼判断。它的输出很简单：要么说「验证成功」，要么指出第几个文件没对齐、差几个字节。

如果手上没有这个工具，也有一个笨办法：把 APK 当 zip 打开，读中央目录里每个文件的偏移，逐个对 4 取余。余数为零就是对齐的。这个方法慢，但它不依赖任何工具，适合在只有一台干净电脑的时候应急。

验证这件事值得养成习惯，因为「对齐没跑」和「对齐跑了但没生效」在外观上完全一样。前者是参数写错，后者是文件被别的步骤覆盖了。两种都表现为「包是好的，只是没优化」，你不查就永远不知道。

七、签名块长什么样：它为什么这么怕填充

要理解「为什么不能先签名后对齐」，得知道签名块在哪、长什么样。

较新的签名方案，会在 zip 的中央目录之前插入一段数据，专门放签名信息。这段数据的开头有一个固定的标识，读的人靠这个标识在文件里找到它。找到之后，按里面记录的「这块有多长」把整段读出来。

注意这里有个依赖：读的人知道这块在哪、有多长，靠的是「中央目录的起始位置」和「这块自己声明的长度」。而中央目录的起始位置，是写在文件末尾的目录结束记录里的。

所以一旦你在文件中间插入字节，中央目录就往后挪了，目录结束记录里记的那个位置就错了。读的人按错误的位置去找，找不到中央目录，整个包就读不出来——这不是「签名无效」，这是「包坏了」。

这也是为什么对齐必须在签名之前：对齐会插入字节，插入会让布局变化，而签名用的就是布局。布局定下来了，才能签；签完了，布局不能再动。

八、内存页变成 16K 之后，-p 的意思变了

前面说内存页「通常是 4KB」，这个「通常」正在被打破。

新一代设备开始用 16KB 的内存页。页变大带来的是更少的页表项、更好的大块内存访问效率，但对 APK 的对齐提出了更高要求：原来按 4KB 对齐够用的文件，在 16KB 页的设备上又变成跨页了。

所以「-p 加一个数字」里的那个数字，不是随便写的。它应该等于「目标设备的内存页大小」。如果你的应用要覆盖新设备，这个数字要跟着变大；如果只覆盖老设备，4 就够。

这个变化带来一个很实际的问题：同一个包，在老设备上对齐得完美，在新设备上仍然是错的。而且它不会报错，只是慢一点、占多一点。所以「按最大公约数对齐」是一个稳妥的选择——按 16KB 对齐的包，在所有设备上都至少满足 4KB 的要求，只是体积会略大一点。

体积大多少？取决于文件数量。每多一个文件，最多多十几个字节的填充，一千个文件也就十几 KB。用十几 KB 换「在所有设备上都对」，这笔账通常是划算的。

九、哪些文件是「不压缩」的：一份清单

对齐只对不压缩的文件有意义，所以知道「哪些文件不压缩」比知道「怎么对齐」更实用。因为你能据此判断：这个包对齐之后，收益大不大。

从这张表能看出来：一个应用的「不压缩文件」主要是资源和原生库。所以资源越重、原生库越多的应用，对齐的收益越大；一个纯代码、资源很少的工具类应用，对齐的收益就很小——小到你测不出来。

十、对齐失败的四种原因

对齐这一步失败，表现通常有两种：一是工具报错，二是工具「成功」了但检查不通过。后者更麻烦，所以四种原因要分开讲。

第一种：目标文件被占用。上一次的产物还开在某个程序里，或者被杀毒软件锁着，工具写不进去。表现是报「拒绝访问」，但很多人会以为是权限问题，去改权限，越改越乱。正确动作是先关掉占用它的程序。

第二种：源文件本身不是合法的 zip。回编产物损坏、传输中断、或者前面某一步写了一半。这种对齐必然失败，而且失败得很早，通常会直接说「不是有效的压缩文件」。

第三种：磁盘空间不足。对齐要写一个新文件，需要额外的空间。空间只够放产物、不够放临时文件时，会写一半失败，得到一个残缺的 APK。这种最坑，因为残缺的包看起来有大小、能双击、能传给别人。

第四种：先签名后对齐。工具不会报错——它只是忠实地在已经签好的包上插入填充，把签名弄坏。检查签名的时候才会失败，而那时候你已经在怀疑密钥了。

这四种里，前三种有明确报错，第四种没有。所以排查顺序建议是：先看报错原文，没有报错就直接去查顺序。这个顺序能省掉大量时间，因为「没有报错但结果不对」的情况，八成是步骤顺序错了，而不是工具坏了。

十一、案例一：启动慢半秒，查了三天

这是一个真实的排查过程，能说明「对齐」这个隐性因素有多难想到。

一个做本地服务的小应用，用户反馈「点图标之后要等一下才出来」。开发自己测了几台设备，确实能感觉到，但说不出慢在哪：冷启动的时间不稳定，有时快有时慢，重启手机之后第一次特别慢。

第一轮怀疑是启动页太重，把启动图从两兆压到两百 K，没变化。第二轮怀疑是初始化逻辑太多，砍掉两个网络请求，还是没变化。第三轮怀疑是设备问题，换了几台不同品牌的手机，都慢。

转折点是有人提出「把包解开，看看里面的文件偏移」。一看就发现了：这个应用里有几十个未压缩的图片和两个原生库，它们的偏移几乎没有一个是 4 的倍数。也就是说，这个包从来没对齐过。

为什么会没对齐？因为出包的流程里，回编之后直接签名了，对齐这一步被漏掉了——不是没跑，是跑在签名之后，等于没跑。这个错误在这个团队里存在了很久，只是以前的应用资源少，感觉不到。

重新按正确顺序出包之后，冷启动时间从「能感觉到」降到「感觉不到」，同一台设备上前后差了三百多毫秒。内存占用也降了两成。

这个案例的教训不是「要对齐」，而是「性能问题不一定是代码问题」。当所有代码层面的优化都不见效的时候，值得往包的结构上看一眼——那里有些东西，代码改不动。

十二、案例二：先签名后对齐，整包失效

第二个案例更短，但更典型。

有人在手工出包的时候，为了让「签名之后包能小一点」，把顺序改成了先签名、再对齐、最后再签一次名。逻辑听起来没毛病：对齐会让包变大，那就对齐完再签一次，覆盖掉之前的签名。

结果装不上。提示是「解析包时出现问题」，连签名无效都没到，直接是包读不出来。

原因是第二次签名时，工具需要在中央目录之前插入签名块。但对齐刚刚在文件里插过填充，中央目录的位置已经变了，而文件末尾的目录结束记录还没来得及更新——或者说，第二次签名的工具读到的是一份「自认为正确」的布局，写出来的却是对不上的。

正确的做法只有一条：对齐一次，签名一次。不要试图通过「多签一次」来修补顺序错误，因为每一次签名都在改变布局，而布局是签名自己的输入。这是一个自我指涉的循环，绕不出来。

如果已经做错了，补救很简单：从回编的产物重新走一遍，别在坏掉的包上修。这也是「每一步都留一个能装的包」这条纪律的价值——你有干净的起点可以回去。

十三、这一步在工具里是怎么被接走的

手工做对齐，最大的问题是「记不住」：要记参数、要记顺序、要记得检查。而这三件事都是可以交给工具的。

安卓修改大师智改工坊把出包做成了一条固定的链路：回编出内容、对齐定布局、签名锁结果、校验确认。四步按死顺序连着跑，中间没有让人选择顺序的余地，所以「先签名后对齐」这种错误在流程上就不可能发生。

更难的是四步各自的结果要能看见。因为对齐失败可能是静默的——参数写错、文件被占用、先签后对，都不一定报错。所以工具在每一步之后都留了一个结果，四步跑完你能看到哪一步过了、哪一步没过，而不是只拿到一个「出包完成」的笼统提示。

这一步对新手最实际的价值，是不需要知道 4 是什么意思。你可以完全不懂页对齐，只要点出包，得到的东西就是对的了。而当你哪天想懂的时候，去看那四步的结果，它把每一步做了什么摆在明面上。

十四、实例一：换掉启动图之后，反而变快了

这是一个「改包之后性能变好」的例子，反过来印证了对齐的作用。

一个客户的应用，启动页是一张很大的欢迎图。原包里这张图放在一个高密度目录下，体积两兆多，而且是未压缩存的。客户想换一张更符合新品牌的图。

以前的做法是：解包、找到这张图、按同尺寸做一张新的塞进去、回编、签名、装机。做完了，能开，图也换了。但用户反馈「好像快了一点」。

为什么快了？因为新图的体积小了一半，未压缩文件变小，映射的数据量变少，启动时少读了 1M。同时，回编过程重新写了一遍文件布局，顺手让偏移变得更规整——虽然没刻意对齐，但比原来的包好。

现在用工具做，流程是：导入、替换那张图、出包。四步自动跑完，对齐是其中固定的一环。结果不只是「图换了」，而是「图换了、布局也规整了」。同样一张图，出来的包比手工做的更小更快。

这个例子的价值在于：改包不一定是「加东西」，也可以是「顺手把包整理好」。每次重新出包，都是给这个包一次重新排布的机会。用得对，包会越改越干净；用得不对，包会越改越乱。

十五、实例二：加了两个原生库之后，启动慢了一倍

反过来，这是一个「改包之后变慢」的例子。

一个做设备控制的应用，需要加两个原生库来支持一种新的硬件。原包里只有一个架构的库，新加的两个把四个架构都补齐了。改完之后功能正常，但启动明显变慢，低端设备上要等两秒。

排查的思路是：先看包大了多少。从 18M 变成 46M，主要增长在原生库。再看这些库是怎么存的——未压缩。这就对上号了：未压缩的大文件在启动时可能被映射，而映射的效率取决于对齐。

一查偏移，果然没对齐。因为这个团队是用脚本手工出包的，脚本里漏了这一步。补上之后，启动从两秒降到一秒二，还是比原来慢——因为库确实变大了，多出来的读取量省不掉。但「从两秒到一秒二」这一段，是完全靠对齐拿回来的。

进一步的优化是：只保留目标设备真正需要的架构，把用不上的删掉。包从 46M 降到 24M，启动回到一秒以内。这一步跟对齐无关，但它说明一件事——对齐是「把已有的东西用得更省」，删减是「减少要用的东西」，两件事不冲突，都要做。

这个案例的顺序值得记住：先补对齐（不改内容，只改布局，零风险），再考虑删减（改内容，有风险）。很多人顺序反了，先删东西，删出问题来，再回头查对齐，两件事混在一起，谁也说不清是哪一步起的作用。

十六、把对齐写进流程：五个检查点

如果要把这件事固化成习惯，只需要五个检查点。

这五个点里，第二个最容易被跳过，因为它需要你「记得上一次的体积」。一个小技巧：把每次产物的体积记在版本号旁边。比如「3.2.3 / 24.6M」，下次出包时对一眼，变大变小都有解释。

十七、手机和平板上改包，同样绕不开这一步

有人会问：在手机上改包，还要管对齐吗？答案是：你不用管，但你需要知道它存在。

因为手机上改包，走的是同一条出包链路——回编、对齐、签名、校验，一步都不少。区别只在于「谁在跑」。你点一下按钮，四步在后台按顺序跑完，结果回到界面上。

这意味着两件事。第一，手机上出的包，质量跟电脑上出的一样——不存在「手机上出的包是简化版」这种说法。第二，如果手机上出的包出了问题，排查方向跟电脑上完全一致：先看四步的结果，再看顺序，再看文件。

为什么这件事值得说？因为很多人对「在手机上改包」有一个误解，觉得它是「轻量版」，做出来的东西不如电脑。实际上它是同一条流水线的另一个入口，产物是同一个标准。理解这一点，你才敢在客户面前掏出手机改包，而不是觉得「先应付一下，回去再用电脑好好做」。

十八、边界：什么时候对齐帮不上忙

说清楚它的边界，比夸大它的作用更可信。有三种情况，对齐帮不上忙。

第一种：包里的文件几乎全是压缩存的。压缩文件本来就要解压，对齐它对映射没有意义。这类包对齐前后，性能差别在你测不出来的量级。

第二种：瓶颈不在读取，而在初始化。有些应用启动慢，是因为启动时要解析一大堆配置、建一堆对象、等几个网络请求。这些跟包的结构无关，对齐再多也没用。判断方法：看启动的耗时是不是集中在「首帧之前」的某一段，而不是均匀分布。

第三种：设备本身很慢。在内存只有 2G、存储是慢速闪存的设备上，对齐带来的收益会被其他瓶颈淹没。这不是说不用对齐，而是说不要指望它解决所有问题。

把边界说清楚之后，对齐的定位就明确了：它是一个几乎零成本、几乎零风险的优化。你不需要为它做取舍，只需要保证它真的跑了。它不会让一个慢应用变快，但它能让一个本该快的应用不变慢。

十九、五个常见误解

这一节列的都是在实际交流里反复听到的说法，每一条都对应一个具体的误解。

误解一：对齐是压缩，能让包变小

正好相反。对齐会插入填充字节，所以对齐之后的包一定比对齐之前略大。那些「对齐之后包小了几兆」的案例，实际变小的是别的东西——比如回编时去掉了冗余资源，或者换掉了压缩率低的老图。对齐本身只增不减，只是增加的量很小。

误解二：小包不用对齐

小包对齐的收益确实小，但「收益小」和「不用做」是两件事。因为对齐的成本几乎是零——它在出包流程里是一步固定的动作，不做也省不下时间。而且小包长大了之后，如果流程里没有这一步，你也不会临时想起来补。所以正确的做法是「一律对齐」，而不是「按大小决定」。

误解三：对齐一次，以后都对齐了

对齐是对「某一次产物」做的，不是对「这个项目」做的。你每次重新回编，出来的都是一个新文件，布局是新的，需要重新对齐。这也是为什么它必须是出包流程里的一步，而不能是「开工时做一次」的动作。

误解四：签名之后再对齐，只要重新签一次就行

前面案例二讲过，这条路走不通。因为签名会读布局、写布局，对齐会改布局，两者互相干扰。第二次签名时读到的布局和文件实际布局不一致，出来的产物在结构上就是坏的。这不是「多签几次能修好」的问题，是「顺序错了就无法挽回」的问题。

误解五：对齐是安卓特有的东西

不是。任何用 zip 作为容器、并且需要「不解压直接读其中某个文件」的格式，都有类似的对齐需求。安卓只是把它做成了出包流程里的一个标准步骤，并且给了专门的工具。理解这一点，你在遇到其他打包格式时，会更容易想明白「为什么要留空隙」。

我以前觉得对齐是玄学，因为看不到它做了什么。后来想明白了：它做的就是把东西摆整齐。摆整齐这件事，你说不出它具体带来了什么，但东西乱了你就知道难受。
—— —— 老吴 · 客户端开发

二十、给新手的五条

如果只想记住五句话，记这五句就够用。

二十一、把它和另外三步放在一起看

单独看对齐，容易觉得它是个孤立的小步骤。放在四步里看，它的位置和作用就清楚了。

回编决定了「包里有什么」，对齐决定了「这些东西摆在哪个位置」，签名决定了「谁为这个包担保」，校验决定了「这个担保是不是真的」。四步里，只有对齐是纯布局层面的，它不改内容、不改身份，只改排布。

这个定位带来一个好处：对齐是四步里唯一可以放心重复做的一步。回编重复做会改内容，签名重复做会改布局，校验重复做只是再看一遍；而对齐重复做，结果是一样的——它只是把已经整齐的东西再确认一遍。所以当你怀疑「这一步到底跑了没有」，最安全的确认方式就是再跑一次。

还有一个组合关系值得注意：对齐和压缩是一对。压缩决定了哪些文件「需要被解压」，对齐决定了剩下的那些「能不能被直接映射」。两者配合得好，包又小又快；只做其中一个，效果打折。所以看到「压缩率调得很高但启动很慢」的包，就该怀疑对齐；看到「包很大但启动很快」的包，通常是没怎么压缩但对齐做得很好。

二十二、一个十分钟的动手练习

如果想把这篇的内容变成自己的，有一个很便宜的练习：找一个你手上现成的 APK，用检查模式跑一次对齐验证，看它有没有对齐。

如果结果是通过的，那你至少确认了「你现在的流程是对的」。这时候可以再做一步：把包解开，找几个体积最大的文件，看它们的存法是不压缩还是压缩。如果最大的那几个都是压缩的，那说明这个应用本来就没打算靠映射省时间，对齐对它的收益确实有限——这也是一个有用的结论。

如果结果是没通过，那就更有价值了。先去查它是什么时候被弄坏的：是回编之后就歪了，还是中间某一步覆盖了它。前者说明工具或参数有问题，后者说明顺序有问题。这两种原因的修法完全不同，而检查结果能直接把范围缩小一半。

这个练习之所以值得做，是因为它把「一个抽象的概念」变成了「一个具体的是非判断」。你对着一行输出，立刻知道自己站在这条线的哪一边。技术这件事，很多时候缺的不是理解，是一次能自己验证的机会。

顺便说一句：这类「检查一条输出就知道对错」的动作，值得在你的流程里多攒几个。签名有没有真的签上、版本号是不是这一版、图标的尺寸和目录对不对，都可以这样验。攒够五六个，你就有了一个不依赖记忆的质检清单——而清单比经验可靠，因为经验在累的时候会失灵，清单不会。

技术上的细节，大多是这样被一点点补齐的：不是一次想明白，而是每次遇到问题，回来补一格。补到后来你会发现，真正让你少出错的，不是某个绝招，是这些格子里早就写好的答案。

二十三、为什么这件事值得单独写一篇

写到这里，可能有人会问：一个 4 字节的对齐，值得写这么长吗？

值得，因为它是一个典型样本：收益看不见、错误也看不见、但影响一直在。这类事情在每个技术领域里都有，而人对它们的处理方式，往往决定了水平高低。新手只处理「看得见的问题」，老手会主动检查「看不见的地方」。

对齐也是「工具价值」最容易被感受到的地方。你手工做，要记参数、记顺序、记检查；交给工具，它固定成流水线里的一环，你想犯错都难。这种「把容易忘的事变成不会忘的事」的能力，比「多一个功能」有价值得多。

安卓修改大师智改工坊把出包做成四步固定链路，对齐是其中不可跳过的一环：回编、对齐、签名、校验依次跑完，每一步的结果都摆出来。你不用记住 4 是什么意思，只要点出包，拿到的东西就是对的。而当你哪天想弄明白，那四步的结果就是最好的说明书。

改包这件事，说到底是在跟一堆细节打交道。只需说话，就能让应用变成你想要的样子——这句话成立的前提，是那些你不必说出口的细节，已经被正确处理了。对齐就是其中一个。官网 www.apkeditor.cn，产品介绍页 https://www.apkeditor.cn/ai-version.aspx，想看看这条链路长什么样，可以去翻一翻。

最后留一句给还在手工出包的人：如果你从来没检查过对齐，今天就花十分钟查一次。它可能什么都不改变，也可能让你发现一个存在了很久、一直被归因到别处的问题。而后者，往往就是那十分钟最值钱的地方。

对齐这件事，四个字概括：把东西摆整齐。它不改内容、不改身份，只改文件在包里的位置，让不压缩的资源能被直接映射。收益看不见，错误也看不见，所以最容易被跳过。但它是四步出包里唯一零成本、零风险的一步——不用为它做取舍，只需要保证它真的跑了，而且跑在签名之前。

www.apkeditor.cn

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

把东西摆整齐，是看不见的基本功。

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