在对比分析之前,我们先 review 一下 Pluto 的使用主场景:一个可以无限加载更多 Feed 的 Feed 列表,要求内存,CPU,流畅度都有不错的表现。
针对这个场景,对比分析现有主流的界面开发库,分别是 Xcode 自带的 Storyboard/Xib,Facebook 主导的开源组件 ReactNative、ComponentKit,以及本文的 Pluto。
● storyboard 是一个可视化的 UI 编辑工具,开发效率比较高。性能上,控件都使用了原生控件,所以性能会差一些。也不支持异步排版,影响流畅度。生成的文件是使用 XML 描述,理论上是可以动态下发,但是 XML 格式不公开,各个版本也不保证兼容,所以比较难做到动态下发。
● React Native 使用 JS+HTML 的方式进行开发,开发效率很高。也有很高的动态性和跨平台特性。但是性能比较捉急,在速度上,内存使用上有一些问题,很难在 Feed 流这种性能要求比较高的地方。
● ComponentKit 跟 Pluto 其实很类似,区别最大的地方在于 Component 不支持 JSON/XML 这种静态表达样式的功能,以及事件动态绑定的功能。在动态性和可维护性方面,会弱很多。我们有思考过在 ComponentKit 的基础上增加 JSON 表达样式的功能。但是
ComponentKit 直接使用了原生视图,并没有一个中间的虚拟视图层,所以性能上也是问题。改造成本太高。
● Pluto 相比 React Native 来说,组件不够丰富,使用 JSON 可以让开发效率在描述排版方面接近 React
Native;性能相比其他组件来说很不错;支持异步保证了主线程的流畅度;动态性跟 React Native 一样,不能新增控件,控件都是本地预埋。比较依赖本地代码的逻辑,不能修改本地代码的已有逻辑,但是可以替换一部分。当然,逻辑只能预埋的话,也不会有审核风险。