Android性能最適化のJavaコード最適化(Android性能最適化の一書より抜粋)

4264 ワード
and roid
コードの最適化はアプリケーション開発の最も重要な任務ではなく、良好なユーザー体験を提供し、コードのメンテナンス性に専念することがあなたの最も重要な任務です.実際には、コード最適化は最後に行われるべきであり、まったく行わない可能性がありますが、良好な最適化はプログラムのパフォーマンスを直接許容できるレベルに達させることができ、コードの欠陥を再審査し、より多くの精力を費やして解決する必要はありません.
プラットフォームAndroid 2.2(Froyo)以降のバージョンの場合、特にAndroid 2.2にリアルタイム(JIT)コンパイラが導入されたため、Dalvik JITコンパイラはDalvikバイトコードをローカルコードにコンパイルし、実行速度を著しく速めた.JITコンパイラ(JITと略称する場合もある)は性能を著しく向上させることができる.理由:
a:ローカルコードは、仮想マシンによって解釈されることなくCPUによって直接実行される
b:ローカルコードは特定のアーキテクチャを最適化できる
JITのないandroid 2.1以降のバージョンでは、最適化ポリシーの選択が大きく影響する可能性があります.android 1.5、1.6、2.1を実行するデバイスの開発を行う場合は、アプリケーションがこれらの環境でどのような機能を提供する必要があるかをよく確認してください.また、android早起きバージョンを実行する古いデバイスには、新しいデバイスが強くありません.android 2.1以降のバージョンを実行するデバイスの市場シェアは縮小していますが、2011年12月までにその数は約12%を占め、オプションポリシーは3つあります.
a:これらの古いデバイスでアプリケーションがかなり遅いため、最適化されません.
b:アプリケーションのAndroid APIレベルを最低8レベルに制限し、android 2.2以降にのみインストールできるようにする
c:JITコンパイラがなくても、古いデバイスを最適化し、ユーザーに快適な体験を与える.つまり、CPUリソースを非常に消費する機能を禁止する.
アプリケーションのmanifestで構成するアプリケーションノードは、Android:vmSafeModeでJITコンパイラを有効または無効にすることができ、デフォルトでは有効である(プラットフォームにJITがある場合).この属性石Android 2.2が導入した.
 
再帰から反復へ
再帰アルゴリズムは開発者の間であまり評判がよくなく、特にメモリがあまり使われない組み込みシステム開発者では、主に再帰アルゴリズムがスタック空間を大量に消費することが多いためである.再帰アルゴリズムはスタックオーバーフローをもたらし,アプリケーションをクラッシュさせる可能性もあるので,できるだけ反復で実現すべきである.
 
oncreate()メソッドには、一般的にsetContentViewまたはリソースの展開を担当する他のメソッドが含まれます.リソース担当者のコストが比較的大きい操作を展開するため、レイアウトの複雑さを低減することでリソースの展開を高速化できます.レイアウトの複雑さを低減するには、次のようにいくつかのステップがあります.
a:LinearLayoutの代わりにRelativeLayoutを使用し、できるだけフラット化されたレイアウトを維持します.また、作成されたオブジェクトの数を減らし、イベントの処理速度を速めます.
b:ViewStubを使用してオブジェクトの作成を遅らせる
 
StrictMode
プログラムを書くときは、常に次の2つの状況を仮定する必要があります.
a:ネットワークが遅い(接続しようとしているサーバが応答していない可能性もある)
b:ファイルシステムのアクセス速度が遅い
結論:遅い操作はシステムの応答能力を牽引するため、メインスレッド内でネットワーク操作とファイルシステムへのアクセスを行わないでください.開発では、ネットワークの問題やファイルシステムのパフォーマンスの問題に遭遇することはありませんが、ユーザーはあなたほどラッキーではありません.
注意:SDカードはすべて同じ「速度」を持っているわけではありません.アプリケーションが外部ストレージデバイスの性能に大きく依存している場合は、異なるメーカーからのさまざまなSDカードでアプリケーションをテストしたことを確認する必要があります.
Androidには、この欠陥を検出するためのユーティリティがあります.StrictModeは不良行為を検出するのに良いツールです.通常、アプリケーションの起動時、つまりonCreate()が呼び出されたときにStrictModeが有効になります.
StrictModeはAndroid 2.3に導入されており、Android 3.0にはより多くの機能が組み込まれているので、適切なAndroidバージョンを選択し、コードを適切なAndroidプラットフォームに抱けるようにしなければならない.
Android 3.0で導入された特に注意すべき方法には、detectCUstomSlowCall()とnoteSlowCall()が含まれています.これらは、アプリケーションで実行される遅いコードまたは潜在的に遅いコードを検出するために使用されます.
public class MyApplication extends Application {

	@Override
	public void onCreate() {
		super.onCreate();
		ueHandler = new UEhandler(this);
		Thread.setDefaultUncaughtExceptionHandler(ueHandler);
		StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
				.detectCustomSlowCalls()  //API   11，   StrictMode.noteSlowCode
				.detectDiskReads()
				.detectDiskWrites()
				.detectNetwork()
				.penaltyLog()
				.penaltyFlashScreen()     //API   11
				.build());
		
		//       ，     StrictMode,     VM  
		try {
			StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
					.detectLeakedSqlLiteObjects()
					.detectLeakedClosableObjects() 	//API   11
					.setClassInstanceLimit(Class.forName("com.apress.proandroid.SomeClass"), 100)
					.penaltyLog()
					.build());
		} catch (ClassNotFoundException e) {
			e.printStackTrace();
		}
	}
}

プライマリ・スレッドからの呼び出しの実行時間が長すぎます.StrictMode Threadポリシーがスロー・コールを検出するように構成されている場合、logcatログにStrictModeに関する情報が表示されます.
Androidは、プライマリ・スレッドでゼロ・タイム・ディスクの読み書きを行うための補助方法を提供しています.
  
StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskReads();
//       
StrictMode.setThreadPolicy(oldPolicy);

現在、ネットワークアクセスを一時的に許可する方法はありませんが、プライマリ・スレッドでこのアクセスを許可する理由はありません.一時的でも、アクセスが速いかどうかを知る適切な方法はありません.
注意:StrictModeを開発段階で有効にし、アプリケーションをリリースするときは無効にすることを忘れないでください.detectAll()メソッドを使用して履歴書ポリシーを実行すると、将来的にはより実行可能になり、将来的にはAndroidバージョンでより多くの不良行為が検出されます.
 
SQLite
ほとんどのアプリケーションはSQLiteの重度の使用者ではないので、データベースとのパフォーマンスをあまり心配する必要はありません.しかし、アプリケーションのSQLite関連コードを最適化するには、いくつかの概念を理解する必要があります.
a:SQLite文
b:物事
c:クエリー
自動化メンテナンスツールansible基礎応用
Python構文特性