Android 5.0 Lollipopのコードを最適化する5つの方法

プログラムを高速化する方法は？ 1つの効果的な方法は、コードの最適化です。 アプリケーションが作成されるプラットフォームの機能を知っていれば、それをスピードアップする効果的な方法を見つけることができます。

予備情報

ART （Android RunTime）は、Androidアプリケーション用の新しいランタイム環境です。 Android 5.0では、デフォルトでLollipop ARTが最初に使用されます。 生産性の向上を目的とした多くの機能強化が含まれています。 この記事では、ARTのいくつかの新機能について説明し、以前に使用したAndroid Dalvikランタイムと比較し、アプリケーションを高速化する5つのヒントを共有します。

ARTの新機能

Dalvik環境で実行される多くのAndroidアプリケーションのプロファイリング中に、ユーザーが特別な注意を払う2つの重要な機能が発見されました。 最初の機能は、アプリケーションの起動に必要な時間です。 2つ目は、さまざまな種類の「スローダウン」（ジャンク）の数です。 最悪の場合、それはつまずく音、動揺するアニメーション、さらにはアプリケーションの予期しない停止です。 これは通常、アプリケーションが次のフレームの準備に時間がかかりすぎるために発生します。 その結果、デバイス画面のリフレッシュレートに追いついていません。 次のフレームが前のフレームよりもはるかに速くまたは遅く形成される場合、フレーム形成の速度が問題になる可能性があります。 このようなことが発生した場合、ユーザーはインターフェイス要素の動作にぎこちが見られます。 これにより、ユーザーと開発者の両方が望むよりも、プログラムとの対話がはるかに不便になります。 ARTには、上記の問題を解決するために設計されたいくつかの新しい機能があります。

• 実行前のコンパイル。 ARTは、デバイスにインストールされたdex2oatツールを使用して、インストール中にアプリケーションをコンパイルします。 結果は、ターゲットアーキテクチャ用にコンパイルされた実行可能ファイルです。 比較のために、Dalvikはインタープリターを使用し、その場でアプリケーションをコンパイルします。 インストール中に、DalvikはAPKファイルを最適化されたDEXコードに変換し、アプリケーションの起動時にすでにマシン命令にコンパイルします。 その結果、ART環境ではアプリケーションの実行が高速になりますが、インストールにかかる時間が長くなります。 さらに、このアプローチでは、インストール中にコンパイルされたコードを保存するために追加のストレージが必要になるため、アプリケーションはより多くのデバイスフラッシュメモリを使用します。
  
  
  
  
• 改善されたメモリ割り当てメカニズム。 メモリを集中的に使用するアプリケーションでは、Dalvikの使用時にパフォーマンスの問題が発生する場合があります。 大きなオブジェクトのデータを保存するための個別のスペースと、ARTでメモリを割り当てるための改善されたメカニズムは、この問題を軽減するのに役立ちます。
  
  
  
  
• ガベージコレクションの改善 。 ARTには、データの並列処理をサポートする高速なガベージコレクターが搭載されており、メモリの断片化が少なくなり、効率的に使用できます。
  
  
  
  
• JNIパフォーマンスの改善。 JNIコード呼び出しの最適化とそれからの戻り。これにより、JNI呼び出しを行うために必要な命令の数が削減されます。
  
  
  
  
• 64ビットアーキテクチャのサポート。 ARTは、64ビットアーキテクチャに最適です。 これにより、多くのアプリケーションを適切なハードウェアで実行する際のパフォーマンスが向上します。
  
  

これらの機能強化の複合効果により、Android SDKのみを使用して記述されたアプリケーションとJNI呼び出しを集中的に使用するプログラムの両方に対するユーザーの認識が向上します。 ユーザーの観点からの追加の利点には、1回の充電でより長いバッテリー寿命が含まれます。 ここでのポイントは、アプリケーションは一度しかコンパイルされず、結果としてより高速に実行されるということです-日常の使用で消費されるバッテリー電力は少なくなります。

ARTとDalvikのパフォーマンスの比較

Android KitKat 4.4の暫定版としてARTがリリースされたばかりのとき、Dalvikと比較してパフォーマンスに批判がありました。 このような比較は正直とは言えません。 結局のところ、彼らはARTの初期の予備バージョンを成熟した製品と比較し、長年の作業を通じて多くの改善を施しました。 これらの初期テストの結果、一部のアプリケーションは、DalvikよりもART環境で遅くなりました。



