uni-app x 蒸汽模式 HarmonyOS 平台性能基准测试深度解析：4050 同屏渲染与死亡长列表帧率实测

uni-app x 蒸汽模式 HarmonyOS 平台性能基准测试深度解析：4050 同屏渲染与死亡长列表帧率实测

【免费下载链接】uni-appA cross-platform framework using Vue.js项目地址: https://gitcode.com/gh_mirrors/un/uni-app

uni-app x 蒸汽模式（vapor）是 DCloud 于 2026 年推出的跨平台开发框架新版本，其核心卖点是"比原生更快"。本文以鸿蒙（HarmonyOS）平台的官方基准测试报告为骨架，完整还原view/text同屏渲染速度测试与"死亡长列表"掉帧测试的测试方法、环境声明、原始数据与结论，并结合当前开源仓库中的复现源码（4050 测试页、FPS 组件、死亡长列表页、mock 数据生成器）逐行解读其实现原理。读完本文，你将掌握这套 Benchmark 的可复现实验流程、数据口径定义，以及蒸汽模式在鸿蒙上实现性能优势的底层技术逻辑。

背景：蒸汽模式是什么，本报告测什么

uni-app x 蒸汽模式是在uni-app x（使用 Vue 语法的跨平台框架）基础上引入的新一代渲染方案，其技术要点如下：

• uni-app x使用 Vue 语法，并在蒸汽模式中去除了虚拟 DOM；
• 蒸汽模式中，template与style被编译为字节码/机器码，script支持 js/ts/uts 语言；
• uni-app x基于原生渲染管线，可融合原生组件生态，并占用更小的内存；
• 蒸汽模式提供大量自研高性能组件，如view、text、image、list、rich-text、swiper、slider、picker等。

本报告为harmony 平台的性能评测（iOS 评测另见 vapor-benchmark-ios，Android 评测另见 vapor-benchmark-android）。评测目标有两层：一是真实呈现主要性能指标，二是确保开发者可自行重现本基准测试并得出相近结论。

测试指标：UI 系统的核心性能指标是渲染速度和帧率——追求渲染速度更快、掉帧更少。人工体感可以录像佐证，但测试指标必须可精准度量，因此本报告采用可编程打点计时的度量方案。

关于蒸汽模式更完整的架构说明（虚拟 DOM 的问题、全新渲染系统、视图层编译目标、拍平属性等），可进一步阅读 docs/app-vapor.md。

环境声明：在鸿蒙最低端机型上控制变量

本 Benchmark 使用了 2 台鸿蒙系统在售的最低端机型 nova 12，具体信息如下：

• 设备型号：nova 12（非 pro），运行内存 8G；
• OS 版本：6.0.0.130（截止测试时间的最新版 OS，patch02）；
• 全部使用release 方式运行；
• 电量 90% 左右，未开启节能模式（该设备仅支持普通模式和节能模式）；
• 屏幕刷新率设置为高，即120Hz；
• 测试前所有设备重启，并静置 2 分钟；除"关于本机"的界面外，杀掉所有其他 App 的进程。

选择最低端在售机型的用意在于：性能瓶颈在低端机上更容易暴露，测试结果对存量用户更具代表性。release 方式运行则是为了保证优化后的真实渲染性能（debug 模式性能较差，不适合测性能）。

测试一：view 和 text 渲染速度测试（4050 元素同屏）

测试方法

view和text是渲染引擎的核心基础，大量组件基于这两个基础组件构建，它们的渲染速度是一套渲染引擎最核心的性能指标。验证创建速度是否足够快，可靠的方式是在同一个屏幕内创建大量组件并计算耗时。

具体做法：点击按钮后，在屏幕上创建 2000 个 view，每个 view 有一个背景色，每个 view 中再套入一个 text 组件。2000 个 view 需在同一屏幕区显示，view 不设宽高，text 字体较小。view 们被分为 50 行、每行 40 个 view，同时每行外层再套一个 view——即一共4050 个元素（2050 个 view 和 2000 个 text），对比uni-app x 蒸汽模式与arkUI 原生的创建速度。

