Android开发之移动端项目架构演化之路从模块化，组件化再到插件化

项目架构

• 前言
• 单工程架构
• 模块化
• 组件化
• 插件化
• 总结

其实在移动端谈架构，可能没有在Web端谈架构更合适，因为大多数情况下移动端的项目不会很大；那为什么还要谈下呢？毕竟麻雀再小也是五脏俱全嘛

通过合适的架构，能让项目的代码更加优美，结构更加清晰，编译效率更高，维护更加简单，人员更替导致的开发成本更低

今天不从狭义上谈项目架构，比如MVC，MVP，MVVM等；我们从广义上来谈下移动架构的思想（因为这些架构内部也会使用MVC，MVP等架构进行开发）如前几年的模块化，去年很火热的组件化，巨无霸APP的插件化等

在早些年从事Android开发或者说移动开发的时候，没有太多架构的概念，基本上属于抡起袖子就是干的情况

比如：公司来了新项目，不管三七二十一，在Eclipse上new一个工程，然后根据业务进行分包，最后就是在不同的包下根据业务需求码代码；绝大多数人都是这么过来的，对吧，项目永远是单工程的模式

这种开发模式，在项目早期是没有问题的，因为很少有哪个项目在一开始就是非常庞大的；同时开发者的上手难度也低，基本上当天新建工程当天就能投入开发了，另外这种模式不复杂，多个业务之间的调用也很方便，开发人员不需要太费脑子在项目架构带来的遗留问题上，只要写代码就行了

当经过N个产品经理的蹂躏，N个开发人员的参与，N伦迭代后，我们的项目可能已经变得很大了，如果再使用这种项目架构继续开发，必然存在大量的代码冗余（你写一份他也写同样的一份代码），业务耦合（导致单元测试几乎无法进行），大量重复的资源文件（每个人都提交自己的图标），项目变得越来越臃肿（有时候你只要改一个小地方，但是却要编译整个项目。。。），我相信很多哥们在某个类里增加代码的时候，肯定是只增加代码，不会去删除或者修改原有代码，即使你看到了那些代码没人用到；所有的开发人员都在同一个工程下开发，也会让多人协同开发的成本上升，代码提交-冲突-合并-更新循环往复

单工程模型如图：

所有的代码，很可能十来万行代码都是在一个包下的多个分包中，业务之间相互调用，耦合十分严重；现在开发节奏非常快，改一个地方都有可能牵一发而动全身，到这时候我们的项目架构就需要升级了

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality

简单说，模块化就是将项目按照功能划分，分成多个独立的模块，这样每个模块之间只有跟自己功能相关的代码，比如登录功能，网络请求功能，数据库操作功能，图片处理功能，多媒体功能等都可以拆分成一个个模块

Android Studio出来后多了一个Modules的概念，其实JetBrains家族的很多开发工具都有这个概念（比如Intellij IDEA，RubyMine，WebStorm，PyCharm，PhpStorm等），一个Project可以有多个Modules，每个Modules有两个格式：application，library；这样每个Modules就是一个小的项目，在AS中我们称为模块；一个工程通常包含有一个application模块和N个library模块

我们在原始架构中，通常会将一些公共功能代码放到一个包下，现在你可以在主工程下新建多个library格式的Modules，然后使application模块依赖这些Modules；这样项目层次更加清晰，模块更加灵活，随意插拔，任意一个应用都可以去依赖这些模块，耦合更低，易于测试

其实模块化和组件化的概念很相似，组件化其实最早是应用于服务端开发的，后来这种思想被互联网公司一推广，在移动端领域火了起来

Component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software

简单说，组件化就是基于重用的目的，将一个大的工程根据关注点的不同拆分成多个独立的组件，降低耦合度

其实这样说还是跟模块化概念有点模糊，因为拆分出来的登录你可以当做一个模块，你也可以当做是一个组件，在AS里都是体现为一个Modules；模块化和组件化的目的是一致的，都是化整为零，将解耦和重用进行到底

那出来组件化又有什么意义呢？其实模块化的粒度更小，侧重于功能重用，组件化粒度大于模块化，侧重于业务解耦