現在、量産デバイスで使用されている成熟したART環境をDalvikと比較する機会があります。 Android 5.0ではARTのみが使用されているため、ARTとDalvikの直接比較は、最初にAndroid KitKat 4.4がインストールされた特定のデバイスでテストを実行し、Dalvik環境のデータを受信し、Android Lollipop 5.0に更新して実行する場合にのみ可能ですART環境向けの同じ一連のテスト。



この資料を準備する際に、Intel AtomプロセッサをベースにしたSurfTab xintron i7.0タブレットで同様のテストを行いました。 最初に、Android 4.4.4がインストールされ、それに応じて、テスト中にDalvikが使用され、次にデバイスがAndroid 5.0に更新されました。 ARTのパフォーマンスをテストしました。



テストはAndroidのさまざまなバージョンで実行されたため、検出された改善の一部はARTではなく、他のAndroidの改善によるものである可能性があります。 ただし、内部パフォーマンス分析に基づいて、システムパフォーマンスが向上する主な理由はARTの使用であると言えます。



何度も実行されるコードの積極的な最適化によりDalvikが利点を得ることができるパフォーマンステストを使用しました。 さらに、インテルが開発したゲームアプリケーションシミュレーターを使用してシステムをテストしました。



得られたデータに基づいて、ARTはすべてのテストでDalvikよりも優れていると結論付けることができます。 場合によっては、この優位性は非常に重要です。





ART（Android Lollipop）およびDalvik（Android KitKat）の相対的なテストパフォーマンス



使用したテストアプリケーションの詳細については、次のリンクをクリックしてください。

• 象限2.1.1
  
  
• カフェインマーク2.0
  
  
• Smartbench 2012の生産性
  
  
• Antutu 4.4全体 （テスト中に使用されたバージョンはダウンロードできなくなりました）
  
  
• CFベンチ1.3全体

IcyRocksバージョン1.0は、Intelが作成したデバイスパフォーマンステストアプリケーションです。 実際のコンピューターゲームを模倣します。 ほとんどの計算では、オープンソースのCocos2DライブラリとJBox2Dライブラリ（物理エンジン、Java物理エンジン）を使用します。 アプリケーションは、さまざまな負荷レベルで1秒間に出力するために管理するフレームの平均数（FPS、1秒あたりのフレーム数）を測定します。 次に、さまざまな動作モードで取得したFPSインジケーターの幾何平均を使用して、最終的なインジケーターを計算します。 さらに、プログラムは、異なる負荷レベルでのそのようなフレーム間の平均として、「不正な」フレーム/秒（ジャンク/秒）のレベルを計算します。 IcyRocksは、Dalvikに対するARTの優位性を示しています。





ARTおよびDalvik環境でパフォーマンスをテストする際の1秒あたりの相対フレーム



テストの結果、ARTではフレームの特性がDalvikよりも一定であり、「不正な」フレームが少ないことがわかりました。 その結果、ARTでは、アプリケーションインターフェイスがよりスムーズに機能します。





ARTおよびDalvik環境でのテスト時の「不正な」フレーム/秒の相対的な数値



得られた結果から、今日のARTでは、Dalvikよりも優れたユーザーエクスペリエンスと生産性を実現できると自信を持って言えます。

DalvikからARTへのコードの移植

DalvikからARTへの移行は透過的です。Dalvik環境で動作するほとんどのアプリケーションは、コードを変更することなくART環境でも動作します。 その結果、ユーザーがシステムを更新すると、余分な労力をかけずにアプリケーションの動作が速くなります。 ただし、特にアプリケーションがJava Native Interfaceを使用している場合、ART環境でテストするのに問題はありません。 実際、ARTは、JNIエラーを処理するためにDalvikよりも厳密なメカニズムを使用しています。 詳細については、こちらをご覧ください。

コードを最適化するための5つのヒント

ART環境で実行されるほとんどのアプリケーションのパフォーマンスは、上記で説明したプラットフォームの改善によってのみ向上します。 ただし、パフォーマンスをさらに向上させるためにアプリケーションを最適化するために従うことができる一連の推奨事項があります。 以下に説明する各コード最適化手法には、その動作の特徴を示す簡単なコード例が装備されています。



