Android應(yīng)用程序運(yùn)行的移動(dòng)設(shè)備受限于其運(yùn)算能力，存儲(chǔ)空間，及電池續(xù)航。由此，它必須是高效的。電池續(xù)航可能是一個(gè)促使你優(yōu)化程序的原因，即使他看起來(lái)已經(jīng)運(yùn)行的足夠快了。由于續(xù)航對(duì)用戶(hù)的重要性，當(dāng)電量耗損陡增時(shí)，意味這用戶(hù)遲早會(huì)發(fā)現(xiàn)是由于你的程序。

　　雖然這份文檔主要包含著細(xì)微的優(yōu)化，但這些絕不能成為你軟件成敗的關(guān)鍵。選擇合適的算法和數(shù)據(jù)結(jié)構(gòu)永遠(yuǎn)是你最先應(yīng)該考慮的事情，但這超出這份文檔之外。

　　1. 介紹

　　寫(xiě)出高效的代碼有兩條基本的原則：

　　◆ 不作沒(méi)有必要的工作

　　◆ 盡量避免內(nèi)存分配。

　　2. 明智的優(yōu)化

　　這份文檔是關(guān)于Android規(guī)范的細(xì)微優(yōu)化，所以先確保你已經(jīng)了解哪些代碼需要優(yōu)化，并且知道如何去衡量你所做修改所帶來(lái)的效果（好或壞）。用開(kāi)投資開(kāi)發(fā)的時(shí)間是有限的，所以明智的時(shí)間規(guī)劃很重要。

　　這份文檔同時(shí)確保你在算法和數(shù)據(jù)結(jié)構(gòu)上作出最佳選擇，同時(shí)考慮了API選擇所帶來(lái)的潛在影響。使用恰當(dāng)?shù)臄?shù)據(jù)結(jié)構(gòu)和算法比這里的任何建議都有價(jià)值，考慮API版本帶來(lái)的影響會(huì)如實(shí)你選擇更好的實(shí)現(xiàn)。

　　當(dāng)你優(yōu)化Android程序時(shí)會(huì)遇到的一個(gè)棘手問(wèn)題是確保你的程序能在不同的硬件平臺(tái)上運(yùn)行。不同版本的虛擬機(jī)在不同處理器上的運(yùn)行速度各不相同。并且不是簡(jiǎn)單的設(shè)備A比設(shè)備B快或者慢，并針對(duì)一個(gè)設(shè)備與其他設(shè)備之間做出排列。特別的，模擬器上只能評(píng)測(cè)小部分可以在設(shè)備上體現(xiàn)的東西。有無(wú)JIT的設(shè)備間也有著巨大差異：對(duì)于有JIT設(shè)備好的代碼有時(shí)對(duì)無(wú)JIT的設(shè)備并不是最好的。

　　如果你想知道程序在設(shè)備上的表現(xiàn)，就必須在上面進(jìn)行測(cè)試

　　3. 避免創(chuàng)建不必要的對(duì)象

　　對(duì)象創(chuàng)建永遠(yuǎn)不會(huì)免費(fèi)的。每個(gè)線程的分代GC給臨時(shí)對(duì)象分配一個(gè)地址池能降低分配開(kāi)銷(xiāo)，但分配內(nèi)存往往需要比不分配內(nèi)存高的代價(jià)。

　　如果在用戶(hù)界面周期內(nèi)分配對(duì)象，會(huì)強(qiáng)制一個(gè)周期性的垃圾回收，給用戶(hù)體驗(yàn)造成小小的停頓間隙。Gingerbread中介紹的并發(fā)回收也許有用，但應(yīng)該避免不必要的工作。

　　因此，避免創(chuàng)建不需要的對(duì)象實(shí)例。下面是幾個(gè)例子：

　　◆ 如果有一個(gè)返回String的方法，他的返回值通常附加在一個(gè)StringBuffer上，改變聲明和實(shí)現(xiàn)，這樣函數(shù)直接在其后面附加，而非創(chuàng)建一個(gè)短暫存在的臨時(shí)變量。

　　◆ 當(dāng)從輸入的數(shù)據(jù)集合中讀取數(shù)據(jù)時(shí)，考慮返回原始數(shù)據(jù)的子串，而非新建一個(gè)拷貝。這樣你會(huì)創(chuàng)建一個(gè)新的對(duì)象，但是他們共享該數(shù)據(jù)的char數(shù)組。換來(lái)的是即使你僅僅使用原始輸入的一部分，你也需要保證它一直存在于內(nèi)存中。

