生産的なアプリケーション開発

生産的なアプリケーション

Androidプラットフォーム用のアプリケーションは、コンピューティング機能とメモリが制限され、バッテリー寿命が短いモバイルデバイスで起動されます。 したがって、アプリケーションは効果的でなければなりません。 バッテリーの寿命は、アプリケーションが十分に高速で実行されている場合でも、アプリケーションを最適化する理由の1つです。 バッテリーの寿命はユーザーにとって非常に重要であり、Androidプラットフォームは、アプリケーションがバッテリーの寿命を大幅に短縮する場合にユーザーに簡単に表示します。



ここではマイクロ最適化について説明しますが、アプリケーションを損傷することはほとんどありません。 適切なアルゴリズムとデータ構造を選択することが常に最優先事項であるはずですが、この側面は考慮されません。

イントロ

生産的なコードを開発するための2つの基本的なルール：

• する必要のない仕事をしないでください
• 割り当てられないメモリを割り当てないでください

賢明な最適化

Androidのマイクロ最適化について説明します。そのため、プロファイラーを使用して、最適化する必要がある特定のコードを決定し、変更の影響を評価する方法を既に知っていることを前提としています。 開発に多くの時間を費やしているので、賢明にそれを費やしていることを知ることが重要です。



また、最適なアルゴリズムとデータ構造をすでに選択しており、APIの決定がパフォーマンスに与える影響を予測していることも前提としています。 適切なデータ構造とアルゴリズムを使用すると、これらのヒントよりもパフォーマンスが大幅に向上し、APIがパフォーマンスに与える影響を慎重に検討することで、将来のより良い実装への移行が容易になります（これは、アプリケーションコードではなくライブラリコードにとって主に重要です）。



Androidアプリケーションのマイクロ最適化中に発生する最も厄介な問題の1つは、アプリケーションが多くの異なるハードウェアプラットフォームで動作する可能性が高いことです。 異なるプロセッサ上の異なるバージョンの仮想マシンは、異なる速度で動作します。 一般に、これは単に「デバイスXはデバイスYのn倍高速/低速」と言って、結果を他のデバイスに外挿できる場合でもありません。 特に、エミュレータでのテストでは、デバイスのパフォーマンスについてほとんど何も言われていません。 また、JITを搭載したデバイスと搭載しないデバイスの間には大きな違いがあります。JITを搭載したデバイスの「最適な」コードは、JITを搭載していないデバイスにとって必ずしも最適なものではありません。



一部のデバイスでアプリケーションがどのように動作するかを知りたい場合は、テストする必要があります。

不要なオブジェクトを作成しない

オブジェクトの作成が無料になることはありません。 各スレッドの一時オブジェクトの世代とプールを操作するガベージコレクターは、メモリの割り当てを容易にしますが、メモリを割り当てるのは、割り当てないよりも常に高価です。



ユーザーインターフェイスでループ内のオブジェクトを選択すると、定期的なガベージコレクションが強制され、ユーザーに表示される小さな「スタッター」が作成されます。 Gingerbreadで導入されたパラレルガベージコレクターはこれに役立ちますが、不必要な作業は常に避ける必要があります。



したがって、不要なオブジェクトの作成は避けてください。 ここに役立ついくつかの例を示します。

• 文字列を返すメソッドがあり、結果が常にStringBufferに追加されることがわかっている場合は、一時的な一時オブジェクトを作成するのではなく、メソッドが直接追加を実行するように実装を変更します。
• 入力データセットから文字列を抽出するとき、コピーを作成する代わりに、初期データの部分文字列を返すようにしてください。 新しいStringオブジェクトが作成されますが、その文字の配列と初期データは共有されます。 （妥協点は、このアドバイスに従えば、初期入力のごく一部しか使用されない場合でも、全体が保存されることです）。

もっと急進的なものを見てみましょう：多次元配列を1つの並列1次元配列に分割します：

• int配列はInteger配列よりもはるかに優れています。 ただし、この事実は一般化できます。2つの並列int配列は、オブジェクトの配列（int、int）よりもはるかに効率的です。 プリミティブの任意の組み合わせについても同じことが言えます。
• ペア（Foo、Bar）を含むコンテナを実装する必要がある場合、2つの並列配列Foo []およびBar []は、オブジェクトの単一の配列（Foo、Bar）よりもはるかに優れていることに注意してください。 （例外は、APIを開発している場合です。これらの場合、パフォーマンスを少し損なうだけで良いAPIに固執することをお勧めします。ただし、独自のコードで可能な限り効率的になるようにしてください。）

一般的に、可能であれば短命のオブジェクトを作成しないでください。 作成されるオブジェクトの数が少ないと、ガベージコレクションの頻度が少なくなり、ユーザーとの対話に直接影響します。

パフォーマンス神話

このマニュアルの古いバージョンには、さまざまな誤った記述が含まれています。 それらのいくつかに対処します。



