App跨平台框架历史悠久，从cordova、reactnative、flutter，直到最近的uni-appx。江山代有才人出，每个都试图颠覆原生，但过去却一直未成功。
过去的问题到底在哪里？
我们先捋一捋各种技术路线，分析这些跨平台开发框架和原生应用的差别具体在哪里。
上表中，uni-appx和原生应用是一样的，逻辑层和渲染层都是原生，都是强类型；而其他跨平台框架或者在逻辑层、或者在渲染层与原生不一致。
webview不行已经是业内常识了，启动慢、渲染慢、内存占用高。这块本文不再详述。
但那些非web-view的框架到底哪里不如原生？
reactnative、weex等抛弃webview，改由原生渲染的跨平台方案，2014年就推出了。如今手机硬件也越来越好了，为什么性能还达不到原生？
js+原生渲染的方案主要有2点缺陷：
所以很多开发者即便使用这类方案，首页也还是原生来写。
弱类型在编译期可优化的幅度有限，还是需要一个运行时来跑，无法像强类型那样直接深入底层。
以数字运算为例，js的number运算确实比强类型的int慢，内存开销也更大。
每个语言有自己的内存空间，跨语言通信都有折损，每次通信几十到几百毫秒不等，视手机当时的状态。一旦频繁通信，就会明显卡顿。
逻辑层的js，即要和原生渲染层通信，还要和原生API通信：
举个简单的场景例子，在js里监听滚动，根据滚动变化实时调整界面上某些元素的高度变化。这个问题能难倒一大批跨平台开发框架。
虽然小程序和uni-app都是js，但实际上逻辑层在独立js引擎里，通过原生桥来控制web-view，通信成本很高。
weex提供了bindingx技术，这是一种弱编程，渲染层预先定义了一些操作UI的方式，调用时全部在渲染层运行，不会来回与逻辑层通信。但这种预定义方式的适应面有限，无法做到在js里高性能、自由的操作所有UI。
操作系统和三方SDK的API都是原生的，js调用这些能力也需要跨语言通信。比如js调用原生的Storage或IO，数据较多时遍历的性能非常差。
flutter在2018年发布，第一次统一了逻辑层和渲染层，而且使用了强类型。
它没有使用原生渲染，而是使用由dart驱动的渲染引擎，这样逻辑层的dart代码操作UI时，再也没有延时了！bindingx、wxs这种补丁方案再也不需要了。
并且dart作为强类型，编译优化很好做，启动速度和运行速度都胜过js。
100个slider同时滑动，非常考验逻辑和UI的通信。如果在webview内部，html和js写100个这样的slider，在新的手机上表现也还ok。但在小程序和reactnative这种逻辑和UI分离的模式下，100个slider是灾难。
flutter看起来很完美。但为什么也没有成为主流呢？很多大厂兴奋的引入后为何又不再扩大使用范围呢？
别忘了上面1.2.2提到的原生API通信。flutter虽然在逻辑层和渲染层都是dart，但要调用原生API时，还是要通信。
操作系统和三方SDK的API是原生的，让dart调用需要做一层封装，又落到了跨语言通信的坑里。
项目里面有源码，大家可自行编译；根目录有打包好的apk，也可以直接安装体验。
这个项目首先在kotlin中构建了包含不同数据量的class，传递到dart然后渲染在界面上，并且再写回到原生层。
有0.1k和1k两种数据量（点击界面上的1k数字可切换），有读和读并写2个按钮，各自循环1000次。
以下截图的测试环境是华为mate305G，麒麟990。手机上所有进程杀掉。如下图：
为什么会这样？因为dart和kotlin不是一种编程语言，不能直接调用kotlin的class，只能先序列化成字符串，把字符串数据从原生传到dart，然后在dart层再重新构造。
当然也可以在原生层为dart封装API时提供wx.batchGetStorageSync这类批处理API，把数据一次读好再给dart，但这种又会遇到灵活性问题。
而在uni-appx中，这种跨语言通信是不存在的，不需要序列化，因为uni-appx使用的编程语言uts，在android上就编译为了kotlin，它可以直接调用kotlin的class而无需通信和封装。示例如下，具体uni-appx的原理后续章节会专题介绍。
很多人都知道iPhone上跨平台框架的应用，表现比android好。但大多数人只知道是因为iPhone的硬件好。
其实还有一个重要原因，iOS的jscore是c写的，OS的API及渲染层也都是ObjectC，js调用原生时，某些类型可以做共享内存的优化。但复杂对象也还是无法直接丢一个指针过去共享使用内存。
而android，不管java还是kotlin，他们和v8、dart通信仍然需要跨语言通信。
flutter的自渲染引擎，在技术上是不错的。但在生态兼容上有问题。
很多三方软件和SDK是原生的，原生渲染和flutter自渲染并存时，问题很多。
flutter开发者都知道的一个常见坑是输入法，因为输入法是典型的原生UI，它和flutter自绘UI并存时各种兼容问题，输入框被遮挡、窗体resize适应，输入法有很多种，很难适配。
这里没有提供开源示例，因为flutter官方是承认这个问题的，它提供了2种方式：混合集成模式和虚拟显示模式模式。
视频中手机切换暗黑主题后，这个UI却还是白的，而且flutter的父容器原生view已经变黑了，它又在黑底上绘制了一个白色界面，体验非常差。
这个小程序首页界面很简单，没有输入框，规避了混合渲染，点击搜索图标后又跳转到了黑色的原生渲染的界面里。
注：如何识别一个界面是不是用flutter开发的？在手机设置的开发者选项里，有一个GPU呈现模式分析，flutter的UI不触发这个分析。且无法审查布局边界。
flutter的混合渲染的问题，在所有使用原生渲染的跨平台开发框架中都不存在，比如reactnative、weex、uni-appx。
总结下flutter：逻辑层和UI层交互没有通信折损，但逻辑层dart和原生api有通信成本，自绘UI和原生ui的混合渲染问题很多。
flutter除了上述提到的原生通信和混合渲染，还有3个问题：dart生态、热更新、以及比较难用的嵌套写法。
其实这是让人困惑的行为。因为这又回到了reactnative和weex的老路了，只是把原生渲染换成了flutter渲染。
flutter最大的优势是dart操作UI不需要通信，以及强类型，而改成js，操作UI再次需要通信，又需要js运行时引擎。
上述视频中，注意看手指按下的那1个slider，和其他99个通过数据通讯指挥跟随一起行动的slider，无法同步，并且界面掉帧。
不过自渲染由于无法通过Android的开发者工具查看GPU呈现模式，所以无法从条状图直观反映出掉帧。
注意ArkUI-x不支持Android8.0以下的手机，不要找太老的手机测试。
很多人以为自渲染是王道，但其实自渲染是坑。因为flutter的UI还会带来混合渲染问题。
也就是说，js+flutter渲染，和js+原生渲染，这2个方案相比，都是js弱类型、都有逻辑层和渲染层的通信问题、都有原生API通信问题，而js+flutter还多了一个混合渲染问题。
可能有的同学会说，原生渲染很难在iOS、Android双端一致，自渲染没有这个问题。
但其实完全可以双端一致，如果你使用某个原生渲染框架遇到不一致问题，那只是这个框架厂商做的不好而已。
是的，很遗憾reactnative在跨端组件方面投入不足，官方连slider组件都没有，导致本次评测中未提供reactnative下slider-100的示例和视频。
2022年，uts语言发布。2023年，uni-appx发布。
uts语言是基于typescript修改而来的强类型语言，编译到不同平台时有不同的输出：
而uni-appx，是基于uts语言重新开发了一遍uni-app的组件、API以及vue框架。
如下这段示例，前端的同学都很熟悉，但它在编译为AndroidApp时，变成了一个纯的kotlinapp，里面没有js引擎、没有flutter、没有webview，从逻辑层到UI层都是原生的。
但是开发者也不要误解之前的uni-app代码可以无缝迁移。
了解了uni-appx的基本原理，我们来看下uni-appx下的100个slider效果怎么样。
如下视频，打开了GPU呈现模式，可以看到没有一条竖线突破那条红色的掉帧安全横线，也就是没有一帧掉帧。
uni-appx在app端，不管逻辑层、渲染层，都是kotlin，没有通信问题、没有混合渲染问题。不是达到了原生的性能，而是它本身就是原生应用，它和原生应用的性能没差别。
这也是其他跨平台开发框架做不到的。
DCloud做了很多年跨平台开发，uni-app在web和小程序平台取得了很大的成功，不管规模大小的开发者都在使用；但在app平台，大开发者只使用uni小程序sdk，中小开发者的app会整体使用。
究其原因，uni-app在web和小程序上，没有性能问题，直接编译为了js或wxml，uni-app只是换了一种跨平台的写法，不存在用uni-app开发比原生js或原生wxml性能差的说法。
但过去基于小程序架构的app端，性能确实不及原生开发。
那么App平台，为什么不能像web和小程序那样，直接编译为App平台的原生语言呢？
uni-appx，目标不是改进跨平台框架的性能，而是给原生应用提供一个跨平台的写法。
这个思路的转换使得uni-appx超越了其他跨平台开发框架。
在web端编译为js，在小程序端编译为wxml等，在app端编译为kotlin。每个平台都只是帮开发者换种一致的写法而已，运行的代码都是该平台原生的代码。
然而在2年前，这条路线有2个巨大的风险：
没有人确定这个产品可以做出来，DCloud内部争议也很多。
还好，经历了无数的困难和挑战，这个产品终于面世了。
换个写法写原生应用，还带来另一个好处。
同样业务功能的app，使用vue的写法，比手写纯原生快多了。也就是uni-appx对开发效率的提升不只是因为跨平台，单平台它的开发效率也更高。
其实google自己也知道原生开发写法太复杂，关于换种更高效的写法来写原生应用，他们的做法是推出了composeUI。
不过遗憾的是这个方案引入了性能问题。我们专门测试使用composeUI做100个slider滑动的例子，流畅度也掉帧。
既然已经把不同开发框架的slider-100应用打包出来了，我们顺便也比较了不同框架下的包体积大小、内存占用：
包体积数据说明：
内存占用数据说明：
跨语言通信、弱类型、混合渲染、包体积、内存占用，这些都是过去跨平台框架不如原生的地方。
这些问题在uni-appx都不存在，它只是换了一种写法的原生应用。
另外，原生Android中一个界面不能有太多元素，否则性能会拉胯。flutter的自渲染和composeui解决了这个问题。而原生中解决这个问题需要引入自绘机制来降低元素数量，这个在uni-appx里对应的是draw自绘API。
uni-appx这个技术路线是产业真正需要的东西，随着产品的迭代完善，它能真正帮助开发者即提升开发效率又不牺牲性能。
让跨平台开发不如原生，成为历史。
欢迎体验uni-appx的示例应用，感受它的启动速度，渲染流畅度。
这个示例里有几个例子非常考验通信性能，除了也内置了slider-100外，另一个是“模版-scroll-view自定义滚动吸顶”，在滚动时实时修改元素top值始终为一个固定值，一点都不抖动。
我们不游说您使用任何开发技术，但您应该知道它们的原理和差别。
欢迎指正和讨论。
DCloud是一个纯粹的工程师团队，公司90%的职员都是写代码的工程师，无需见客户、写方案，大部分都有原始股权，欢迎有好奇心、追求卓越的极客加盟。