Androidの裏返し：DalvikとARTの比較

こんにちは、Habr！約半年前、私は詳細なJVMガイドを公開しました。投稿は一般的に行っており、コメントの中で彼らは「アンドロイドのために何かが計画されているかどうか」と尋ねました。最後に、私はそれを手に入れました。







この投稿では、Androidランタイムについて説明します。特に、ARTとDalvikの違い、およびAndroid開発ツールが時間の経過とともにどのように改善されたかについて、簡潔かつ簡潔に概説します。このトピックは明らかに新しいものではありませんが、それを掘り下げ始めたばかりの人にとって役立つことを願っています。誰が気にする-猫へようこそ。

仮想マシン

まず、JVMとDVMの違いを見てみましょう。



Java Virtual Machineは、基盤となるプラットフォームに関係なく、Javaバイトコードを実行できる仮想マシンです。これは、「一度書き込み、どこでも実行」の原則に基づいています。Javaバイトコードは、JVMをサポートできる任意のマシンで実行できます。



Javaコンパイラは、.javaファイルをクラスファイル（バイトコード）に変換します。バイトコードはJVMに渡され、JVMはそれをマシンコードにコンパイルして、CPUで直接実行します。



JVMの機能：

• スタックアーキテクチャがあります。スタックは、メソッドが配置および保存されるデータ構造として使用されます。LIFOまたは「ラストイン-ファーストアウト」または「ラストイン、ファーストアウト」スキームで機能します。
• クラスファイルのみを実行できます。
• JITコンパイラを使用します。

Dalvik Virtual Machine（DVM）は、Androidモバイルプラットフォームの一部としてDanBornsteinらによって開発および作成されたJava仮想マシンです。



Dalvikは、Androidオペレーティングシステムコンポーネントとカスタムアプリケーションを実行するための環境であると言えます。各プロセスは、独自の分離されたアドレス空間で実行されます。ユーザーがアプリケーションを起動すると（またはオペレーティングシステムがそのコンポーネントの1つを起動すると）、Dalvik仮想マシンコア（Zygote Dalvik VM）は、共有メモリに個別の保護されたプロセスを作成します。このプロセスでは、VMがアプリケーションを起動するための環境として直接展開されます。つまり、内部から見ると、AndroidはDalvik仮想マシンのセットのように見え、それぞれがアプリケーションを実行します。



DVMの機能：

• レジスタベースのアーキテクチャを使用します。メソッドが配置されるデータ構造は、プロセッサレジスタに基づいています。POPおよびPUSH操作がないため、登録された仮想マシンの命令は、スタックされた仮想マシンの同様の命令よりも高速に実行されます。
• ネイティブ形式のバイトコードを実行します。Androiddexer（以下で説明します）は、クラスファイルを.dex形式に変換し、DalvikVMでの実行用に最適化します。クラスファイルとは異なり、dexファイルには一度に複数のクラスが含まれます。

DVMアーキテクチャの詳細については、こちらをご覧ください。

Android Dexer

Android開発者は、Androidランタイム用にJavaバイトコードを.dexバイトコードに変換するプロセスがAPKを作成するための重要なステップであることを知っています。 dexコンパイラは、主に日常のアプリケーション開発の内部で機能しますが、アプリケーションのビルド時間、.dexファイルのサイズ、および実行時のパフォーマンスに直接影響します。



すでに述べたように、dexファイル自体には一度に複数のクラスが含まれています。複数のクラスファイルで使用される重複行やその他の定数は、スペースを節約するためにのみ含まれています。 Javaバイトコードも、DVMで使用される代替命令セットに変換されます。圧縮されていないdexファイルは、通常、同じ.classファイルから取得された圧縮されたJavaアーカイブ（JAR）よりも数パーセント小さくなります。



最初に、クラスファイルは組み込みのDXコンパイラを使用してdexファイルに変換されました。しかし、Android Studio 3.1以降、D8がデフォルトのコンパイラになりました。 DXコンパイラと比較して、D8はより高速にコンパイルし、より小さなdexファイルを出力すると同時に、実行時のアプリケーションパフォーマンスを向上させます。この方法で取得されたdexバイトコードは、オープンソースのProGuardユーティリティを使用して最小化されます。その結果、同じdexファイルが得られますが、サイズは小さくなります。次に、このdexファイルを使用してapkを構築し、最終的にAndroidデバイスにデプロイします。







しかし、2018年のD8の後ろにはR8がありました、実際には同じD8ですが、追加されているだけです。