　　一個(gè)更徹底的觀點(diǎn)是將多維數(shù)組切割成一維數(shù)組：

　　◆ Int類(lèi)型的數(shù)組比Integer類(lèi)型的好。推而廣之，兩個(gè)平行的int數(shù)組要比一個(gè)(int,int)型的對(duì)象數(shù)組高效。這個(gè)定理對(duì)于任何基本數(shù)據(jù)類(lèi)型的組合都通用。

　　◆ 如果需要實(shí)現(xiàn)存放元組(Foo,Bar)對(duì)象的容器，記住兩個(gè)平行數(shù)組Foo[], Bar[]會(huì)優(yōu)于一個(gè)(Foo,Bar)對(duì)象的數(shù)組。（例外情況是：當(dāng)你設(shè)計(jì)API給其他代碼調(diào)用時(shí)，最好用好的API設(shè)計(jì)來(lái)?yè)Q取小的速度提升。但在自己的內(nèi)部代碼中，盡量嘗試高效的實(shí)現(xiàn)。）

　　通常來(lái)說(shuō)，盡量避免創(chuàng)建短時(shí)臨時(shí)對(duì)象。少的對(duì)象創(chuàng)建意味著低頻的垃圾回收。這對(duì)于用戶(hù)體驗(yàn)產(chǎn)生直接的影響。

　　4. 性能之謎

　　前一個(gè)版本的文檔給出了好多誤導(dǎo)人的主張，這里做一些澄清：

　　◆ 在沒(méi)有JIT的設(shè)備上，調(diào)用方法所傳遞的對(duì)象采用具體的類(lèi)型而非接口類(lèi)型會(huì)更有效（比如，傳遞HashMap map比傳遞Map map調(diào)用一個(gè)方法耗費(fèi)的開(kāi)銷(xiāo)小，盡管兩種情況下的map都是HashMap）。但這并不是兩倍慢的情形，事實(shí)上，只相差6%，而JIT使這兩種調(diào)用的效率不分伯仲。

　　◆ 在沒(méi)有JIT的設(shè)備上，訪問(wèn)緩存后的字段比直接訪問(wèn)字段快大概20%。在有JIT的情況下，字段訪問(wèn)和局部訪問(wèn)耗費(fèi)是一樣的 。所以這里不值得優(yōu)化，除非你覺(jué)得他會(huì)讓你的代碼更易讀（對(duì)于final,static，及static final 變量同樣適用）.

　　5. 用靜態(tài)代替虛擬

　　如果不需要訪問(wèn)某對(duì)象的字段，將方法設(shè)置為靜態(tài)，調(diào)用會(huì)加速15%到20%。這也是一種好的做法，因?yàn)槟憧梢酝ㄟ^(guò)方法聲明知曉調(diào)用該方法不需要更新此對(duì)象的狀態(tài)。

　　6. 避免內(nèi)部的Getters/Setters

　　在源生語(yǔ)言像C++中，通常做法是用Getters（i=getCount()）代替直接訪問(wèn)字段（i=mCount）。這是C++中一個(gè)好的習(xí)慣，因?yàn)榫幾g器會(huì)內(nèi)聯(lián)這些訪問(wèn)，如果需要約束或者調(diào)試這些域的訪問(wèn)，你可以在任何時(shí)間添加代碼。

　　在Android中，這是個(gè)不好的想法。虛方法調(diào)用代價(jià)比直接存取字段高昂的多。按照通常面向?qū)ο笳Z(yǔ)言的做法在公共接口中使用Getters和Setters是有原因的，但應(yīng)該在一個(gè)經(jīng)常訪問(wèn)其字段的類(lèi)中采用直接訪問(wèn)。

　　無(wú)JIT時(shí)，直接字段訪問(wèn)大約比調(diào)用無(wú)關(guān)緊要的getter來(lái)訪問(wèn)快3倍。有JIT時(shí)（直接訪問(wèn)字段開(kāi)銷(xiāo)和訪問(wèn)局部變量是一樣的），要快7倍。在Froyo版本中確實(shí)如此，但以后會(huì)在JIT中改進(jìn)Getter方法的內(nèi)聯(lián)。

　　7. 對(duì)常量使用Static Final修飾符

　　考慮下面類(lèi)首的聲明：

　　Java代碼

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

        

        
        
      
        
it知識(shí)庫(kù)：官方文檔：Android應(yīng)用程序運(yùn)行的性能設(shè)計(jì)，轉(zhuǎn)載需保留來(lái)源！
        
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。