带你读《2022技术人的百宝黑皮书》——跨桌面端之组件化实践(1)https://developer.aliyun.com/article/1340326?groupCode=taobaotech
怎么选择组件化方案?
组件化的落地方案很多,我们怎么选择适合自己的技术方案?
业界的组件化方案很多,例如windows下的com组件,andriod下的ARouter组件,基于消息总线的ths组件,千牛 自研的prg::com组件,还有一些基于rpc框架,更宽泛意义上组件化(微服务)。
在我看来,组件化方案没有最好的,只有相对合适的。根据业务场景,选择一个满足当前业务需要,又能适当照顾到未来发展需要,好用好维护的方案就可以。
这里提供一些组件化方案选型一些可参考的维度:
1. |
发现机制 |
2. |
通信机制 |
3. |
跨平台 |
4. |
跨编程语言 |
5. |
维护成本 |
6. |
研发效率 |
7. |
编译依赖 |
8. |
性能 |
9. |
稳定性 |
|
|
在跨端千牛的场景下,我们的诉求优先级是:
- 首先必须是支持跨平台的,
- 其次是良好的可维护性,长期来看,可维护性对产品质量、效能和研发体验都影响深远。
- 然后是良好的性能和稳定性,
- 最后是较好的研发效能和研发体验。
这里我们主要对比了ths组件和prg::com组件方案:
- ths组件:ths方案类似于一个rpc调用框架,所有调用以消息的形式在总线上传递,其运行时隔离&有中心节点切面,但其接口可维护性较差,无法在编译期发现问题。ths方案更适合跨团队场景,或开放场景。
- prg::com组件:prg::com组件类似于微软的com组件,但它支持了跨平台,并对com接口调用方式进行了优 化,调用方便。其接口的可维护性较佳,编译时就可以发现接口兼容性问题,性能也非常不错,十分适用于团队内部的组件化场景。
最终我们选用了自研的prg::com作为跨端框架组件化的技术方案,下面具体介绍一下这个方案。
带你读《2022技术人的百宝黑皮书》——跨桌面端之组件化实践(3)https://developer.aliyun.com/article/1340324?groupCode=taobaotech