Android Studio3.4およびAndroidGradle 3.4.0プラグイン以降を使用する場合、コンパイル時にコードを最適化するためにProguardは使用されなくなりました。代わりに、プラグインはデフォルトでR8で動作します。これは、コードの縮小、最適化、および難読化自体を実行します。R8は、Proguardが提供する機能のサブセットのみを提供しますが、Javaバイトコードからdexバイトコードへの変換を1回実行できるため、ビルド時間がさらに短縮されます。

R8とコード削減

通常、アプリはJetpack、Gson、Google PlayServicesなどのサードパーティライブラリを使用します。これらのライブラリの1つを使用する場合、多くの場合、アプリケーションは個々のライブラリのごく一部しか使用しません。コードを縮小しないと、すべてのライブラリコードがアプリケーションに保存されます。



開発者が冗長なコードを使用して、アプリケーションの読みやすさと保守性を向上させることがあります。たとえば、意味のある変数名とデザインパターンを使用して、他の人がコードをより簡単に理解できるようにすることができます。ただし、テンプレートを使用すると、必要以上のコードが生成される傾向があります。



ここでR8が助けになります。アプリケーションのサイズを大幅に削減し、アプリケーションで実際に使用されるコードのサイズも最適化できます。



例として、以下はAndroid Dev Summit'19で発表されたShrinkingYour App with R8レポート







の図です。ベータリリース段階でのR8の効率の比較は次のようになりました（ソースのAndroid Developers Blogから取得）：













詳細については、こちらをご覧ください。でオフィス文書と報告。

AndroidでのARTとDVM

DVMはモバイルデバイス用に特別に設計され、

Android 4.4KitkatまでのAndroidアプリケーションを実行するための仮想マシンとして使用されました。



このバージョンから、ARTがランタイムとして導入され、Android 5.0（Lollipop）ではARTがDalvikに完全に取って代わりました。



ARTとDVMの主な明確な違いは、ARTはAOTコンパイルを使用し、DVMはJITコンパイルを使用することです。少し前まで、ARTはAOTとJITのハイブリッドを使い始めました。これを詳しく見てみましょう。



DVM

• JITコンパイルを使用します：アプリケーションが起動するたびに、
• アプリケーションの実行に必要なコードの部分がコンパイルされます。残りのコードは動的にコンパイルされます。これにより、アプリケーションの起動と操作が遅くなりますが、インストール時間が短縮されます。
• , .
• , DVM, , , ART.
• , CPU.
• Dalvik “” 4.4.

ART

• AOT , . , .
• , .
• AOT , DVM.
• , - .
• 改善されたガベージコレクションまたはガベージコレクション。Dalvikを使用する場合、ガベージコレクターは2つのヒープパスを実行する必要があり、その結果UXが低下しました。ARTの場合、そのような状況はありません。メモリを統合するためにヒープを1回クリーンアップします。

そして、Dalvik対ARTの小さな図：

JIT + AOT in ART

Android 7以降のAndroidランタイム（ART）には、コードプロファイリングを備えたJITコンパイラが含まれています。 JITコンパイラは、AOTコンパイラを補完し、ランタイムパフォーマンスを向上させ、ディスクスペースを節約し、アプリケーションとシステムの更新を高速化します。



これは次のように発生し





ます。インストールフェーズで各アプリケーションのAOTコンパイルを実行する代わりに、JITコンパイラ（Android <5.0とほぼ同じ）を使用して仮想マシンの制御下でアプリケーションを実行しますが、どれを追跡します。アプリケーションコードのセクションが最も頻繁に実行されます。この情報は、これらのコードセクションをAOTコンパイルするために使用されます。後者の操作は、充電中にスマートフォンが非アクティブの場合にのみ実行されます。



簡単に言うと、2つのまったく異なるアプローチが連携して機能するようになり、次のような利点があります。

• より効率的なコンパイル-アプリケーションをリアルタイムで実行する場合、コンパイラーは静的分析を実行するよりもはるかに多くの作業について学習する機会があり、その結果、より適切な最適化方法が各状況に適用されます。
• RAMと永続メモリの保存-バイトコードはマシンコードよりもコンパクトです。アプリケーションの特定のセクションのみのAOTコンパイルを実行し、ユーザーが使用しないアプリケーションをコンパイルしない場合、NANDメモリスペースを大幅に節約できます。
• システム更新後のインストールと最初の起動速度の劇的な向上-AOTコンパイル、遅延なし。

ARTでのJITコンパイラの実装について詳しくは、こちらをご覧ください。

結論

この記事では、DalvikとARTの主な違いを調べ、Androidが開発ツールを時間の経過とともにどのように改善してきたかを一般的に見てみました。



ARTはまだ開発中であり、ユーザーと開発者の両方のエクスペリエンスを向上させるために新しい機能が追加されています。



役に立ったら、コメントで教えてください。