只要是包含了很多业务的客户端，都会面临这个问题，各个业务代码量越来越多，新需求又源源不断的来，业务团队之间要是有直接依赖，那被依赖最多的团队成员，在改代码的时候都是战战兢兢的，生怕自己的改动导致其他业务奔溃。最终交付的时候，总会被一个业务线的人卡住，导致没法及时交付这个版本。而且随着代码量越来越多，方法数超65535的问题也跟着到来。
对于中型团队，可以参考美团 团队的做法：http://tech.meituan.com/mt-android-auto-split-dex.html， 每个业务是一个单独的工程，打包成aar，每次发版的时候，将aar提交到maven仓库，然后有一个Main工程，包含所有业务的aar，Main工程打包出来的就是apk。而且还通过引入MulitDexApplication，解决了方法数超限的问题。
自然而然的，在美团的基础上面我们可以发展出这样一个架构，业务aar之间不允许依赖，业务如果要对外提供接口，那就提供接口jar包，在自己业务 aar里面去实现。有一个BaseCompat的项目将集成这些接口jar包，还包括一些基础jar包，业务aar可以依赖BaseCompat aar，业务aar之间没有依赖，这样做的好处就是每次发版本的时候不需要等任何一个业务，某个业务没有在截至时间内集成，就直接使用上一个稳定的版本即可。
aar包最终会被打包成一个dex文件（或者多个dex文件，引入MulitDexApplication），但是这个解决不了手机淘宝Android客户端的问题，手机淘宝Android客户端底层有Atlas插件框架。通过将业务包打成awb（其实就是apk包），然后外面包一个壳工程，壳工程中包含所有的业务awb包。在手淘客户端启动的时候，载入各个业务的awb包，当然这个里面包括awb包解析，dex文件优化，res文件加载一系列操作。
Atlas插件框架大概的工作原理就是：当跳转到一个Activity的时候，看看Activity所在的awb包有没有被加载到内存，如果没有，那就load optDex文件，res文件。
还在看老罗的博客：http://blog.csdn.net/Luoshengyang/article/list/1 研究一下apk包加载，Activity启动。应该是可以做一个开源Atlas出来，大部分情况是然并卵，因为大部分公司的应用都没有这么复杂的业务。