源码层面的测试实现

该测试页在本仓库中的复现源码为 src/pages/template/4050/4050.uvue。对照源码可以还原完整的计时机制：

• 模板结构：外层 5 行 x 10 列用于初始化预热；点击按钮后show置为 true，渲染 50 行 x 40 列的结构，每个格子内部再套一个text（字号与行高仅 5px），所有格子均带flatten（拍平）属性与背景色；
• 计时起点：按钮@click的ShowEvent中startime = Date.now()；
• 计时终点：通过getCurrentInstance().proxy.$page获取页面实例，注册insPage.onRenderChange(({ duration }) => {...})回调，该回调表示主线程渲染指令已全部送达 OS 渲染进程，此时主线程已完成本次渲染所需工作、处于空闲状态；
• 结果呈现：用uni.showToast直接弹出耗时（单位 ms），同时在控制台输出click -> render end的总时长。

需要特别说明计时口径：结束时间并非肉眼所见的屏幕显示时间——渲染进程和 GPU 仍需一定时间才能让屏幕真正显示图像，但该后续时段无法通过编程打点计时。经录屏与计时粗略对比，arkUI和uni-app x 蒸汽模式在渲染进程和 GPU 阶段的耗时接近（都在 1 帧左右），故在后续精准比较中忽略这段时间，保留上述结束时间定义。

原始测试数据

该实验重复 5 次，每次均杀掉应用进程重新进入，精准计时的耗时（单位 ms）如下：

轮次	arkUI	uni-app x 蒸汽模式
1	791	243
2	805	244
3	811	244
4	771	243
5	810	242

平均值：

arkUI	uni-app x 蒸汽模式
797.6	243.2

（录屏对比中，界面 toast 显示 arkUI 为 804ms、uni-app x 蒸汽模式为 267ms，与 5 次重复实验数据处于同一量级。）

测试结论

在 4050 个 view 和 text 同屏渲染测试中，uni-app x 蒸汽模式的渲染速度是 arkUI 的3.3 倍（797.6 / 243.2）。

复现工程与体验方式

• 鸿蒙 arkUI 对照工程需要自行编译原始工程；
• uni-app x 蒸汽模式版，可在HBuilderX 5.0 以上版本编译运行，注意选用 release 方式运行，或发行为正式包安装；
• hello uni-app x示例应用已上架鸿蒙应用商店（搜索"DCloud开发者中心系统"），安装后点击右下角"模板"选项卡，顶部有view 和 text 性能测试入口；
• 本仓库中的同源示例代码即 src/pages/template/4050/4050.uvue。

需要强调：uni-app x作为通用引擎，未对该示例做任何定制优化，没有诸如预加载、预测量等影响实验结果的行为。

测试二：长列表掉帧测试（死亡长列表）

测试方法

list组件在渲染引擎中的地位仅次于 view 和 text。现代渲染引擎普遍采用复用技术实现长列表，确保持续滑动后内存不持续增长。复用式长列表进入速度都很快（只加载了一部分数据），但在滚动过程中持续加载数据并复用已有视图时，如果列表复杂，会发生滚动掉帧。

为此本测试设计了一个非常复杂的"死亡长列表"：

• 加载 4000 行数据（7.4M 的 JSON）；
• 每行超过 40+ 元素，包括文字、图片、视频、自定义 vue 组件；
• 每行嵌套 10+ 层；
• 渲染 2 万个元素，占据普通手机约 1333 屏；
• 列表中还有大量阴影、圆角、边框等复杂渲染样式。

数据并非静态存储在本地，而是由代码生成，生成数据的代码是预执行的，arkUI 版和 uni-app x 版均如此。

帧率度量方案：FPS 组件

