apk合包，apk合并。附工具

Android应用合并：实现apk合并，将两个不同功能的单独apk，合并成一个apk。

0.序

在市面上发现了一款牛逼的Android应用，里面能加载展示不同的其他Android应用。两个应用的功能完全不一样，分别就是两个不同的包。

1.如何实现apk合并

那他是如何实现多个apk合并到一个apk里的呢。

1.1.方案1-虚拟化Android引擎

这个方案是比较牛逼的方案。

原理：就是一个架子，壳。hook和虚拟化了apk加载运行的Android环境。

用户启动真实apk时，会被这个壳拦截，然后包装成这个壳在展示请求，清单等注册时也只用注册这个壳的相关信息。

你可以把这个壳理解为虚拟的Android系统，在里面安装运行apk

1.1.1.优点

开发apk时，基本上不用太做注意和更改，就正常开发apk就行，前期开发适配需要的开发量很少。

可以动态下载apk，动态按需加载apk。

1.1.2 缺点

这个方案实在是太牛逼，导致技术门槛高，一般开发者只能用，自己开发没戏。有公司在搞这个，技术支持费用肯定是免不了的。

性能有影响，加载启动apk速度慢，因为每次启动一个apk，都需要先启动一个虚拟的Android系统，这个速度比较慢。

适配性有一定的问题，毕竟是虚拟Android系统，hook拦截真实系统的消息，这种操作相当危险，这种方案的代码有的已经被标记为病毒，很难改动。

有些权限和功能，在有的设备和环境会无法运行，这个兼容程度取决于提供这个技术的开发者适配的能力。

如果自己公司想确保应用的兼容性和稳定性，不建议这种方案。

1.2.方案2-插件化

这个方案市面上很多公司都在用。大公司基本都是用的这个。
如果应用很大，模块很多，功能很多，就会实现插件化，其他不常用和非基础的模块都是后面下载动态加载的。

原理：设计一个基础通用框架协议，所有其他应用或模块都遵循使用这个框架协议，相当于套了一层壳。

运行时，是这个通用框架协议的壳与系统交互，里面的应用或模块不会直接与系统交互。

1.2.1. 优点

这个方案很稳定，适配性好，毕竟所有代码都是自己开发的，维护也比较方便。
可以动态下载apk，动态按需加载apk。

1.2.2 缺点

前期开发成本很大，每个应用都需要遵循通用模块协议开发，
如果已经开发完的apk，想合并，那重写适配的成本很高很高。

1.3. 方案3-资源代码合并

这个方案是我目前使用的方案。市面上也有人在自行研究，大多是因为觉得方案1太贵，适配不太好，方案2开发量太大。

原理：将多个apk的资源代码so直接加密保存，清单进行合并，不同包注册为不同进程，启动对应进程时释放加载对应的资源代码so。

运行时，对应apk是一个单独的进程，资源代码等互不影响。

优缺点介于上述两种方案之间。

1.3.1. 优点

已开发完的apk基本不用改动就能合并。开发适配工作量不大。

相对方案一来说，兼容和性能较好，基本和方案二持平。

1.3.2 缺点

实现 对apk处理 资源代码so 动态加载比较麻烦，原理就是市面上的加固方案。有一定的技术门槛。

合包时有一定的困难，毕竟需要将多个独立的apk合并在一起，会有很多冲突，有些自动解决后会有一定的问题，有些还是需要对原包做一定改动进行适配。

2.工具介绍

我最开始是处于应用安全的目的去开发的工具，实现了apk加固的功能。
后面看见这种对应用合并的功能，觉得很牛逼，于是基于apk加固的实现上，实现了apk合并。

详见工具apk加固合并工具

3.尾

可能你有这方面的研究兴趣和需求，可以使用工具合并研究一下。欢迎技术交流讨论。