small插件化方案踩坑

集成方案

基本思想：把可变的集成到lib或者app中，不可变的以stub的方式集成

工程结构如下图：

集成方案：保持现有的组件化方案不变，将openali，utils以stub的方式集成到工程中，app.工程名 的 build.gradle文件plugin由com.android.library改为com.android.application

和普通开发之间的区别

##缺点：

1:service，provider集成到宿主中
2:activity 仅支持launchmode属性，如果有process，configchanged等属性需要在宿主中注册
3:lib模块如果引用含有资源的lib模块会出问题
4:跨进程资源调用必须要写在stub模块中（动画，通知），造成模块资源泄漏
5:android系统碎片化严重，各厂商对系统的定制 及 android系统每个framework版本api的不同，造成crash－－mi ui系统资源占用0x10，与small资源分配冲突
6:模块间传递参数问题通过small.openuri来，传递参数会有限制，不如intent方便－－可定制
7:small自动化脚本做到不够完善，经常出现打包资源问题

##优点：

1:快速发版，bug修复，abtest
2:解藕，加快编译速度

给我们现有工程带来的好处

1: 解藕，工程结构变更，（登录，登出借口，logincallback接口）－－需要反哺到组建化方案中

2: 模块间跳转最好通过action方式来，尽量少用类名–（强制：app模块之间的跳转必须用action，模块内部的跳转可用class名）

3: 从最初的开发方式来进行模块解藕

需要注意的点

1： small加载插件没有按需加载，会一次把所有的插件都加载进来，是一个耗时的操作
2: 更新操作每次，如果清空缓存，同样也会把缓存的更新模块包给删掉，所以需要注意更新包备份

总结

现在还不到时机，现在用的话只能给工程的开发增加复杂度－－应该后续也不会考虑

建议继续使用组件化开发

http://blog.zhaiyifan.cn/2016/10/20/android-new-project-from-0-p11/