いずれかの最適化アプローチを使用して、どのパフォーマンスゲインが期待できるかを正確に事前に予測することは不可能です。 ここでのポイントは、すべてのアプリケーションが異なり、それらの最終的なパフォーマンスは、残りのコードとその使用機能に大きく依存するということです。 ただし、提案された最適化方法がアプリケーションのパフォーマンスを改善できる理由を説明します。 アプリケーションへの影響を評価するには、コードに適用してテストします。



私たちが提供する推奨事項は広く適用できますが、ARTで作業する場合、dex2oatコンパイラーによって改善が認識され、dexファイルからバイナリー実行可能コードを生成して最適化することに焦点を当てています。

ヒント番号1。 可能な限り、クラスのパブリックフィールドの代わりにローカル変数を使用します。

変数のスコープを制限することにより、コードの可読性が向上し、潜在的なエラーの数が減るだけでなく、最適化により適したものになります。



以下に示す非最適化コードのブロックでは、変数vの値が実行時に計算されます。 これは、この変数がm（）メソッドの外部からアクセス可能であり、コードの任意の部分で変更できるという事実によるものです。 したがって、変数の値はコンパイル段階では不明です。 コンパイラは、 some_global_call（）メソッドを呼び出すと、この変数の値が変更されるかどうかを知りません。変数vを繰り返すと、メソッド外のコードを変更できるためです。



この例の最適化バージョンでは、 vはローカル変数です。 そのため、その値はコンパイル段階で計算できます。 その結果、コンパイラーは生成するコードに変数の値を入れることができます。これは、実行時に変数の値を計算することを回避するのに役立ちます。

最適化されていないコード	最適化されたコード
class A { public int v = 0; public int m(){ v = 42; some_global_call(); return v*3; } }	class A { public int m(){ int v = 42; some_global_call(); return v*3; } }

ヒント番号2。 finalキーワードを使用して、フィールド値が定数であることをコンパイラに伝えます

finalキーワードは、定数でなければならない変数を誤って変更することからコードを保護するために使用できます。 ただし、コンパイラの前に定数があることを伝えるため、パフォーマンスは向上します。



最適化されていないコードのフラグメントでは、 vの値が変更される可能性があるため、実行時に値v * v * vを計算する必要があります。 最適化されたバージョンでは、変数を宣言してそれに値を割り当てるときにfinalキーワードを使用すると、変数の値が変更されないことがコンパイラーに通知されます。 したがって、値の計算はコンパイル段階で実行でき、プログラム実行中に値を計算するコマンドではなく、値が出力コードに追加されます。

最適化されていないコード	最適化されたコード
class A { int v = 42; public int m(){ return v*v*v; } }	class A { final int v = 42; public int m(){ return v*v*v; } }

ヒント番号3。 クラスとメソッドを宣言するときにfinalキーワードを使用します

Javaのメソッドはいずれも多態的である可能性があるため、 finalキーワードを使用してメソッドまたはクラスを宣言すると、メソッドはサブクラスでオーバーライドされないことがコンパイラーに通知されます。



コードの最適化されていないバージョンでは、関数m（）を呼び出す前に、それを解決する必要があります。

最適化されたコードでは、 m（）メソッドを宣言するときにfinalキーワードを使用するため、コンパイラーはメソッドのどのバージョンが呼び出されるかを認識しています。 したがって、メソッドの検索を回避し、プログラムの必要な場所に埋め込むことにより、 m（）メソッドの呼び出しをそのコンテンツに置き換えることができます。 その結果、生産性が向上します。

最適化されていないコード	最適化されたコード
class A { public int m(){ return 42; } public int f(){ int sum = 0; for (int i = 0; i < 1000; i++) sum += m(); // m return sum; } }	class A { public final int m(){ return 42; } public int f(){ int sum = 0; for (int i = 0; i < 1000; i++) sum += m(); return sum; } }

ヒント番号4。 JNIを介した小さなメソッドの呼び出しを避ける

JNI呼び出しを使用するのには十分な理由があります。 たとえば、Javaアプリケーションで再利用したいC / C ++コードまたはライブラリがある場合。 おそらく、クロスプラットフォームアプリケーションを作成するか、低レベルのメカニズムを使用して生産性を向上させることが目標です。 ただし、JNI呼び出しはそれぞれシステムに大きな負荷をかけるため、JNI呼び出しの数を最小限に抑えることが重要です。 JNIを使​​用してパフォーマンスを最適化すると、この追加の負担により、期待される利点が失われる可能性があります。 特に、計算上重要ではない短いJNIメソッドを頻繁に呼び出すと、パフォーマンスが低下する可能性があります。 そして、そのような呼び出しがサイクルに入れられると、システムの不必要な負荷が増加するだけです。



コード例

