HarmonyOS api8 ArkUI正式发布于杭州HDD线下沙龙 原创 精华
杭州HDD观后感·大为震撼
作者：张旭乾（ID:九弓子）
2022年的HDD在杭州，我有幸成为受邀开发者之一。
这次HDD的主要宣传内容之一，就是关于HarmonyOS 3.0发布后开发者可以直接用最新版的DevEco Studio开发api8版本的eTS声明式开发范式。
这对于接触过HarmonyOS开发的开发者来说，可以说是非常重要了。
但其实呢，这半年关于api7 8 9 在上一个版本的IDE我基本都大致了解过了。已经大概清楚能有什么更新和重点。
吸引我的活动议程还有在开场ArkUI之后的HMS Core的3D图形技术，和Serverless云服务。
HarmonyOS 3.0带来了Api8
从接触HarmonyOS开始到现在细说也快两年了，我一开始关注就是因为在这里可以用JavaScript语言写手机app。
从那个只为应付简单场景的api5，到js+java混合开发的api6，勉强可以维持常用应用场景。
一直等着文档中描述的api7版本更新，没想到HarmonyOS 3.0的版本更新直接对照openharmony的api8更新上线。
不能说是正中下怀吧，可以说是喜出望外了属于是。
虽然这个架构图已经在openharmony3.1的发布会上见过了。
但这一次是HarmonyOS同步这样的能力，对于整个“鸿蒙”北向应用开发可以说是意义重大。
1.优雅简洁的eTS
首先新版本ArkUI使用的声明式开发范式eTS解决掉了传统前端三件套开发面临的一个窘境。
代码臃肿，样式频繁复用导致css规划繁琐，多层UI组件套嵌后事件混乱难以维护。
eTS的声明式开发范式是将一个常用界面组件需要的属性和方法，统统封装成了原生平台自带的链式回调函数。
一开始可能不太习惯，但是一旦接受了这种单语言(ts)书写界面的设定。就会沉迷其中不能自拔，以后就是天王老子来了我也不乐意多写一行标记语言和css。
当UI的书写变得函数过程化，将更便于与数据和事件动作一起打包封装。这样的设计让前端对于未来ArkUI下的UI框架设计，多了更多的想象力。
2.问题不在于性能，因为性能已经被解决掉了
用js、ts书写前端面对最大的质疑就是性能问题。
然而其实这本身也是一个伪命题，因为之前的js ts之所以有性能问题，是因为他们跑在chorm内核里，浏览器网页里。是上层弱类型寄生语言。
而eTS之所以选择ts语言肯定是要做强类型定义后去底层编译处理，我们开发HarmonyOS的app的时候必然是要先编译后安装再运行。
这里就与web开发有本质的区别，我们写的代码并不是跑上去的代码。
换句话说，我们这里写的eTS在ArkUI的加持下本质上写出去的是具备C++代码能力的图形组件。
3.TS/C++混合开发，把跨平台玩的明明白白
其实HarmonyOS一直被网友诟病的问题就是在java和安卓。
Java是一个时代的产物，解决了当时的问题。
但到了现在的手机里看起来更像是仗着安卓生态不依不饶，让HarmonyOS应用开发者没办法忽视安卓生态的车轮。
那么问题来了，为什么不用安卓的车轮。
答：因为js ts开发者本来也不会用。
在我看来HarmonyOS既然选择了js/ts做ArkUI的开发语言，那面向的开发者大程度会来自现在的浏览器web开发。
Web开发在W3C标准的引领下给全球程序员指了一条明路，网页即应用。
在未来随着设备性能和web平台能力的加强。
不论大小的软件公司，都会在网页书写一个自己项目的运行端，即开即用才是未来。
那么web向开发者其实本身就不会去考虑跨平台，或者他们写的代码本来就是跨平台。
前端的js本身就借着浏览器在跨平台。
后端为了给分离后的前端交出web平台接受的数据，早就已经深入到系统底层。
近几年随着网页汇编wasm的流行，网页也已经有很多核心业务在做前端C++化。
最大程度的不浪费用户设备性能，以保证给用户提供更多元强大的浏览体验。
比如：网页视频剪辑，云电脑云手机云游戏，webGL即开即用的webVR AR场景。
那这样的大前提下，面向未来的HarmonyOS应用开发，为什么要向java和安卓妥协？
Xcomponent是ArkUI提供给前端一个高级UI组件拓展场景，TS语言负责应用的业务逻辑，C++实现的动态链接库接入NativeAPI实现更底层的高性能需求与图形需求。
单从这个场景就能看到未来的开发者人群是怎样的一群人。
手中写出的代码本身就自带跨平台属性，那么借着openharmony与HarmonyOS的联系。
我们开发者写的北向软件应用同样可以无缝跑到服务万物互联的openharmony开发板标准系统之中。
4.为什么非要c++？
因为未来就是图形，
图形就是数学，
数学需要计算，
计算需要性能，
性能需要底层，
底层需要c++ 。
最开始吸引我的内容不仅有这次更新的api8，还有议程表单上的HMS Core 3D图形技术。
如果想要前端场景具备自己应用的核心表现力，3D就是当今无法忽视的一种重要场景。
3D图形学开发，openGL就是无法忽视的开发内容。
HarmonyOS从去年就已经支持openGL ES，到现在的ArkUI同样具备webGL与Xcomponent。
目前从官方看到的示例中，Xcomponent不仅能实现Surface接入视频摄像头的画面，同样可以渲染出cocos游戏引擎产出的3D游戏画面。
那么这就给ArkUI做应用开发，提供了一个跑3D项目的场景。
通过HMS Core 3D图形技术新能力的介绍，得知一个惊为天人的消息。
手机不仅能够通过拍照产出模型，还能通过拍照产出材质球！我个人对游戏开发纯属兴趣爱好，但也知道3D相关建模和美术工作的复杂程度全在这两件事上面。
现在通过HMS Core就可以轻松实现基础3D素材的生产，这甚至比2D平面素材制作还要方便。这无疑是一种生产力的改变，肉眼可见的那个时代要来了
…
…
Web3.0…属于是没有一句说元宇宙，句句都在说元宇宙
5.每个人都可以是一个军队，Serverless + 低代码
我个人并不喜欢元宇宙，但元宇宙背后技术我不仅不排斥而且非常着迷。
Web3.0 为开发者勾勒的场景是数据即资产，每个人都是数据的生产者，也是数据的消费者。
更丰富的场景体验就是必须的开发内容，但是代价就是开发者未必具备同等需要的开发能力。
Serverless本身也在我强烈求知的领域，华为的Serverless接入HarmonyOS应用开发，我做过初步的尝试之后。我的感受就是，非常过瘾。
本地docker环境模拟测试，云端部署云函数。
用户认证SDK，接入的毫无道理让小微应用开发根本不需要考虑用户验证和后端开发。对于我这样的个人开发者来说，简直就是挽救于水火。
在DevEco Studio中不停宣传的低代码加持下，配合Serverless逐渐的易用和便捷。肉眼可见的程序员开发一个复杂程序的门槛正在飞速的降低。
虽然我并不喜欢低代码，但如果低代码能向前推进一步将业务逻辑像蓝图一样轻松通过连线绘制一个可用的程序。
那么未来的开发场景一定会非常有趣，未来可期，与君共勉
前来围观！
楼主的分析过于优秀，只能献出膝盖了
真够详细啊
我来踢场子：
1、HAP也不是全部都是编译后执行，也有解释执行的；
2、安卓现在也有AOT，而且大多数都是AOT，也都是编译成目标代码执行。所以比较的应该是runtime的效率，不应该纠结于编译还是解释。
3、eTS也是先编译成JS再编译成panda ir，所以这里面并没有强类型带来的太多优势。
4、eTS编译成C++的东西，有没有真的在HarmonyOS当中得到应用？
一句话，我认为目前的ARKUI只是一种妥协方案，本身并没有本质上的突破与提高，只是用eTS/JS替代了Java而已，没见到什么牛逼的不行的技术。
围观钊哥踢馆
哪来的场子，这文章分明是被邀请写分享的KPI的KPI。
不过就eTS方面我与钊哥有点不同的意见，就按照大哥这四点一个个回复吧...
------
不是全部编译，也有解释执行，是不是有编译且只有部分是解释执行？那还得看哪里给了解释，哪里给了编译。
我放两张截图吧...手边刚好有一个最新DevEco3.0 Beta4的Demo。
图1是开发源码，从外部导入了json做数据。
图2和3是编译后的hap包，很明显一个页面变成了map js 和 abc三个文件。
abc二进制文件中，不仅存在我从外部导入的json，同样有编译后js文件里面的内容。
css hml json 其实在三件套中本来就是数据的一种形态，这可能就是所说的“不是全部编译”，但我认为这是合理的。因为这些本来就是数据，还要怎么变呢？
那这里abc文件中js语言的逻辑代码编译成二进制，才是真正影响效率的操作吧。不然ark_runtime的存在是干啥呢？
确实这是类web范式，不是eTS，那看完再看eTS会更有趣一点。
但是要结合上面类Web编译的abc一起看，eTS编译后的一样是产出abc二进制文件啊。
不能说有js和map文件存在，abc二进制编译就成了一部分了吧。
至于说哪里是解释运行，怎么运行，我认为人家都产出abc去ark_runtime里面跑，这样的性能效率一定比传统web网页里面直接跑JavaScript快N倍的吧！
-----分割线----
我觉得也是，那么其实还是上一个问题，ark_runtime到底快还是慢其实很好判断。
一个测试样例对比ArkUI的页面和webview网页就能看出来。
-----分割线----
这里我有不同意见，这一个编译看似没什么，实则ArkUI的存在就与平常网页项目开发有本质的区别。
区别就是，ArkUI不是网页。就这一点就足够了。
为什么？
1.遵循w3c规范，实现图形界面
2.没有web内核也能运行
问：是不是在国产系统前进的过程中，顺便实现了半个国产浏览器吧！
我不知道各位什么想法，我认为就算没有HarmonyOS和openharmony，ArkUI与ark_runtime本身就足够惊艳了。因为ArkUI的存在提供了另一种可能，一个JavaScript可以没有web的可能。
-----分割线----
大哥，7月15号才正式发布。
那openharmony3.1前半年就发布了，在开发板上面早就有api8甚至api9，TS/C++混合开发Xcomponent的项目，到底有没有得到应用呢？
应用开发需要带场景带需求，很明显还需要一套混合开发的中间车轮去解决不同需求。
但是JS/C++混合开发的形式，早就在网页中流量好多年了。
前段时间python可以跑在网页里，靠的就是网页汇编wasm。虽然环境不同，但不同的也只是wasm环境向外输出的轮子，并不是内部C++跨平台的程序啊。
ArkUI能提供TS/C++混合开发的场景，面向的就是这样的开发者和团队呀。
如果很难想象的话，就现在网页中JS/C++开发的wasm能做到什么呢?
我举几个例子：
1.视频网站，网页前端的视频解码
2.网页前端运行古老的3D游戏迁移（如：CS1.5）
3.上面说过的python网页运行需要的Pyodide runtime
4.现在最新的云手机云游戏。
....等等
只要前端需要拓展场景，现在前端C++化是必然趋势。那这些新的轮子，多少也可以反馈到ArkUI的TS/C++混合开发的场景。
-----分割线----
总之一句话，ArkUI在现在手机应用开发中可以取代Java，本身就是很nb的技术。
而且面向的是比安卓更广阔的开发者场景和未来。
不是要比较arkui和webview，是要比较arkui和ART，这两个基本上是对等的。如果ARKUI最终的效率相对ART没有显著提升，那就不知道在扯什么淡了。
即使编译成ABC也还是有解释执行的，ABC是byte code，并不是native code。
强类型语言的优势，除了工程管理的需要，更主要是在于编译器中段，也就是基于各种IR或者byte code的编译优化，现在arkui的编译器并没有做多少中段优化，所以我说强类型语言的优势发挥不出来。
TS2C++在ohos的开源代码里面是可见的，这个不是用于xcomponent的，是TS和C++整合开发的一种提高代码运行效率、减少应用尺寸的有效途径，可以利旧C++编译器的各种牛逼的优化技术。
前面的我认同，不管拿什么对比ArkUI。
计算机很简单，能做到就是能，做不到就是不能。
测试就行了，给一个极端环境炸机就完了。
我认为不太需要太过纠结。
就最后TS/C++在ohos的利用，那是天然的可以重构源码。
HarmonyOS天然是闭源，但不代表HarmonyOS没有NativeAPI吧...
目前没有需求让开发者去碰NativeAPI，还不是因为目前开发者太少了。也就去年cocos给了一套HarmonyOS的Native运行库，让引擎可以产出HarmonyOS原生应用之外。
基本个人和小公司，手里不会存在大量的C++原生项目框。即便有也是小模块，但不代表不可以。
所以我认为的是，如果HarmonyOS专区的应用有100个，99个都是不起眼的小应用，但只要有1个在写NativeAPI，只要有1个做的很好。
就说明有问题的是人，不是平台。
就不能说开发者在HarmonyOS做应用是徒劳的，HarmonyOS和openharmony同出一处，手机应用的开发一样能反馈到ohos，而且能直接交付到用户手上。
为了完整阐述我的疑惑，或者说对arkui的挑战，请见下图：
而下面这条绿色线路，现在好像还没见到怎么才能用，deveco是不支持的。
不是说让开发者用NAPI，而是说在deveco里面直接把eTS编译成C++，再用C++编译器编译成.so，这些都是自动的，现在还没看到相关的功能。
不可能吧····.... 弱类型语言必过解释器吧....那要是华为做出来，那不就更nb了
就这个图要是实现了，大呼创举了属于是。
【看到讨论热烈，特意注册账号上来说几句 :-D】
作为ArkCompiler（方舟编译器）的开发者我提供一下信息，供大家参考：
总体来说，OpenHarmony里的ArkCompiler（包括host侧的语言前端编译器以及端侧的运行时）整体思路是，将应用的eTS代码提前编译为字节码（arkcompiler bytecode，简称abc），以及根据profiling支持将部分代码进一步AoT编译为native代码，从而减少在端侧运行时动态解析源代码、编译优化和生成代码的开销；
同时，在提前编译的过程中，区别于传统的做法，我们会希望原生支持TS，将TS的类型标注信息利用起来，基于此进行类型推导分析，从而在静态编译阶段就得到较多的类型提示信息，并将这些信息通过abc文件保留到运行时，这样运行时在开始执行代码的时候就具备了一部分的类型信息而无需完全依赖传统的运行时profiling和speculation；AoT编译器也能利用这些类型信息，从而更有效地施行编译优化和生成native代码；
再进一步，eTS也会在目前兼容TS的基础上，根据鸿蒙应用开发和运行的需求进行不断完善，包括对语言特性本身的扩展和定制，这也会是ArkCompiler接下来结合eTS语言设计进行优化的一个重要方向。
上面说的工作有的已经完成，有的仍然在持续进行中，现在OpenHarmony社区里其实可以看到相关的一些工作
1）ArkCompiler eTS frontend - 这是eTS的前端编译器，目前支持标准的JS/TS编译。-
https://gitee.com/openharmony/arkcompiler_ets_frontend
2）ArkCompiler字节码优化器 - 这里会对字节码生成进行编译优化。 -
https://gitee.com/openharmony/arkcompiler_runtime_core/tree/master/bytecode_optimizer
https://gitee.com/openharmony/arkcompiler_runtime_core/tree/master/compiler
3）ArkCompiler eTS runtime - 这里提供eTS字节码和AoT执行环境。 当前abc解释器（包括C++实现的解释器和汇编解释器）更成熟，包含类型推导分析以及native代码生成等在内的AoT仍然在开发中，在代码仓里也能实时看到进展 -
https://gitee.com/openharmony/arkcompiler_ets_runtime
https://gitee.com/openharmony/arkcompiler_ets_runtime/tree/master/ecmascript/interpreter
https://gitee.com/openharmony/arkcompiler_ets_runtime/tree/master/ecmascript/compiler
此外，还想解释一下。ArkCompiler并不会走TS2C的路线，主要有两个原因：
1）标准的TS是无法轻易被转换为C并用C的语义来完整表示的，这是由TS的动态类型语言特性决定的；业界有过一些尝试的相关项目，都或多或少走到限定TS语言特性这样的路上来；
2）ArkCompiler基于TS类型推导的静态编译，也可以直接从ArkCompiler的IR对接传统编译器（例如LLVM）中后端进行传统的编译优化，当然这取决于我们在编译时间和编译生成的代码执行效率之间的权衡。从前面列的代码仓里应该可以找到相关的在进行中的工作。
后续我们会在OpenHarmony社区提供更多的信息和文档，便于大家更好了解ArkCompiler的状态，同时也很希望有更多的人一起参与进来。
另外，OpenHarmony CompileRuntime SIG也提供了一些基本的信息，后续会在这里逐步完善，并将SIG社区更好地运营起来，期待大家的参与。谢谢
https://gitee.com/openharmony/community/blob/master/sig/sig-compileruntime/sig-compile-runtime_cn.md
hiahiahia ~~ 一顿高强度交流，把编译器开发大哥勾引来了。
git仓都是学习参考资料啊，都别愣着，点赞收藏😄
首先说一下，ARK的相关资料是极其匮乏的，代码仓里的md就是糊弄小孩子的，panda IR也没有介绍，这个锅开发团队应该背着，我跟NEEN反馈过这个问题。坦白讲，我能坚持看这么多代码，然后去反推设计思路，已经是很不容易了，我猜错了也不怪我。
然后回到主话题。这时候我不得不贴出当年老余发布会的这张图：
华为官方介绍，方舟编译器是首家完全替代语言虚拟机的静态编译器，完全不需要解释器。兼顾Java开发效率和C语言运行效率的编译器。相比现有的编译机制：
1.方舟编译器是一种静态的编译方式，而现有的安卓系统，运行一个应用程序首先启动虚拟机，然后读入应用程序代码，逐条解释执行。会占用较多的处理资源，影响程序执行的效率。当然，也有包括AOT或JIT等提前或运行时的编译技术，把部分程序转换成机器码直接在CPU上执行。但是，仍旧无法做到100%做到摆脱虚拟机的执行，这也是当前安卓阵营不如IOS阵营的关键。
2.华为方舟编译器的静态编译方式可将语言里的动态特性直接翻译成机器码，手机安装应用程序后可全速运行程序，彻底消除虚拟机的弊病，带来效率上的极大提升。
3.方舟编译器是在开发环境部署的编译器，而现有编译过程，主要发生在手机上，带来额外的资源消耗。
这是当年发布会的话术，虽然三年过去了，可能技术条件有了很多变化，但立的一些flag，要认吧？
好，即使完全不管3年前余总说了什么，那我们现在再来看，现在的技术方案能否匹配OHOS的需求，我认为，现行方案有如下几个问题：
1、无法适应mini和small设备的开发需要，做不到一次开发多端部署，只能是富设备的多端，瘦设备被遗忘了。
2、无法适应分布式应用开发的需要，这套开发语言/环境，体现不出针对分布式进行的设计和优化。
3、性能天花板明显，我理解AOT在做，也理解类型推导带来的提升，但我认为这些都很难超越AOT加持的Java+ART组合。
4、无法与将来的静态编译语言形成有效技术积累和继承，现在基于eTS/js开发的应用和组件，将来怎么办？再一次重头再来吗？
总而言之，我觉得OHOS的runtime和应用编程环境设计，应该是胸怀星辰大海的一条爬喜马拉雅北坡的攻坚之路，而不是再造一个Java+ART组合的苟且，更不是满足于稍优于小程序和webview的小改良，如果不志存高远，原地打转几年后，还是马马虎虎，形不成真正有效的竞争力。
感谢大家对方舟的关注和关心。
开源社区里的相关资料目前是很匮乏。之前主要是通过在类似HarmonyOS公众号上定期放出一些主要技术博文的方式来提供。后续我们会加强社区资料的丰富性、及时性和透明性，更多地直接在社区开发各种文档。
仅代表个人观点：
方舟编译器和运行时的目标事实上应该一直没变过，就是为了更好地支持鸿蒙应用。而在鸿蒙发展的不同阶段，其实也对具体的技术方案提出了不完全一样的诉求，所以方舟编译器也会随着鸿蒙业务的发展需求，提供更加合理的规划和更合适的技术方案。这也是为什么从局部来看可能技术方案有些变化的原因。
具体到某一些技术方案上，比如为什么方舟会放弃全静态编译，也正是考虑到鸿蒙万物互联的需求。要想做到一次开发多端部署、分布式协同和迁移等场景的应用开发和运行体验，我们需要一个设备无关的代码分发格式，以及一个为应用代码屏蔽掉多种设备平台差异的运行时；同时不同设备能力（CPU、内存、ROM等资源）的差异也使得我们需要提供更加丰富和灵活的代码执行方式，而非单一的全静态AoT编译方式。同时，业界的相关技术也在高速发展，无论是运行时的解释执行、动态编译执行，还是内存管理等相关技术都持续在演进，持续在解决之前因为具体算法和工程方面不够成熟导致的运行性能和GC卡顿等等问题；结合高速持续演进的技术，我们也需要实时审视前期发现的问题、以及基于前期问题判断而给出的早期解决思路，是否需要动态进行调整，这也是一个务实的解决问题的态度。
前面说过，方舟编译器和运行时支持万物互联的鸿蒙应用的目标一直没有动摇过。但我们也清醒地认识到，这是一个长期的工作，我们承认在当前阶段还更多地是处于打基础的阶段，但我们也正希望花时间认真把基础打好，这样才能在将来更好地支撑在这一个完全自己构建的基础平台上长出更多有差异化的、符合鸿蒙业务需求的且能实在产生竞争力的特性。比如对分布式应用开发及运行，在编程语言、编程框架以及相应的编译器和运行时方面，方舟有一些规划和计划，但这些还并未很直接地体现在当前的打基础的工作中。
最后，如一开始提到的，现在鸿蒙和方舟的主要开发工作都在开源社区进行，随着开源社区工作及相关机制的逐渐成熟，后续的信息会更加丰富和透明，也是希望借此社区平台，能让更多的开发者加入我们一起来完善方舟。
这个帖子的回复内容可比任何一篇技术贴都丰富。
看来又要关注一波大佬了。