人工体验可以感知加载速度和快速滑动流畅度，但严谨的 Benchmark 需要精准数据。方案是制作一个 fps 组件，监听系统的帧回调：在 120Hz 高刷屏上，每8.33ms触发一次帧回调，如果两个帧回调的代码响应时长超过 8.33ms，就意味着掉帧。该 fps 组件使用同样的逻辑分别实现 arkUI 版本和 uni-app x 版本。

本仓库中的 fps 组件源码为 src/components/fps/fps.uvue，核心逻辑是：

• 通过requestAnimationFrame(calculateFPS)递归注册帧回调；
• 每次回调累加frameCount，与上次统计时间fpsUpdateTime求差，当时间差达到props.interval（默认 1000ms）时，用Math.round(frameCount * 1000 / delta)计算 FPS 并更新显示、通过emit('updateFps', value)上报；
• 组件卸载时用cancelAnimationFrame注销回调，position: fixed悬浮于屏幕右上角显示实时 FPS。

测试流程

arkUI 端使用LazyForEach，uni-app x端使用list-view。2 端分别进入长列表：滚动到底部、加载完 4000 行数据，然后点击鸿蒙手机的顶部状态栏，此时会滚动回到列表顶部。2 端回滚时间一致（均为 1 秒），在这个回滚到顶部的过程中计算帧率、验证掉帧情况，同时从录像视觉上直观感受。视觉体验中可看出，arkUI 的 fps 组件数字在 1 秒动画期间更低，回滚过程中很多视频呈现黑块。

原始测试数据

该实验重复 5 次，每次均杀掉应用重新进入、重新滚动到顶部，数据如下：

arkUI：

• 回滚过程中平均 FPS: 19.67，最高 FPS: 49，最低 FPS: 13
• 回滚过程中平均 FPS: 24.14，最高 FPS: 61，最低 FPS: 15
• 回滚过程中平均 FPS: 19.50，最高 FPS: 43，最低 FPS: 13
• 回滚过程中平均 FPS: 20.67，最高 FPS: 53，最低 FPS: 13
• 回滚过程中平均 FPS: 21.67，最高 FPS: 56，最低 FPS: 13

uni-app x 蒸汽模式：

• 回滚过程中平均 FPS: 78.29，最高 FPS: 100，最低 FPS: 52
• 回滚过程中平均 FPS: 112.30，最高 FPS: 120，最低 FPS: 90
• 回滚过程中平均 FPS: 106.33，最高 FPS: 120，最低 FPS: 45
• 回滚过程中平均 FPS: 88.43，最高 FPS: 120，最低 FPS: 29
• 回滚过程中平均 FPS: 104.50，最高 FPS: 120，最低 FPS: 55

汇总统计：arkUI 的 5 次平均 FPS 为21.13，最高 61，最低 13；uni-app x 蒸汽模式的 5 次平均 FPS 为97.97，最高 120，最低 29。

源码层面的测试实现

本仓库中的死亡长列表页源码为 src/pages/template/long-list-perf/long-list-perf.uvue，其实现与测试报告完全对应：

• 数据与列表：onMounted中调用generateMockList()一次性注入 4000 条数据，list-view设置:scroll-with-animation="true"，list-item通过v-for ... :key="item.id" :type="item.type"按类型复用；
• 五种行类型：Type1 单图配文、Type2 三图配文、Type3 九宫格、Type4 卡片条、Type5 视频，每行均以 10 层flatten的nest-row嵌套结构模拟深层节点，并叠加.b1~.b10十级彩色边框、圆角、阴影等复杂样式；
• 数据生成：4000 条记录由 src/pages/template/long-list-perf/mock-data.uts 中的generateData()预生成（含图片 URL 数组、9 宫格图、视频 URL、封面、评分等字段），并通过模块级缓存_mockListData保证只生成一次；
• 回滚计时：页面顶部scrollToTop()清空fpsArr/fpsTimeArr后把listViewRef.value.scrollTop置 0 触发回滚，onScroll首次触发时开启统计，onScrollEnd时按fpsTimeArr做时间加权平均计算平均 FPS，并输出平均FPS / 最高FPS / 最低FPS到控制台——这正是报告中 5 次数据的采集逻辑。

