React Native發布新一代JS引擎Hermes 前不久，Facebook在ChainReac

前不久，Facebook在ChainReact 2019大會上正式推出了新一代JavaScript執行引擎Hermes。 Hermes 是一款小巧輕便的 JavaScript 引擎，專門針對在 Android 上運行 React Native 進行了優化。對于許多應用程序，只需啟用 Hermes 即可縮短啟動時間、減少內存使用量并縮小應用程序大小，此外因為它采用 JavaScript 標準實現，所以很容易在 React Native 應用中集成。

在這里插入圖片描述
Hermes簡介
自ReactNative推出以來，有大量的APP接入并使用，其中也包括大型應用的主流程業務。隨著業務復雜度不斷上升，性能問題變得無法忽視。

在分析性能數據時，Facebook團隊發現 JavaScript 引擎是影響啟動性能和應用包體積的重要因素。由于JavaScriptCore最初是為桌面瀏覽器端設計，相較于桌面端，移動端能力有太多的限制，為了能從底層對移動端進行性能優化，Facebook團隊選擇自建JavaScrip引擎，設計了Hermes，限于iOS AppStore審核限制，目前僅用于Android平臺。

Chain React大會上官方給出了Hermes引擎的一組測試數據：‘

從頁面啟動到用戶可操作的時間長短（Time To Interact：TTI），從4.3s減少到2.01s
App的下載大小，從41MB減少到22MB
內存占用，從185MB減少到136MB
可以發現，切換到Hermes后，加載時長，App大小和內存占有三個關鍵指標都有了顯著的提高。

在這里插入圖片描述
由于 Hermes 是針對移動應用優化的，因此我們沒有計劃將其集成到任何瀏覽器或 Node.js 等服務端基礎架構中。在這些環境中現有的 JavaScript 引擎仍然是首選。
Hermes優化方案
在移動應用開發中，首次加載啟動，內存大小和應用大小都是衡量應用好壞的重要指標，因此Hermes也是從這些方面還對React Native應用進行優化。

字節碼預編譯
通常來說，JavaScript 引擎會在加載后才解析 JavaScript 源代碼并生成字節碼，JavaScript 代碼需要在生成字節碼后才開始執行。為了跳過這一步，Hermes 引入了一個預編譯器，在移動應用構建過程中運行。這樣一來優化字節碼的時間可以更長，使字節碼更小、效率更高?，F在還可以針對整個程序做優化，例如刪除重復數據和打包字符串表等。

字節碼的設計使其在運行時可以映射到內存中并解釋，而無需急切地讀取整個文件。許多中低端移動設備上性能較差的閃存 I/O 顯著增加了延遲，因此按需從閃存加載體積經過優化的字節碼會顯著提升 TTI。此外，由于內存以只讀方式映射并由文件支持，因此不使用虛擬內存的移動操作系統（如 Android）可以在內存不足時清除這些頁面，進而減少了內存較少的設備上殺掉進程的現象。

在這里插入圖片描述
盡管壓縮后的字節碼比壓縮后的 JavaScript 源代碼略大，但由于 Hermes 的原生代碼體積較小，因此 Hermes 從整體上減少了 React Native 項目Android 應用的體積。
無 JIT
為了加快執行速度，流行的 JavaScript 引擎可以將頻繁解釋的代碼編譯為機器碼，這項工作由即時（JIT）編譯器執行。

Hermes 現在并沒有 JIT 編譯器。這意味著 Hermes 在某些基準測試中表現不會很出色，特別是那些依賴于 CPU 性能的基準測試。這一設計是有意為之：這些基準很難反映移動應用程序的實際工作負載。我們也對 JIT 做過一些實驗，但我們認為想要獲得真正的速度提升還是要關注上述現實指標。因為 JIT 必須在應用程序啟動時預熱，所以它們難以改善 TTI，甚至可能會損害 TTI。此外，JIT 會增加原生代碼體積和內存消耗，這會對我們的主要指標產生負面影響。JIT 可能會拖累我們最關心的指標，因此我們選擇不實現 JIT。

垃圾回收策略
在移動設備中內存的高效利用是非常重要的。一般來說，低端設備的內存往往是有限的，因此操作系統會強制殺掉使用過多內存的應用程序。當應用被殺后再次使用時需要緩慢地重啟，后臺功能也會受到影響。在早期測試中我們了解到，在 32 位設備上運行大型應用時虛擬地址（VA）空間，尤其是連續的 VA 空間都能是一種有限的資源，就算用了物理頁面懶惰分配都沒多大幫助。

因此，為了盡量優化引擎使用的內存和 VA 空間，我們構建了一個具有以下功能的垃圾回收器，主要的措施有：

