これまでのところ、私はウェブサイトYouhtc.ruでそのような情報を見つけることができました
」
過去数年間、Androidのクリエイターの仕事の重要な部分は、システムの主要な先天的な「病気」との戦いになっています-インターフェースのアニメーションの遅れです。 この方向への最初の重大なステップは、Android 4.1 Jelly Beanとともに発表されたProject Butterであり、システムを実際に「加速」しましたが、根本的に問題を解決しませんでした。 Googleはこれを認識しているため、Dalvik仮想マシンの代替品であるARTを準備しています。
現在でも、マルチコアプロダクションプロセッサの時代では、特定の状況下で、Androidのアニメーションが完全にレンダリングされず、アクション間に目に見えるヒッチがあることがわかります。 問題は複雑であるため、それを解決するために多くのステップを踏まなければなりませんでした-その1つとして、DalvikをARTプリコンパイラに変更することにしました。
Androidコードは、モバイルデバイス専用にGoogleが作成したJavaマシンで実行されますが、外出中にハードウェアに変換されます（ジャストインタイムコンパイル）。 このようなメカニズムにより、アプリケーション開発者は実際には特定のアーキテクチャやハードウェアに縛られることはありませんが、深刻なパフォーマンスの損傷を引き起こし、コンパイル中にプロセッサをロードします。 もちろん、プログラムの最初の「ブレーキ」開始後、受信した「ネイティブ」コードの一部はキャッシュに保存されますが、これはラグの問題を完全には解決しません。
ARTはAOT-Of-Timeコンパイラ（Ahead-Of-Time）であり、インストールプロセス中にJavaコードを「ネイティブ」に変換します。 つまり、ユーザーは既にコンパイルされたプログラムを起動します。これにより、プログラムの起動と実行が大幅に高速化されます。 ARTがAndroid 4.4 KitKatにすでに組み込まれていることは、興味深いことに、開発者のメニューでアクティブ化できます。 libart.so（コンパイラライブラリ）に切り替えた後、デバイスは再起動し、インストールされているすべてのアプリケーションをコンパイルします。 ARTを慎重に研究したAndroid Policeの関係者は、これはまだAOSPのカスタムファームウェアで行う価値はないと主張しています。Googleのソフトウェアパッケージに問題がある可能性があります。
ARTの不完全な状態を考慮しても、それへの移行は、リソースを集中的に使用するタスクの速度とインターフェイスの円滑な動作に大きな影響を与え、また、マルチコアプロセッサが未使用のカーネルをより頻繁に無効にすることを可能にします。これにより、デバイスのバッテリ寿命が向上します。 新しいコンパイルシステムには欠点がありますが、それらを重要と呼ぶことは困難ですが、インストール時間が長くなり、最終的なプログラムサイズが10〜20％増加します。 確かに、コード部分のみのサイズが大きくなり、アプリケーションの半分以下で済むことがよくあります。マルチメディア（画像、サウンド、ビデオ）およびその他のデータのサイズは変わりません。
Googleは1年以上ARTに取り組んでおり、KitKatに含めることは、システムの作成者が本格的なテストを実施し、アプリケーション開発者が今後のDalvikの「出発」に備えることを可能にする絶対に意図的なソリューションです。 Googleが今年10月に購入したFlexyCore開発者が新しいコンパイラにどの程度影響を与えたかはまだ明らかではありませんが、プロジェクトは検索の巨人自身の中で始まりました。
GoogleはまだARTがDalvikに取って代わる時期を明言していないが、企業がシステムの次のバージョンでこれを行うことを妨げるものは何もない。 興味深いことに、Project Butterのように、コンパイラはアプリケーション開発者の労力を必要としません-確立された慣行を使用して、よく知られた言語でコードを記述します。
」
新しいテクノロジーを自分で試すためのAndroid 4.4のデバイスはありませんが、Googleのシステムのイメージは既に利用可能であり、エミュレーターで「タッチ」できます。
この機能が、Google以外のAndroid 4.4を搭載した他のデバイス（Samsung、HTCなど）で利用可能になるかどうか、まだ疑問があります。 新しいプラットフォームへの移行後、アプリケーションのすべての機能は正しく機能しますか？
情報は非常に少ないので、コメントに書いてください。より大きなサイズで入手できます。