测试结论

在长列表帧率测试中，uni-app x 蒸汽模式的平均帧率是 arkUI 的4.6 倍（97.97 / 21.13）。

此外，实测还发现一个功能层面的差异：arkUI 版本长列表中的 video无法记忆播放进度（播放 A 视频到 5s 时滚动到别处再滚回，A 视频会重头播放）；而uni-app x版本记忆了播放进度。这一差异需计入帧率对比——记忆播放进度本身也耗费时间，即如果 uni-app x 取消记忆播放进度，帧率还能进一步提升。

复现工程与体验方式

• 鸿蒙 arkUI 版对照工程需自行编译原始工程；
• uni-app x 蒸汽模式版，可在 HBuilderX 5.0 以上版本编译运行（release 方式或发行为正式包安装）；
• hello uni-app x已上架鸿蒙应用商店，安装后点击右下角"模板"选项卡，顶部有死亡长列表入口；
• 本仓库中的同源示例代码即 src/pages/template/long-list-perf/long-list-perf.uvue 与 src/pages/template/long-list-perf/mock-data.uts。

同样需要强调：uni-app x作为通用引擎，未对该示例做任何定制优化（无预加载、预测量等行为）。

其他组件的极限性能测试

一套渲染引擎除了 view、text、list，还需要更多高性能组件。uni-app x对各种组件都做了极限性能测试，但受限于精力，未对 arkUI 组件全面做性能对比。开发者可以在hello uni-app x中体验各种组件的性能测试——几乎每个组件的示例都单独提供了组件性能测试。以下为鸿蒙平台实测表现：

• rich-text 组件：App 平台的 rich-text 过去一直没有太好的解决方案——鸿蒙自身的 richText 组件基于 webview 渲染，存在加载慢、内存占用高、快滑白屏等问题。蒸汽模式提供更快的 rich-text 组件。测试加载 5 万字长文、59 张插图，可以无等待进入页面，上下快滑不掉帧，除联网图片加载外滑不出白屏。
• swiper 组件：加载 100 个 item，无等待进入页面；在上述 5 万字长文中点击图片，swiper 中无等待呈现 59 张图片，左右切换图片无延迟。
• picker 组件：加载省市区 4000 条数据，无等待弹出组件。
• slider 组件：拖动 100 个 slider，流畅丝滑。
• loading 组件：屏幕上同时旋转 100 个 loading 不掉帧。
• canvas 组件：屏幕上同时移动数百个小球不掉帧。
• 表单组件：众多表单组件均有 100 或 200 个的创建速度测试监控。
• 进阶示例：hello uni-app x 模板中还提供了日历、竖滑视频、侧滑删除长列表、AI Chat 流式打字机等性能考验示例。

注：以上录屏时帧率只能为 60Hz，实际使用中是完整的 120Hz。

在 AI 时代，很多 App 需要内嵌一个开源的 AI 对话聊天库，能流式解析 markdown 且解析过程不掉帧。另外值得关注的是：从 2007 年 iPhone 发布后，手机用户每天都要为每次页面转场等待 300ms，而hello uni-app x的蒸汽模式中已默认改为150ms，这 150ms 更多是留给网络的；如果开发者使用 h3 等新兴网络技术优化好服务器速度，还可以把等待时间缩得更短。

FAQ：关于性能优势的核心质疑与澄清

uni-app x 的 App 平台是自渲染还是原生渲染？

