一、插件化、组件化下Android产品研发-总纲

---

插件化、组件化下Android产品研发-总纲
[插件化、组件化下Android产品研发-面向服务编程]
[插件化、组件化下Android产品研发-框架自由扩展服务管理]
[插件化、组件化下Android产品研发-Bundle应用管理]
[插件化、组件化下Android产品研发-框架BroadcastReceiver管理]
[插件化、组件化下Android产品研发-框架管道任务管理]
[插件化、组件化下Android产品研发-业务模块接口化]
[插件化、组件化下Android产品研发-页面路由]
[插件化、组件化下Android产品研发-H5容器]
[插件化、组件化下Android产品研发-模块通信]

---

引言

手机淘宝android客户端容器化框架Atlas已正式开源，其以OSGI容器化思想实现了大规模团队协作，并行开发、快速迭代和动态部署。框架原理图如下：

Atlas容器框架

这里抛砖引玉，不具体讲解Atlas的原理以及具体使用，详情请参考Atlas官方文档。本系列博客基于Atlas容器框架，进行Bundle应用层面的扩展，实现插件化、组件化下Android产品研发，使其充分发挥出Atlas带给我们的能力，更好的为大规模团队协同开发服务。框架图如下：

插件化下Android产品研发架构

基于本人的工作经历以及所获得的Android项目开发经验，逐步形成了插件化、组件化下Android产品研发的架构的思想模型，这里不对Android具体业务以及服务开发做深入研究，而是从技术架构上实现app开发的协同化、实现上的并行开发。并且对于架构图中的各项服务，原则上在脱离插件化框架的情况下也是可以被使用的。此架构图在虽在脑中良久，奈何实践起来难，除了工作繁忙之外，也有自己的懒惰，在此先列出提纲，步步为营，在接下来的一段时间内将其实践出来，再次用博客的形式进行记录，愿敦促自己，如果能对同行同学有所帮助更是一件美事！！

底部架构层

行业上开源的插件化的方案已经不少，从网上找了一些插件化方案对比的图，如下：

插件化方案对比

本博客是基于手淘的Atlas插件化方案，在阿里系内部多个大型App上进行了应用，功能强大，具有动态部署、热修复的能力。所以架构的底层采用Atlas。

基础框架层

该层提供了框架最重要的基础框架服务，依赖于此，形成业务服务化、接口化，并对外开放，并对框架级的Bundle、广播、管道任务以及其他基础服务提供输出能力。

服务层

服务层的分层目的是分离出业务依赖的，但与业务相关的服务作为基础服务，对所有的业务Bundle提供接口服务，统一各个Bundle应用业务的网络库、图片库等基础服务。

业务层

业务层即Bundle应用业务层，该层具有业务需求变化快，需要快速迭代，其不用操心网络库、图片库等基础服务，直接引入服务层的服务即可，专注于具体业务的开发，做到app整体安装包尽可能小，而且做到性能佳。

主业务入口

提供app进入的唯一入口，其功能是当app启动时，做一些框架服务初始化的工作。

其他

因为服务以及业务都是已独立bundle的形式存在，做到了完全解耦，所以完全可以独立插件提供给第三方app，尤其适合于大厂的多个app，因不同app中有相同的业务，没采用这种插件化方案之前，需要该业务团队抽调人手分别维护不同app中的归属自己的业务模块，这在业务需求变更、升级等变化时会给业务团队带来巨大的麻烦，一个业务，维护两份以上代码，修改bug以及迭代依赖简直就是噩梦，但是采取此种方案后，只需维护一份代码就可以了，一份bundle可以实现在不同app中一起升级，简单高效。

结束

说了这么多，虽然豪情万丈，犹如胸中熊兵百万，良将千员，但目前为止还是纸上谈兵阶段。开了这个博客单元也是希望给自己一个督促，在完成自己日常工作的基础上，尽可能的将心中的指点江山落到实处，真实做到挥斥方遒，提升自己，服务他人。谨记！