 class A { public final int factorial(int x){   int f = 1;   for (int i =2; i <= x; i++)     f *= i;   return f;  } public int compute (){   int sum = 0;   for (int i = 0; i < 1000; i++)     sum += factorial(i % 5); //    JNI-  factorial(), //     , //        //          JNI-   return sum; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ヒント番号5。 ネイティブコードで同じ機能を実装する代わりに標準ライブラリを使用する

標準Javaライブラリは真剣に最適化されています。 Javaの内部メカニズムを可能な限り使用すると、可能な限り最高のパフォーマンスを実現できます。 標準ソリューションは、自作の実装よりもはるかに高速に動作できます。 実際には、標準ライブラリ関数の呼び出しを拒否することにより、追加のシステム負荷を回避しようとすると、パフォーマンスが低下する可能性があります。

コードの最適化されていないバージョンは、数値の絶対値を取得するアルゴリズムの独自の実装により、標準関数Math.abs（）の呼び出しを回避しようとする試みを示しています。 ただし、コンパイル時にARTの最適化された内部実装によって呼び出しが置き換えられるため、ライブラリ関数が呼び出されるコードはより高速に動作します。

最適化されていないコード	最適化されたコード
class A { public static final int abs(int a){ int b; if (a < 0) b = a; else b = -a; return b; } }	class A { public static final int abs (int a){ return Math.abs(a); } }

最適化手法のテスト

ART環境で実行する際のヒント＃2の最適化されたコードと最適化されていないコードのパフォーマンスの違いを調べてみましょう。 この実験では、Intel Atom Z3530 CPUをベースに構築されたAsus Fonepad 8タブレットを使用します。 デバイスがAndroid 5.0に更新されました。



テストするコードは次のとおりです。

 public final class Ops {   int v = 42;   final int w = 42;   public int testUnoptimized(){       return v*v*v;   }   public int testOptimized(){       return w*w*w;   } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

testUnoptimizedメソッドとtestOptimizedメソッドの違いは、2番目のメソッドが最適化され、その中で使用される変数wがfinalキーワードで宣言されることだけです。



テスト中、各メソッドは指定された回数呼び出されます。 これらの呼び出しが行われるサイクルは、バックグラウンドスレッドで実行されます。 テストが完了すると、結果がアプリケーションのユーザーインターフェイスに表示されます。





最適化結果をテストするためのアプリケーションインターフェイス



この表は、アプリケーションのリリースバージョンで10回連続してテストを実行した結果を示しています。 個々のインジケータはそれぞれ、対応するメソッドのサイクリックコールの結果として1,000万回取得されました。



最適化されたコードと最適化されていないコードの実行速度の比較

いや	最適化、ミリ秒。	最適化されていない、ms。
1	25	193
2	21	203
3	30	220
4	25	175
5	23	184
6	28	177
7	30	186
8	27	191
9	34	212
10	27	174
平均	27	191.5

その結果、最適化されたメソッドは、最適化されていないメソッドよりも平均で7倍速く実行されることがわかりました。



Android Studioへのインポートに適したプロジェクトソースコードは、 こちらにあります 。

ARTのIntel最適化

IntelはOEMと協力して、Intelプロセッサ向けに最適化されたバージョンのDalvikを提供しました。 ARTでも同じことが起こります。その結果、新しいランタイム環境のパフォーマンスは時間とともに向上します。 コードの最適化されたバージョンは、Androidオープンソースプロジェクト（AOSP）で入手するか、デバイスメーカーから直接入手できます。 前と同様に、最適化はユーザーと開発者の両方にとって透過的です。つまり、それらの利点を活用するために、どちらも追加の努力をする必要はありません。



Intelプロセッサーに基づいたデバイス向けのAndroidアプリケーションの最適化の詳細については、コンパイラーについて知り、 Intel Developer Zoneにアクセスしてください。

まとめ

この記事では、新しいART Androidランタイムの主な機能を調べました。 ceteris paribusを使用すると、Dalvikよりも優れたパフォーマンスインジケーターを実現できます。 しかし、特定の各アプリケーションのパフォーマンスは、ランタイムだけでなく開発者にも大きく依存します。 コード最適化のヒントが、高速で便利なアプリケーションの作成に役立つことを願っています。