饿了么Android插件化开发实践（一）

发表于  分类: Android  authored by JackCho

痛点

随着饿了么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

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

© copyright 2016-2017 by Eleme Mobilists

eleme-mobile hexo theme by eleme ios team