原文：https://mp.weixin.qq.com/s/8UHznZenc7A_UICta2bETg，點選連結檢視更多技術內容。
隨著數字化時代的發展，手機、平板、PC、電視、智慧手錶、車機等智慧裝置的普及率越來越高，但不同裝置往往搭載了不同的作業系統。面對不同的作業系統與開發框架，應用開發難度大、成本高；同時，不同裝置之間互動匱乏、體驗割裂，難以為使用者帶來一致性的應用互動體驗。
HarmonyOS是一款面向全場景的分散式作業系統，能夠相容手機、平板、PC、智慧屏、智慧手錶、車機等智慧裝置。我們知道，HarmonyOS應用開發需要使用高階程式語言，包括TypeScript（以下簡稱“TS”）、JavaScript（以下簡稱“JS”）、基於TS增強的ArkTS等，還需要配套相應的工具鏈和執行時實現高效開發和執行。面對不同裝置，開發者如何使用同一套應用框架開發應用，讓使用者獲得統一的應用互動體驗呢？
基於此，方舟編譯器（以下稱“ArkCompiler”）應運而生。ArkCompiler支援ArkTS/TS應用預先編譯最佳化機器碼，帶來高效能的執行體驗；同時，ArkCompiler的併發例項啟動更加輕快，並且提供混淆位元組碼能力，有效提升了原始碼的安全性。ArkCompiler助力開發者更加高效、便捷、安全地開發HarmonyOS應用。
一、什麼是ArkCompiler
ArkCompiler作為HarmonyOS應用開發的統一程式設計平臺，包含編譯器、工具鏈、執行時等關鍵部件，支援ArkTS、TS、JS等高階程式語言的開發、除錯調優、執行等業務。
接下來，我們來看一下ArkCompiler編譯工具鏈與執行時的架構。
編譯工具鏈架構
ArkCompiler的編譯工具鏈以ArkTS/TS/JS原始碼作為輸入，將其編譯生成為abc（ArkCompiler Bytecode，即方舟位元組碼）檔案。
執行時架構
ArkCompiler執行時包含了執行引擎、記憶體管理器、語言內建標準庫等部件，直接執行位元組碼檔案，實現對應語言規範的語義邏輯。
二、ArkCompiler的效能亮點
動態型別語言由於執行前無法確定物件型別，需要等程式執行一段時間後，JIT Compiler（Just-In-Time Compiler，即時編譯器）才能根據抓取到的執行資訊明確物件型別並編譯生成對應的最佳化機器碼。
而靜態型別語言則可以根據確定的物件型別，直接編譯生成對應的最佳化機器碼，啟動即可獲得高效能，二者的啟動效能差異比較顯著。
編譯最佳化視角主要區別
基於JS擴充出型別概念的TS已經成為了前十流行的語言，然而業界目前並沒有直接執行TS的引擎，如需執行TS，要先將TS轉換成JS，再透過JS引擎執行。那麼，TS的型別資訊也就在轉換過程中丟棄了，執行時無法接收型別資訊並作相應的最佳化。然而我們發現，大部分情況下，JS程式中的物件型別是單一固定的，這也表明JS的物件型別大部分情況下保持不變。TS的型別是不是也可以在程式碼執行前直接做編譯最佳化呢？
2.1 業界JS引擎方案
JS開發者直接把原始碼打到應用包裡，當執行時，引擎解析JS原始碼需要先將JS原始碼編譯成位元組碼，然後再執行位元組碼。引擎抓取剖析一些執行時的資訊，再使用JIT Compiler在執行時編譯生成最佳化機器碼，最後才能執行最佳化機器碼，這樣才能以比較高的效能執行JS。
業界JS引擎方案
2.2 ArkCompiler的優勢
高效能ArkTS引擎—AOT編譯
我們前面已經分析過，大部分情況下，JS的物件型別保持不變，而TS又會攜帶物件型別。因此，ArkCompiler讓ArkTS/TS能夠持平靜態語言的啟動效能，其實就是利用語言裡的型別資訊，讓ArkTS/TS像靜態語言一樣可以直接編譯生成最佳化機器碼。
Bytecode Compiler（位元組碼編譯器）會生成帶型別的位元組碼，AOT Compiler（Ahead-Of-Time Compiler，預先編譯器）會根據型別位元組碼預生成相關的型別物件，結合PGO1的配置檔案資訊，進行編譯最佳化最終生成對應的最佳化機器碼。
ArkCompiler支援應用執行前就編譯出最佳化機器碼和位元組碼。當應用在移動裝置上首次執行時，就可以直接執行高效能最佳化機器碼了。
三、ArkCompiler的併發亮點
併發例項執行對比
3.1 業界JS引擎的Actor併發模型
上圖左側是業界併發例項的執行情況，由於JS是一門單執行緒語言，JS引擎在設計之初也沒有考慮多執行緒執行的支援和最佳化。
從Actor併發模型的示例圖中，我們可以看出，每一個併發例項都建立了一個完整的引擎例項來支援執行。它的優勢在於，類Actor的介面可以讓開發者不需要關心共享狀態和鎖，容易維護和測試，而且非常容易把併發例項遷移成分散式的服務。不過在移動應用的場景中，這樣的實現也是HTML規範把Web Worker描述成啟動慢並且記憶體開銷大的主要原因。
3.2 ArkCompiler的Lite Actor併發優勢
上圖右側是ArkCompiler實現併發的執行情況。ArkCompiler的Lite Actor的實現，實質還是Actor模型，但是透過共享程式內各併發例項之間的不可變物件，把基礎設施分層和輕量化，在各例項之間重用了一些公共基礎設施，讓併發例項執行更輕快。ArkCompiler的實現中，新增一個併發例項只需要拉起相應獨有的部分。
基於此，我們和瀏覽器頭部引擎做了一個對比，在一定負載下，我們的併發啟動時間和啟動記憶體取得了顯著提升。根據實驗資料表明，相較於業界的方案，Lite Actor併發例項啟動時間和啟動記憶體均最佳化了50%。
四、ArkCompiler的安全性亮點
位元組碼混淆對比
4.1 業界JS引擎的安全性
現行的JS引擎，往往採用只有名稱混淆的UglifyJS2，應用包中的原始碼也是可見可除錯，商業應用原始碼的安全性相對較差。
4.2 ArkCompiler的安全性優勢
在ArkCompiler中，Hap包包含了混淆後的位元組碼，相較於直接攜帶原始碼，提高了開發者程式碼的安全性。
HarmonyOS的程式碼保護，打包的是二進位制的ArkCompiler位元組碼。即使經過ArkCompiler編譯執行時提供的Disassembler反編譯，也只有位元組碼能被看到，無法直接修改除錯執行。
五、總結
目前，執行在ArkCompiler上的開發語言ArkTS，在TS的基礎上主要擴充了宣告式正規化和狀態模式的UI程式設計。往後我們會在靜態模式、併發、安全等方面持續增強，讓ArkTS成為更卓越的應用開發語言。
面對IoT時代的發展，我們會結合HarmonyOS應用生態、開發體驗和使用者體驗等方面的需求，讓ArkCompiler與硬體、作業系統、開發框架、程式語言協同設計最佳化；同時，在多語言統一編譯執行和多裝置支援的基礎上，ArkCompiler讓HarmonyOS應用的開發和執行效率顯著提升。
未來，ArkCompiler在持續最佳化基礎體驗的同時，會更進一步結合HarmonyOS萬物互聯的需求，在跨端遷移、多端協同等創新場景，從編譯器和執行時等方面提供底層的解決方案和最佳化機制，提升分散式應用的開發和執行體驗。
說明：
1. PGO即Profile guided optimization，是一種基於效能分析(profiling)的編譯最佳化技術。
2. UglifyJS是前端開發打包的最常用工具之一，包含JS解析器、程式碼最小化、壓縮、美化的工具集。