JITを持たないデバイスでは、特定のクラスのオブジェクトのメソッドを呼び出す方が、インターフェイスを介して呼び出すよりもわずかに高速です。 （したがって、同じオブジェクトであっても、Mapの代わりにHashMapメソッドを呼び出す方が安価です。）2倍高速ではありません。 実数は6％に近い値です。 さらに、JITを使用した場合、その違いはほとんど認識できません。



JITのないデバイスでは、クラスフィールドへのキャッシュアクセスは、フィールドへの直接呼び出しを繰り返すよりも20％高速です。 JITでは、フィールドにアクセスするコストはローカルアドレスにアクセスするコストと等しいため、コードを読みやすくするまでこの最適化は必要ありません。 （最終フィールド、静的フィールド、および静的最終フィールドに関して当てはまります）。

仮想よりも静的を優先

オブジェクトのフィールドにアクセスする必要がない場合、メソッドを静的にすることができます。 呼び出しは15〜20％高速になります。 これは、メソッドがオブジェクトの状態を変更しないことを署名によって言うことができるため、良いです。

内部アクセサーメソッドを避ける

C ++などのネイティブ言語では、直接アクセス（i = mCount）の代わりにゲッター（i = getCount（）など）を使用することをお勧めします。 これは、コンパイラが通常インライン置換を実行できるため、C ++のすばらしい習慣です。フィールドアクセスを制限またはデバッグする必要がある場合は、必要なコードをいつでも追加できます。



Androidの場合、これは悪い考えです。 仮想メソッドの呼び出しは非常に高価です-オブジェクトフィールドを検索するよりもはるかに高価です。 もちろん、一般的なOOPプラクティスの使用、およびインターフェイスでのゲッターとセッターの使用は正当化されますが、クラス内では常にフィールドに直接アクセスする必要があります。



JITがない場合、フィールドへの直接アクセスは、通常のゲッターを呼び出すよりも約3倍高速です。 JITでは、直接アクセスがローカルアドレスへの直接アクセスと同じ速度である場合、直接アクセスはアクセサメソッドを呼び出すよりも約7倍速くなります。 この声明はFroyoにも当てはまりますが、将来のリリースでは、JITがgetterをインライン化するため、状況は改善されます。

定数に静的ファイナルを使用

クラスの先頭で次の宣言を検討してください。

static int intVal = 42; static String strVal = "Hello, world!";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイラは、クラスが最初に使用されるときに実行される名前で、クラス初期化メソッドを生成します。 メソッドは42をintValに割り当て、strValのクラスファイルの不変行のテーブルからリンクを抽出します。 これらの変数にアクセスすると、クラスの対応するフィールドが検索されます。



最後の1つのキーワードでこの動作を変更する方法は次のとおりです。

  static final int intVal = 42; static final String strVal = "Hello, world!";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

定数はdexファイルの静的フィールド初期化子に書き込まれるため、このメソッドは不要になりました。 intValにアクセスするコードは整数値42を直接使用し、strValにアクセスすると、フィールドを検索する代わりに文字列定数への安価な呼び出しが発生します。 （この最適化は、すべての任意のリンクタイプではなく、プリミティブと文字列に対してのみ機能することに注意してください。それにもかかわらず、可能な限り静的なfinalとしての定数宣言を使用する必要があります。）

改良されたForループ構文の使用

for-eachループは、 Iterable



インターフェイスと配列を実装するコレクションに使用できます。 hasNext（）およびnext（）メソッドを呼び出すために、コレクションにイテレーターが割り当てられます。 ArrayList



カウンターを使用しArrayList



従来のループは（JITの有無にかかわらず）約3倍高速ですが、他のコレクションの場合、「for-each」構文はイテレーターを明示的に使用するのと同等です。



