少し前までは、FacebookはChainReact 2019年の会議は正式にはJavaScript実行エンジンエルメスの新世代を立ち上げました。エルメスは、Android上で実行するために設計された小型・軽量のJavaScriptエンジンは、最適化されてネイティブリアクトされます。多くのアプリケーションでは、単にそれがJavaScriptの標準的な実装を使用しているためだけでなく、起動時間を短縮し、メモリ使用量を削減し、アプリケーションのサイズを小さくするためにエルメスを可能にするので、中に統合するネイティブアプリケーションを反応させることは容易です。
ここでの挿入の説明
エルメスはじめは
ReactNative発売以来、APPの大多数は、大規模なアプリケーションのための主要なビジネスプロセスを含め、アクセスして使用します。ビジネスの立ち上がりの複雑さによって、パフォーマンスの問題が無視できなくなります。
パフォーマンスデータを分析すると、Facebookのチームは、JavaScriptエンジンは、起動時のパフォーマンスとアプリケーションパッケージのボリュームに影響を与える重要な要因であることがわかりました。JavaScriptCoreにおけるはもともと非常に多くの制限があるために、デスクトップ、モバイル端末の能力に比べて、デスクトップブラウザとして設計されていたので、下端のパフォーマンスの最適化から移動するために、Facebookのチームは、限られた、エルメス設計された自己JavaScripエンジンを選択しました現在、唯一のAndroidプラットフォーム用のiOS AppStoreの監査の制限、。
チェーンは、公式の会議は、テストデータエルメスエンジンのセットを提示しリアクト '
開始ページからのユーザ操作可能な長さ：2.01s 4.3sから（TTIを相互作用するように時間）を低減する
41メガバイトから22メガバイトに、アプリのダウンロードサイズ減らす
185メガバイトから136メガバイトまで減少メモリ使用量を、
ヘルメスへのハンドオーバの後に見いだされることができます長いロードするときに、アプリケーションのサイズとメモリフットプリントの3つの主要な指標が大幅に改善しました。
ここに画像を挿入説明
エルメス以来、モバイルアプリケーション用に最適化されたので、私たちはどのブラウザやNode.jsのサーバーインフラストラクチャに統合する予定はありません。このような状況では、既存のJavaScriptエンジンは、まだ最初の選択肢です。
エルメスの最適化
、モバイルアプリケーションの開発では、初めてのロードを開始し、メモリサイズ、およびアプリケーションのサイズは、アプリケーションの品質の重要な指標であるため、エルメスは、ネイティブのアプリケーションがこれらの領域から最適化されてもリアクトされます。
プリコンパイルされたバイトコードは
一般的に、JavaScriptエンジンが唯一のJavaScriptのソースコードをロードした後に解決され、バイトコードを生成するに言えば、JavaScriptコードは生成されたバイトコードの後に起動する必要があります。このステップをスキップするために、エルメスは、ビルドプロセスを実行しているモバイルアプリケーションでは、事前にコンパイラを導入しました。バイトコードの最適化時間が長くなるので、バイトコードより小さく、より効率的にすることができたよう。今、あなたはまた、このような重複したデータ列を削除し、リストを梱包として、プログラム全体の最適化を行うことができます。
熱心にファイル全体を読み込むことなく、バイトコードは、実行時のメモリにマップされ、説明されるように設計されています。ローエンドの携帯機器用のフラッシュメモリ上の多くのパフォーマンスの低下は、I / Oの待ち時間が大幅に増加し、その需要の負荷最適化されたバイトコードの量が大幅にフラッシュメモリからTTIを向上します。また、ファイルのサポートによりマッピングされた読み出し専用メモリのために、そうすることにより、より少ないメモリデバイス現象でプロセスを殺す削減、メモリ不足にこれらのページをクリアすることができ、仮想メモリ（Androidなど）のモバイルCaozuojitongを使用していません。
本明細書に記載のピクチャ挿入
バイトコードをJavaScriptのソースコードであるが、全体としてわずかに、しかし理由従ってヘルメスの容積を減少ヘルメスネイティブコードの小さい容積の反応させた圧縮ネイティブAndroidアプリケーションプログラムの圧縮比。
いいえJIT
実行を高速化するためには、人気のJavaScriptエンジンは、頻繁にマシンコードにコンパイルされたコード、リアルタイム（JIT）コンパイラによって実行される作業を解釈することはできません。
今エルメスなしJITコンパイラ。これはエルメスではなく、いくつかのベンチマークでは、CPUのパフォーマンスのベンチマークに特に依存して非常に優れた性能であることを意味します。この設計は意図的なものである：ベンチマークは、モバイルアプリケーションの実際のワークロードを反映することは困難です。我々はまた、いくつかの実験のJITをしましたが、我々はあなたが実際の速度向上を得るために、または上記の指標の現実に注意を払うようにしたいと思います。JITは、アプリケーションが起動時にウォームアップする必要があるため、それは彼らがTTIを改善することは困難である、とさえTTIを破損する恐れがあります。また、JITネイティブコードは、ボリュームとメモリ消費量が増加します、これは私たちの重要な指標にマイナスの影響を与えることになります。JITは、我々が最も懸念しているので、我々は、JITを実装しないことを選択したメトリックの足かせかもしれません。
ガベージコレクションの方針
やモバイルデバイスのメモリを効率的に使用することは非常に重要です。一般的に、ローエンドのメモリデバイスは、多くの場合、限られているので、オペレーティングシステムは、あまりにも多くのメモリを使用するアプリケーションを殺すために強制されます。アプリケーションが殺される必要があるの後に再び使用する場合は、ゆっくりとバックオフィス機能が影響を受けることになります、再起動してください。初期のテストでは、我々はあなたが32ビットのデバイスの仮想アドレス（VA）空間上で大規模なアプリケーションを実行すると、特にVA連続した領域でもあまり助けにはならなかった怠惰な物理ページ割り当てで、限られた資源であることを学びました。
そのため、メモリ空間とVAエンジンの使用を最適化しようとするために、我々は、ガベージコレクタを構築し、次のような機能を持っている、主な施策は以下のとおりです。
DAMA：必要なときにのみブロック内のVA空間を形成。
不連続：VAスペースは、デバイス32上のリソースの制約を回避する単一のメモリ範囲で必要ではありません。
モバイル：オブジェクトを移動する機能を使用すると、メモリ、ブロックを最適化することはできません、もはや、オペレーティング・システムに戻すために必要とされることを意味します。
世代：JavaScriptがそれぞれGC、GC縮小時にヒープ全体をスキャンしません。
統合されたエルメス
クイックスタートエルメス
hermesvm：FacebackチームはエルメスがNPMにアップロードツールがあります。hemresツールは、直接JSコード、バイトコード変換を実行し、同調制御パラメータの多くを提供することができます。
例えば、以下のように、コード及びhermesvm JSバイトコード変換機能の実装を次
// hermes_testファイルの内容を作成：印刷（「これはエルメスデモです」）;
VIM hermes_test.jsを
//直接実行平文JS
〜/ node_modules / hermesvm / OSX-binに/エルメスhermes_test.js
これはエルメスデモです
//转换成バイトコード
〜/ node_modules / hermesvm / OSX-binに/エルメス--emit-バイナリhermes_test.js -out hermes_test.hbc
//バイトコードを実行
〜/ node_modules / hermesvm / OSX-binに/エルメスhermes_test.hbc
これはエルメスのデモです
コードをコピーし
、新しいプロジェクトに統合され
、現在エルメスは、ネイティブはオプション機能であるリアクトです。あなたがエルメスを有効にする場合は、バージョンを確保する必要性は上記0.60.2にネイティブプロジェクトを反応し、また、アンドロイド/アプリ/ build.gradleファイルを必要とし、以下の変更を行います。
= project.ext.react [
entryFile：「index.js」、
enableHermes：trueに
]
コードをコピーして
、アプリケーションが少なくとも一度構築されている場合は、クリーンアップするには、次のコマンドを使用します。
CDのアンドロイド&&クリーン./gradlew
コードのコピーを
、あなたは、通常のアプリケーションを開発し、展開することができます。
反応ネイティブ実行アンドロイド
コピーにコード
ここに挿入された画像の説明
デバッグ
優れたデバッグ体験を提供するために、我々は、デベロッパーツールの契約上のリモートデバッグのためのChromeのサポートを実装しています。今日では、ネイティブにはまた、唯一のデバッグ時にプロキシアプリケーションを使用して、アプリケーション内で実行されているChromeのJavaScriptコードをサポートして反応します。このサポートを使用してアプリケーションをデバッグすることができますが、ネイティブブリッジがネイティブ呼び出しを同期させることができない反応します。リモートデバッグプロトコルをサポートするために、エルメスは、開発者が自分のデバイス上で実行されているエルメスのエンジンに接続することができ、およびネイティブデバッグそのアプリケーションの生産と同じエンジンを使用しています。試運転に加えて、我々はまた、クロームデベロッパーツールの合意のための追加サポートを実装することを検討します。
ここで絵の説明を挿入
エルメス、JavaScriptCoreにおけるコントラストとV8
公式データ検証の後、以前のJavaScriptCoreにおけるプログラムに比べFacebackチームが作られた重要な指標が大幅に改善されましたが。
まず、域外の領域のサイズは、ファイルので、RNはとても必要なライブラリを依存して、エルメスは16％程度JavaScriptCoreにおける削減（約0.5Mで減少し、単一のアーキテクチャ圧縮armeabi後）、V8はエルメスとJavaScriptCoreにおけるよりもはるかに大きい必要があります。
ここに画像を挿入する記述
続いた後は、変動のメモリであり、RNを入力するRNTesterエンジニアリングテストページを取り、いくつかのページや終了に滑り込む、比較のメモリ内変動が見られることができ、V8とエルメスメモリの増加は、より滑らかに。
ここで絵の説明を挿入
CPUの変動が続くが、その後、RNは、CPUの変動に比べて、いくつかのページと終了にスライド入力するRNTesterエンジニアリングテストページを取ります。V8とJavaScriptCoreにおけるよりも有意に良好エルメス。図に示すように。
ここで記述した画像を挿入
エルメスの問題の存在
JavaScriptCoreにおけるが話すと比べを、エルメスは多くの利点を持っているが、JavaScriptCoreにおけるは、テストや統合、エルメスは徐々にもたらした質問で行うと言って必ずしも良好ではありません。
バイトコードファイルは大きすぎるサイズを占める
テストに合格するために、100％の増加JSプレーンテキストファイルよりもエルメスコンパイルされたバイトコードファイル。したがって、パッケージが大型RN、RNをヒットすると、増分パッケージは、バイナリファイルの差分、微分効率が低下するため、動的ました。
あなたがエルメスを使用する場合、クライアントjsのストレージとバイトコードファイルはバイトコードをコンパイルしながら、この問題を解決するために、エルメスの特性に応じて、我々は、それ以外の場合は、まだJavaScriptCoreにおけるを使用し、エルメスのクライアントかのバイトコードコンパイラに自分の考えを変更することができます。
ビジネスユースのために露出JNIを通して、エルメスのオープンソースプロジェクトは、complieJSメソッドのバイトコードコンパイラを提供していますが、このコードはRNエルメスのエンジンへのデフォルトパッケージの一部ではありません、我々は少し統合を持って、梱包。
時間のかかるプレーンテキストが長いJS実行する
バイトコードにプレーンテキストに変換するために、クライアントのJS前に、私たちは、エルメスは、プレーンテキストをロードしてみましょう。しかし、本当のテストは、彼がほぼ30％より遅いエルメスのロード・パフォーマンスプレーンテキストJavaScriptCoreにおけることを発見しました。主な理由は、プレーンテキストのJSに遅く実行されるコードで、その結果、エルメスJIT機能を削除しています。
継続的な最適化
とエルメスの移行を簡単にするためには、iOSのJavaScriptCoreにおける上の作業を支援し続け、我々はJSIを構築し、それはC ++アプリケーションでAPIを埋め込むための軽量なJavaScriptエンジンです。このAPIは、彼らのリアクトネイティブインフラの改善を実現するために、エンジニアを可能にします。使用上の織物JSIは、ネイティブプレゼンテーションに反応差し替えることができ、元のモジュールの体積を減少させも使用TurboModules JSIは、必要な遅延ロードがネイティブアプリケーションを反応させることができます。
関連リンク：