作为一个终端长期从业人员，我只能说走了一条无比艰难的路，这条路上限低坑还多。性能上限大概率是浏览器。
- CPU有效利用率 ：先说ArkTS 选型问题，js 语系是单线程语言。鸿蒙为了充分利用CPU多核性能，将单一应用的js 线程数设置成 8 。然而，对于多数应用来说8压根不够，无论虚机类型的 android 或者机器码的ios 应用。启动过程中50+线程稀松平常。 设计成8 线程的原因根本就是js运行效率低，不得不降低worker数量，否则应用、系统流畅度会降低。
请反驳的看这里，不要说android、ios 都是垃圾设计，鸿蒙设计超前、优化彻底、方舟屌炸天。这些银弹在系统纬度压根不存在。应用启动50+线程是因为业务需要如此，程序员并不傻！
2. 技术选型问题-头秃 ： js(ts)+native(c/c++) 的选型简直是灾难。js 是一个长生命周期，内存管理稀碎的语言。再碰上native(c/c++)各种内存泄露、内存践踏。这个选型逆天至极。想想就头秃。
3. 技术选型问题-俄罗斯套娃 ：各家APP基本都用了Hybird技术保证业务及时性。动态化好不好，千家之言。动态化必不必须，答案肯定是必须的。目前，鸿蒙的方案是js runtime堆叠，套娃之后的性能可以预见。
4. 技术选型问题-生态问题： 在java与js 生态之间摇摆过一次，这点搁置不提。一个号称ts的语言，竟然无法支持js 标准函数。此外，明显打算采用arkts 吸引前端开发，竟然几乎完全抛弃nodejs生态遗产，另造轮子。只能说，基础架构眼光不够。举一个例子：js 中的http函数需要替换成ohs.net.http。
综上所述，鸿蒙终端架构设计与技术选型堪称地狱级。
PS：纯吐槽系统的终端架构设计，鸿蒙大佬们看着不爽，我*帖删**。如果让我设计终端架构，我会选择Go 生态，毕竟Go的生态、性能、与Native(C/C++)集成都很省心，全心全意解决Go 的旁路生态建设——排查工具等即可。