文章总结： 本文介绍uni-appx蒸汽模式历经四年研发实现跨平台性能反超原生，同屏渲染4050个组件时耗时显著低于各平台原生。团队通过实验室机制体系化实验攻克渲染与语言两大难关，并战略转向JS/TS生态以适应AI时代。文章也指出生态成熟度不足、热更新受限等挑战，并探讨AI时代跨平台框架价值。 综合评分： 75 文章分类： 实战经验,技术标准,解决方案

uni-app x蒸汽模式：磕了四年，跨平台性能反超原生

原创

老王同志 老王同志

码到深处自然成

2026年9月29日 17:00 山东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

前几天读了DCloud CEO王安的一篇访谈，说实话，看完之后倒不是说里面的技术细节有多震撼，而是那种四年闷头做一件事的状态，在当前这个做什么都讲究快节奏的环境里，确实少见。

先说说那个让人不太敢信的数据，在同屏渲染4050个view和text的测试场景下，uni-app x蒸汽模式的耗时是Android 273ms、iOS 167ms、鸿蒙267ms，而对应平台的原生渲染分别是505ms、325.76ms和804ms。这个数据刚出来的时候，社区里不少人的第一反应是怀疑，觉得是不是针对测试例做了定向优化。

王安在访谈里回应得很直接，说这个逻辑是反过来的。团队是先有了如何测试一个渲染系统在处理基础组件时速度更快这个问题，才设计了这个4050个元素的实验场景。换句话说，测试是为问题服务的，不是为结论服务的。

访谈里还提到了几个关键点。uni的文字系统更快，如果往测试例里塞更多text组件，差距会拉得更大。模板和Style区域的代码被编译成字节码，执行效率更高。排版系统统一走flex，性能也比各平台原生的布局系统快。

有个细节让我印象挺深。王安说，如果原生团队真的愿意好好优化底层，肯定可以反超uni蒸汽现在的数据。但uni蒸汽自己也不会停，如果原生追上来了，他们也会再立项去追。这种话说出来，能感觉到团队对底层优化这件事已经形成了某种惯性。

另外uni-app当前在小程序领域的市占率是第一，不管大厂小厂都在用，这个没什么争议。但在App平台，市占率只有百分之十几，主要集中在中小开发者群体。原因不复杂，就是性能满足不了中大开发者的需求。

DCloud做了二十多年跨平台，这个问题一直卡在那里。王安用了如鲠在喉这个说法。2022年内部讨论uni-app x立项的时候，反对的声音不小。守住原来的盘子，做好服务和商业化，团队的日子能过得更好。一旦立项去啃跨平台性能这块硬骨头，注定不是短期能解决的，投入大，风险也大。

但最后还是决定做了。王安的原话是不服气，觉得这辈子不能就一直解决不了跨平台的性能问题。立项时以为两年能搞定，实际做了四年。他说如果当初知道要四年，承受的压力会非常大，不一定能下得了决心。

回头看，这段话里最有信息量的不是四年这个数字，而是一个技术人在面对一个长期未解的问题时，那种不甘心的状态。

四年里当然不是一帆风顺。有的路走了很久才发现不通，团队中间有段时间非常焦虑。大约2025年初的时候，项目快三年了还不达预期，那种压力不用多说也能想象。

王安在访谈里说的最大的教训，不是技术路线选错了，而是开始就应该建立一个更高效的探路机制。他们直到2025年才完善了这个机制，叫实验室。核心思路是不着急做产品，不着急写代码，先做实验，体系化地做实验。但又发现要做严谨的实验，得先建实验室的基建。

有很长一段时间，王安每天只看实验报告，不看产品里提交了多少代码。这种管理方式在大多数公司里是不太可能出现的，常规的技术考核看的是需求实现工期、完成度、bug数量。但对于蒸汽模式这种产品，实验室机制才是最终能做出来的核心原因。

说实话，读到这段的时候我想到了很多团队做性能优化的方式，基本都是在产品里遇到瓶颈了再回头调。像这样先搭一套实验基建再动手的做法，投入的时间成本很高，但后面的回报也确实大。

uni-app x立项时推的是UTS语言，一个可以编译成Kotlin、Swift、ArkTS的跨平台编译型语言。团队连续磕了语言和渲染系统两个大难关。

但AI来了之后，情况变了。UTS作为新语言，国外模型不熟悉，也没有模型为它单独做强化学习。这让团队开始思考另一个问题：既然渲染系统已经能做到比原生快这么多，那把语言改回普通的JS/TS，是不是也能保持性能优势？是不是这样的产品在AI时代对开发者更友好。

