編寫:kesenhoo - 原文:http://developer.android.com/training/articles/perf-tips.html
這篇文章主要介紹一些小細節(jié)的優(yōu)化技巧，雖然這些小技巧不能較大幅度的提升應用性能，但是恰當?shù)倪\用這些小技巧并發(fā)生累積效應的時候，對于整個App的性能提升還是有不小作用的。通常來說，選擇合適的算法與數(shù)據(jù)結(jié)構(gòu)會是你首要考慮的因素，在這篇文章中不會涉及這方面的知識點。你應該使用這篇文章中的小技巧作為平時寫代碼的習慣，這樣能夠提升代碼的效率。
通常來說，高效的代碼需要滿足下面兩個原則：
在優(yōu)化App時其中一個難點就是讓App能在各種型號的設備上運行。不同版本的虛擬機在不同的處理器上會有不同的運行速度。你甚至不能簡單的認為“設備X的速度是設備Y的F倍”，然后還用這種倍數(shù)關(guān)系去推測其他設備。另外，在模擬器上的運行速度和在實際設備上的速度沒有半點關(guān)系。同樣，設備有沒有JIT也對運行速度有重大影響：在有JIT情況下的最優(yōu)化代碼不一定在沒有JIT的情況下也是最優(yōu)的。
為了確保App在各設備上都能良好運行，就要確保你的代碼在不同檔次的設備上都盡可能的優(yōu)化。
創(chuàng)建對象從來不是免費的。Generational GC可以使臨時對象的分配變得廉價一些，但是執(zhí)行分配內(nèi)存總是比不執(zhí)行分配操作更昂貴。
隨著你在App中分配更多的對象，你可能需要強制gc，而gc操作會給用戶體驗帶來一點點卡頓。雖然從Android 2.3開始，引入了并發(fā)gc，它可以幫助你顯著提升gc的效率，減輕卡頓，但畢竟不必要的內(nèi)存分配操作還是應該盡量避免。
因此請盡量避免創(chuàng)建不必要的對象，有下面一些例子來說明這個問題：
StringBuffer，請修改你的函數(shù)實現(xiàn)方式，避免直接進行連接操作，應該采用創(chuàng)建一個臨時對象來做字符串的拼接這個操作。char[]空間的。一個稍微激進點的做法是把所有多維的數(shù)據(jù)分解成一維的數(shù)組:
通常來說，需要避免創(chuàng)建更多的臨時對象。更少的對象意味者更少的gc動作，gc會對用戶體驗有比較直接的影響。
如果你不需要訪問一個對象的值，請保證這個方法是static類型的，這樣方法調(diào)用將快15%-20%。這是一個好的習慣，因為你可以從方法聲明中得知調(diào)用無法改變這個對象的狀態(tài)。
考慮下面這種聲明的方式
static int intVal = 42;
static String strVal = "Hello, world!";編譯器會使用一個初始化類的函數(shù)intVal，還從class文件的常量表中提取了strVal的引用。當之后使用intVal或strVal的時候，他們會直接被查詢到。
我們可以用final關(guān)鍵字來優(yōu)化：
static final int intVal = 42;
static final String strVal = "Hello, world!";這時再也不需要上面的intVal的代碼會直接使用42，調(diào)用strVal的代碼也會使用一個相對廉價的“字符串常量”指令，而不是查表。
Notes：這個優(yōu)化方法只對原始類型和String類型有效，而不是任意引用類型。不過，在必要時使用
static final是個很好的習慣。
像C++等native language，通常使用getters(i = getCount())而不是直接訪問變量(i = mCount)。這是編寫C++的一種優(yōu)秀習慣，而且通常也被其他面向?qū)ο蟮恼Z言所采用，例如C#與Java，因為編譯器通常會做inline訪問，而且你需要限制或者調(diào)試變量，你可以在任何時候在getter/setter里面添加代碼。
然而，在Android上，這不是一個好的寫法。虛函數(shù)的調(diào)用比起直接訪問變量要耗費更多。在面向?qū)ο缶幊讨校瑢etter和setting暴露給公用接口是合理的，但在類內(nèi)部應該僅僅使用域直接訪問。
在沒有JIT(Just In Time Compiler)時，直接訪問變量的速度是調(diào)用getter的3倍。有JIT時，直接訪問變量的速度是通過getter訪問的7倍。
請注意，如果你使用ProGuard，你可以獲得同樣的效果，因為ProGuard可以為你inline accessors.
增強的For循環(huán)（也被稱為 for-each 循環(huán)）可以被用在實現(xiàn)了 Iterable 接口的 collections 以及數(shù)組上。使用collection的時候，Iterator會被分配，用于for-each調(diào)用hasNext()和next()方法。使用ArrayList時，手寫的計數(shù)式for循環(huán)會快3倍（不管有沒有JIT），但是對于其他collection，增強的for-each循環(huán)寫法會和迭代器寫法的效率一樣。
請比較下面三種循環(huán)的方法：
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;
}
}所以請盡量使用for-each的方法，但是對于ArrayList，請使用方法one()。
Tips：你還可以參考 Josh Bloch 的 《Effective 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 is " + value);
}
}這里重要的是，我們定義了一個私有的內(nèi)部類（Foo$Inner），它直接訪問了外部類中的私有方法以及私有成員對象。這是合法的，這段代碼也會如同預期一樣打印出"Value is 27"。
問題是，VM因為Foo和Foo$Inner是不同的類，會認為在Foo$Inner中直接訪問Foo類的私有成員是不合法的。即使Java語言允許內(nèi)部類訪問外部類的私有成員。為了去除這種差異，編譯器會產(chǎn)生一些仿造函數(shù)：
/*package*/ static int Foo.access$100(Foo foo) {
return foo.mValue;
}
/*package*/ static void Foo.access$200(Foo foo, int value) {
foo.doStuff(value);
}每當內(nèi)部類需要訪問外部類中的mValue成員或需要調(diào)用doStuff()函數(shù)時，它都會調(diào)用這些靜態(tài)方法。這意味著，上面的代碼可以歸結(jié)為，通過accessor函數(shù)來訪問成員變量。早些時候我們說過，通過accessor會比直接訪問域要慢。所以，這是一個特定語言用法造成性能降低的例子。
如果你正在性能熱區(qū)（hotspot:高頻率、重復執(zhí)行的代碼段）使用像這樣的代碼，你可以把內(nèi)部類需要訪問的域和方法聲明為包級訪問，而不是私有訪問權(quán)限。不幸的是，這意味著在相同包中的其他類也可以直接訪問這些域，所以在公開的API中你不能這樣做。
Android系統(tǒng)中float類型的數(shù)據(jù)存取速度是int類型的一半，盡量優(yōu)先采用int類型。
就速度而言，現(xiàn)代硬件上，float 和 double 的速度是一樣的?？臻g而言，double 是兩倍float的大小。在空間不是問題的情況下，你應該使用 double 。
同樣，對于整型，有些處理器實現(xiàn)了硬件幾倍的乘法，但是沒有除法。這時，整型的除法和取余是在軟件內(nèi)部實現(xiàn)的，這在你使用哈希表或大量計算操作時要考慮到。
除了那些常見的讓你多使用自帶庫函數(shù)的理由以外，記得系統(tǒng)函數(shù)有時可以替代第三方庫，并且還有匯編級別的優(yōu)化，他們通常比帶有JIT的Java編譯出來的代碼更高效。典型的例子是：Android API 中的 String.indexOf()，Dalvik出于內(nèi)聯(lián)性能考慮將其替換。同樣 System.arraycopy()函數(shù)也被替換，這樣的性能在Nexus One測試，比手寫的for循環(huán)并使用JIT還快9倍。
Tips：參見 Josh Bloch 的 《Effective Java》這本書的第47條
結(jié)合Android NDK使用native代碼開發(fā)，并不總是比Java直接開發(fā)的效率更好的。Java轉(zhuǎn)native代碼是有代價的，而且JIT不能在這種情況下做優(yōu)化。如果你在native代碼中分配資源（比如native堆上的內(nèi)存，文件描述符等等），這會對收集這些資源造成巨大的困難。你同時也需要為各種架構(gòu)重新編譯代碼（而不是依賴JIT）。你甚至對已同樣架構(gòu)的設備都需要編譯多個版本：為G1的ARM架構(gòu)編譯的版本不能完全使用Nexus One上ARM架構(gòu)的優(yōu)勢，反之亦然。
Native 代碼是在你已經(jīng)有本地代碼，想把它移植到Android平臺時有優(yōu)勢，而不是為了優(yōu)化已有的Android Java代碼使用。
如果你要使用JNI,請學習JNI Tips
Tips：參見 Josh Bloch 的 《Effective Java》這本書的第54條
在沒有JIT的設備上，使用一種確切的數(shù)據(jù)類型確實要比抽象的數(shù)據(jù)類型速度要更有效率（例如，調(diào)用HashMap map要比調(diào)用Map map效率更高）。有誤傳效率要高一倍，實際上只是6%左右。而且，在JIT之后，他們直接并沒有大多差異。
在沒有JIT的設備上，讀取緩存域比直接讀取實際數(shù)據(jù)大概快20%。有JIT時，域讀取和本地讀取基本無差。所以優(yōu)化并不值得除非你覺得能讓你的代碼更易讀（這對 final, static, static final 域同樣適用）。
在優(yōu)化之前，你應該確定你遇到了性能問題。你應該確保你能夠準確測量出現(xiàn)在的性能，否則你也不會知道優(yōu)化是否真的有效。
本章節(jié)中所有的技巧都需要Benchmark（基準測試）的支持。Benchmark可以在 code.google.com "dalvik" project 中找到
Benchmark是基于Java版本的 Caliper microbenchmarking框架開發(fā)的。Microbenchmarking很難做準確，所以Caliper幫你完成這部分工作，甚至還幫你測了你沒想到需要測量的部分（因為，VM幫你管理了代碼優(yōu)化，你很難知道這部分優(yōu)化有多大效果）。我們強烈推薦使用Caliper來做你的基準微測工作。
我們也可以用Traceview 來測量，但是測量的數(shù)據(jù)是沒有經(jīng)過JIT優(yōu)化的，所以實際的效果應該是要比測量的數(shù)據(jù)稍微好些。
關(guān)于如何測量與調(diào)試，還可以參考下面兩篇文章：
掃碼關(guān)注鍍金池微信號
手機訂課，優(yōu)惠多多