背景
uni-app x 蒸汽模式，是DCloud于2026年推出的跨平台开发框架新版本。
该产品的特点是：比原生更快。
继 uni-app x 蒸汽模式 鸿蒙版发布后，iOS版也已于5.1+ 发布了alpha，并于5.14发布了正式版。
iOS的原生性能优化是业界标杆，想要做到超过iOS原生是非常难的。这可能会让很多人觉得天方夜谭。所以一份严谨、客观的benchmark尤为重要。
本基准测试的目标，即为了真实呈现主要性能指标，并确保开发者可自行重现本基准测试，并得出相近结论。
先简要介绍 uni-app x 及 蒸汽模式
- uni-app x 使用vue语法，并在蒸汽模式中去除了虚拟DOM
- 蒸汽模式中，模板和样式编译为机器码或字节码，script在iOS上编译为js语言。
- uni-app x 基于原生渲染管线，可融合原生组件生态，并占用更小的内存
- 蒸汽模式提供了大量自研高性能组件，如view、text、image、list、rich-text、swiper、slider、picker等
测试指标
UI系统的核心性能指标是：渲染速度和帧率。
追求渲染速度更快、掉帧更少。
人工体感可以录像，但测试指标必须可精准度量，需要准确的度量方案。
环境声明
本Benchmark使用了2台iOS系统在售的最低端机型 iPhone SE2，发布于2020年，具体信息如下：
- 设备型号：iPhone SE2
- OS版本：iOS26
- 全部使用release方式运行
- 电量90%左右，未开启节能模式。
- 测试前所有设备重启，并静置2分钟。杀掉所有其他App的进程。
view和text渲染速度测试
view和text是渲染引擎的核心基础，大量组件基于这2个基础组件构建。这2个基础组件的渲染速度是一套渲染引擎最核心的性能指标。
验证一个view和text创建速度是否足够快，可靠的方式是在同一个屏幕内创建大量view和text组件，计算耗时。
测试方法
点击按钮后，在屏幕上创建2000个view，每个view有一个背景色，每个view中再套入一个text组件。
2000个view需在同一屏幕区显示，view不设宽高，text字体较小。view们被分为50行，每行40个view，同时每行外层再套一个view。
即，一共4050的元素，其中2050个view和2000个text。
对比使用 uni-app x 蒸汽模式和UIKit原生，进行创建速度的测试。
首先看录屏对比。 左边为UIKit原生，右边为uni-app x 蒸汽模式。
高清视频，可移步B站观看，uni-app x vs UIKit 4050 元素渲染速度对比视频（iOS 平台）
界面上方显示了耗时，单位为ms。UIkit原生为325.76ms、uni-app x蒸汽模式为167ms。计时说明：
- 开始时间为按钮的click事件触发时间
- 结束时间为主线程渲染指令已全部送达OS渲染进程时间。此时主线程已经完成本次渲染所需的工作，处于空闲状态。
该结束时间并非肉眼所见的屏幕显示时间，实际上渲染进程和GPU仍需一定时间工作才能让屏幕显示图像，但后续时间段无法通过编程打点计时，都在1帧左右，故在后续精准比较中忽略这段时间，保留目前的结束时间定义。
该实验重复5次。每次均杀掉应用进程重新进入，明细耗时如下：
| 原生UIKit | uni-app x蒸汽模式 iOS |
|---|---|
| 325.76 | 167 |
| 330 | 157 |
| 330 | 159 |
| 330 | 160 |
| 328 | 160 |
平均值：
| UIKit | uni-app x蒸汽模式 |
|---|---|
| 328.75 | 160.6 |
以上数据单位均为ms。
测试结论
结论：在4050 view和text同屏渲染测试中，uni-app x 蒸汽模式的渲染速度是 iOS原生UIKit的 2倍。
需要说明的是，在iOS18上，原生和uni-app x蒸汽模式的差距更大，尤其是SwiftUI。在更低端的iPhoneXR、iOS18上测试数据如下：
| 5次平均耗时(ms) | |
|---|---|
| 原生UIKit | 339.7 (340.9 339.1 337.7 343.9 336.9) |
| 原生SwiftUI | 610.56 (609.6 614.2 613.1 613 602.9) |
| uni-app x蒸汽模式 | 185.8 (186 186 185 185 187) |
渲染4050个元素，uni-app x的增量内存也更低，依次是 uni-app x < UIKit < SwiftUI。相关数据较多，本报告不再罗列，有兴趣的开发者可以使用xcode自行观测。
复现工程源码和体验方式
上述2个示例，源码如下：
- iOS原生的源码：gitcode.com/dcloud/test…
- uni-app x的源码：gitcode.com/dcloud/hell…
原生版本，需要在xcode中自行编译原始工程。
uni-app x 蒸汽模式，可以在HBuilderX 5.14+版本编译，注意真机运行为debug模式，不能用于性能测试，需发行为正式包安装以release方式测试性能。
你也可以不编译uni-app x，直接下载示例应用体验：
hello uni-app x示例应用已经在Appstore以abm方式上架，使用iOS手机扫描下方二维码，并通过DCloud账户登录即可下载：
安装 hello uni-app x 后，点击右下角模板 -> 顶部有 view和text性能测试。
uni-app x 作为通用引擎，未对该示例做任何定制优化，没有诸如预加载、预测量、强制调用大核等影响实验公平性的行为。
长列表掉帧测试
list组件的地位，在渲染引擎中仅次于view和text。
现代渲染引擎，都采用复用技术实现长列表，确保持续滑动长列表后，内存没有持续增长。
使用复用技术的长列表，进入速度都很快，因为只加载了一部分数据，但在快速滚动过程中不掉帧是难点，持续加载数据并复用已存在视图时，如果列表复杂，很难在1帧之内完成渲染，这就会引发掉帧或白屏。
测试方法
设计一个非常复杂的“死亡长列表”：
- 加载4000行数据，7.4M的JSON
- 每行超过40+元素，包括文字、图片、视频、自定义vue组件
- 每行嵌套深度10+层
- 列表共渲染2万个元素，占据普通手机1333屏左右
- 列表中还有大量的阴影、圆角、边框等复杂渲染样式
在人工体验中，用户可以体验加载速度、快速滑动时的流畅度，但在严谨的Benchmark中，需要精准的对比数据。
首先需要制作一个fps组件，监听系统的帧回调，在iPhone se2上，每16.6ms会触发一次帧回调。如果2个帧回调的代码响应时长超过了16.6ms，就意味着掉帧。
该fps组件需要使用同样的逻辑分别实现原生版本和uni-app x版本。源码见后续 复现工程 章节。
同时死亡长列表的代码，也需要在iOS原生和uni-app x中使用相同逻辑实现。由于工作量原因，长列表测试只编写了SwiftUI的版本，未编写UIKit版本。
在2端分别进入长列表，长按选中滚动条，拖动滚动条可让列表快速滑动，滚动到底部，加载完4000行数据，然后点击返回顶部。
2端回滚速度一样，回滚到顶部的过程中，计算帧率，验证掉帧情况。同时从录像视觉上进行直观感受。
首先看录屏对比。 左边为uni-app x蒸汽模式，右边为原生SwiftUI
高清视频，可移步B站观看，uni-app x 高性能演示-死亡长列表-iOS平台
视觉体验中可看出：右边的原生列表在快速滑动时大量灰块，无法及时渲染图片和视频。而左边的uni-app x 列表都能及时渲染，看不到灰块。fps组件的数字，原生大量在30、40左右，而uni-app x基本在50以上。
该实验重复5次，每次均杀掉应用重新进入，重新滚动到顶部。
5次的测试数据如下：
- SwiftUI:
-
- 回滚过程中的平均FPS: 40.06, 最高FPS: 60, 最低FPS: 28.1
- 回滚过程中的平均FPS: 37, 最高FPS: 60, 最低FPS: 25
- 回滚过程中的平均FPS: 38, 最高FPS: 60, 最低FPS: 23
- 回滚过程中的平均FPS: 37, 最高FPS: 60, 最低FPS: 27
- 回滚过程中的平均FPS: 36, 最高FPS: 60, 最低FPS: 27
- uni-app-x 蒸汽模式:
-
- 回滚过程中的平均FPS: 50, 最高FPS: 60, 最低FPS: 16.23
- 回滚过程中的平均FPS: 54, 最高FPS: 60, 最低FPS: 19
- 回滚过程中的平均FPS: 48, 最高FPS: 60, 最低FPS: 16
- 回滚过程中的平均FPS: 48, 最高FPS: 60, 最低FPS: 15
- 回滚过程中的平均FPS: 48, 最高FPS: 60, 最低FPS: 21
SwiftUI的5次平均fps为 37.6，最高fps为60，最低fps为23。
uni-app x蒸汽模式的5次平均fps为 49.6，最高fps为60，最低为15。
测试结论
结论：在长列表帧率测试中，uni-app x蒸汽模式的平均帧率是 SwiftUI 1.32倍。
虽然长列表帧率上uni-app x比SwiftUI快的不多，但考虑到SwiftUI滚动时大量的灰块不渲染，可以推测其使用了快速滚动时跳过渲染的方式来减少掉帧。哪种用户体验更好，一目了然。
另外SwifUI版本的长列表中的video，未实现记忆video的播放进度，即播放A视频到5s时，滚动到其他地方，然后再滚回来显示A视频，A视频会重头播放。
但uni-app x的版本记忆了播放进度。除了功能的不同外，此差异也需要考虑到帧率对比中，记忆播放进度本身也耗费时间，也就是如果uni-app x取消记忆播放进度，帧率还能再提升。
复现工程源码和体验方式
上述2个示例，源码如下：
- iOS的SwiftUI版源码：gitcode.com/dcloud/iOSD…
- uni-app x版源码：gitcode.com/dcloud/hell…
原生版本，需要自行编译原始工程。
uni-app x蒸汽模式，可以在HBuilderX 5.14+以上版本编译运行（注意发行为正式包安装测试，勿使用真机运行测试性能）。
hello uni-app x示例应用已经在Appstore以abm方式上架，使用iOS手机扫描下方二维码：
安装hello uni-app x后，点击右下角模板 -> 顶部有 死亡长列表。
uni-app x作为通用引擎，未对该示例做任何定制优化，没有诸如预加载、预测量、强制绑定大核等影响实验结果的行为。
其他组件
一套渲染引擎，除了view、text、list外，还需要更多高性能的组件。
uni-app x中对各种组件都做了极限性能测试，但受限于精力，未开发iOS原生组件的测试例进行性能对比。
所以以下组件没有原生对比数据，只有uni-app x 蒸汽模式的数据。
开发者可以在 hello uni-app x 中体验各种组件的性能测试，几乎每个组件的示例中，都单独提供了 组件性能测试。
- rich-text组件：
rich-text组件很重要，不管是新闻、UGC内容，还是AI输出的markdown富文本，包括表格、代码高亮。这些在App平台过去一直没有好的解决方案。大多数开发者只能忍受webview初始化慢、内存占用高、快滑白屏等问题。uni-app x 蒸汽模式 提供了应该是业内当前最好的rich-text组件。
以下测试，用一个rich-text组件加载5万字长文，其中包括59张插图。可以看到1. 无等待进入页面。2. 上下快滑不掉帧、不白屏，都是瞬间渲染3. 初次联网加载图片的速度受网速影响，再次进入后使用本地缓存，速度会更快。
高清视频，可移步B站观看，uni-app x 高性能演示-richtext 组件-iOS 平台
- swiper组件：
在上述5万字长文中点击图片，打开的预览图片界面，就是使用swiper组件实现的。可以看到swiper中无等待呈现59张图片，左右切换图片无延迟。很多单一指标变好，可以依靠牺牲其他指标来做到。比如启动时做懒加载，会造成启动快，但后续切换慢。同时做到启动快、切换快，且还没有预加载，那就是真的性能好。
- picker组件：
加载省市区4000条数据。无等待弹出组件，没有预加载，数据都是点击picker时才加载并渲染的。
高清视频，可移步B站观看，uni-app x 高性能演示-picker组件-iOS平台
- slide组件：
进入一个有100个slider的页面，瞬间进入。拖动100个slider，丝滑流畅。完全不担心逻辑层和渲染层的通信阻塞。
高清视频，可移步B站观看，uni-app x 高性能演示-slider 组件-iOS 平台
注：手机录屏时帧率只能为60Hz，实际在高刷屏手机使用时是120Hz。下同
- loading组件：
屏幕上同时旋转100个loading，同时计时器文字每ms更新一次，在高绘制压力下完全不掉帧。
高清视频，可移步B站观看，uni-app x 高性能演示-loading 组件-iOS 平台
- canvas组件：
屏幕上同时移动数百个小球不掉帧
高清视频，可移步B站观看，uni-app x 高性能演示-canvas-iOS 平台
- 众多表单组件
均有100或200个创建速度测试监控。hello uni-app x 模板中还提供了日历、竖滑视频、侧滑删除长列表、ai chat的流式打字机等性能考验示例。
高清视频，可移步B站观看：
在ai时代，很多App都需要内嵌一个开源的AI对话聊天库，能流式解析markdown，解析过程不掉帧。为此DCloud推出开源的uni-ai x，详见ext.dcloud.net.cn/plugin?id=2…
没有用户喜欢等待、没有用户喜欢卡顿掉帧。
从2007年iPhone发布后，几十年来手机用户每天都要为每次页面转场等待300ms。uni-app x 将支撑这个时间大幅缩短。hello uni-app x的蒸汽模式中已默认改为150ms，这150ms更多是留给网络。
如果开发者使用h3等新兴网络技术，优化好服务器速度，还可以把等待时间缩的更短。
FAQ
uni-app x 的App平台到底是自渲染还是原生渲染？
是原生渲染。准确的讲，是在原生渲染管线上自己做几乎所有组件。
如果使用自渲染，会因为2条渲染管线并存额外消耗硬件资源。初始化慢、内存占用高。
并且原生生态发展多年，有很多三方组件SDK，比如map、直播、广告等，自渲染方案在与原生生态融合时问题较多。两条渲染管线在同一个页面内融合，滚动同步、资源消耗均导致这一路线不是最佳方案。
站在宏观视角，在原生渲染管线中优化，提供更快的核心组件，兼容所有原生组件，比自立一套组件生态对产业更有意义。
为什么都是原生渲染，uni-app x的蒸汽模式比原生渲染更快？
这里面涉及数千项工程优化，举例一些：
-
Android的compose ui也是基于原生渲染管线的，但没有使用Android自带的view、textview，而是实现了自己的组件系统。
这条路可行，只不过compose ui没有成为一个好标杆，它实际渲染速度比view体系更慢。（在上述4050示例对比中，有原生view和compose ui的测试例，详见）
uni-app x 蒸汽模式，也几乎没有使用系统自带的组件，不管是textView、recycleView、viewPage...，基本都没用。全新研发的组件做到了性能更高。 -
vue里template和style里的代码，被直接编译为优化度非常高的机器码/字节码。
目前它的副作用就是编译速度变慢，后续DCloud会改良编译器进一步提升编译速度。
在uni-app x的示例中发现了拍平。如果不拍平的话，uni-app x蒸汽模式中渲染速度还会比原生快吗？
不拍平时，uni-app x蒸汽模式仍然快于UIKit和SwiftUI。有兴趣的开发者可以修改4050.uvue代码自行测试。
k/n驱动c层渲染，是否也快过SwiftUI或uni-app x蒸汽模式？
Compose Multiplatform ，在iOS上使用自渲染，有原生UI生态融合问题，且性能表现不佳。
性能排名是 uni-app x蒸汽模式 > UIKit > SwiftUI > Compose Multiplatform。
AI时代，跨平台的意义还大吗？
提升生产效率，是社会发展不变的趋势。AI和跨平台都是推进生产效率提升的重要手段。
但如果用AI来生成多平台代码，那么AI并不是一个稳定的公共抽象。如果你实践过后就会发现，除了给AI发出的第一句话可以多平台复用外，后面的每个问题都需要分平台处理，不具备专业平台知识很难做出商业级应用。
提升性能，是用户体验发展不变的趋势。页面切换从300ms等待变成150ms，操作任何交互都丝滑流畅，这都是用户选择一个App或放弃另一个App的重要原因。AI + 原生的UI体系并不能实现比uni-app x更高的性能。
另外，欢迎关注uni-agent，它对uni-app系产品的了解程度超过任何AI Coding工具，可以帮助开发者更好的用AI生成uni-app x、uniCloud等产品代码。
AI默认生成的代码是react，对vue的影响是什么样的？
由于美国开发市场react的份额高于vue，AI在不指定前端框架的时候默认会使用react。但如果据此认为AI生成react代码比vue更好，那就反了。
- 实际上有更规范约束的vue写法，让AI幻觉更少，而灵活的react更容易让AI犯错。
- react在海外有个优势是生态，但国内的多端情况比国外复杂，国内的跨端vue库反而更多。
- web平台上，vue蒸汽模式的性能和包体积，都领先于react。随着vue3.6的成熟，产业可能会迎来分水岭。
vue3.6蒸汽模式在web平台还是beta状态，App就能商用了吗？
目前vue官方蒸汽模式在web平台需要关注的是ssr服务器渲染等功能的稳定性，这在App平台用不到。App平台的蒸汽模式的vue部分已经单独跑过了所有相关的测试例。
另外uni-app x的蒸汽模式，其实并不只是使用了vue的无虚拟DOM技术。无虚拟DOM只能更接近原生，而不能超过原生。超过原生的核心是uni-app x的新渲染引擎和各种基于C实现的新组件库。只是为了减少概念和条件编译，这套新渲染引擎没有对外推出独立名字。
uni-app x蒸汽模式在Android何时发布？是否也快过原生？
uni-app x蒸汽模式的Android版的已处于群测版状态，进入uni-app x im群中可下载。预计几天后正式对外发布。
不管在iOS还是Android，均比原生快2~3倍，均基于原生渲染管线。
已公开如下预览版对比测试例：
- Android平台的uni-app x 蒸汽模式的4050同屏创建示例apk：gitcode.com/dcloud/test…，安装其中apk即可体验。
- Android平台的原生view，以及compose ui的与源码 gitcode.com/dcloud/test…
上述示例在华为mate30 Android版上，对比数据如下：
| 5次冷启动平均耗时（单位:ms） | |
|---|---|
| 原生view | 436 |
| 原生compose ui | 673.2 |
| 原生compose ui aot | 544.2 |
| uni-app x 蒸汽模式 | 224 |
后续会对Android版也推出一份类似的、全面的性能评测报告。
即跨平台，又比原生性能更高，曾经被认为是幻想。
DCloud一直把这个幻想当做梦想，持续努力追梦，2023年推出uni-app x，2026年推出蒸汽模式。数年坚持不懈的追求这个梦想，把别人眼中的幻想变为现实。
继续前行！
