背景：
uni-app x 蒸汽模式，发表了比原生渲染还快的benchmark。这让业内大为震惊。
本期请来了DCloud的CEO王安，从设计者的角度聊聊，为什么做这个产品、为什么这么做而不那么做、性能提升的关键在哪里？
1. 跨平台框架赛道，并非当下VC的关注领域，DCloud投入4年，花了几个亿搞 uni-app x，这种执着和冒险的底层逻辑是什么？
我做跨平台已经二十多年了，老骨灰了。我做的产品，虽然也有很大的市场体量，但也一直被开发者们吐槽。
uni-app的第一代产品，在小程序领域是市占率第一的，不管大厂小厂都在用。因为用uni-app开发小程序不会比原生小程序性能差，还能跨平台。
但在App平台，市占率只有百分之十几，主要集中在中小开发者。原因就是App平台的性能不能满足中大开发者的需求。
所以App平台的性能问题，对我们一直是如鲠在喉。
2022年，我们内部讨论 uni-app x 的立项问题，能不能让app像小程序那样，做到与原生开发相比没有性能损失。
其实团队内部，对 uni-app x 的立项是有反对声音的。如果我们守住原有盘子，做好服务和商业化，能让团队成员的日子过的更好点。
但一旦要立项解决跨平台框架的性能问题，这注定不是一个短期能解决的问题，投入肯定不少，机会风险很大。
当时觉得就是不服气，觉得这辈子不能就一直解决不了跨平台的性能问题，活得太憋屈了，想赌一把。
其实当时我也不知道这个项目一做就是4年，我以为2年能搞定。当初如果知道要4年，那承受的压力会非常大，不一定能下得了决心。
2. 这4年中间，有过犹豫和后悔吗？
中间是走了很多弯路啊。有的路走了很久才发现不通，肯定是非常郁闷的。
但并不会因为走错路而后悔。你在登一个没人登过的山，走错路是正常的。
要说后悔的话，从开始就应该建立一个更高效的探路机制，能更快的验证路线的正确性。
这个机制，我们直到2025年才完善，这是我最大的教训吧。
中间有段时间非常焦虑，大约25年初的时候，当时觉得搞了快3年了，不达预期怎么办。
幸好几个月后，25年夏天，一系列技术突破后，终于重拾信心，知道自己搞对了。
3. 你们建的这个高效的探路机制，是什么？
类似实验室。
就是别着急做产品，别着急提代码。
就是先做实验，体系化的、严谨的做实验。
但是然后呢，你又会发现还不能着急做实验，为了能严谨的输出各种实验报告，其实需要做很多基建，你要先投入大量资源去建实验室的基建。
我们以前吃了不少亏，调研报告不准确，误导了技术决策。这都需要一套良好的实验基建、严谨的实验规范流程才能解决。
有很长一段时间，我看不到产品里提交代码，我也不关注这个指标。我每天只看实验报告。
这个过程可能很多公司都没有，大多数公司的技术考核，可能是产品需求的实现工期、完成度、bug数量。
但对于uni-app x蒸汽模式这种产品来讲，实验室机制是它最终能做出来的核心原因之一。
4. 非常延迟满足啊。不做产品先做实验，不做实验先搞批量实验的基建。那这注定不是短期投入。然后我有点好奇，当初是怎么说服团队成员同意这个指标的：比原生渲染还快。
没有。当初如果定一个比原生渲染快2~3倍的目标，别说团队成员了，我自己都不信。
当初的目标，就是参考小程序，uni和原生小程序没有性能差别。然后app也做到和原生app一样，没有性能差别就行。
就这，当时团队成员都不同意，说做不到，最多能做到15%的性能差距，就是比原生慢15%。为了这15%拉扯了半天。
但后来发现，实现到15%的性能差距，仍然困难重重。只能一路往底层追，从系统组件源码、追到系统底层渲染原理，往下又追到编程语言原理，又往下追到硬件层操作原理。
直到你把整个事情都搞明白了，这时候你才发现，传统的原生渲染一层一层套轮子，叠了太多层了，性能优化空间太大了。
不要说达到原生渲染的性能了，比原生渲染快几倍都没问题。
以前如果我diss一个团队成员，说你做的这个东西性能太差了，怎么连原生的同类组件的性能都拼不过。这个人肯定会觉得这个老板有病。
但现在我可以随便diss，在我们团队，做到比原生快并不难，已经是团队共识了。
当然一个新入职的人，还需要一段时间才能适应这种文化。
5. 原生渲染那么多年的优化，真的是流程很长吗？能举个例子吗？
新的挑战者打破旧的，心里是需要这个世界都是草台班子的信念的。虽然这个新的挑战者也会被后来的挑战者视为草台班子。
计算机工业发展了这么多年，长成了庞然大物，轮子一层叠一层，减肥的空间其实挺多的。
我们公司有个面试题，手机左上角的那个返回箭头，怎么绘制是性能最高的。
很多人在项目中使用字体图标，矢量缩放不失真，暗黑能变色，跨平台都能用，不同平台渲染结果一致，听着挺好。
但是一个字体图标，从你写代码加载字体那刻，到屏幕上最终显示出来，经过了非常多环节。
你可能觉得你就写了几行代码，还好吧。但实际上，
• 首先系统需要从IO里加载你的字体库到内存里，
• 然后需要构造字体管理对象，解析字体头文件，确定字体的很多参数。
• 然后要去字体中的众多字里匹配，你想要显示哪个字符。
• 然后要做文字塑型，确定连字等字间距处理。
• 然后做换行、双向文本流（有从左到右的文字、也有从右到左的，还有混合的）。
• 然后做文字测量，把高宽定下来。
• 然后做光栅化或三角形化。
• 然后提交给GPU。
• 最后整体合成上屏。
这里面提到的每个步骤，都有专业的库负责。这些库的源码如果你看过的话，逻辑都非常多。
在Android和鸿蒙上，这些逻辑还涉及原生的kt/arkts和c库的反复交互。
你只看到你写的几行代码，但实际上背后是几十年的文字系统各种库的协作配合。
你知道了背后的流程多长，你肯定想跳过一些流程，比如就一个返回箭头图标，它理应不涉及换行和双向文本流，但这里又有另一个坑。
不同os，上述流程的可控性是不一样的，有的os提供了专门的api可以跳过换行和双向文本流流程，有的os没有提供。
如果你对文字系统有研究兴趣，可以去看看harfbuzz、freetype、icu这些c库的源码，都是几十年的老库了，每个库都是不同的顶级大牛写的。
但作为一个应用开发者，想优化这块，真没有ROI。
5.1. 所以uni蒸汽模式中的返回箭头、文字渲染，都比原生自带的要更快？
是的。首先要投入大量精力研究每个系统的底层，然后优化，然后再给开发者暴露简单易用的跨平台写法。
6. 你们提供了一个benchmark，一个界面中创建了4050个view和text，渲染耗时比原生短2~3倍。这个测试例让很多人不解、甚至不信。不知道这个访谈中，王老师能否透露一些细节原因。比如这个测试例，是因为uni蒸汽的文字系统更快吗？有些人觉得这可能是你们的测试例定向优化，能解释下吗？[^1]
没有定向优化。是反过来的，如何测试一个渲染系统在处理view、text这种基础组件时速度更快？带着这个问题，我们才在一个屏幕内大量创建view和text来做实验。
你想创建多少个、怎么排布，都可以，文字是数字还是汉字都可以，结论都是 uni-app x 蒸汽模式更快。
这种快，来源于很多方面。uni的文字系统真的更快，如果你把4050的例子改一下，在里面放置更多text组件，你会发现uni比原生快了不止2~3倍，会快更多，界面上文字越多，uni的优势越明显。
除了文字系统快，整个template和Style区域，执行的都比原生快。在4050的例子里，是模板里的v-for创建这些view和text，这些代码都是编译成字节码/机器码的，这些高度优化的二进制码性能更高。
uni蒸汽的排版系统也更快，不管是什么组件，view、text还是其他组件，都要排版。uni蒸汽统一是flex排版，这套排版系统的性能也比原生提供的那些排版布局系统快。并且这套排版也不会为4050这种示例做定向优化。
4050这个例子有拍平和非拍平2套测试数据，都是uni蒸汽快。有些人认为uni蒸汽的4050快是拍平的功劳。并不是的，这2套数据之差，已经说明了拍平在这里能提供的价值。
当然拍平也是我们给开发者提供的一个挺好的性能优化方案，让开发者可以方便构造更高性能的UI。一个简单的flatten属性，这种开发方式比原生高效非常多。
7. 有的原生工程师表示不服，他们也可以在原生的基础上优化代码，跑出更快的原生版数据。你怎么看？
我们需要牢记初心，这个测试例比的是view和text的创建速度，不是比4千多个方格子固定排放后如何快速渲染。
uni提供的就是标准的view和text组件，没有定向优化。原生的对比测试例，也不能为了这个4050的测试例而定向优化。
有的原生工程师说，我用draw的方式，只创建1个view，在上面自绘出4050个方格子出来，不测量不排版，所有格子等宽。
那这就是原生为这个测试例定向优化了。这就没法比较原生的view、text，和uni的view、text到底谁快了、排版系统到底谁快了。
如果你基于draw，自己实现文字测量、布局排版，能布任何界面，那其实就是自己做了一套渲染系统。其实这就是 Compose UI 在Android上做的事情。
首先真的做出来这套系统是非常难的，其次做出来性能也很难匹敌uni蒸汽。
Compose UI 的view和text同屏4050测试例，我们是在benchmark里公开过的，比Android原生view还慢，更比不过uni蒸汽。[^1]
如果某个原生工程师有兴趣钻研此道，自己一个人搞是不行的，这是大工程，还是加入DCloud一起干吧，哈哈。
8. 我有个疑惑，为什么操作系统那么多专业的人，不去把原生UI优化的更快呢？给三方这么大的超越空间
我不是操作系统团队的人，我也不知道他们怎么想的。我可以推测下，随便聊了。
可能有的系统厂商，觉得自己已经够快了，没有竞争压力给他们。因为要动这些底层的东西，代价不低，立项时总会有人问花这么多钱能带来什么财务回报？
很多领先的厂商，有一个产业义务，就是推进用户买新设备。这对用户来说听着有点恶心。但产业链的兄弟们持续有钱赚也很重要，大家有钱可以持续创新，推进产业进步。
然后就是组织大了，跨部门协调也难。
比如Android，原生的kotlin是一拨人，各种c库是另一拨人，现有的框子是一层一层叠起来的，想压穿，需要协调非常多人。
还有的技术栈喜欢自举，比如java/kotlin，很多重要的库是java写的、而不是c或汇编写的。当你的产品哲学是自举优先而不是性能优先，就很难把性能做到极致。
你看v8的源码，那不止是优秀的c代码，很多地方要上汇编的，比如json解析，这就是性能优先。
当然了，如果操作系统的人真的愿意好好优化，肯定是可以反超uni蒸汽现在的benchmark数据的。
不过呢，其实uni蒸汽，也还可以再提升性能，只不过我们也一样，觉得快了2~3倍已经足以。现在立项投很多人力财力再让uni蒸汽快4倍5倍，没有性价比。
如果原生优化的更快了，我们也会立项再追。
还是那句话，现代计算机工业这么多年，这个庞然大物减肥的空间挺多的。
9. AI时代，跨平台框架的价值是否要重新看待了。最近shopify放弃react native，转原生。这是不是未来的趋势？你们搞了4年多，这个跨平台框架是不是在AI时代生不逢时了？
AI刚来时，我也有点焦虑，担心AI会颠覆掉跨平台框架。
但后来实践、观察、深入思考，心就定了。
首先看数据，AI Coding后，uni的应用数量进一步增长，并不是下降。
然后看我们内部的实践，我们除了框架，也做应用，比如uni-ai、uni-im，一个是开源的AI聊天客户端，一个是开源的IM系统，我们和我们的开发者沟通，都是在uni-im上。
如果没有uni-app x和uniCloud，这些项目在我们内部根本无法立项。是因为实际这2个项目，只有一个前端工程师。
如果要用原生来做，2个应用系统，5个客户端平台，Android、iOS、鸿蒙、web、微信小程序，客户端+服务器+测试，即使每个人都在用ai，最少也是十几个人。
除了开发，还要考虑。不同平台，不但代码不同，测试例、测试工具链也不同。但在uni下，不止代码统一了、测试例也是一套。
uni这边，真的从前到后，从开发到测试，所有平台，只有一个人。他用着AI并行开发，快速完成了2个系统。这生产效率和成本，其他方案真的比不了。
主持人：有的人说，我不要6个人，我一个人就让ai干活，写5个平台的原生代码加服务器和测试例，不行吗？
AI只是工具，它需要人用，需要人背锅。工具不背锅。进度延期、线上出bug，你无法甩锅给AI。只有懂AI写的代码，才能hold住，才能担起责任。
尤其是面向广大用户的、涉及重要权益的系统，AI写的代码有问题，造成线上损失，是需要你担责的。
做一些压力不大的系统，比如自用的、有限人使用的内部管理只读报表，可以不看代码。但真要上线，要面向用户承担责任，那人得把关。
回到上一个问题，我们做的uni-ai，它的性能比原生开发的AI客户端都好，和ChatGPT、豆包、deepseek相比帧率都更稳。
如果使用原生开发，每个平台都达到这个性能水平，那我刚才说的十几个人都还不够，那投资得非常大了。
所以uni系产品带来的价值，生产力，非常大。
AI虽然是个工具，但你让它干活时，它也想用好工具，它不会用好工具它就不是个好AI，对吧。
在AI时代，写代码并不是不需要框架，只是需要好框架。
比如ts、vue，这些都是框架，你也可以让AI去写原始的js，但人们为什么不这么做呢？
因为明显是用ts、vue这些好框架，写代码更轻松、更容易保障性能和质量，也更省时间和token。
在AI时代，并不是跨平台框架没有价值了。而是需要更好的跨平台框架。
一个跨平台框架，只跨2个平台，性能比原生差了不少，那么shopify认为AI降低了我的成本，原生带来了更高性能，这ROI是合适的，就会转原生。
假使，我说的是假使，react native的渲染性能比原生更快，那shopify怎么会切原生去？闲的慌啊。
所以AI时代，那些问题比较多的跨平台框架，不管是性能、质量、跨平台数量，如果做的不好，就会没落。
我个人觉得，AI Coding时代，在App平台，可能未来只有原生和uni-app x。其他跨平台框架估计要走下坡路。
这会和小程序领域类似，拼到最后只剩原生和uni-app了。
我这话说的，听起来有点满，其实我是深入思考过的。
新的编程框架规范，对AI非常不友好，很难冒出来。
老的这几家，比如flutter、react native、CMP，如果能解决做到即跨平台、又不比原生性能差，那自然也不可能被AI淘汰。
但flutter的自渲染，包括CMP在iOS上也是自渲染，这种在混合原生渲染时有硬伤。这个在另一篇文章专门讨论过自渲染和原生渲染的问题。[^2]
而react native，从meta挪到基金会后，这个机制有好有坏，不好的就是很难找到一个强力的人做大改，但如果不大改，它解决不了比原生性能差的问题。
shopify本来是基金会的重要赞助者，出力做了不少关键库，更是给基金会出钱。它的撤出，对react native的打击很大。
当然难归难，也不是绝对的，不知道谁家会天降猛人改变局面。
说回来，我认为，AI会淘汰一些简易、低质量的轮子。但复杂、高质量的轮子，永远都受欢迎。AI想要好轮子。
10. uni-app x 刚出来的时候推的是uts语言，现在蒸汽模式又改成了普通的js/ts。为什么会这样调整？怎么考量的？
uni-app x 立项的时候，是参考我们在小程序上的做法，小程序就是把uni-app的写法，编译成了小程序的原生写法，重编译轻运行时。
那么怎么把uni-app x也编译成各个平台的原生应用？比如在Android上，把uni的写法就编译成一个纯的kotlin应用。
这就需要先做一个基建，跨平台的编译型语言，这就是uts，一个语言可以编译成kotlin、Swift、ArkTS。
一个语言，做出来难，做好更难。
但是语言搞定后，我们发现渲染系统做的不好，拖累了整体表现，又开始研究渲染系统。
语言是一个大关，渲染系统又是一个大关，我们连续磕了2个大难关。
当初立项新版渲染系统时，搭配的语言还是uts。因为当时没有预期蒸汽渲染系统这么快。
新版渲染系统出来后，结果是大幅超过我们预期的。我也没想到这块的优化余地这么大，在这么多测试场景中，都能比原生能快2~3倍。[^1]
然后这个时候AI来了，uts语言作为一个新语言，国外模型不熟悉，也没有模型为uts单独做强化学习，给我们带来了巨大的压力。
其实AI在某种程度上，是不利于创新的。不止uts，其他新的编程语言也一样难。
这逼着我们思考，既然渲染系统能快这么多，那么把语言改回到普通ts/js，合体版本是不是也可以做到比原生快？是不是这样的产品才是AI时代更适合开发者的。
这个时候我们团队内部是转不过来弯的，辛辛苦苦搞了几年uts，投入大量心血，真的要尝试换回js吗？自己的孩子，怎么能不心疼？
我自己也给自己做了很多心理建设。
最后是分期立项，优化跨语言通信。先在鸿蒙和iOS上，确认js+蒸汽渲染仍然可以做到比原生渲染快，然后才全体坚定信心，大力推进Android的js更换。
外部看不到，内部其实经历了一个过渡期才把弯转过来。
优化跨语言通信，这个立项最初目标是js+蒸汽渲染系统，能和原生一样快就行。
最终这个项目的结果，也超过了当初立项的预期。
也得益于这几年对语言底层的持续研究，搞明白很多原理，优化后，跨语言通信只损失了百分之几，但蒸汽渲染系统比原生渲染快200%~%300%，最后整合的效果，基本没变，那百分之几在各种评测实验数据上几乎看不出来，还是比原生快2~3倍。[^1]
跨语言通信有个极限例子，就是canvas，在js中绘制碰撞的小球，绘制逻辑都是在js里。最终这个测试例大家也看到benchmark里的数据了，uni蒸汽下，可以绘制几十万个小球同屏碰撞而不掉帧。
最后js+蒸汽渲染引擎这个方案就定下来了，AI熟悉、开发者门槛低、还能热更新，还比原生渲染快，这不就是最佳方案了吗？夫复何求，对吧。
有最佳方案就行，你过去投入的心血，不要遮蔽住你为用户寻找最佳方案的眼睛。
11. 那uts以后怎么办呢？不管是uts语言，还是你们的HBuilder，都是国产自主创新的代表，最近你们基于vscode搞了HBuilderV，感觉这些国产创新的东西好不容易做出来，要被丢掉吗？
国产化，除非是政府资助，对于一个市场化的产品来讲，还是需要在市场中让用户买单。
我们也会觉得可惜，但以国产创新的理由做技术自嗨，得不到用户的认可，没用。
反正我们自己从来不说：flutter、react native不是国产的，请大家支持国产的uni-app。
uts语言不会消失，我们内部也有大量代码是基于uts的，而且我们内部的uts代码还在增加，它仍然是一个不错的跨平台语言。
会的人可以继续用，不会的人，不学也行，原生插件开发也可以使用原生混编。
其实我们还研究过uts直接编译成机器码，发现可行。只是，做出来容易，但想做好，又得几年、好几亿的投入。
除非是政府主导，一定要搞国产化语言，对于市场主体来讲，这事没有性价比。
编译机器码不难，但编译出的机器码非常高效，这特别难。
我们不能假设只要编译成机器码，性能就一定高。
很多语言都尝试过这事，kotlin也有k/n方案，但同样是机器码，它还得处理gc，它的机器码优化程度，和c语言差太多了。
我们也可以很快拿出一个uts编译机器码的方案，但性能想达到第一梯队，就是达到c、zig的水平，需要很长时间和很多资金投入。
至于HBuilderV，这个产品得感谢AI时代，没有AI迁移，这个产品很难立项。
我们的逻辑是这样，给习惯vscode的开发者提供一种选择，有助于大家更接受uni蒸汽，且在AI的帮助下这个产品的成本可接受，那就做了。
目前HBuilderX和HBuilderV会一起演进。
至于未来，HBuilderX是基于QT的，QT以后不会再用了。
其实我们掌握了优秀的渲染优化技术，在PC上也是一样的，后续我们会出uni蒸汽的pc版，届时也会是最快的跨PC平台渲染引擎，体积也会很小。
在uni蒸汽的pc版出来后，我们会再重构HBuilder。
当然也可能换名字。未来AI持续发展，IDE的传统功能都不一定适用了。可能会是一个全新形态。
11.1 那很期待。至于HBuilderV，你们为什么不做vscode插件，而是和cursor一样整体套壳修改？
大家可能对vscode的插件api的丰富度有过高预期。
当初cursor之所以基于vscode套壳二开，就是因为vscode的插件api不够用，AI所需要的功能，插件无法实现，只能整体二开。
对于HBuilderV也一样，HBuilderX里很简单的一个常用需求，就是同时运行多个平台，在底部开一堆控制台，这功能插件就做不了。
还有各处弹出的界面，比如运行、打包，以及我们也有一个AI产品，叫uni-agent，大量的功能需求，用vscode插件无法实现。只能整体二开。
12. 你刚才提到了c、zig，没有提到rust，现在rust风生水起，bun也从zig迁移到rust了。你们的组件不用rust，还使用c语言吗？
rust在pc上发展的更顺利些，手机上用的要少一些。手机系统的c api、ndk编译链，都是围绕c、c++构建的。
不管是c、zig、rust，核心差别是内存谁来管。
其实放大看，所有语言都有这个终极问题，内存到底怎么管。用这点，可以把所有编程语言放在一个坐标体系里看待。
最开始的c语言，典型的手动管理内存。
但人们觉得，我就是开发业务，你让我研究内存怎么管，还经常泄漏，这门槛太高了，不利于编程普及。
然后就出现了gc，就是垃圾回收，java、js，这些语言凭借一点，你别再操心内存了，专注你的业务就完事，帮助这个世界产生了更多的程序员。
然而gc从来都是有代价的，会影响性能。于是有人又想出点子，能不能让编译器来管内存，运行时不要gc了，然后就设计了一套复杂的借用机制，在编译阶段确保内存安全，这就是rust。
但这套机制，学习门槛很高，为了高性能有时还得用unsafe。
于是又有人想，那能不能还是人手动管理内存，但管理的方便点。zig就出现了。
当然zig不止这一个优势，但通过这个对比，可以简单的明白这些编程语言的定位差异。
就我个人喜好，其实我喜欢zig。当然zig的成熟度、生态确实不如rust。
bun的压力来自于基于它的claude code，用户量巨大，带来了很多边界问题。
但bun的问题，并非zig下不能解。
只不过在zig下，需要投很多人来解。但对于一个AI模型公司来讲，能让AI解更符合他们的飞轮。
当然站在第三方来看，折腾这事干嘛，想求稳，应该直接把bun换成nodejs，而不是把bun从zig改成rust。
13. 你也提到一个成熟的产品，需要处理掉各种边界问题，才能获得开发者的认可。那么uni蒸汽刚出来，是否短期内也面临成熟度问题？
这是肯定的。所有新产品都有成熟过程。对于uni蒸汽来讲，就要想各种办法加速它的成熟。
我可以分享下我们怎么做的。
uni-app x 从2023年起第一个版本就开发了自动化测试系统。
并且 uni-app x 坚持一个原则，修复的每个开发者报的issues，都要配套自动化测试例。每个版本发布，都要过测所有测试例才能发版。
我们专门做了一套issues系统，开发人员在提测issues的时候，表单里就有自动化测试例地址。
这几年来，已经积累几万个自动化测试例，包括功能、性能、UI截图对比、内存泄漏、崩溃等多种维度。
每天晚上，在我们内部的持续集成系统里，都要跑几万个测试例，在各种手机os、各种版本上跑，几十万次，做断言比对、截图对比。。。
uni-app x 蒸汽模式 虽然是2026年推出的，但它每次发版，都得通过uni-app x积累的所有自动化测试例。
uni蒸汽的质量管理压力，其实对我们来讲，轻了很多。
以前在vdom模式时，我们还要操心uts语言的质量，现在语言的稳定性交给js引擎处理了。
我们就可以集中精力在渲染系统的质量上。
uni蒸汽还有一个特点：不同平台的组件内部实现代码基本都是一套，都是跨平台的c或uts。所以它的平台差异很小。这也让我们的质量管理压力变小。
精力不分散后，我们也有更多人力投在响应开发者反馈的bug上，现在uni蒸汽的修bug速度还是很快的。
在AI时代，AI其实也在帮助我们把控质量，分析隐患、生成更多自动化测试例。这些都让一个新产品的成熟度比以往更快。
我不能说uni蒸汽已经成熟了，但我认为它的质量是可商用的。
好的，感谢王总的坦诚分享。与王总交流，总能感受到一些新的观点和角度。相信读者们，除了更深度的了解uni相关产品外，还可以从这个访谈中学到一些其他东西，比如一个复杂项目如何立项、如何管理、如何提升性能和质量。更多问题，大家可以留言，我们尽量协调王总回答哈。
没问题。
引用：
1. uni-app x 蒸汽模式各平台和原生的对比benchmark：
• Android - https://doc.dcloud.net.cn/uni-app-x/benchmark/vapor-benchmark-android.html
• iOS - https://doc.dcloud.net.cn/uni-app-x/benchmark/vapor-benchmark-ios.html
• 鸿蒙 - https://doc.dcloud.net.cn/uni-app-x/benchmark/vapor-benchmark-harmony.html
2. 一文讲透原生渲染和自渲染 - https://doc.dcloud.net.cn/uni-app-x/select/native-render-and-self-render.html