隨著數(shù)字化時代的發(fā)展，手機、平板、PC、電視、智能手表、車機等智能設(shè)備的普及率越來越高，但不同設(shè)備往往搭載了不同的操作系統(tǒng)。面對不同的操作系統(tǒng)與開發(fā)框架，應(yīng)用開發(fā)難度大、成本高；同時，不同設(shè)備之間交互匱乏、體驗割裂，難以為用戶帶來一致性的應(yīng)用交互體驗。HarmonyOS是一款面向全場景的分布式操作系統(tǒng)，能夠兼容手機、平板、PC、智慧屏、智能手表、車機等智能設(shè)備。我們知道，HarmonyOS應(yīng)用開發(fā)需要使用高級編程語言，包括Typescript（以下簡稱“TS”）、Javascript（以下簡稱“JS”）、基于TS增強的ArkTS等，還需要配套相應(yīng)的工具鏈和運行時實現(xiàn)高效開發(fā)和運行。面對不同設(shè)備，開發(fā)者如何使用同一套應(yīng)用框架開發(fā)應(yīng)用，讓用戶獲得統(tǒng)一的應(yīng)用交互體驗?zāi)兀?/span>基于此，方舟編譯器（以下稱“ArkCompiler”）應(yīng)運而生。ArkCompiler支持ArkTS/TS應(yīng)用預(yù)先編譯優(yōu)化機器碼，帶來高性能的運行體驗；同時，ArkCompiler的并發(fā)實例啟動更加輕快，并且提供混淆字節(jié)碼能力，有效提升了源碼的安全性。ArkCompiler助力開發(fā)者更加高效、便捷、安全地開發(fā)HarmonyOS應(yīng)用。ArkCompiler作為HarmonyOS應(yīng)用開發(fā)的統(tǒng)一編程平臺，包含編譯器、工具鏈、運行時等關(guān)鍵部件，支持ArkTS、TS、JS等高級編程語言的開發(fā)、調(diào)試調(diào)優(yōu)、運行等業(yè)務(wù)。
接下來，我們來看一下ArkCompiler編譯工具鏈與運行時的架構(gòu)。ArkCompiler的編譯工具鏈以ArkTS/TS/JS源碼作為輸入，將其編譯生成為abc（ArkCompiler Bytecode，即方舟字節(jié)碼）文件。
ArkCompiler運行時包含了執(zhí)行引擎、內(nèi)存管理器、語言內(nèi)建標準庫等部件，直接運行字節(jié)碼文件，實現(xiàn)對應(yīng)語言規(guī)范的語義邏輯。
動態(tài)類型語言由于運行前無法確定對象類型，需要等程序運行一段時間后，JIT Compiler（Just-In-Time Compiler，即時編譯器）才能根據(jù)抓取到的運行信息明確對象類型并編譯生成對應(yīng)的優(yōu)化機器碼。
而靜態(tài)類型語言則可以根據(jù)確定的對象類型，直接編譯生成對應(yīng)的優(yōu)化機器碼，啟動即可獲得高性能，二者的啟動性能差異比較顯著。
編譯優(yōu)化視角主要區(qū)別
基于JS拓展出類型概念的TS已經(jīng)成為了前十流行的語言，然而業(yè)界目前并沒有直接運行TS的引擎，如需運行TS，要先將TS轉(zhuǎn)換成JS，再通過JS引擎運行。那么，TS的類型信息也就在轉(zhuǎn)換過程中丟棄了，運行時無法接收類型信息并作相應(yīng)的優(yōu)化。然而我們發(fā)現(xiàn)，大部分情況下，JS程序中的對象類型是單一固定的，這也表明JS的對象類型大部分情況下保持不變。TS的類型是不是也可以在代碼運行前直接做編譯優(yōu)化呢？
2.1 業(yè)界JS引擎方案
JS開發(fā)者直接把源碼打到應(yīng)用包里，當運行時，引擎解析JS源碼需要先將JS源碼編譯成字節(jié)碼，然后再執(zhí)行字節(jié)碼。引擎抓取剖析一些運行時的信息，再使用JIT Compiler在運行時編譯生成優(yōu)化機器碼，最后才能執(zhí)行優(yōu)化機器碼，這樣才能以比較高的性能執(zhí)行JS。
2.2 ArkCompiler的優(yōu)勢
我們前面已經(jīng)分析過，大部分情況下，JS的對象類型保持不變，而TS又會攜帶對象類型。因此，ArkCompiler讓ArkTS/TS能夠持平靜態(tài)語言的啟動性能，其實就是利用語言里的類型信息，讓ArkTS/TS像靜態(tài)語言一樣可以直接編譯生成優(yōu)化機器碼。Bytecode Compiler（字節(jié)碼編譯器）會生成帶類型的字節(jié)碼，AOT Compiler（Ahead-Of-Time Compiler，預(yù)先編譯器）會根據(jù)類型字節(jié)碼預(yù)生成相關(guān)的類型對象，結(jié)合PGO1的配置文件信息，進行編譯優(yōu)化最終生成對應(yīng)的優(yōu)化機器碼。
ArkCompiler支持應(yīng)用運行前就編譯出優(yōu)化機器碼和字節(jié)碼。當應(yīng)用在移動設(shè)備上首次運行時，就可以直接運行高性能優(yōu)化機器碼了。
3.1 業(yè)界JS引擎的Actor并發(fā)模型
上圖左側(cè)是業(yè)界并發(fā)實例的運行情況，由于JS是一門單線程語言，JS引擎在設(shè)計之初也沒有考慮多線程運行的支持和優(yōu)化。從Actor并發(fā)模型的示例圖中，我們可以看出，每一個并發(fā)實例都創(chuàng)建了一個完整的引擎實例來支持運行。它的優(yōu)勢在于，類Actor的接口可以讓開發(fā)者不需要關(guān)心共享狀態(tài)和鎖，容易維護和測試，而且非常容易把并發(fā)實例遷移成分布式的服務(wù)。不過在移動應(yīng)用的場景中，這樣的實現(xiàn)也是HTML規(guī)范把Web Worker描述成啟動慢并且內(nèi)存開銷大的主要原因。
3.2 ArkCompiler的Lite Actor并發(fā)優(yōu)勢
上圖右側(cè)是ArkCompiler實現(xiàn)并發(fā)的運行情況。ArkCompiler的Lite Actor的實現(xiàn)，實質(zhì)還是Actor模型，但是通過共享進程內(nèi)各并發(fā)實例之間的不可變對象，把基礎(chǔ)設(shè)施分層和輕量化，在各實例之間重用了一些公共基礎(chǔ)設(shè)施，讓并發(fā)實例運行更輕快。ArkCompiler的實現(xiàn)中，新增一個并發(fā)實例只需要拉起相應(yīng)獨有的部分。
基于此，我們和瀏覽器頭部引擎做了一個對比，在一定負載下，我們的并發(fā)啟動時間和啟動內(nèi)存取得了顯著提升。根據(jù)實驗數(shù)據(jù)表明，相較于業(yè)界的方案，Lite Actor并發(fā)實例啟動時間和啟動內(nèi)存均優(yōu)化了50%。
4.1 業(yè)界JS引擎的安全性
現(xiàn)行的JS引擎，往往采用只有名稱混淆的UglifyJS2，應(yīng)用包中的源碼也是可見可調(diào)試，商業(yè)應(yīng)用源碼的安全性相對較差。
4.2 ArkCompiler的安全性優(yōu)勢
在ArkCompiler中，Hap包包含了混淆后的字節(jié)碼，相較于直接攜帶源碼，提高了開發(fā)者代碼的安全性。
HarmonyOS的代碼保護，打包的是二進制的ArkCompiler字節(jié)碼。即使經(jīng)過ArkCompiler編譯運行時提供的Disassembler反編譯，也只有字節(jié)碼能被看到，無法直接修改調(diào)試運行。
目前，運行在ArkCompiler上的開發(fā)語言ArkTS，在TS的基礎(chǔ)上主要拓展了聲明式范式和狀態(tài)模式的UI編程。往后我們會在靜態(tài)模式、并發(fā)、安全等方面持續(xù)增強，讓ArkTS成為更卓越的應(yīng)用開發(fā)語言。面對IoT時代的發(fā)展，我們會結(jié)合HarmonyOS應(yīng)用生態(tài)、開發(fā)體驗和用戶體驗等方面的需求，讓ArkCompiler與硬件、操作系統(tǒng)、開發(fā)框架、編程語言協(xié)同設(shè)計優(yōu)化；同時，在多語言統(tǒng)一編譯運行和多設(shè)備支持的基礎(chǔ)上，ArkCompiler讓HarmonyOS應(yīng)用的開發(fā)和運行效率顯著提升。未來，ArkCompiler在持續(xù)優(yōu)化基礎(chǔ)體驗的同時，會更進一步結(jié)合HarmonyOS萬物互聯(lián)的需求，在跨端遷移、多端協(xié)同等創(chuàng)新場景，從編譯器和運行時等方面提供底層的解決方案和優(yōu)化機制，提升分布式應(yīng)用的開發(fā)和運行體驗。1. PGO即Profile guided optimization，是一種基于性能分析(profiling)的編譯優(yōu)化技術(shù)。2. UglifyJS是前端開發(fā)打包的最常用工具之一，包含JS解析器、代碼最小化、壓縮、美化的工具集。
該文章在 2023/9/15 16:11:41 編輯過
400 186 1886
