第4章 ThorComponent组件化框架(基于CC)
1、编写框架涉及技术
| 组件化涉及技术 |
优点 |
缺点 |
是否选用 |
理由 |
| serviceload |
调用是接口形式，比较直观 |
模块间调用解耦不易 |
否 |
java的serviceload并不完备，实现多采用反射与效率背道而驰 |
| weixinapi技术 |
解决部分公用代码动态下沉到base |
编写.api要注意分包摆放 |
是 |
项目稳定后，一般不会有下沉base代码，可以将base抽象成公共库，本作者实现 |
| 组件单独运行和集成发布thorAlone |
编写组件减少他们之间的依赖 |
专用sourceSet.main.debug目录，sourceSet项目中用法过于负责慎用 |
是 |
module间代码隔离,与壳工程隔离 |
| P工程 |
细粒度的解耦，减少module内过度依赖 |
一般中小项目中，粒度过于细了 |
否 |
一般项目多P工程解耦成本太高 |
| asm |
动态生成字节码效率高 |
底层技术编写过于复杂 |
是 |
参照cc-register，为了效率 |
| 总线模式 |
将服务扁平化 |
改造CC过于复杂 |
是 |
本框架采用改造CC，实现扁平化 |
| RPC |
多进程间通讯快 |
涉及远程调用场景不多 |
否 |
组件化间场景并不多，建议用专门库来实现这个功能 |
| apt注解 |
编译时注解，减少编写过多模板代码 |
编写有些复杂，如果不是强烈需要，建议不要 |
是 |
组件化框架目的就是为了使用者减少不必要代码编写 |
| 反射 |
可以hack代码，也可以动态化加载 |
运行时效率低下，用户体验差 |
否 |
尽量少采用反射 |
| 线程池 |
避免new Thread方式过于浪费内存资源，复用 |
实现有技术成本且慎用 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
本文标题：第4章 ThorComponent组件化框架(基于CC)
本文链接：https://www.haomeiwen.com/subject/kuulxctx.html
网友评论