是原生渲染。准确地说，是在原生渲染管线上自己做几乎所有组件。如果使用 xComponent 自渲染，会因 2 条渲染管线并存额外消耗硬件资源；并且鸿蒙有很多原生组件（权限按钮、webview 组件、map 地图以及三方生态中大量 arkUI 原生组件），自渲染方案在与原生生态融合时问题较多——两条渲染管线的滚动同步、层级合成、资源消耗均使该路线不是最佳方案。站在宏观视角，在原生渲染管线中优化、提供更快的核心组件、兼容所有原生组件，比自立一套组件生态对产业更有意义。

为什么都是原生渲染，蒸汽模式比原生渲染更快？

涉及数千项工程优化，举例说明：

1. 不依赖系统自带组件，全新自研：Android 的 Compose UI 也是基于原生渲染管线的，但它没有使用 Android 自带的 view、textview，而是实现了自己的组件系统，这条路可行，但 Compose UI 实际渲染速度比 view 体系更慢。uni-app x 蒸汽模式也几乎不使用系统自带组件——无论是 textView、recycleView、viewPage，还是鸿蒙的 arkUI 相关组件，基本都是全新研发的组件，性能更高。
2. 视图层直接编译为高度优化的 C 代码：vue 里template和style中的代码被直接编译为优化度非常高的 C 代码，其运行速度远快于 arkts、kotlin 及 k/n。

蒸汽模式的快是因为拍平（flatten）吗？

不是。如果不拍平，同屏创建 4050 个 view 和 text 示例的平均耗时为467ms，仍远快于 arkUI 的 797.6ms。且 uni-app x 组件众多，支持拍平的仅 view、text、image，其他组件如 rich-text、canvas 性能高与拍平无关。拍平属性的具体行为与鸿蒙平台注意点可参见 docs/app-vapor.md（拍平即不创建独立元素、绘制在父级上，仅在存在至少两个相邻元素同时拍平时才提升性能）。

k/n 驱动 C 层渲染是否也快过 arkUI 或蒸汽模式？

截止到测试时点（2026 年 2 月初），基于 k/n 的开源跨平台框架在上述基准测试中的表现均比 arkUI 差很多，更无法与uni-app x 蒸汽模式相比。

"基于原生渲染，又宣称比原生渲染快"是否矛盾？

需要严谨化名词：uni-app x 蒸汽模式，是基于原生渲染管线、渲染性能超过原生 UI 框架。原生渲染管线与原生 UI 框架是两个概念：

• 原生渲染管线：应用启动后，OS 一定会给应用分配的画布、合成机制、渲染线程资源、GPU 上下文；
• 自渲染：指新开一个独立画布，占用一大块新内存、内部有自己的小合成机制，再并入原生大合成里，自己创建渲染线程、独立 GPU 上下文（Android 上是新开 surface/textureView，鸿蒙上是新开 XComponent），因此自渲染在启动和与原生 view 合成时性能不佳；
• 原生 UI 框架：基于原生渲染管线可以有多套原生 UI 框架，Android 有 Android View 体系、Compose UI 体系，iOS 有 UIView 体系、SwiftUI 体系，它们都有自己的排版系统、组件库、命令式或声明式编写框架。

uni-app x 做的事情，是在原生渲染管线上新增了一套原生 UI 框架，拥有自己的排版布局系统和组件系统，这套系统的性能高于上述 OS 自带 UI 框架。

基于原生渲染，是否涉及跨平台不一致问题？

uni-app x 蒸汽模式只是使用了原生渲染管线，但几乎不使用各平台的原生组件，基本都是用跨平台的 C++ 和 uts 自己编写，因为是同一套代码，可以很好地保持跨平台一致性。对比之下，之前 uni-app x 的 VDOM 模式中不同平台组件差异较多（Android 的 list 基于 recycle-view，iOS 的 list 基于 UICollectionView，代码完全不同，细节和 bug 难免有差异）；而蒸汽模式中 list 是基于 C 和 uts 一套代码实现的，逻辑上高度统一。

是否存在测试例定向优化？其他测试例下性能不如原生怎么办？

官方明确表示 uni-app x 未对测试例做定向优化：

