OpenHarmony 目前主推的應用開發語言是js，談到javascript多數人想當然的認為不适合用在單片機或嵌入式上，它是腳本語言且還是解釋執行的，效率肯定不會高，當然這是傳統意義上的偏見。 個人部落格：blog.csdn.net/yyz_1987，blog.51cto.com/u_10125763 歡迎共同愛好者來訪交流。 歡迎來訪
談一談 OpenHarmony 的方舟編譯體系
早前js僅在web浏覽器上用的時候确實是這樣的。
但自從出現了V8和nodejs, js逐漸的在MVVM前端，移動端H5和後端上都煥發了第二春。微軟針對腳本語言的類型不安全也創造發明了typescript，可見重視程度不一般，基于此還創造了很流行的vscode編輯器。不過ts它最終還是先編譯成了js，隻是寫法上更規範和安全。 谷歌的V8引擎則更厲害，V8更加直接的将抽象文法樹通過JIT技術轉換成本地代碼，放棄了在位元組碼階段可以進行的一些性能優化，但保證了執行速度。源代碼-→抽象文法樹-→位元組碼-→JIT-→本地代碼(V8引擎沒有中間位元組碼)。
是以js造已沒有傳統意義上認為的低性能了。
方舟JS運作時（ARK JavaScript Runtime）是OpenHarmony上JS應用使用的運作時。包含JS對象的配置設定器以及垃圾回收器（GC）、符合ECMAScript規範的标準庫、用于運作ARK前端元件生成的方舟位元組碼（ARK Bytecode，abc）的解釋器、用于存儲隐藏類的内聯緩存、方舟JS運作時對外的函數接口（AFFI）等子產品。
下面介紹下方舟編譯器的故事。
之前隻知道大名鼎鼎的GCC和Clang編譯器，想不到我們也有這麼強大的編譯器。這值得我們自豪，更值得好好學習和推廣使用。
安卓系統使用Java作為程式設計語言，易于開發，但是不會将代碼直接編譯成機器語言，程式運作時有相當一部分代碼還需要通過手機上的虛拟機臨時同步編譯，影響程式執行的效率。華為方舟編譯器采取了靜态編譯的方式，是首個取代了安卓虛拟機模式的靜态編譯器。Android7.0之後的每個系統版本雖然仍然有一些改變，但基本都是在AOT+JIT+解釋執行之間進行動态調整，以找到一個更好的平衡點。可是制約Android運作效率最關鍵的虛拟機這個點，Google卻一直都無法解決。
方舟編譯器直接幹掉了虛拟機，改變了系統及應用的編譯和運作機制，直接将進階語言編譯成機器碼，讓手機能直接聽懂“進階語言”，消除了虛拟機動态編譯的額外開銷，提升了手機運作效率。同時，方舟編譯器還能夠了解程式特征、使用适合的指令來執行程式，是以能夠極大程度地發揮出晶片的能力。
方舟編譯器采用全程執行機器碼高效運作程式，架構進一步得到優化，可供開發者在開發環境一次性的将進階語言編譯為機器碼，手機安裝應用程式後可全速運作程式，帶來效率上的極大提升。根據華為實驗室的測試資料，EMUI 9.1在僅僅對系統元件System Server應用了華為方舟編譯器後，就帶來了系統操作流暢度提升24%，系統響應性能提升44%。
目前，方舟編譯器聚焦在 Java 代碼性能上，未來，方舟編譯器将覆寫多種程式設計語言（包括 C/C++、JS 等），多種晶片架構（包括CPU、GPU、IPU等），覆寫更廣的業務場景。
方舟編譯器的誕生經曆過很長的過程，是一幫滿腔熱血的工程師在華為大平台之上經過多年的醞釀和磨砺，一步一步發展到今天，是必然的産物。
2009年下半年開始，第一批編譯器工程師加入了位于矽谷的華為美研所，從此開始了華為自研編譯器及工具鍊的曆史。初創時期團隊人員少，一個巴掌數得過來，但是幸運的是，這個團隊經過十來年的積澱，留下了一批華人編譯器專家的精華。他們平均從事編譯器相關行業20+年。相應的平均年齡40+ 。 作為IT行業的研發人員，我認為這個年齡正是人生的精華，對技術的了解最透徹、精純。同樣幸運的是，華為對基礎技術的持續投入，在國内也孕育了一批高達數百人的編譯、虛拟機的相關隊伍。裡面聚集了國内最頂尖的人才。可以說，中國做編譯和虛拟機的，有四分之一在華為。
編譯器團隊的業務從零起步，經曆的産品包括多核晶片仿真、基于GDB的調試器、GCC和LLVM基礎上的編譯器設計，為公司主航道提供了大量的工具鍊，也創造了很多性能優化的奇迹。可是我一直認為，最大的收獲在于培養了大量的人才 。
在經曆過這些産品之後，我們感覺到華為内部紛繁複雜的産品需求，應該需要一套自主的軟體程式設計體系來支撐。單純憑借開源的零散的軟體來定制不同的業務需求，效率低下，而且不論是對編譯/虛拟機等系統軟體還是應用軟體團隊來說，都沒有積累，是很大的浪費。還有一個重要因素，我們從不同的國際大公司聚攏在一起，對這個行業非常了解，很清楚像華為這樣的大公司擁有自己的程式設計體系是多麼的重要。我們都非常渴望做這個事情。
最終促使我們下決心的是一個設計程式設計語言的項目。它的需求是，有沒有可能開發一種新的進階語言，類似matlab，同時又能夠發揮DSP的硬體能力。傳統DSP軟體的開發嚴重依賴于類似彙編的intrinsic，當晶片換代時，這樣的軟體不得不重新設計和實作。是以，這裡很直覺的就提出新語言的需求，同時兼顧産能和性能。這就是我們的進階語言Cm的誕生。這是一個在C基礎之上融合了類似matlab資料類型和操作的語言。為了追求性能，大量的優化需要在進階IR就開始，即在文法樹上進行徹底優化。工作的重點集中在前端，必須對文法樹進行深入改造。
GCC沒有被我們選中，因為它的前端過于晦澀，需要依賴lex/yacc這類工具自動生成一些代碼，這些代碼很難用人工去了解，而新語言的開發需要頻繁的改動前端。Clang的前端是手寫的，非常友善閱讀，是以我們就以此為基礎進行Cm的設計和實作。Cm取得了巨大的成功。但是，暴露出的問題是，在别人的開源編譯器上進行深入的改造，效率太低。有很多具體問題，這裡不展開。
至此，那個自主程式設計體系的問題又進入我們腦海，揮之不去。首先，從純技術角度來看，華為的業務從最初的CT發展到今天的ICT，編譯器工程師面對的晶片從DSP，CPU，GPU到NPU，面對的計算類型和資料通路類型種類繁多，編譯器要适配的優化和實作也種類繁多，在各種差異存在的同時又有共性存在。依靠開源的項目實作上述目标，幾乎是不可能的，或者說效率是非常低下的。最大的原因在于每個改動尤其是IR以及基礎優化的改動，在他人的項目基礎之上是很難順利完成的。其次，從公司的業務來看，華為内部龐大的軟體開發隊伍以及無數的軟體項目，其實是存在很多共性的，一個略微通用的軟體開發全棧，從程式設計語言開始往下直至核心，對于多數項目是有很大收益的，特别在版本維護、演進和優化上。
基于上述現實，我們一直在思考的是，應該有一個自主設計的中間語言，也就是編譯器的IR，作為一切軟體編譯和運作的基礎。進而避免在舶來品上進行基礎性的改動帶來的痛苦，也不需要考慮是否跟随舶來品演進的問題，進而制定自己的技術路線。我個人堅定認為，華為龐大的軟體開發體量，迫使我們必須有自主要制獨立演進的軟體編譯分析架構。在此，我們要求這個IR具有很強的伸縮性，能夠消化多數常見的語言特性，動态的或者靜态（當然，很可能一下子達不到這個要求，但我願意也能夠大幅修改）。在此基礎上，編譯器的輸出應該具有多樣性，既可以直接編譯成binary，也可以不同層次的IR輸出，即以中間代碼形式打包，類似Java的位元組碼。既可以直接送給硬體，也可以中間碼進行多種格式的分發。下面這張圖展現了我們的意思。
基于此，走自主研發的道路是無法回避的，特别是目前的GCC、LLVM和Open64等IR的設計是沒有考慮Java這類語言的特性，包括對象模型以及各種動态特性的描述，與其在他人基礎上不停打更新檔，不如從頭開始設計一個全新理念的IR。這也就是上圖中紅色的Maple IR。 對于技術人員來說，擁有一個每個細胞都具備自己基因的編譯器，是多麼惬意的事情。這也是大家的一點技術情節。
方舟編譯器原先的名字叫MAPLE（Multiple Architecture Programming Language & Environment），這也是吻合了我們上圖的意思。在開源的代碼中可以看到很多maple字眼，以及檔案的字尾名為.mpl以及.mplt等。MapleIR是重新設計的，跟傳統編譯器最大的差別在于我們在IR中引入對象的概念，也引入異常處理、同步操作等，是以，它能表達的語義比LLVM和GCC更貼近進階語言且囊括了語言的動态特性。
從上圖的描述可以看出，方舟編譯器是會輸出中間碼格式的軟體包，中間碼是平台無關的。這意味着未來的規劃中，我們能夠服務于一個分布式、多裝置的系統，各裝置接收的軟體包可以是二進制或者中間碼格式。根據裝置的能力大小，中間碼所包含的資訊可以不同。為了實作這個能力，方舟引擎應運而生。這是針對中間碼的執行引擎，類似于Java虛拟機。是以一個裝置既可以采用直接運作機器碼，也可以采用方舟引擎運作中間碼。不同于Java虛拟機的是兩個方面。一是，方舟引擎輸入的Maple IR，這是瞄準多語言的，是以，它比Java位元組碼的表達範圍大了很多。隻要能編譯成Maple IR，引擎就可以執行。二是，方舟引擎未來要包含仿真能力，也就是說，開發人員在沒有實際硬體的條件下，可以仿真一些裝置并運作方舟軟體。
方舟最早的産品可以追溯到2016年，是JavaScript程式的編譯器以及虛拟機，代号為MapleJS。它的目标裝置是IoT。配合華為的LiteOS，可以支撐多數的IoT小裝置。MapleJS的整體記憶體消耗在十幾KB級别，好于三星的JerryScript。
最近火熱的方舟編譯器的産品是針對安卓系統下面的Java程式的靜态編譯（原來代号叫MapleJava）。把Java代碼直接編譯成機器碼，所有的動态語義都通過靜态方法來解決。這樣的話，Java虛拟機就不用存在了。在安卓系統中，ART（Android Runtime）也不需要了。最常見的卡頓原因，即GC，是通過Reference Counting解決（環引用通過一個按需觸發的backup GC搞定，觸發頻率低到可以忽略不計）。這也是方舟取得流暢度提升的一個主要原因。綜合來講，做靜态編譯的最強大的地方在于看到更多的程式資訊，這其實是為我們将來更宏偉的計劃做準備。大家常見的虛拟機JIT編譯可以得到profiling資訊的優點，在靜态編譯通過訓練一樣可以獲得，隻是兩者在資訊類型和資料量上各有千秋。
前面圖中描述的MapleIR，其核心設計思想是能夠相容常見的幾種語言。這個要求背後隐藏的一個長遠的設想就是消除跨語言的障礙。舉個例子，在Java程式設計中如果想調用C庫，則必須通過JNI機制實作。這個實作的成本是很高的，因為兩種不同語言的資料類型、調用約定完全不同，又牽涉到跨語言的異常傳播和記憶體管理，不得不通過虛拟機進行昂貴的處理，效率十分低下。如果能夠把兩種語言都翻譯到MapleIR，在IR上進行資料類型的融合，并在相當大程度上實作調用約定的統一，那麼則可以極大的提高效率。我們把這個計劃稱為“拆牆行動” 。在拆牆行動基礎之上，在我們長遠的構思中是要做全程式優化的，這是一個跨語言的全程式優化，是對我們自己的巨大挑戰。
顯然，我們的理想不是做編譯器，而是做軟體開發系統。這是一個相當大的範圍，可以了解為軟體開發的生态。我們今天在做的每一件事情，包括Java靜态編譯，都是為這個目标做準備。它的未來已經着眼于建立完整的軟體開發體系。在這整個生态中不得不提的就是程式設計語言和程式設計架構。軟體開發人員看到的就是程式設計語言和相關架構，是以，這是生态的入口，方舟的未來必然在語言上要嘗試，即使失敗也要做。基于此，一個強大的具有相對自動适配能力的編譯器前端是必須的。這個前端最大的特點必須是能夠最大程度上的自動化，降低語言設計過程中的各種反複帶來的開發成本。
除此之外，大量的基于一緻的IR的開發工具，包括調試、調優等，必定會應運而生，為此，我們願意和業界的共同愛好者一起努力，建構一個完整的方舟體系，在程式設計語言、編譯、分布式異構程式設計架構、分布式運作系統等多個領域奠定基礎。
OpenHarmony上的js，得益于方舟編譯器的神威相助，自然性能也是提高了一大截。可以直接編譯為機器指令執行，不需要經過解釋器和虛拟機執行。且它的這套JS UI架構是基于ACE架構模型的，系統UI和各種api調用，直接調的是底層的C++接口，效率當然沒問題。
Adaptive Communication Environment（自适配通信環境），簡稱ACE。為一個以C++的Template技術所做成的開放源代碼的可跨平台的網絡應用程式的程式庫套件。
ACE自适配通信環境（ADAPTIVE Communication Environment）是可自由使用、開放源碼的面向對象（OO）架構（framework），它實作了許多用于并發通信軟體的核心模式。ACE提供了一組豐富的可重用C++包裝外觀（wrapper facade）和架構元件，可跨多種平台完成通用的通信軟體任務，其中包括：事件多路分離和事件處理器分派、信号處理、服務初始化、程序間通信、共享記憶體管理、消息路由、分布式服務動态（重）配置、并發執行和同步，等等。
ACE的目标使用者是高性能和實時通信服務和應用的開發者。它簡化了使用程序間通信、事件多路分離、顯式動态連結和并發的OO網絡應用和服務的開發。此外，通過服務在運作時與應用的動态連結，ACE使系統的配置和重配置得以自動化。
下面是ACE的體系結構圖：
從這個圖中,可以很明顯的看出,ACE架構的大緻輪廓。
從底層往上，依次是C風格的OS适配層,也就是對不同的作業系統底層調用的封裝；
上一層是C++的封裝類，就是把各種系統調用和系統對象封裝成C++類對象；
再往上就是架構層，主要就是Reactor, Acceptor, Connector和Proactor。
在上面就是ACE提供的一些服務元件。
有人會說js不是有一種鴨子模型的用法，編譯時怎麼知道類型呢，隻能解釋執行吧。這裡有個限定是OpenHarmony上的js隻支援ES2015标準和嚴格模式（use strict)，也就是說把之前那種js寬泛的用法給拒了，其實這是好事。js文法不斷進化，越走越規範了，早已不是傳統腳本語言的範疇了。
OpenHarmony 是真正意義上的面向未來、萬物互聯的全場景作業系統。
想象下未來任何裝置都可以發揮出自己獨特的能力，且隻需各自發揮自己擅長的能力即可，互相之間可以快速連接配接、能力互助、資源共享。不需要裝app也不需要繁瑣的操作，即便個别硬體性能不好，隻要搭載鴻蒙都是可以輕松連接配接使用，不會占用太多的性能，這體驗多讓人興奮。音響效果好，裡面沒歌曲操控不友善，手機一滑動用音響放歌曲。手機編輯不友善，手指一劃動，輪轉到電腦上辦公。電影正在在手機上觀看，直接輪動到電視上全家觀看，這些在華為的産品上都已是現實。華為的創新力，在國内真可謂稱得上是No1。單憑OpenHarmony 的軟總線技術這一創新，相信就會有更多美好的場景體驗在路上。
最後推薦下這一優秀的系統，希望更多人加入openharmony的隊伍共同豐富下生态。目前還不太完善，比如開發闆太少，甚至沒有旗艦版能跑完整openharmony3.0的全部功能。我覺得這是openharmony目前最大的痛點，但未來可期。
鴻蒙OS的“分布式OS架構”和“分布式軟總線技術”通過公共通信平台、分布式資料管理、分布式能力排程和虛拟外設四大能力，使開發者能夠聚焦自身業務邏輯，像開發同一終端一樣開發跨終端分布式應用，也使最終消費者享受到強大的跨終端業務協同能力為各使用場景帶來的無縫體驗。
是多種終端裝置的統一基座，為裝置之間的互聯互通提供了統一的分布式通信能力，能夠快速發現并連接配接裝置，高效地分發任務和傳輸資料。
分布式資料管理基于分布式軟總線的能力，實作應用程式資料和使用者資料的分布式管理。使用者資料不再與單一實體裝置綁定，業務邏輯與資料存儲分離，應用跨裝置運作時資料無縫銜接，為打造一緻、流暢的使用者體驗創造了基礎條件。
分布式任務排程基于分布式軟總線、分布式資料管理、分布式Profile 等技術特性，建構統一的分布式服務管理（發現、同步、注冊、調用）機制，支援對跨裝置的應用進行遠端啟動、遠端調用、遠端連接配接以及遷移等操作，能夠根據不同裝置的能力、位置、業務運作狀态、資源使用情況，以及使用者的習慣和意圖，選擇合适的裝置運作分布式任務。
鴻蒙OS将N個裝置組合成1個“超級終端”，硬體互助、資源共享，根據個人需求自由調用。華為消費者業務軟體部總裁王成錄在鴻蒙OS 2及華為全場景新品釋出會上表示，“超級終端”在控制中心中提供了手機與PC、平闆、音箱等各個裝置的無線連接配接組合，隻需要手指将不同裝置的圖示輕輕滑動到一起即可實作深度連接配接，為萬物互聯時代提供了一種全新的連接配接、操作方式。
安卓和iOS受限于較大的系統體積，難以在小型記憶體終端上廣泛搭載。
鴻蒙OS定位于面向未來的IoT作業系統，為滿足萬物互聯的全場景智慧時代對OS提出的新要求，實作子產品化解耦，根據不同裝置的硬體能力與需求組合拼裝，在不同的裝置上都可以彈性部署。同時，鴻蒙OS通過分布式軟總線連接配接不同終端，讓應用輕松調用其他終端的硬體外設能力，為消費者帶來跨終端無縫協同體驗。
生态共享：讓開發者“書同文”，讓終端“車同軌”
鴻蒙OS配備面向多終端開發的統一 IDE（內建開發工具），可支撐開發者實作一次開發、多端部署，最終實作跨終端生态共享。跨終端生态将打破各終端被不同系統隔離的“孤島效應”，将大大降低使用者在不同終端間資料傳輸的門檻，并提升使用效率與便捷性。
鴻蒙 2.0 全面開源，助力硬體廠商與開發者
2020年，華為面向開發者釋出鴻蒙2.0的Beta版本，并宣布将鴻蒙OS的源代碼捐贈給開放原子開源基金會進行開源孵化。根據華為公布的開源路标，2021年10月以後，鴻蒙将面向4GB以上所有裝置開源。
面向硬體生産廠商：華為開放源代碼、SDK、開發闆/模組、HUAWEI DevEco等平台和工具鍊，為鴻蒙OS裝置提供一站式開發環境。
面向應用開發者：鴻蒙借助分布式軟總線技術，為開發者提供包括程式設計架構、APIs、DevEco、方舟編譯器等一系列平台及工具鍊，幫助開發者快速開發基于鴻蒙系統的跨裝置、全場景的應用軟體。
實作合作夥伴快速、低成本連接配接使用者：
合作夥伴的智能硬體産品能夠基于鴻蒙OS，實作極簡配網、萬能卡片、極簡互動、硬體互助等能力。使用者手機一碰即可将智能裝置聯網，無需安裝APP也能随時控制，有效解決了裝置智能特性使用率低等難題。
各合作廠商産品可融合成為“超級終端”：
基于鴻蒙OS，各合作品牌廠商之間互相分離的裝置可以根據消費者不同的需求、不同的場景，組合不同裝置的軟硬體能力，融合成“超級終端”。
引用：
方舟程式設計體系 - 知乎
認識 V8 引擎 - 知乎
TypeScript中文網 · TypeScript——JavaScript的超集
鴻蒙OS：萬物互聯，方舟Compiler - 吳建明wujianming - 部落格園
鴻蒙OS2全場景體驗有點強，簡單的使用，不簡單的體驗
ACE架構簡介以及一個基于ACE的C/S服務程式執行個體_擁抱變化-CSDN部落格_ace架構
ACE架構了解(一)_1-CSDN部落格_ace架構
ACE架構介紹 - 知行合一 - OSCHINA - 中文開源技術交流社群
華為Developer文檔中心
華為方舟編譯器官網正式上線，寫一篇你應該知道的科普文章_郭霖的專欄-CSDN部落格_方舟編譯器