配列を走査する方法はいくつかあります。

  static class Foo { int mSplat; } Foo[] mArray = ... public void zero() { int sum = 0; for (int i = 0; i < mArray.length; ++i) { sum += mArray[i].mSplat; } } public void one() { int sum = 0; Foo[] localArray = mArray; int len = localArray.length; for (int i = 0; i < len; ++i) { sum += localArray[i].mSplat; } } public void two() { int sum = 0; for (Foo a : mArray) { sum += a.mSplat; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

zero（）は最も遅いメソッドです。JITは反復の各ステップで配列の長さを取得することを最適化できないためです。



one（）は高速です。 必要な情報をローカル変数に取り込み、フィールド検索を回避します。 ここではarray.lengthのみがパフォーマンスを改善します。



two（）は JITのないデバイスではより高速で、JITのあるデバイスでは1（）と区別できません。 Java 1.5で導入された拡張構文を使用します



結論：デフォルトでfor-each構文を使用しますが、パフォーマンスが重要なArrayList



パスを手動で繰り返すことをArrayList



してください。 （ 有効なJavaの段落46も参照してください。）

プライベート内部クラスには、プライベートではなくパッケージプライベートアクセスを使用します。

次のクラス定義を検討してください。

  public class Foo { private class Inner { void stuff() { Foo.this.doStuff(Foo.this.mValue); } } private int mValue; public void run() { Inner in = new Inner(); mValue = 27; in.stuff(); } private void doStuff(int value) { System.out.println("  " + value); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注意すべき最も重要なことは、プライベートクラスと外部クラスのプライベートフィールドを直接参照するプライベート内部クラス（Foo $ Inner）の定義です。 コードは正しく、予想どおり「値は27」と表示されます。

ここでの問題は、Javaが内部クラスから外部クラスのプライベートメンバーへのアクセスを許可している場合でも、FooとFoo $ Innerは異なるクラスであるため、仮想マシンは内部クラスからFooのプライベートメンバーへの直接アクセスを受け入れられないと見なすことです。 このギャップを埋めるために、コンパイラーはいくつかの人工的なメソッドを生成します。

 /*package*/ static int Foo.access$100(Foo foo) { return foo.mValue; } /*package*/ static void Foo.access$200(Foo foo, int value) { foo.doStuff(value); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

内部クラスは、mValueにアクセスする必要があるたびにこれらの静的メソッドを呼び出すか、外部クラスのdoStuff（）を呼び出します。 つまり、上記のコードは、アクセサーメソッドを介してクラスのフィールドにアクセスする場合になります。 フィールドに直接アクセスする前に、そのようなメソッドの速度が遅いという問題についてはすでに説明しました。そのため、言語の特定のイディオムは「目に見えない」パフォーマンスの低下につながります。



アプリケーションのパフォーマンスが重要な部分で同様のコードを使用する場合、内部クラスからアクセスされるフィールドおよびメソッドを宣言することにより、この動作を回避できます。プライベートではなくパッケージプライベートです。 残念ながら、これはフィールドがパッケージ内の他のクラスからアクセスできることを意味するため、この手法はパブリックAPIで使用できません。

浮動小数点数を賢く使う

要するに、浮動小数点の計算は、Androidデバイスの整数の約2倍遅くなります。 これは、G1（JITおよびFPUなし）およびFPUおよびJIT付きNexus Oneに当てはまります。 （もちろん、算術演算の速度に関する2つのデバイスの絶対的な差は約10倍です）。



速度の面では、最新のハードウェアではfloatとdoubleの間に違いはありません。 メモリから、doubleは2倍大きくなります。 デスクトップコンピューターでは、メモリを考慮せずに、floatではなくdoubleを使用する必要があります。



また、一部のチップには整数の整数乗算が搭載されていますが、整数除算は組み込まれていません。 このような場合、整数の除算とモジュロ演算はソフトウェアレベルで実行されます。 ハッシュテーブルを作成する場合、または多くの数学演算を実行する場合は、このことを考慮してください。

ライブラリを理解して使用する

独自のコードを作成する代わりにライブラリコードを使用するすべての通常の理由に加えて、システムがライブラリコードをアセンブラーインサートに置き換えることができることを念頭に置いてください。これは、同等のJava用のJITコンパイラーによって生成された最高のコードよりも高速です 典型的な例は、 String.indexOf



およびDalvikが内部コードに置き換える他のメソッドです。 このため、 System.arraycopy



、既存のJITを備えたNexus Oneに手動で実装されたループよりも約9（！）倍高速です。 （ 有効なJavaの段落47も参照してください。）

ネイティブメソッドを賢く使用する

ネイティブコードは必ずしもJavaよりも効率的ではありません。 理由の1つは、Java->ネイティブコードの移行に料金がかかり、JITはこれらの範囲内では何もできないことです。 ネイティブリソースを割り当てる場合

（ヒープ上のメモリ、ファイル記述子など）、これらのリソースをタイムリーに収集する複雑さが著しく増加します。 また、JITに依存する代わりに、実行する予定の各アーキテクチャのコードをコンパイルする必要があります。 同じアーキテクチャの複数のバージョンをコンパイルすることもできます。G1のARMプロセッサ用にコンパイルされたネイティブコードは同じプロセッサを最大限に活用できませんが、Nexus Oneでは、Nexus One用にコンパイルされたコードはG1で実行されません。



ネイティブコードは、Androidに移植したいネイティブベースがあり、Javaアプリケーションの個々の部分を高速化しない場合に最も役立ちます。 （有効なJava、段落54も参照してください。）

最後に

最後に、常に測定します。 最適化を開始する前に、問題があることを確認してください。 既存のパフォーマンスを正確に測定できることを確認してください。そうしないと、代替ソリューションから得られる利点を測定できなくなります。



ここで作成されたすべてのステートメントは、テストによってバックアップされます。 ソースコードは、dalvikプロジェクトのcode.google.comにあります。



これらのテストは、Caliper微量測定フレームワークを使用して記述されています。 マイクロ測定を正しく実行するのは難しいため、Caliperを使用すると、ハードワークを行うことができ、測定しようとしているものを測定していない場合も特定できます（たとえば、仮想マシンがコードを完全に最適化したため）。 Caliperを使用して独自の微量測定を行うことを強くお勧めします。



プロファイリングにTraceviewを使用することもできますが、JITがオフになり、JITが再生できる多くのランタイムにつながることを理解することが重要です。 Traceviewによって提案された変更を行った後、Traceviewなしで実行された場合、結果のコードが実際により速く実行されることを確認することが特に重要です。