• 4050 view + text是对 view、text 两个核心组件的性能极限测试。开发者可以不使用方格、用任意其他方式测试对比，结论一致；也可以使用多种布局方式（线性布局、约束布局等）测试，"蒸汽模式比原生快数倍"的结论不会变；
• 死亡长列表是对 list 组件的性能极限测试；5 万字长图文是对 rich-text 的性能极限测试。开发者可以构造其他方式的长列表和长图文来做性能测试，一样会得出 uni-app x 性能更好的结论。

因为不是恰好这些测试例的写法中 uni-app x 表现更好，而是这些组件的性能确实更好，怎么做极限测试都一样。当然，并非 uni-app x 的几十个组件每个都比原生组件性能高——有些组件（如 video 使用的 exoplayer）与原生性能一样，但高频使用、有性能压力的组件，uni-app x 均会优化到比原生组件更快。

对比测试例中，原生的写法是否没有极致优化？

原生的写法均已开源，怀疑的开发者可以查看源码自行优化，若能优化到比 uni-app x 快，官方会公布。但需注意不能写测试例定向优化代码，要在同一层面对比（即使用原生组件和排版系统）。uni-app x 比较的对象是 Android View 体系、Compose UI 体系、UIView 体系、SwiftUI 体系、ArkUI 体系。如果原生不使用 view、text 组件而自己绘制，在某些测试例中可以定向优化（例如 4050 示例中把宽高定死、不走测量和排版、在自定义 view 上自绘，肯定更快），但这反而是原生为测试例更好看而做的定向优化。4050 示例对比的是两套 UI 组件系统，不是定宽高的，大小由文字撑开，要完整测试排版、测量和绘制的性能。uni-app x 自然也可以跳过排版和测量自绘，但拍平并不是跳过排版测量的自绘，它仍然要走排版、测量和绘制；而跳过排版测量的自绘不具备通用性，没有比较意义。

uni-app x 的 css 是 web 子集，是否够用？功能增加后性能会下降吗？

uni-app x 的 css 支持度与 react native 的 Style 支持度类似，都是 web 子集，足够开发者写出想要的界面。未来确实有计划增加更多 css 能力，但都可以做到不使用新能力时老能力的渲染速度不变。此外，DCloud 实验室内部还有非常多性能优化技术未进入产品化，当前已经够快，所以这些技术的产品化优先级被放低，uni-app x 未来只会更快、不会变慢。

如何在自己的鸿蒙设备上重现本 Benchmark

1. 环境准备：鸿蒙 nova 12（或同级别设备），OS 不低于报告版本，电量 90% 左右、不开启节能模式，设置中搜索"刷新率"并打开强制 120Hz；
2. 对照端：编译运行鸿蒙 arkUI 对照工程（4050 示例与死亡长列表示例各自独立工程）；
3. 测试端：使用 HBuilderX 5.0 以上版本打开 hello uni-app x（或本仓库 src/pages/template/4050/4050.uvue / src/pages/template/long-list-perf/long-list-perf.uvue 对应工程），务必选用 release 方式运行或发行为正式包安装，不要在 debug/运行模式下测性能；
4. 数据采集：4050 测试直接读取 toast/控制台耗时时长；死亡长列表进入后滚动到底部、点击顶部状态栏回滚，观察 FPS 组件数值，或直接读取控制台输出的时间加权平均 FPS；
5. 复测规范：每次测试杀掉应用进程重新进入，重复 5 次取平均，与报告数据对比。

注意：蒸汽模式最低支持的 OS 版本比 VDOM 模式更高，鸿蒙要求 API 20+（鸿蒙 6.0+），可在 manifest 可视化界面鸿蒙配置中设置最低版本；相关运行注意事项详见 docs/app-vapor.md。

【免费下载链接】uni-appA cross-platform framework using Vue.js项目地址: https://gitcode.com/gh_mirrors/un/uni-app