Skip、Compose、Flutter和RN

哈喽，我是老刘

前几天看到一个新的跨平台框架Skip，它的底层技术方案是转译。
感觉还挺巧的，因为不久前刚刚做了一个内部分享，就讲到了虚拟化的转译方案。
其实跨平台开发的技术和虚拟化的技术有很多相通的地方。
正好本文就把跨平台开发的三种技术方案盘点对比一下。
话说6年前我们刚开始选择Flutter作为跨平台框架的时候，还没有Compose、Skip这些选项。
所以当时做出选择并不难，如果放到今天可能选择困难症就要犯了。

跨平台的三种技术方案

我们知道，跨平台开发的目标就是一套代码多个平台使用。
但是不同系统平台提供的编程语言、SDK等都是截然不同的，于是为了让同一套代码在不同平台能跑起来并且能绘制UI界面，就产生了不同的技术方案。

1、套壳

这里的套壳可不是操作系统的套壳，这里说的其实是一种中间层方案。
这种方案最典型的代表就是RN。

从上面架构图中可以看出来，RN使用JS开发页面和逻辑。
然后把页面相关的信息传递给原生的RN模块。
原生的RN模块把页面的内容转换为原生的各种组件，然后交给原生SDK进行渲染。

中间层是软件工程中最常用的一种解决方案，其最大的好处就是灵活、省事。
有了RN Android和RN iOS两个中间层，就可以在其上随意搭建自己的页面框架了。
这样基本不需要考虑底层系统带来的影响，理论上一切差异都可以在中间层搞定。
当然在实际的实践中做不到这么完美，不过也足以满足工程应用。

当然中间层也有它固有的缺陷。
最大的问题就是性能的损失，从RN来看性能的损失来源于以下几个方面。
中间层本身的消耗
中间层肩负着上下层转换的工作，这本身就会带来内存和CPU等运行期资源的消耗。
相对于原生开发来说，这种损耗是额外增加的。
在客户端这种对流畅性非常敏感的应用场景下，也很容易造成用户体验下降。

上下层通信造成的延迟
要知道，页面不是一次渲染就放在那不动了。
随着用户的操作，页面要随时进行更新。
这就涉及到了上下层的通信。
比如用户在页面上点击了按钮，需要把点击事件从原生SDK传递给JS页面。
JS页面响应点击后也需要把页面的变化传递给原生SDK。
这种跨编程语言运行时的通信，比原生组件和原生SDK间的通信要慢很多。
如果碰到用户拖动一个页面元素移动的场景，比如把阅读App中书架上一本书拖动到