饿了么Android插件化开发实践(一)

痛点

随着饿了么APP业务急速的发展,项目组内部各个模块的业务越来越多,同时其他项目组也有在主APP集成的需求,现行的Single Code Repo越来越不适合项目的推进。

团队内部需求

目前饿了么APP是基于业务分成Shopping、Booking、Order、Account、Marketing和Application六个模块,每个模块由相关的开发人员进行负责。APP方法数早就超过了65k,最新发布的5.9.0版本方法数已经到达了85k。

  1. 业务量比较复杂,六个模块一共占去了30k

  2. 为了避免开发中出现大量的boilerplate code,写了很多工具,在compile time auto generate code

  3. 业务之外,项目中也依赖了很多团队各位小伙伴写的给力库,比如图片解析、HotFix、ORM

  4. 同时团队对开源也比较活跃,使用了一些很赞的library,如retrofit、RxJava、OkHttp

  5. 再加上庞大的Android Support Library

方法数越来越大,codebase也越来越庞大。快速的发版周期,codebase只会越来越庞大,这时来自团队内部推动模块化开发的声音逐渐起来。

  1. 不管是开发new feature,还是对代码的重构,引入bug的风险也越来越大

  2. 虽然基于业务分包,代码逻辑还算比较清晰,但是各个模块的耦合也越来越重

  3. 在同一repo下开发,一个模块的重构很可能会影响到其他模块,导致小伙伴对refactor code 比较谨慎,不利于个人能力的发挥,也不利于项目的发展,这当然不是我们愿意看到的

公司内部需求

使用过饿了么APP的同学都知道,饿了么首页有很多运营位,这些运营位有一些是被其他事业部占去的,比如早餐。这些坑位的产品同学也希望他们的页面如丝滑般流畅,对用户体验比较有要求,他们不满足于H5,也不满足于react-native。这种情况下,只能上native code了,但是不同项目组之间有着不同的研发周期,使得我们一起维护一个codebase的想法不大现实。

Plugin Dev 规划

针对插件化开发的规划,定义了几点需求。

  1. 基于模块进行拆分,把一个不易维护的大APP变成多个精简的小APP

  2. 满足公司内部的需求,为其他团队提供插件支持,最好可以直接把一个独立的APK load起来

  3. 可随意加载、卸载插件APP

  4. 插件APP可免升级更新

  5. 满足不同的研发周期,可降级展示插件APP,如 H5/native随意切换显示

  6. 隔离插件的crash

  7. 安全性校验,防止插件被劫持

小结

面对上面的业务场景,我们就理所当然的走上了插件化的不归路了。所幸2015年国内Android圈迎来了一波开源小高潮,有一些比较成熟的案例和library可供参考,我们饿了么在这条路上不是一个人在奋斗。业务达到一定量级瓶颈,codebase越来越难以维护的场景下,插件化开发是目前比较靠谱的一条路,很多的同学都已经在这路上走了很远,比如携程、360。

来自wequick的Small、还有CtripMobile的DynamicAPK都是通过在同一进程中加载,重心放在在资源的冲突解决上;而来自Qihoo360的DroidPlugin的实现则独树一帜,为了避免处理复杂的资源问题,直接一个Plugin对应一个独立的process,构建了一个沙箱,一个运行环境。

基于不同的实现方式,大致可以把插件化开发的方向分成两个

  1. Host & Plugin in a single process

  2. create another process when load a plugin

这是一个开篇文章,后面会针对这两种不同的实现方式分别做详细的分析和解读。有兴趣的同学可以在评论区留言