这个转变在团队内部并不容易。王安说辛苦搞了几年UTS，投入了大量心血，要换回JS，自己的孩子怎么能不心疼。他自己也做了很多心理建设，最后通过分期立项，先在鸿蒙和iOS上确认JS加蒸汽渲染仍然能比原生快，才全体推进Android的JS更换。

UTS不会消失，DCloud内部还有大量基于UTS的代码，原生插件开发也可以继续用UTS或原生混编。但从产品策略上看，蒸汽模式最终选择了拥抱JS/TS生态，这背后的考量很明显是AI Coding时代对语言生态的要求。

截至2026年6月，uni-app全域开发者突破900万，覆盖iOS、Android、HarmonyOS NEXT、十余类小程序和H5全端，承载月活12亿的业务体量。JetBrains 2025年的开发者生态调查显示，中国区30.27%的专业开发者在做小程序开发，框架选择上uni-app占35.06%，微信原生占34.21%，两个方案吃掉了近七成市场。

小程序大盘也在增长。QuestMobile的数据显示，截至2026年6月，小程序整体月活跃用户规模达到10.23亿，微信小程序9.62亿，支付宝和抖音小程序分别向外渗透。

但社区反馈不是一边倒的好评。有开发者在论坛里说，测试下来性能确实比uni-app快，但官方更新太快了，文档上午打开停留在那个页面，下午就提示已更新。TMUI4x组件库的维护者在8月时也表态说还不够成熟，基础API和列表还有问题需要修复，建议再等等。

这些反馈说明一件事：蒸汽模式的技术底子有了，但生态的厚度还需要时间。渲染快和好用之间，还隔着大量细节。

另外，目前蒸汽模式在编译到Web和小程序时会降级为VDOM模式运行，性能优势在非App端还没有完全释放。热更新方面，uni-app x编译为纯原生应用后代码变成原生二进制，不再支持传统uni-app的wgt资源包热更新方案。

访谈里主持人问了一个挺尖锐的问题。Shopify最近放弃了React Native转原生，这是不是意味着AI时代跨平台框架的价值在下降。

王安的回答我觉得值得琢磨。他说AI刚来的时候自己也有点焦虑，担心AI会颠覆掉跨平台框架。但实践和观察之后心定了。原因有两个层面。

一是数据。AI Coding之后uni的应用数量在增长，不是下降。二是内部实践。DCloud自己做的uni-ai和uni-im两个项目，只有一个前端工程师，用着AI并行开发，快速完成了2个系统。如果用原生做，2个应用系统，5个客户端平台，最少需要十几个人。

他后面说了一段我挺认同的话。AI只是工具，需要人来用，需要人来担责。进度延期、线上出bug，你没办法把责任甩给AI。只有懂AI写的代码，才能hold住，才能担起责任。这话放到任何一个AI辅助开发的场景里都成立。

至于跨平台框架的未来格局，王安的判断是AI Coding时代在App平台可能只有原生和uni-app x能留在牌桌上。他提到Flutter和CMP的自渲染在混合原生渲染时有硬伤，React Native从Meta挪到基金会后很难找到一个强力的人做大改。

这个判断对不对，现在没人能下结论。但有一点是确定的，如果跨平台框架能做到和原生没有性能差距，那它在AI时代的生存空间不会缩小，反而可能更大。因为AI帮开发者省的是写代码的时间，框架帮开发者省的是跨平台适配的时间，这两件事不冲突。

写到这里，我想回到一个比较个人的感受上。

蒸汽模式这件事让我印象最深的地方，是2025年初那个时间节点。项目快三年了，不达预期，团队焦虑，然后夏天技术突破，重拾信心。从结果倒推，所有的弯路和焦虑看起来都是成功故事的一部分。但如果当时夏天没有突破呢？

DCloud的CEO说了一句话，如果当初知道要四年，不一定能下得了决心。这句话放在任何一个做长期技术投入的团队面前都成立。很多时候不是不知道方向对不对，而是不确定自己能不能撑到验证方向的那一天。

蒸汽模式现在有了成绩单，但距离生态成熟还有一段路。不过至少有一点可以确认，跨平台开发在性能这个维度上，不再是只能做到差不太多，而是可以做到比原生更快。这个变化本身，就已经改变了这个领域的讨论方式。

（关注这个公众号，一起来探索编程的意义吧）

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：码到深处自然成 老王同志 老王同志《uni-app x蒸汽模式：磕了四年，跨平台性能反超原生》