比如微信的四个tab可以划分为四个组件，我们就新建四个Modules，每个开发者只需要关心自己的模块，每个组件中用到的相同功能可以抽出为模块，比如网络请求模块，四个组件都要用到

在AS里新建一个Modules，我们在口语上都称为是模块，但是它具体干什么用，是作为功能模块还是作为业务组件，那就看具体需求了

当作为组件的时候，每个模块（此模块非模块化的模块，确实有点拗口）都可以作为一个单独的APP，这样业务更加专一，开发只需要负责自己的模块，不会与他人产生冲突，在修改和调试的时候更加方便，一个组件小版本进行升级,如果对外提供的接口没有发生任何变化,其他组件完全不需要再进行测试，每个组件有自己单独的版本，可以独立编译，测试，打包，部署，最后一个完整的工程由多个组件合成打包

产品组件化后能够实现完整意义上的按需求进行产品配置和销售，用户可以选择使用哪些组件（也就是选择哪些业务），组件之间可以灵活的整合；在单工程架构和模块化架构中，很难做到这点

组件化架构图如下

所有的组件在Android Studio里都处于同一个project下，在开发过程中，每个组件都是作为一个单独的APP，可以独立开发与测试；当合到应用外壳工程打包成一个总的应用进行发布的时候又是作为依赖库存在的；应用外壳工程也是一个APP，只不过它不负责具体业务逻辑，只需组合众多组件即可

这种架构下，每个业务高度解耦，多个业务相互跳转通信通过路由和消息订阅发布机制进行，这样不管其中的哪个组件挂了或者被拿掉了，其它组件都能正常执行

实现组件化架构，相应的成本也会增加，但是它带来的好处是值得这么做的

• 各业务间不耦合，单独开发测试，加快迭代速度


• 功能组件独立出来供各业务调用，避免重复开发，降低工作量


• 业务可以灵活组装，可加可减，充分适应多变的市场需求


• 因为每个业务组件可以作为单独的APP，所以可以独立编译测试，提高开发效率


• 代码权限可以控制的更小，每个人可以只拥有自己负责的业务模块的权限，提高项目安全性

组件化其实不难，复杂的是在项目配置上，需要充分了解Gradle机制和Groovy语言开发

支付宝和微信相应每个年轻人的手机里都安装了，可是你有奇怪这两个APP里怎么会有这么的功能吗？它们到底是怎么把众多单独的应用集成到里面的呢？它们是怎么做到不需要安装那些应用就可以在一个APP里去使用它们的呢？

实现这些功能的技术就是插件化做到的

插件化技术的核心是动态加载，动态加载可理解为，应用在运行的时候通过加载一些本地不存在的可执行文件实现一些特定的功能

插件化其实跟组件化非常相似，都是将业务独立出来，按需加载，但是它们两有一个核心的区别

组件化不管怎么将业务划分，每个业务都是壳APP的一部分，比如微信有四个tab页，支付宝有5个tab页，它们都将这些tab分成单独的组件进行开发维护

但是插件化分出来的业务是独立于壳APP本身的，不属于应用开发商的软件，比如微信和支付宝内部都集成了滴滴出行的应用，但你不会说滴滴出行是腾讯或者阿里的吧

想要实现插件化需要了解的知识点比较多

• 需要掌握Activity的启动流程，生命周期管理，因为通过dex文件单独加载一个Activity的字节码文件是展示不了的，因为没有生命周期


• 需要掌握反射技术，加载第三方应用的资源需要使用到AssertManager，它的API是隐藏的，只有通过反射构造出实例


• 需要掌握ClassLoader技术，显示第三方应用需要通过类加载技术将Activity的字节码文件加载到虚拟机

这里只列举几个，当然还有更多的

至于真正进行开发的时候选用哪种架构，需要根据实际情况决定，比如这个项目开发团队很小，项目也不复杂，那使用单工程架构也就可以了；只有当项目变得越来越复杂的时候，参与的开发人员越来越多，那你就有必要升级你的项目架构了