android组件化方案对比

 

现在公司准备项目组件化，前公司项目其实用了组件化，但功能比较少，比较好拆，现在公司项目比较庞大，功能繁杂，参与人员多，感觉非常不大好拆，拆的时候还涉及到功能、代码重构。老大对技术比较看重，还要求大家在重构项目前看完三本书（重构、Effective Java、23种设计模式），这三本书确实也不错的。

近期一直在研究项目组件化，看了业界不少组件化方案，这是下面对组件化方案的一些对比，后面还会不断完善，争取探索出一套适合自己项目的组件化方案。

组件化方案 功能	Component Caller	Arouter	WMRouter	ModularizationArchitecture
调用Activity、Fragment	支持组件与Activity、Fragment的生命周期关联	编译期通过apt生成path和activity.class映射关系的类文件，在app进程启动时加载这些类文件，保存映射关系到内存中，再直接获取。	支持多schemem、host、path,支持URI正则匹配	支持，组件生命周期与应用的Application相关联
组件间方法调用	基于总线方式转发调用请求，组件总线只负责通信，即转发调用请求和返回执行结果，不需要下沉接口，面向通信协议编程，支持任意指令的调用/回调，可以跨进程调用转发给其他app	基于路由方式，将接口类下沉到base层，面向接口编程，依赖倒置原则 需要通信组件打包到同一个app内部才能获取到	API设计思想，支持获取接口所有实现，获取Class或实例，支持无参构造或自下义Factory/Provider构造	支持
是否支持跨进程组件调用（组件开发/调试时单独作为app运行）	采用BroadcastReceiver+Service+LocalSocket方式 每个app都能给其他app调用 app可设置是否对外提供跨进程组件调用支持 组件调用请求发出去之后，能自动探测当前设备上是否有支持此次调用的app 支持超时、取消 跨进程调用数据传递，同下一个app支持非基本数据类型对象，跨app只支持基本数据类型	URLScheme方式 基因中自带支持从webview中调用，不用互相注册； 缺点：只能单向给组件发送信息，适用于启动Activity和发送指令，不适用于获取数据； 需 有额外的中转Activity统一处理URLScheme，再进行转发	根据URI不同的Scheme、host、path进行不同处理，分成native页面、h5､外部app呼起、通知中心push等，自己也可以添加UriInterceptor进行拉截，做跳转前处理等	AIDL方式，可传递Parcelable类型的对象 缺点：调用组件前需提前知道组件在哪具进程，否则无法建立ServiceConnection. 组件在作为独立app和作为lib打包到主app时，进行名称不同，维护成本高
app间调用的开关及权限设置	满足不同级别的安全需求	无法进行权限设置、开关设置，任意app都可调用	支持设置host权限跳转	支持设置跨app调用开关
同步/异步调用组件	支持，同步调用采用Callbale.call()获取结果； 异步：放入线程池中运行，执行无后调用IComponentCallback.onResult(cc, result)	不支持	支持	支持
同步/异步实现组件	支持，对于同步调用异步实现的组件，用Oject的wait-notify机制，当线件需要异步返回结果，在CC框架内部进行阻塞	不支持	不支持	支持
添加自定义拦截器	支持	支持	支持配置全局和局部拦截器
超时设置	支持	不支持	不支持	不支持
手动取消	支持	不支持	不支持	不支持
动态注册/反注册组件	编译时自动注册组件，无需手动维护组件注册表（ASM修改字节码方式）	每个module都生成自己的java类，这些类的包名都在特定包下，运行时读取dex文件中该包下所有类，通过反射完成映射表的注册	java动态注册或注解配置自动注册	支持
crash、null等错误处理	组件调用处、回调处、组件实现处的crash全部在框架内catch住；可根据CCResult结果进行降级处理	支持降级处理，失败回调	支持降级处理，失败回调	支持
组件生命周期管理	组件与调用方 Activity、Fragment生命周期关联	不支持	不支持	每个组件都实现一个类似Application的生命周期管理类，并与应用的Application进行绑定，实现组的生命周期与应用生命周期绑定