插件化技术在安卓sdk开发中实际应用

笔者从 2016 年初就因为公司业务需求转战 android sdk 开发， 应用插件化技术将公司 android sdk 重新翻版。先来说说需求。

由于笔者所在一家创业公司， android sdk 实际运营时间并不长， 处于业务成长阶段， 经常会面对各种需求更改以及运营通道稳定性等个方面的问题。由于种种的不稳定性， 会导致 sdk 可能会经常出现小规模修改的问题， 用户对这种行为当然是非常不满意的了。可以想象，每一次 sdk 更新商务部门的同学要扛着多少用户口水去和用户商谈，而技术部门又要承受到少商务部门同学的白眼。

为了彻底解决这种现状， 从 16 年初我就开始正式介入 android sdk 重新开发这边的工作。 需求 (1) 很明确， 就是要能够做到 一次对接。介绍一下这个需求， 一次对接， 对于正常的 sdk 开发来说是最基本的需求， 因为 sdk 就应该处于长期稳定的状态， 要不然用户不太愿意使用。 可是这对我们公司的现状来说是致命的， 恰恰是最基本的我们保障不了。为了能够留下为数可怜的那些用户们，一定要做些事情。需求 (2) 能够做到及时 升级。 当然这个 升级 的需求就是针对我们自己的现实状况， 产品处于成长期迭代的功能多少都会有。

主要的需求就是这两个。 从技术的角度仔细去分析这两个需求， 其实就是一个需求。 就是做 sdk 的 热更。笔者之前从事的是 cocos2d-x 游戏开发， 对 热更 不可谓不熟。对于移动领域的 app 开发热更技术也都是了解的， 不过都是建立在脚本语言基础上的。 如大家经常提及的 cocos2d-x/u3d lua/js, android/iOS h5等， 这些都有成熟的方案做参考， 而当时摆在我面前的却是翻阅了所有搜索引擎都没找到先例的问题。经过一番苦思冥想之后， 从自己的记忆中提取到了一个片段 - 插件化。

15 年年底的时候， 快放假那段时间翻阅 github, 看到了一个很简明的 android 插件化框架 PluginMgr。果断翻阅了当时能找到的关于 插件化 的所有技术文章， 看懂看不懂的都阅读一边。 最终还是选择了 PluginMgr。 我需要一个只需要支持 android activity 的插件化框架就可以了，另外，在 sdk 中使用也不能体积太大。它能满足我目前的所有需求。 但是缺点却也很明显， 作者当时已经在开发新的插件化框架了， 并没有太多的时间去做维护和更新， 这意味着我自己需要能够把控这个框架，这让我一度很迟疑。 经过一段时间后， 发现自己能够完全掌握所需要的技术栈。于是开始动手， 新版 sdk 框架部分开发大概一周左右，然后另一位同事加入， 帮我开发我们 sdk 业务 apk。

业务 apk 的开发是一个正常的 android 项目， 插件化框架对他开始就是个黑匣子， 他不需要关心。 在后来实际上线的时候， 我提供了一些 宿主 和 插件 交互的 api 给他替换掉以前的一些 api 调用就可以了。 最后索性将这部分封装做的彻底了点， 让他自己去调试自己的 业务 apk, 成功了就可以直接发布。

而我这边需要做的前期工作就是把 PluginMgr 做一些定制化的修改， 并修复一些原本的 bug。 然后就是做动态更新部分的， 这很好做， 完全可以把以前做过的 热更 部分拿过来做相应的改动就好了。 只不过我需要面向的是 更新 apk, 而不是原来的一个加密后的 脚本压缩包。

最终的目标就是长期维护热更和插件化壳， 需要发布新的内容或者是解决非框架bug， 就通过更新业务 apk来解决。 当然，这种技术方案也暴露出一些不好的地方， 如插件化框架对安卓不同机型的兼容问题， 我先后遇到 三星， OPPO 等不同的兼容问题。 还有就是一定要使用足够的测试去保证热更和插件壳的稳定性， 也遇到因为测试没发现的问题而导致的问题。

博客中就不涉及代码了， 主要是阐述一下自己的思路。 如有兴趣或问题， 相关探讨请联系@石头( cn.stonexy@gmail.com )。

PluginMgr https://github.com/houkx/android-pluginmgr

感谢开源领域内的同学们作出的贡献， 能够给我们不断提供技术解决方案。