Atlas动态化
在一个容器框架内，组件化和动态化是相辅相成的，组件只是解决了解耦的问题，但我们如果想要随时发包，就必须让容器框架具备动态化能力。我们在完成了Atlas的组件化之后，做了动态化的支持。动态化的好处一个是包的大小缩减，我们可以将一些包在运行后下载到应用中，另一个是具备动态发版和修复能力。
增量动态化方案
Atlas提供了动态部署的能力，主要目标是动态业务发布，以及问题修复。它基于手淘自研差量算法，主Bundle基于ClassLoader机制，业务Bundle基于差量merge，支持全业务类型。
另外，Atlas也支持Andfix作为插件使用，目标是快速故障修复，它的原理基于Native hook，主要做方法的修改，在实际中可以两个一起用。在工程构建期适配之后，可以做到一套代码两套方案通用。
自研动态部署功能实现原理，首先，对于Dex Patch的生成，我们通过修改Dex的字节码实现，将Dex文件转为Smali，对其中的ClassDef和ClassDataMethod结构体进行分析，可以实现删除、新增、修改类，然后通过Diff处理得到差量文件，再通过Merge处理即生成补丁。
其次是整个资源Patch的生成，分为两块，一个是业务Bundle，本来是一个不断加载的过程，它实现起来会比较简单，通过Md5 diff/BSDiff即可得到。对于主Bundle，因为安卓本身有一个限制，所有的资源必须得在base包里，新增一个资源是不生效的。所以一个做法是在打包的时候预留很多空资源。另外更新已有的资源则通过资源覆盖来完成。
最后，如果新加业务的话，会新加Activity，我们的做法首先在Manifest预埋一个StubActivity，然后在Instrumentation.execStartActivity()阶段进行替换，同时配合Intent setFlag模拟Activity launch mode并继续startActivity，接着System_server进程进行处理，更新ActivityStack，创建binder，并通知ActivityThread进行实例创建，最后我们在ActivityThread的handler里面进行拦截，更新ActivityInfo等信息，创建目标Activity。
另外在工程实践上，因为补丁的生成会涉及到Dex和资源的基线，我们会在部署的时候，每次发布APK包同步发布AP(基线包)到Maven，AP基线包里是所有影响基线的文件，第一是安卓APK，第二是Mapping.txt，最后是Dependency.txt，这样的话整个构建的速度会非常的快。
所以我们这种方式，版本的升级是不同的方式。比如今天手淘的详情要更新，会发布版本，这个版本可能不是到应用市场的版本，而是一个Patch包。业务版本的动态部署，我们是同步的，5.3.0到5.3.1到5.3.2，这样一个好处是只要容器版本没有升级，只要有需求，patch就可以一直升级，而且是无感知的差量升级。
周边优化点
最后来讲讲我们的周边优化点，为什么到今天才说要开源，做的过程当中还是遇到了不少问题。
第一点是Bundle的重复资源合并。因为我们发现，因为宿主问题，必然而然会出现冲突的问题，包括图片资源，我们会放到整个宿主类目中去。
第二是Bundle的依赖校验，以前是代码的话，是编译过的，但因为今天是二进制，这个问题会遗留到现场去，所以会看看API是否会影响Bundle。
第三是类库“瘦身”，因为手淘依赖的各种中间件类库太多了，导致手淘本身很臃肿，方法数很大;所以打包的时候对类库有一个裁剪的过程，优化方法数。
第四是依赖导致的，依赖查询库。
第五是做Dex File等，进行混淆Mapping。
最后是开源准备中，我们在工程期、运行期都会去做开源，并且将机制通过云服务的方式提供出来，阿里百川会提供Atlas的研发支撑能力，包括快捷的生成，发布，回滚，监控等能力。