按需分配：僅在需要時以塊的形式分配 VA 空間。
非連續：VA 空間不必在單個內存范圍內，這避免了 32 位設備上的資源限制。
移動：能夠移動對象意味著可以對內存進行碎片整理，并將不再需要的塊返回給操作系統。
分代：每次 GC 時不掃描整個 JavaScript 堆，減少 GC 時間。
集成Hermes
快速上手Hermes
Faceback團隊已經將Hermes工具上傳到了npm : hermesvm。hemres工具可以直接運行JS代碼、轉換字節碼并且提供非常多的參數進行調優控制。

例如，下面是hermesvm執行JS代碼和轉換bytecode功能，代碼如下：

// 創建hermes_test文件，內容：print("This is Hermes Demo");
vim hermes_test.js

// 直接執行純文本js
~/node_modules/hermesvm/osx-bin/hermes hermes_test.js
This is Hermes Demo

// 轉換成bytecode
~/node_modules/hermesvm/osx-bin/hermes --emit-binary hermes_test.js -out hermes_test.hbc

// 執行字節碼
~/node_modules/hermesvm/osx-bin/hermes hermes_test.hbc
This is Hermes Demo
復制代碼
在新工程中集成
目前 Hermes 是一個可選的 React Native 功能。如果要啟用Hermes，需要確保 React Native項目的版本在0.60.2 以上，并且還需要對android/app/build.gradle 文件并進行以下更改。

project.ext.react = [
entryFile: "index.js",
enableHermes: true
]
復制代碼
如果應用已經至少構建了一次，請使用如下命令進行清理。

cd android && ./gradlew clean
復制代碼
然后，就可以正常開發和部署應用。

react-native run-android
復制代碼
在這里插入圖片描述
調試
為了提供出色的調試體驗，我們通過 DevTools 協議實現了對 Chrome 遠程調試的支持。時至今日，React Native 還只支持在 Chrome 中運行應用的 JavaScript 代碼時使用應用內代理調試。有了這種支持就能調試應用了，但 React Native 橋接器中不能同步原生調用。Hermes 對遠程調試協議的支持允許開發者連接到在其設備上運行的 Hermes 引擎，并使用與生產中相同的引擎原生調試其應用程序。除了調試之外，我們還在考慮實現對 Chrome DevTools 協議的額外支持。

在這里插入圖片描述
Hermes、JavaScriptCore和V8 的對比
經過官方的數據驗證，Faceback團隊提出的關鍵性指標相較于原先的JavaScriptCore方案都有了顯著提高。

首先，是原生 so文件的大小方面，RN所依賴的必要so庫，Hermes比JavaScriptCore減少了約16%（單armeabi架構壓縮后降低了0.5M左右），V8則要遠大于Hermes和JavaScriptCore。

在這里插入圖片描述
接下來，就是內存的波動情況，拿RNTester工程測試進入RN頁面滑動進入若干頁面并退出之后，內存的波動情況比較可以看到，V8和Hermes內存增長要更加平滑。
在這里插入圖片描述
接下來是CPU波動情況，拿RNTester工程測試進入RN頁面滑動進入若干頁面并退出之后，對比CPU波動情況。Hermes明顯好于V8和JavaScriptCore。，如下圖所示。
在這里插入圖片描述
Hermes存在的問題
相比JavaScriptCore來說，Hermes的確有很多的優點，但不是說一定好于JavaScriptCore，隨著測試和集成的進行，Hermes帶來的問題逐漸顯現。

bytecode文件占用size過大
通過測試，Hermes編譯的字節碼文件比純文本js文件增大100%。因此，打出的RN包就會比較大，并且動態下發RN增量包時，由于是二進制文件diff，差分效率也會降低。

為了解決這個問題，我們根據Hermes的特性，轉變思路，將Hermes的bytecode編譯放到客戶端去做，客戶端同時存儲js和bytecode文件，如果有bytecode編譯完成則使用Hermes，否則仍然使用JavaScriptCore。

Hermes開源項目提供了編譯bytecode的complieJS方法，但這部分代碼沒有默認打包到RN的Hermes引擎中，我們稍加整合、封裝，通過JNI暴露出來，供業務使用。

執行純文本js耗時長
在客戶端將純文本js轉換成bytecode之前，我們讓Hermes加載純文本。但實際測試下來，發現Hermes加載純文本的性能比JavaScriptCore要慢將近30%。主要原因是Hermes刪除JIT功能，致使對純文本js代碼運行變慢。

持續優化
為了簡化 Hermes 的遷移工作并繼續在 iOS 上支持 JavaScriptCore，我們構建了 JSI；這是一種用于在 C++ 應用程序中嵌入 JavaScript 引擎的輕量級 API。此 API 使 React Native 工程師可以實現自己的基礎架構改進。Fabric 就使用了 JSI，它可以搶占 React Native 呈現；TurboModules 也用了 JSI，它縮小了原生模塊的體積，可以根據 React Native 應用程序的需要懶加載。

相關鏈接：