ファーウェイは、新しいArk Compilerの動作に関する重要な詳細を発表し、Android上のアプリのパフォーマンスを大幅に向上させることを約束した。 続きを読む
ファーウェイをめぐる最近の話題の多くは、ファーウェイの不幸な政治的状況を中心に展開してきた。 多くの企業がファーウェイとの取引を制限する米国大統領令. このような極めて重要な決定の影響は、注意を払わないにはあまりにも巨大です。 しかし、この大統領令が存在しない別の現実では、ファーウェイはその功績で脚光を浴びていただろう。 最近発表された Ark Compiler は、Android と Android の間のアプリパフォーマンスのギャップを埋めると主張する最新のイノベーションです。 iOS。
Ark Compiler とは何かを説明する前に、一歩下がってコンパイラーとは何か、そして Android システムでコンパイラーが果たす目的を理解する必要があります。
Android 上のコンパイラとインタプリタの簡単な歴史
コンパイラは、コードをある言語から別の言語（多くの場合はネイティブの機械語）に翻訳するコンピュータ プログラムです。 これは、コンピュータによって直接実行されるか、別のプログラム (インタプリタ) を通じて実行されます。 私たちは人間が読めるプログラミング言語 (Java や Java など) でコードを記述するため、この翻訳が必要です。 Kotlin)、コンピューターはネイティブの機械語 (1 と 2 の形式のバイナリ コード) のみを理解します。 0 です）。 したがって、コンパイラは、人間が作成する命令と、それらの命令を理解して実行するマシンの能力との間の橋渡しとして機能します。 この変換とその後の解釈がいかに迅速かつ効率的に行われるかによって、コンパイラの効率が決まります。 コンパイラーの効率とコードのパフォーマンスおよび効率の間に直接的な相関関係を導入し、さらにその延長として、 アプリ。
ダルビック VM
Android の初期の頃、OS は、JIT (ジャストインタイム) コンパイラーとともに Dalvik VM (インタープリター) と呼ばれるものを利用していました。 この古いビデオは、XDA TV の Android Basics 101 からのものです。 シリーズでは、Dalvik VM と JIT セットアップについて触れています。どちらも、メモリの制約が多かった初期の Android システムのニーズに応えました。 Dalvik VM は Java バイトコードを取得し、コードの実行が必要なときにマシンコードに変換しました (したがって、ジャストインタイム)。 当時、携帯電話のストレージ容量には実際の制約があったため、これが必要でした。そのため、このアプローチにより、アプリがシステム内のより小さいファイルサイズで動作できるようになりました。
実行時にアプリをコンパイルおよび解釈すると、ユーザーがアプリを使用しているときにコンパイルが並行して行われるため、アプリのパフォーマンスが全体的に遅くなるという欠点がありました。
Dalvik のガベージ コレクション メカニズムにも制限がありました。 Dalvik は、各メモリ割り当てをまとめて追跡しました。 Dalvik は、メモリの一部がプログラムによって使用されなくなったと判断すると、プログラマの介入なしに、このメモリを解放してヒープに戻します。 このプロセスはガベージ コレクション (GC) と呼ばれ、プログラム内でアクセスされなくなったメモリ オブジェクトを見つけ、それらのオブジェクトが使用していたリソースを再利用してメモリを解放することを目的としています。 システムはいつ GC が必要になるかを集合的に決定するため、アプリ開発者は [ART であっても] GC イベントがいつ発生するかを選択できません。 そのため、フォアグラウンド アプリでの集中的な処理アクティビティの途中で GC イベントが発生した場合、システムは一時停止します。 プロセスの実行と GC の開始により、処理時間が増加し、顕著な「ジャンク」が発生します。 ユーザー。
これらおよびその他の制約により、Google はパフォーマンスを高速化するための代替アプローチを模索することになりました。
Android ランタイム
Android 4.4 KitKat で、Google は導入しました ART (Android ランタイム) AOT (Ahead-Of-Time) コンパイラーを使用したプレビュー形式で、Android 5.0 Lollipop では、Google は利用可能な唯一のインタープリターとして ART を優先して Dalvik を削除しました。 AOT を使用した ART は、アプリの使用中に変換が行われるのを待つのではなく、アプリのインストール時にコードを機械語に変換します。 このアプローチにより、アプリの起動時間が短縮されましたが、インストール時間が遅くなり、ディスク領域の使用量が増加するという欠点も生じました。 すべてのバランスをとるために、Google 採用された AOT、JIT、および Android 7.0 Nougat 上の ART を使用したプロファイルガイド付きコンパイルを組み合わせて、単一の要因が大幅に影響を受けないようにします。
ART は、ガベージ コレクションを目立たないようにすることにも取り組みました。 GC プロセスは、一時停止が少なく (短い一時停止が 1 回であるのに対し、Dalvik の一時停止は 2 回)、断片化が少なく、メモリ使用量が少なくなり、全体的に高速になるように最適化されました。 Google I/O 2014 での Google のプレゼンテーションでは、Dalvik の GC の限界と、その点での ART の改善についてさらに詳しく説明されています。
長年にわたるこうした変化にもかかわらず、Google のアプローチの基本的な前提には、コンパイル (翻訳) 要素のタイミングを変更しながら実行中にコードを解釈することが含まれていました。 また、ガベージ コレクションは、その固有の中断的かつ集団的な性質により、アプリ開発者にとって依然として悩みの種となっています。 おそらく、オーバーヘッドが引き続き発生するため、結果として Android アプリのパフォーマンスが低下します。
Huawei 社の Ark コンパイラー
ファーウェイは、より効率的なソリューションの開発に取り組んでおり、その結果、この分野で何百人もの専門家を雇用しました。 この努力の結果、Ark Compilerが誕生しました。これはファーウェイが主張する史上初の静的コンパイラです。 これにより、機械語への直接翻訳が可能になり、翻訳の必要性が完全に排除されます。 通訳者。 Ark Compiler も Java と C の実行効率を最大化することを目的として開発されたため、理論的にはこれらの言語で最良の結果が得られるはずです。
ファーウェイは、Ark Compiler の主要な機能を以下のようにいくつか紹介しています。
- AOT や JIT などのコンパイル手法を使用すると、一部のプログラムをマシンコードに変換し、CPU 上で直接実行できます。 しかし、これらの技術は、インタプリタやそれに付随する制限から完全に解放することはできません。 Ark コンパイラーは静的コンパイルを利用しているため、動的インタープリターから自身を切り離すことができ、アプリのパフォーマンスを向上させる可能性が広がります。飛躍的に。"
- 静的コンパイルには、柔軟性が高すぎて、動的コンパイラーが実行中に行うことができる調整ができないという潜在的な欠点があります。 ファーウェイは、Ark Compiler の静的コンパイルがこの問題を解決すると主張しています。プログラミング言語の動的機能をマシンコードにシームレスに変換します。"
- 既存のコンパイル プロセスは、モバイル デバイスへのアプリ パッケージのインストール中またはインストール後に実行されます。 Ark Compiler はソフトウェア開発中に導入できるように設計されており、これによりインストールおよび実行時のオーバーヘッドが軽減されると考えられます。 アプリ開発者は、アプリの開発中にさまざまな言語をネイティブ マシン コードに直接コンパイルできると考えられます。 したがって、結果として得られる APK は、インタプリタや仮想マシンとの対話を必要とせずに済みます。 関数。 これにより、理論的には、たとえば JNI に関連するオーバーヘッドが削減されます。
- Ark Compiler は、ガベージ コレクションの集合的な性質も変更します。 これにより、GC イベントを異なる Java スレッドに対して個別に発生させることができます。 この区画化されたアプローチにより、フォアグラウンド アプリでのジャンクが軽減されると主張されています。
これらの変更の結果、Ark Compiler は次のことが可能になります。 Android システム操作の流暢性が最大 24%、応答速度が最大 44%、サードパーティ アプリケーションのスムーズさが最大 60% 向上したようです。、Android アプリのパフォーマンスを iOS と同じレベルにすると主張しています。
Ark コンパイラは現在、ARM チップ アーキテクチャ用にコンパイルおよび最適化されています。 ファーウェイは、将来的にはハードウェアとソフトウェアの協調設計がキリンチップの能力を最大限に発揮できるようになることを期待している。
Ark コンパイラーは標準的な Java の使用法をサポートしており、アプリ開発者がコードを変更する必要なく、サードパーティ アプリを直接コンパイルできます。 Ark Compiler では、パフォーマンスとメモリをさらに向上させるための「コード構造の調整」も可能です。 ファーウェイは、Ark Compilerをオープンソースシステムにすることを選択し、これによりサードパーティ開発者が採用できるようになります。 テクノロジーをニーズに合わせて適応させ、アプリ開発者や携帯電話での採用を促進します。 メーカー。
Huawei は Ark Compiler の短所については言及していませんが、アプリのサイズが非常に大きくなることが予想されます。 少なくとも、これは十分な機能を備えた現行世代のデバイスでは問題を引き起こさないはずです。 ストレージ。 また、Google の互換性の問題は Huawei の頭痛の種ではないため、Ark Compiler はすべての CPU アーキテクチャで利用できるわけではないと予想しています。 Ark Compiler は、インストール時ではなく開発時に使用するように設計されています。 これは、HuaweiがアプリのAndroidデバイスへの展開とインストール方法を変更した可能性があり、独自のAPK設計にも取り組んだ可能性があることを示しています。 もし正しければ、これはエコシステムに大きな互換性の問題を引き起こす可能性があり、これが Android の標準機能になるまでには長い時間がかかるでしょう。
ユーザーのデバイス上でコンパイルしないことも、最適化に関して大きな問題を引き起こします。 ART は現在、マイクロアーキテクチャごとに最適化を行っています。つまり、結果として得られるバイナリは次のようになります。 Snapdragon デバイスと Exynos デバイス、さらには Snapdragon 845 と Snapdragon では異なります。 625. このアプローチは、Apple や Huawei など、SoC を完全に制御できるメーカーにとっては理にかなっています。 ただし、Android の他の世界ではさまざまな SoC が使用されているため、デバイス間で汎用的な最適化を強制的に使用することは、やはり Ark コンパイラーの標準化の障害となります。 したがって、Ark Compiler がお気に入りのカスタム ROM にすぐに登場するとは期待しないでください。
明確にするために、Ark コンパイラーは Android で動作するように開発されており、ファーウェイはそのコンパイラーに関して何も言及していません。 自作OS疑惑 また、Ark Compiler との互換性も考慮されているため、この点に関しては何の推測も行いません。
ファーウェイは、開発者とより大きなエコシステムに特化した 2 つの主要なカンファレンスを開催する予定です。 それは、Huawei Device China Developers ConferenceとGreen Alliance China Developers Conferenceです。 どちらのイベントでも、ファーウェイの Ark コンパイラーに関連する特定のオープンソースの問題が取り上げられ、このテクノロジーの利点をできるだけ広く利用できるようにする取り組みが行われます。
XDA 上級貢献者に特別な感謝を捧げます ディーズ・トロイ および認められた開発者 アート97 彼らの支援と意見に感謝します。
注: Huawei/Honor は、自社デバイス用の公式ブートローダー ロック解除コードの提供を停止しました。 したがって、デバイスのブートローダーのロックを解除することはできません。つまり、ユーザーはルートを解除したり、カスタム ROM をインストールしたりすることができません。