HDC技術分論壇：ArkCompiler原理解析
ArkCompiler(方舟編譯器)是組件化、可配置的多語言編譯和運行平臺，它既能支撐單一語言運行環境，也能支撐多種語言組合的運行環境。它目前主要支持的語言是JavaScript、TypeScript和Java。
一、概述
HarmonyOS的設計目標，是成為打通手機、PC、平板、電視、車機和智能穿戴等多種設備的統一操作系統。
圖1 多設備互聯
其應用開發有多編程語言、多范式的支持需求，其中高級編程語言包括JavaScript、TypeScript、Java等，開發范式包括聲明式UI范式、分布式編程范式。 我們需要相應的編譯器和運行時來支撐這些高級應用編程語言的高效開發、部署和運行。 使應用開發者能使用同一套開發框架實現一次開發多端部署運行。并且讓使用HarmonyOS設備的用戶，能獲得統一的用戶體驗。于是，ArkCompiler應運而生。
1. 目標
ArkCompiler是為支持多種編程語言、多種芯片平臺的聯合編譯、運行而設計的統一編程平臺，其設計目標是提供一個語言可插拔、組件可配置的多語言編譯器運行時。
語言可插拔： 設計架構上支持多種語言接入，ArkCompiler有能力提供具有高效執行性能且具有跨語言優勢的多語言運行時，也可以在小設備上提供高效輕量的單一語言運行時。
組件可配置： ArkCompiler具有豐富的編譯器運行時組件系統。通過定制化配置編譯運行時的語言和組件，以支持手機、PC、平板、電視、汽車和智能穿戴等多種設備上不同的性能和內存需求。
2. 架構
如圖2所示，ArkCompiler包含編譯器、工具鏈、運行時等關鍵部件。ArkCompiler工具鏈實現對應語言的前端編譯器，將前端開發框架的高級語言編譯成統一的字節碼/二進制文件。根據不同的應用場景，通過ArkCompiler運行時解釋器解釋執行字節碼文件或JIT/AOT編譯器編譯執行對應體系架構的優化機器碼，從而提升運行效率和啟動性能。
圖2 ArkCompiler運行原理
下面，本文將從前端編譯器，運行時展開介紹。
二、前端編譯器
前端編譯器是高級語言通往語言運行時的橋梁，它按照語言規范，將編程語言表達的語義翻譯為運行時能夠理解的介質，在ArkCompiler解決方案里，這體現為ArkCompiler字節碼。即圖3中的ArkCompiler Bytecode(簡稱abc)。部分語言，也支持通過ArkCompiler的AOT Compiler組件直接將字節碼編譯成對應體系架構的優化機器碼。
圖3 ArkCompiler前端
1. 前端編譯器功能
在需要支持多種語言的ArkCompiler中，前端編譯器的主要作用是在Host側把源碼生成字節碼文件，這樣的優點：
利用Host強大的計算能力，能夠在運行前做更多更復雜的算法優化，減少運行時的工作，提高運行效率。
相比常見的JavaScript運行時，可以把端側的編譯解析過程提前到發布前，提升程序的啟動性能。
圖4 JavaScript運行流程
編譯優化
ArkCompiler提供對TypeScript(TS)的原生支持。在前端編譯TS源碼時，會利用TS的顯式類型聲明，應用類型推導進行類型優化，并且將推導出的類型信息通過字節碼文件保留至運行時，由此運行時可以直接利用類型信息執行快速路徑。此外，靜態的類型分析和推導也使得TS AOT (Ahead of Time) Compiler成為可能，靜態分析得到的類型信息幫助AOT Compiler直接編譯生成高質量的機器碼，使得TS源碼可以直接以機器碼形式運行，進一步提升運行性能。
圖5 編譯優化
2. ArkCompiler字節碼
ArkCompiler字節碼(ArkCompiler Bytecode)是運行時解釋器能夠解析運行的一種硬件和平臺無關的中間表現形式，以緊湊、可擴展、多語言支持作為設計目標。屏蔽設備的差異，支持應用的跨設備分發、部署和運行。ArkCompiler采用的是基于寄存器的字節碼格式。每個寄存器的寬度為64位，最多支持65536個寄存器。
(1)寄存器
ArkCompiler寄存器要求能夠放置對象引用和基本類型，寬度采用64位。寄存器的作用域是以函數棧幀為范圍。在字節碼指令編碼中，寄存器索引支持4位、8位以及16位的變長編碼，在支持方法內不同數量范圍的寄存器尋址的同時減小字節碼尺寸。
(2)累加寄存器
累加寄存器，俗稱累加器，是一個特殊的寄存器，被指令隱含使用。使用累加器的主要目的是在不損失性能的前提下改善指令編碼密度。在ArkCompiler字節碼中，上一條指令利用累加器作為結果輸出，下一條指令將此累加器作為輸入，可以有效改善指令密度，減小字節碼的尺寸。同時，通過在生成字節碼階段的數據流及控制流分析和優化，前端編譯器可以有效消除冗余的累加器load和store操作。
(3)基本類型支持
ArkCompiler字節碼提供對32位(i32)和64位(i64)整型數值的寄存器操作支持，8位和16位數值通過擴展到32位來模擬。支持對IEEE-754雙精度浮點f64值的寄存器的操作，f32數據類型(IEEE-754單精度)也通過轉換為f64值進行模擬。基本數據類型不需要虛擬機進行記錄、跟蹤和推導，而是通過操作不同基本數據類型的專用字節碼進行表示，包括整數值的符號性。為了更有效地利用字節碼的指令空間，設計中對高頻使用的數據類型和操作引入更多的專用字節碼，而對低頻使用的數據類型和操作采用更通用的字節碼。
(4)語言相關類型支持
ArkCompiler根據其執行的語言支持層次化的類型系統。這樣，創建或者從常量池加載的字符串、數組、異常對象等，都是含有相應層次關系的、和具體語言規范相匹配的數據對象。
(5)動態類型語言支持
為支持類似JS/TS的動態類型語言，ArkCompiler通過特殊的標記值(“Any”)表示動態類型值，其包裝了值本身和相應的類型信息(包括基本類型和對象引用類型數據)。虛擬寄存器的寬度可以容納“Any”值。同時，在動態類型語言代碼的執行上下文中，也可能使用到包含類型檢查指令在內的靜態確定類型指令序列，以表示動態類型相關語義。
三、ArkCompiler運行時
ArkCompiler運行時，如圖6所示，被分為了核心運行時(Core Runtime)和各自語言獨立的運行時插件(Runtime Plugin)。
核心運行時主要由運行時的公共核心組件構成，包含定義字節碼格式和行為的Public ISA模塊，對接系統調用的ArkCompiler Base Platform模塊， 支持Debugger、Profiler等工具的Common Tool模塊和承載字節碼文件處理的ArkCompiler File模塊等。也提供了可選的語言無關的解釋器、內存管理、編譯器和并發等基礎設施組件。
各語言運行時插件則包含各語言特有的特性實現以及標準庫來支撐語言的運行行為符合對應的語言規范，由各語言按需定制。
圖6 運行時框架
1. 執行引擎
ArkCompiler運行時執行引擎有多種組件，包括解釋器、JIT編譯器和AOT編譯器，如圖7所示。
圖7 執行引擎結構
(1)解釋器
解釋器可直接運行前端編譯器輸出的字節碼。
(2)JIT Compiler
JIT編譯器一般需要運行時執行代碼一段時間，Profiler生成了profiling數據之后，根據profiling數據即時編譯生成高質量的機器碼(上圖Optimized Code II)來運行。(JIT可以根據代碼執行情況實時編譯生成最優機器指令)
(3)AOT Compiler
AOT編譯器則是在運行前根據靜態信息直接編譯生成高質量的目標機器碼(上圖Optimized Code I)在設備上運行，PGO(Profile Guided Optimization)配置文件可以作為AOT Compiler的輸入之一，給AOT Compiler一些指示，比如編譯的范圍以及編譯某個方法時使用哪些優化技術。通常這種PGO配置文件由在同等規格的設備上經過運行時profiling或者大數據分析生成。
無論是JIT 編譯器生成的優化代碼，還是AOT編譯器生成的優化代碼，通常都是在一定優化假設或者優化推斷的前提下生成的。如果這個前提在運行時不成立，則需要進行Deopt(逆優化)，回退到解釋器執行，這種情況一般較少發生。
2. 定制化需求
各個執行引擎的性能如圖8所示：
圖8 各執行引擎的性能對比
ArkCompiler運行時通過不同執行模式的按需組合，支持多種設備不同的定制化需求。
在低端IOT設備上，ArkCompiler執行引擎支持純解釋器的執行模式，以滿足小設備的內存限制條件;
在高端設備上，ArkCompiler執行引擎支持解釋器配合AOT編譯器以及JIT編譯器的模式運行，對相當部分代碼使用AOT編譯器編譯，使得程序一開始就可以運行在高質量的優化代碼上，獲得最好的執行性能;
在其它設備上，則根據設備的硬件條件限制來選擇策略，設定高頻使用需要AOT編譯的代碼范圍，其它代碼則依靠解釋器配合JIT Compiler運行，使得應用執行性能能夠得到最大化。
為了提升解釋執行性能，在特定的體系架構下，解釋器約定了將解釋執行上下文中某些頻繁使用的數據放在對應的物理寄存器中，比如在Arm64架構下，上下文中當前字節碼指令地址、累加器值、解釋器棧幀、指令映射表、當前線程對象等，直接放在固定的寄存器上，避免了在棧上頻繁的加載和寫入操作。
3. 并發
復雜移動應用的開發和運行對并發有較強的需求。ArkCompiler運行時除了提供標準的“Java多線程編程”和“運行支持”之外，也提供響應式的Actor并發編程模型支持。此模型下執行體之間不共享任何數據，通過消息機制進行通信。當前，業界的一些Actor并發模型，例如傳統JS引擎的web-worker實現，有啟動速度慢、內存占用高等缺陷。
為了利用設備的多核能力獲得更好的性能提升，在Actor內存隔離模型的基礎上，ArkCompiler運行時通過共享Actor實例中的不可變或者不易變的對象、內建代碼塊、方法字節碼等，提升Actor的啟動性能和節省內存開銷，達到實現輕量級Actor并發模型的目標。
圖9 輕量級Actor實現
4. 跨語言優化
HarmonyOS應用在某些情況下實際上是由多種語言的代碼組成的。例如對HarmonyOS JS/TS應用，有一些系統庫、框架和應用依賴的部分能力的實現使用了C/C++ 和Java語言。HarmonyOS開發框架也提供了JS/TS與C/C++ 交互的JS NAPI以及JS/TS與Java交互的Channel機制。考慮不同語言之間的交互場景的開發和運行效率需求，ArkCompiler和開發框架聯合設計，提供了對應的優化機制。
(1)JS/TS與C/C++交互
在TS 版本的操作系統平臺API實現中，通常需要面臨C/C++ 代碼訪問和操作TS對象的場景。對這個業務場景，ArkCompiler可以根據TS源碼的class聲明和運行時約定，生成包含TS對象布局描述的C/C++ 頭文件，以及操作這些TS對象的C/C++ 實現庫。在 C/C++ 代碼中，通過包含TS對象描述頭文件以及鏈接對應實現庫，實現直接操作TS對象的效果。需要說明的是，由于TS類型或其內在布局并非總是固定不變的，因此在TS對象操作的代碼實現中，會插入類型檢查，如果對象類型或布局在運行時發生變化，則回退執行通用的慢速路徑。
圖10 跨語言交互
(2)JS/TS與Java交互
HarmonyOS中有一些應用所需的能力是通過系統、框架或應用的Java庫提供的。因此在HarmonyOS應用中，也存在較多JS/TS代碼與Java代碼交互的場景。常見的案例中，由于JS/TS代碼和Java代碼有各自獨立的運行環境，相互之間對于對方的數據表示、調用約定都是不可知的，所以JS/TS與Java的數據交互通常需要經過標準的JSON序列化和反序列化流程，以及經由Native層橋接的相互調用。這造成在一些場景中開銷較大，影響用戶體驗。
ArkCompiler利用同時支持多語言的優勢，運行時具備不同語言的數據表示、對象布局、函數調用約定等信息，這使得跨語言之間的直接數據訪問、對象操作和方法調用成為可能，同時Java代碼提供的更多確定的類型信息也成為JS/TS類型推導的額外輸入，利于對JS/TS的編譯優化。另一方面，這也使我們能為開發者提供一個更簡化的多語言編程模型，減少需要額外手工編寫的業務無關的跨語言交互代碼工作量。
圖11 簡化的多語言編程模型
四、總結
HarmonyOS所支持的IoT時代下，結合應用生態、開發體驗和用戶體驗等方面的需求， ArkCompiler與硬件、操作系統、開發框架、編程語言協同設計，在多語言統一編譯運行和多設備支持的基礎上，實現對HarmonyOS應用在開發和運行效率等方面的提升。
未來，ArkCompiler在持續優化基礎體驗的同時，更會進一步結合HarmonyOS萬物互聯的需求，在跨端遷移、多端協同等創新場景，從編譯器和運行時等方面提供底層的解決方案和優化機制，提升分布式應用的開發和運行體驗。
