手机淘宝Android客户端架构

eeec4 4年前

  手机淘宝Android客户端有几百人开发,十几个团队。如果整个Android客户端是一个工程,那十几个团队每个人上午上班第一件事情估计就是合代码,运气不好,一天都在合代码,而且只要有一个人提交的代码编译不过,所有人都会被堵塞在那里,所以单个工程是不可能的事情。

    只要是包含了很多业务的客户端,都会面临这个问题,各个业务代码量越来越多,新需求又源源不断的来,业务团队之间要是有直接依赖,那被依赖最多的团队成员,在改代码的时候都是战战兢兢的,生怕自己的改动导致其他业务奔溃。最终交付的时候,总会被一个业务线的人卡住,导致没法及时交付这个版本。而且随着代码量越来越多,方法数超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出来,大部分情况是然并卵,因为大部分公司的应用都没有这么复杂的业务。