ARTICLE · 1033661
从uni-app到uni-app x,跨端 App 的性能实现了质的飞跃
从uni-app到uni-app x,跨端 App 的性能实现了质的飞跃2017年我开始用uni-app，那时候App端就是WebView。JS跑在逻辑层，通过桥接驱动WebView里的UI，启动慢、滚动涩、列表一卡一卡的，重一点的交互就得靠原生插件硬绕。 说实话我从来没把它当回事过，就当是个临时方案，迟早要换。但一套代码跑iOS、Android加小程序，这个诱惑太大，忍了就忍了。 性能敏感的地方单独写原生？说得好听，真这么做跨端的意义就没了一半。那时候企业的项目只分安卓和IOS端，所以还是会用react native开发。 这一忍就是十年。直到蒸汽模式的出现。 uni-app x的蒸汽模式 真正改变我看法的是uni-app x的蒸汽模式。 DCloud 2026年发了三端的benchmark，数据挺夸张：4050个view+text同屏渲染，效果很明显。
刚开始我也纳闷，基于原生渲染管线怎么可能比原生快？ 原生渲染管线是操作系统分配给应用的画布、合成机制、GPU上下文——这是"地基"，原生UI框架（Android View、Compose、iOS UIKit、鸿蒙ArkUI）这些是在地基上盖的房子。 蒸汽模式是在同一个地基上自己盖了栋房子——用C++和UTS重写了排版布局和组件体系，基本不用系统原生组件。虚拟DOM也没了，1000个元素不再先建1000个虚拟节点再映射，编译器直接生成操作渲染管线的代码，能拍平的节点全拍平。 包体积还比Flutter小40-50%。 uni-app进入维护期 不仅数据好看，更重要的是，老uni-app实际上已经进入维护模式了。 官方口径很直白：vue2、plus、nvue停维，其他的修bug可以，但新功能只上uni-app x。论坛上有人直接问，回复原话是"uni-app x有很多先进的新功能，uni-app没有，这种差别也会随着时间拉大而明显"。翻译一下：别等新东西了。 这个信号从2024年就开始了。新功能只发alpha，npm上没有3.x稳定版，HBuilderX 5.x只内置uni-app x编译器。2026年起新建项目默认就是蒸汽模式，鸿蒙Next适配也是uni-app x先跑通的。 性能数据会过时，但战略信号不会。老uni-app还能用、还稳定，但功能已经冻结了。继续留在上面，就是用着一个不会再长大的框架。 （老项目也不用着急换到uni-app x，继续使用还是没问题的。） 如果要迁移，麻烦吗？ 比想象中省事，结构基本不变。 蒸汽模式支持JS/TS/UTS写script，不用强制强类型；编译到小程序和Web端会自动降级成VDOM模式跑，多端能力不丢；项目结构跟老版基本一致，只是不支持App原生插件，改用uts插件，uts插件两边通用。 坑也有： 不支持Vue3选项式API，只支持setup； 部分CSS声明行为变了； NPM生态兼容还在补。 如果你的旧项目里用的是传统的 nativeplugins 目录下的原生插件（通常包含 .aar 或 .framework 文件），那么这些插件在 uni-app x 中是无法直接使用的。 对于这些原生插件，可以先去 DCloud 插件市场搜索是否已有现成的 UTS 版本，直接替换是最省事的。也可以参考下面的官方解决方案： 将原有的原生插件代码（如 Android 的 Java/Kotlin 代码）打包成 AAR 库，然后编写一层 UTS 代码来调用这个 AAR 库。这样，你原有的原生功能代码大部分可以复用，只需要用 UTS 重新编写调用层和生命周期逻辑即可。 但这些是适配问题，不是架构天花板。WebView时代的卡是结构性的，怎么优化都没用；蒸汽模式这些坑，随着版本迭代是能填平的。 以前跨端等于"一套代码跑多端，性能打个折"，现在可以是一套代码编译到各平台的原生渲染管线上，跑得比原生框架还快。 当然了，不是说uni-app x就是最好的了，只是看样子，uni-app x以后是要代替 uni-app 了。而 Flutter 的稳定性、RN 新架构的JS生态、以及Kotlin Multiplay等在特定场景仍有自己的优势。 跨端开发相关文章： 2026年移动端开发选型：5大框架选哪个 零基础学 Flutter：一篇搞定开发环境配置
关注我，前端/全栈开发少走弯路、高效摸鱼～
如果你觉得文章内容有用，请记得点赞、收藏、转发。
👋 关于我
19 年开发背景，现在独立接项目、做分享。记录真实过程，分享真实经验，不贩卖焦虑。
技术交流群：点击下方二维码拉你进群或者公众号菜单栏点击“加入群聊”扫码进群