前言：最近对整体的Android项目进行了初步的整理并设计了一个小小的demo，记录下过程中遇到的一些小问题。此处不进行系统讲解。
重构的目的及解决方案：
- 1.组件化，提高代码的通用性
鉴于Android端本身是支持多端（用户端/门店端/配送端/OA）项目，必须提高代码的利用率，增加、修改代码的成本。
解决方案
抽离基础组件生成单独的sdk，以aar的依赖形式加入项目中。
- 2.单元测试,增加项目的稳定性
鉴于现在的代码本身的耦合度比较严重，很难做到单独在JVM上运行单元测试，为了提高项目本身的稳定性，以及降低上线时的项目bug率，单元测试提上日程。
解决方案
使用标准的mvp-clean架构
- 3.模块化，减少各个模块之间的依赖关系
现有代码各个模块之间的界限不明显，相互之间的关联性严重，有些类的代码本身臃肿，一个类掺杂好几个人的代码，无法确定代码负责人的界限。
解决方案
设立模块负责人的概念，调整gradle的打包方式，将业务拆分为几个模块每个模块需要单独人员进行负责，以gradle plugin的方式区分代码界限，并尽量做到每个模块的自完备性，后期扩展gradle plugin 一键切环境，每个模块可单独为一个project，提升代码编译速度
- 4.符合项目人员分配
鉴于整体项目组人员多，项目少，拆分模块负责人更多的原因是基于现有项目人员结构，确立代码界限。
- 5.扩展性，AOP的数据统计
因为现有代码是直接使用的一些三方库并未封装使用，替换底层代码的成本过高。再有进行数据统计的代码进行侵入度过高
解决方案
增加中间层代码，此中间层提供承接的作用，上层的代码都是依托中间层代码调用基础组件
遇到的问题以及解决方案
- 1.拆分模块，代码隔离
因为本身项目是单一业务线，逻辑简单直接拆分项目为几个module本身增加项目的复杂度，也比利于项目的后期演变。
解决方案
这里使用了P工程的实现，修改了gradle的打包方式，并增加了plugin来check 代码
main:为主工程入口；
p_generate:生成的下沉接口
p_kernel：中间层
p_order/p_my:业务层
- 2.模块之间的通信
模块之间需要进行activity的跳转，类与类之间的参数传递等。这里主要进行了以下的几处调研：
| 方式 | 优点 | 缺点 |
|---|---|---|
| eventbus /otto | 很好的进行模块通信，自由穿梭于线程之间 | 需要提供各个模块之间的通用eventObject，频繁使用会打包类之间的依赖关系，debug查找问题比较难 |
| 广播 | LocalBroadcastManager本地广播 、系统广播可夸进程通信，本身的效率也不低 | 使用bundle传递无法获知发送端的对象类型，匹配字符串，只能相互定义字符串协议 |
| serviceloader | 读取META-INF/services文件 ，可在任意模块读取反射此类 | 直接使用系统的serviceLoader会造成很多的services文件，需要自定义sdk使用 |
| 自定义event接口 | 动态代理接口，模块之间自由调用，类与类之间的关系依然体现在接口上，debug比较好定位 | 需要单独写sdk（好在之前已经有过积累直接可以拿来用），接口下沉的问题 |
| ARouter | Activity之间的粘滞性减少，不使用隐式跳转即可实现路由 | 开源的工程功能比较多，有些代码会增加项目体积 |
综合上面的对比，我们这里选用了自定义Event接口跟ARouter进行模块之间的通信
需要解决的问题：
1.接口下沉，我们这里学习了微信的api概念将接口定义为以api为后缀的文件，将接口写到模块上层，使用gradle plugin进行自动生成接口文件到p_generate 的sdk中，这样我们就可以在上层模块自己定义接口，其他模块也可以相互调用
2.关于ARouter的问题，后期会单独自定义路由sdk
总结：以上便是重构中遇到的一些小小问题，总结下来主要的难点是在模块之间的通信问题，好在前人栽树后人乘凉，以上的所有具体实施都是依托别家项目进行的。有关于整体的项目架构，等项目具体实施时在更新，谢谢。
