実際には、オンライン・パフォーマンスの最適化アンドリュースは、多くの記事を書いた書き込みにはしたくなかったが、突然、今日以前に気づいていないポイントを見て、彼らの通常でもので、すべての既知のパフォーマンスの問題を書きたかった、多くのことを経験しましたすべて一緒に、私はこの記事を更新していきます。
1.リサイクル
固定された変数のプロパティにアクセスする場合よりも通常低い効率、5よりもしばしば大きいサイクル数の見積もり、場合
値は5 xxx.GetLength（）メソッドよりも大きいことが一般的な仮定は、通常の状況下で、私たちはそうなど、書き込まれる
（のために私は0 int型=; I <xxx.GetLength（）; I ++）
ここxxx.GetLength各サイクルが呼び出されなければなりませんが、必然的にゲーム開発では、プログラムの効率に影響する、より明白になり、
改良された方法があるべき
int型J = xxx.GetLength（）
のための（INT I = 0; I <J; I ++）
これは私がこれを書い通常、ハード注意を払うに私たちは、私はこの点を見たのは初めてである小さな点に似ているので、なぜ、これが最初に書きます。
2.最適化の画像
これは、メモリが流出によって引き起こされる絵ですが、私は開発の初期に発生した最大の問題です。
A.最初のアーティストが私たちのマップに与えることが多いので、問題の画像サイズであるが、大きな画像のためにあまりにも多くのロード時にメモリにつながる、大きすぎると私はサイトをお勧めします
https://tinypng.com/、このサイトは画像可逆圧縮であってもよいし、圧縮率が非常に高く、非常に良いです。それはSVGのために提案されたアートワークを示すいくつかの小さなマップで、その後、我々はアンドロイドのスタジオで変換された場合は、ベクター形式の機能が付属していますので、あなたは良い最適化の結果を再生することができます。
II。資源利用の絵が、メモリオーバーフローにリリースされていないので、優先順位は次の3つのレベルのキャッシュアーキテクチャの写真を見てする必要があり、良いのための既製のフレームワークが存在しないので、私は、あなた自身のレベル3キャッシュを書くことをお勧めしないでなぜ時間を無駄に、確かに自分の問題を記述するために多くが、私は、我々は負荷にいくつかの画像を使用することをお勧めします。このフレームワークに指示して、関連する原理を理解しなければならないが、いくつかのイメージロードフレームを、次のことは、今主流のフレームワークであり、非常に有効であることができます最初の3が大量に使用されているよりも少ない人々とフレスコに加えて、独自のGoogleのそれを使用する方法を、各スピーカーの長所と短所として、問題の画像メモリオーバーフローを解決します。
あなたが遠くに見ることができ巨人の肩の上に立って、良いフレームワークやツールの多くを使用することを学ぶ必要があります
文字列のスプライシングを3.String
私たちはしばしば遭遇文字列の連結コードを書くとき、私たちは、ほとんどの場合、2つの文字列が追加された書くための方法である、これは、実際には非常に非効率的なアプローチであり、我々は実際のほとんどを使用しますステッチへのStringBufferとStringBuilderのは、以下では、これら3つの方法の比較スプライシング効率であります
String s = "";
long sBeginTime = System.currentTimeMillis();
for (int i = 0; i < 100000; i++) {
s+="s";
}
long sEndTime = System.currentTimeMillis();
System.out.println("s拼接100000遍s耗时: " + (sEndTime - sBeginTime) + "ms");
StringBuffer s1 = new StringBuffer();
long s1BeginTime = System.currentTimeMillis();
for (int i = 0; i < 100000; i++) {
s1.append("s");
}
long s1EndTime = System.currentTimeMillis();
System.out.println("s1拼接100000遍s耗时: " + (s1EndTime - s1BeginTime) + "ms");
StringBuilder s2 = new StringBuilder();
long s2BeginTime = System.currentTimeMillis();
for (int i = 0; i < 100000; i++) {
s2.append("s");
}
long s2EndTime = System.currentTimeMillis();
System.out.println("s2拼接100000遍s耗时: " + (s2EndTime - s2BeginTime) + "ms");
これは、試験の結果であり、それは有意に低い効率で+の文字列の連結、およびStringBuilderのStringBufferの追記（）+スプライシングを使用して時間のスプライシング効率百または数千のための方法、およびのStringBufferの使用を使用することは明らかですスレッドセーフたStringBuffer、必然的に関してのStringBuilder少し低い効率を達成することが原因であるのStringBuilder、より効率的。したがって、ストリングの蓄積動作、スレッド選択問題の提案された組み合わせは、+文字列連結を使用して回避します。
4.リリース未使用のリソース
コールcursor.close（）解放にしてくださいカーソルを使用した後、
また、我々は終了することを忘れないでください、タスクを実行する（）postDelayedへのハンドラを使用するために使用される、それはすべてのメッセージとコールバック関数を削除するにはhandler.removeCallbacksAndMessages（null）を呼び出します。
