逐語大きな柱 https://www.dazhuanlan.com/2019/08/26/5d6344d89bd96/
##
Dalvik仮想マシンがAndroidモバイルプラットフォームこの設計のために設計されています。一般的なメモリの小さなモバイルプラットフォームは、ディスクが非常に遅い読み込みます。
これらの特性および制限については、以下の目的の主な焦点である必要があります。
圧縮されたドキュメントからのクラスは、それを抽出して、メモリに保存されたときに実行されている伝統的な古典的なJava仮想マシン。この実装、プロセスが起動スピード、別のコピーを持って戻って、プロセスが比較的になりませんそれは伸長処理（読み取りまたはディスクからのデータの別のクラス）を必要とするため。ローカルメモリに保存されているさらにバイトコード、いくつかの最適化が求められているので、これらのコマンドは好きで書き換えることが容易になり、遅いです操作。
これらの目標は、私たちは、次の意思決定をすることができます：
- すべての文書は、クラス「DEX」文書にまとめています。
- DEXファイルは読み取り専用、およびプロセス間で共有使用されます。
- 操作システムに応じて調整バイトアラインメントのためのバイトの順序。
- バイトコード検証は、すべてのクラスのために強制する必要がありますが、最高のが先です。
- バイトコードを変更するための最適化は、AOTは、実装の工程の前に行う必要があります。
次のセクションに分かれて説明します。
システムへの応用処理コードは瓶やAPK方法。ジャーによって運営されており、APKが実際にzipファイルで、いくつかの余分なメタデータのメタデータを追加しました。のDalvik DEXデータファイルがclasses.dexと呼ばれています。
データが圧縮され、そしてバイトアライメントを保証できないためバイトコードは、直接実行するためにメモリにzipファイルから直接マップすることができません。この問題はDEXない文書によって圧縮することができ、単にジップからDEXを解決するために出して生きています。しかし、戻ってインストールパッケージにボリュームの増加。
だから我々は実際に出たzipから実行プロセスが。我々はまた、トップ述べ合わせ、最適化、検証の一部を行うことができますというように。これは、治療のこれらの事をやって責任者に関連する前にclasses.dexを抽出する必要がありますどこ出力文書の？
準備
少なくとも3つの方法で、この前処理後のDEXドキュメントを作成ありますが、それは我々がODEX（DEXを最適化）と呼んでいるものです。
- Dalvikキャッシュ・ディレクトリへのJITモードの出力ドキュメント「ジャストインタイム」の仮想マシン。あなたは、エンジニアリングのマシンにすることができますこの方法ではなく、のDalvikキャッシュ・ディレクトリ・システムはアクセス制限を持っているので、実行することはできません本当のリリース後、デバイス、一般アプリは権限がありません。
- システムインストーラは、アプリのインストール後に実行されます。インストーラは、のDalvikキャッシュとしての権限を記述しています。
- ときにコンパイルシステムAOTの「前もって」の実施例による。APK DEX-抽出アウトから、そのような最適化などの操作を行い、ODEXドキュメントを生成するが、/データ/のDalvikキャッシュ・ディレクトリを置くが、/システムを入れていません/ appディレクトリ。
/データ/のDalvikキャッシュ・ディレクトリの下のDalvikキャッシュ・ディレクトリ。文書の権限0771は、システムに属している。アプリは唯一の変更はできません読み取ることができます。
ODEXドキュメントを生成する「ジャストインタイム」および「システムインストーラ」の方法について、次の3つの手順があります。
- 一般のDalvikキャッシュディレクトリのシステムインストーラ（installd）によって作成され、最初に。
- 第二に、classes.dexが出ジップ、および文書、目標ODEX書き込みヘッドの初めに予約領域の一部からドキュメントを抽出します。
- 第三に、ODEX文書が素早くアクセスするためのメモリに直接のmmapができ、および現在実行中のシステムにいくつかの調整をするために、ように再編成し、バイトスワップおよび構造を含む。しかし、元の文書には何もDEXの変更を行いません。同時に、基本的な構造の一部を行いますこのようなインデックスは、データをオフセットして境界を越えないよう文書を確認するチェック。
バックは、実行時に説明します、その理由は、これらの事に対処するために、事前にコンピュータ上ではもはやありませんが、その理由の特定のプロセスがあります。（これはdexopt、実行に時間がかかるため、アプリケーション開発に何らかの影響を持っていることはできませんが、 dexoptを進め、処理のみ）ターゲットマシン上で実行します
バイトスワップを行い、ODEX頭を記入します、合わせたとき。その後、あなたが実装プロセスを開始することができます。あなたはdexoptステップを追加する必要性を実行する前に、検証とoptimizaitonを懸念している場合。（Dexopt実際には、実行する必要があります）
dexopt
私たちは、障害が発生した場合、ベリファイ最適化プロセスが失敗した。最も簡単な方法は、仮想マシンにロードされたすべてのクラスを入れて、再びそれを実行することです。すべてのクラスDEXを確認し、最適化を実施している尋ねる。しかし残念ながら、そうすることはあまりを割り当てますそして（ネイティブlibのオフロードなど）のリソースを解放することは困難であるので、検証プロセスは、我々は最後の仮想マシンのプロセスが同じであるアプリケーションを実行することはできません。
呼ばれるdexoptプロセスを呼び出すことです、別のプロセス（実行時のフォークプロセスアウト）で実行して、実際には仮想マシンの小さなバックドアプロセスで物事を解決します。Dexoptラインまで、いくつかの小規模な初期化VMとロードされたDEX、その後、検証作業。完全終了プロセス、すべてのリソースの解放の実装を最適化します。
複数のVMが同じドキュメントを選ぶ必要がある場合には、文書を同期するためにロックを必要とし、文書には、彼と一緒に対処するための唯一のdexoptプロセスです。
検証
バイトコード検証プロセスは、目標は、この段階では、すべての違法なコマンドを識別することである。すべてのクラスのすべてのメソッドをスキャンするコマンドを必要としますが、実行時にチェックしません。
パフォーマンス上の理由から、正常に実行オプティマイザ仮説検証の次の章について話をする。そして、基礎的前提のいくつかは、安全でないだろう。のDalvikは、デフォルトですべてのクラスを確認し、そして唯一のクラスをオフにチェックするために最適化します。あなたがしたい場合は無効検証フラグでコマンドラインによって操作されてもよい。またによってhttp://www.netmite.com/android/mydroid/dalvik/docs/embedded-vm-control.html場合、フレームワーク内の制御層。
レポートの検証エラーは、このようなパッケージアクセス違反など、より複雑な問題である、我々は実際には、実行時に、このような検査報告書は、非常に時間がかかる。..することができ、開花段階でエラーを報告する必要はありません//www.netmite：HTTP。 COM /アンドロイド/ mydroid /のDalvik /ドキュメント/ verifier.html より詳細な理解。
ODEX文書にマークを行います。ロード時間が再びチェックしませんクラスフラグによって検証されます。
最適化
仮想マシンのインタプリタは、通常、最初のコードで行われ、このような定数プールの参照など、いくつかの最適化の作業は、内部データ構造に変換されます実行し、多くの場合、いくつかの作品に住んでコードの実装を成功させるための方法をポインター、それが別のものに変換されます他の人が静的なルールの数を介して行うことができますが、実行時にのみ動作し、その一部シンプルなフォーム、。
Dalvikオプティマイザは、次の手順を実行します。
- 仮想メソッド呼び出しのために、vtableの仮想関数ポインタテーブルインデックスの代わり方法インデックス文書を使用して。
- オブジェクトフィールドに/フィールドインデックスの代わりにオフセットが1バイトで、動作を入れます。また、32ビット形式のショートブーリアン/バイト/文字/を組み合わせる。（インタプリタで少ないコードはCPU Iキャッシュにおけるより多くの部屋を意味します）。
- このようString.lengthですのようないくつかの単純な関数（）これは、消費関数の呼び出しを減らすことができます。多くの場合、インライン関数に変更と呼ばれます。
- 空のメソッドをトリム。最も単純な例オブジェクトを。
そして、何もしない。しかし、それぞれの時間は、オブジェクト割り当てが呼び出されなければならなかった。デバッガがない限り、コマンドは、別の新しい実装に置き換えられ添付、または他に何もしません。 - いくつかの良いデータを追加する事前に計算することができ、再計算を実行することなく、ハッシュテーブルの良いクラス名を見つけるために、仮想マシンの事前に計算することができますような。
これらのコマンドはすべて、オペコードの交換は制約なしに、いくつかの仮想マシンの仕様を交換する必要変更します。これは、組み合わせ最適化および最適化されていないコマンドのために、より自由である。最適化されたコマンドと、彼らは結合を表す仮想マシンのバージョンと実際の意義。
最適化の作業の大半は成功です。より速く、元のインデックスを使用して実行できるオフセットだけでなく、シンボルテーブルを初期化し、無視することができます。ディスクスペースを食べるために、事前に計算されるので、必要な事前作業は、適切な計算します。
最適化の作業は、いくつかの潜在的に面倒があります。2番目のクラスの仮想マシンの更新は、別の文書でのdexのスーパー、とはDEXを更新した場合場合のVtable最初の仮想関数テーブルのインデックスとバイトオフセットの変更が発生します、その後、私たちはDEXがインデックスおよびオフセットを（つまり、再OPTに必要である）を更新する必要があることを確認する必要があります。私たちは実際には存在しないかもしれないクラスを呼び出すときに、我々はクラスローダーをカスタマイズする場合にも、同様のシナリオがより微妙です所望のクラス（クラス内の別のDEXをロードするDEXカスタムクラスローダによってクラスの最初を指します？）
これらの問題を最適化することができるかに依存関係リストと、いくつかの制限に対処しています。
依存関係と制限事項
最適化ODEXファイルは他のDEX 1つのリストが含まれた後に、それは修正さclasses.dex原稿と対応ODEX CRCを含む。依存関係リストは、文書のDalvikキャッシュへの完全なパスは、SHA-1を有する含ま署名タイムスタンプ文書タイムスタンプシステムは、VMのバージョン番号を含む。（時間フィールドであるべきであるzipファイルを使用して）信頼されるべきではなく、使用されると同時に、データに依存していません。
最適化されたDEXはDEX文書内のシステムブートストラップクラスパスのすべてに依存します。ブートストラップがより前方のDEXに他のブートストラップへの依存度である。他のすべての文書DEX頼る以外には利用できないことを確実にするために、dexoptだけ負荷クラスのブートストラップクラスは、他のDEXに依存する負荷とverificatinエラーにつながることができ、外部DEX依存クラスは単純に最適化されていませんがあります。
それらのよりDEX呼び出しまたは可変基準検証処理のうち、メソッドクラスのないよう最適化された粒径がないため、外部に頼る方法はありません。これは、負の効果がある場合、コードが複数のDEXとしてパッケージ化されたときことを意味します。あまりにも多くのビットをしている間、クラスのDEXが。最適化するが、これは、別のdexの更新を保証する唯一の方法である、他のDEXに影響を与えません。
もう一つの負の影：システムアップデートのためのDEXブートストラップ、これらの最適化の障害発生後に依存DEXに戻り、再OPTする必要があります。
我々は非常に注意を払っているが、Stringなどのクラスのシステムに戻るには、クラスの名前のように、カスタムを使用してクラスローダをカスタマイズすることも可能である。DEXでは、クラス名と同じのブートストラップDEX場合。その後、このクラスがマークされているが曖昧であり、そして最適化にプロセスを識別し、VM内のクラスの連結コードを検証することができない細部（VM / OO / class.c）のためのVMソースに詳細な説明を参照;.別の穴を塞ぐための追加のチェックを行い。
ODEX dexopt文書出力装置は、バイトスワップその動作に、構造体整列相対。索引オフセット、等であり、仮想マシンが含まれており（バージョン、プラットフォーム、などを含む）高度に一致している。このため、しません事前にこれを行うには、PC上dexopt実行を書き込むことができる。dexopt最も安全な方法は、デバイスの実行、または対応するシミュレータ上で実行することです。
上記の言語は、単なる翻訳で関連情報の最近の外観を整理する必要性を感じている。これは、システムのソースコードで見つけることができます。
オンラインリンクhttp://www.netmite.com/android/mydroid/dalvik/docs/dexopt.html