Android-模块化架构研究
1 Aug 2018
本项目研究功能模块化APP架构，基于Android系统。
代码下载地址：https://github.com/pulque/MultModuleDemo
主要内容
1.开发痛点
2.设计理念
3.应用环境
4.原理
5.需要注意
6.存在的疑问
正文
1. 开发痛点
传统开发理念是判断权限值来判定功能模块是否可以使用，所有用到用不到的模块都打包在APP中，并且启动应用的时候，初始化了很多不必要的功能模块。
这样就导致APP安装包很大，运行慢，内存占用高。
私有化定制功能的时候，一般会复制代码单独修改维护，或者在代码中添加标识，判断定制修改。
增加代码逻辑复杂性，后期维护成本高，升级困难。
编写新APP软件的时候，老APP软件的功能只能通过拷贝代码来实现功能的迁移。
迁移容易出错，同时维护多套相同代码，更新相同功能困难。
2. 设计理念
针对功能模块化，使之在最大程度上进行复用。类似七巧板，每一个板块想象成一个功能模块，板块拼凑成的图案即为APP。
实际上就是将功能的复用提高到应用层级上来整合APP。
3. 应用环境
一家软件公司可能有好几款应用软件，一般都会有相同的登录验证方式，相同的广告展示等等。资源管理型软件，针对不同的角色，会有不同的功能模块显示。
4. 原理
基本原理：
每个功能模块设计为Module（模型），作为项目中的Library（库）。而APP的Module只是集成各个功能模块，从而形成可编译的应用软件。
项目举例说明：
以通用的进销存软件为例，进行详细说明。以下是功能设计图：
从上图可以看出，不同的功能模块通过组合，可以形成不同的APP。
以下是项目代码的截图：
以下是编译安装后APP的截图：
这样新开发APP就比较简单了，只要添加依赖，就可以显示不同的功能。
当然权限还是需要标识来控制。
5. 需要注意
> 各个Module中的包名不能相同。
> XML资源名字不能相同。
> 通过判断Activity名字来实现打开模块或指定页面。
详细参考LoginActivity类的attemptLogin方法
> 各个Module中的Activity不能设置为启动页，
否则安装后会显示多个相同APP。
6. 存在的疑问
> 是不是功能拆分的太细了？
> 随着需求的不断变化，Module会不会很多？
> 依赖升级build.gradle会不会很多，难以维护？
> 交叉依赖越来越多，会不会影响APP编译？
> 更改一个多APP引用的Module，能保证所有APP都能正常使用？
> 经常在各个Module中穿插编写代码，会不会对开发效率产生影响？