Android 项目重构中遇到的小问题（初版）

2018-07-31 本文已影响55人 heiheiwanne

前言：最近对整体的Android项目进行了初步的整理并设计了一个小小的demo，记录下过程中遇到的一些小问题。此处不进行系统讲解。

鉴于Android端本身是支持多端（用户端/门店端/配送端/OA）项目，必须提高代码的利用率，增加、修改代码的成本。

解决方案

抽离基础组件生成单独的sdk，以aar的依赖形式加入项目中。

鉴于现在的代码本身的耦合度比较严重，很难做到单独在JVM上运行单元测试，为了提高项目本身的稳定性，以及降低上线时的项目bug率，单元测试提上日程。

解决方案

使用标准的mvp-clean架构

现有代码各个模块之间的界限不明显，相互之间的关联性严重，有些类的代码本身臃肿，一个类掺杂好几个人的代码，无法确定代码负责人的界限。

解决方案

设立模块负责人的概念，调整gradle的打包方式，将业务拆分为几个模块每个模块需要单独人员进行负责，以gradle plugin的方式区分代码界限，并尽量做到每个模块的自完备性，后期扩展gradle plugin 一键切环境，每个模块可单独为一个project，提升代码编译速度

鉴于整体项目组人员多，项目少，拆分模块负责人更多的原因是基于现有项目人员结构，确立代码界限。

因为现有代码是直接使用的一些三方库并未封装使用，替换底层代码的成本过高。再有进行数据统计的代码进行侵入度过高

解决方案

增加中间层代码，此中间层提供承接的作用，上层的代码都是依托中间层代码调用基础组件

因为本身项目是单一业务线，逻辑简单直接拆分项目为几个module本身增加项目的复杂度，也比利于项目的后期演变。

解决方案

这里使用了P工程的实现，修改了gradle的打包方式，并增加了plugin来check 代码

p工程

main:为主工程入口；
p_generate:生成的下沉接口
p_kernel：中间层
p_order/p_my:业务层

模块之间需要进行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

总结：以上便是重构中遇到的一些小小问题，总结下来主要的难点是在模块之间的通信问题，好在前人栽树后人乘凉，以上的所有具体实施都是依托别家项目进行的。有关于整体的项目架构，等项目具体实施时在更新，谢谢。

Android 项目重构中遇到的小问题﻿（初版）