【正文】 。 正確構(gòu)建應(yīng)用 ——通常需要花費(fèi)更長(zhǎng)的時(shí)間，并且通常意味著犯錯(cuò)誤并從錯(cuò)誤中學(xué)習(xí)。那不是一個(gè)高效率的過程 。 成功地應(yīng)用會(huì)提 供出色的終端用戶體驗(yàn)。盡管 Android 團(tuán)隊(duì)已經(jīng)構(gòu)造了一個(gè)強(qiáng)健的內(nèi)核系統(tǒng)，但用戶更多的體驗(yàn)是來自于與你應(yīng)用的交互。 出色的用戶體驗(yàn)有三個(gè)特征：速度快 。響應(yīng)及時(shí)以及無縫。當(dāng)然從早期計(jì)算機(jī)到現(xiàn)在的計(jì)算機(jī)，每個(gè)平臺(tái)都曾不只一次地引用過這三個(gè)特征。然而，每個(gè)平臺(tái)實(shí)現(xiàn)它們的方法不同 。下面的信息解釋了你的應(yīng)用如何能夠在 Android 上實(shí)現(xiàn)這些特征。 速度快 Android 應(yīng)用應(yīng)該是快速的。更準(zhǔn)確的說他應(yīng)該是高效的?，F(xiàn)在，在計(jì)算界中有一個(gè)趨勢(shì)，該趨勢(shì)假設(shè)摩爾定律可以最終解決所有問題。然而對(duì)于嵌入式應(yīng)用而言， Moor 定律會(huì)變得有些復(fù)雜。 摩爾定律沒有如同應(yīng)用于桌面和服務(wù)器應(yīng)用一樣真正地應(yīng)用于移動(dòng)設(shè)備。摩爾定律實(shí)際上是關(guān)于晶體管密度的定律，它是說每隔一段時(shí)間后，你可以在給定的芯片上部署更多電路。對(duì)于轉(zhuǎn)面和服務(wù)器應(yīng)用而言，由于性能的提高，這意味著你可以在一塊差不多大小的芯片中得到更高的速度。對(duì)于類似手機(jī)這樣的嵌入式應(yīng)用而言，摩爾定律通常被用于造出更小的芯片。在嵌入式界的趨勢(shì)是利用這種晶體管密度的增加來造出更小、更節(jié)能的芯片，從而使手機(jī)更小，電池待機(jī)時(shí)間更長(zhǎng)。象手機(jī)這樣的嵌入式設(shè)備在不斷增加，速度遠(yuǎn)遠(yuǎn)要慢于桌面系統(tǒng) 。對(duì)于嵌入式設(shè)備而言，摩爾定律意味著更多特性和更好的電池壽命 。而速度則是次要因素。 這就是為什么需要寫高效的代碼：你不能假設(shè)手機(jī)與桌面系統(tǒng)和服務(wù)器一樣提速。一般來講，寫快速的代碼意味著要是內(nèi)存分配最小化，代碼緊湊，并且避免可能影響性能的語(yǔ)言和編程習(xí)慣。在面向?qū)ο蟮男g(shù)語(yǔ)中，很多類似情況都是發(fā)生在方法級(jí)，關(guān)于實(shí)際的代碼順序，循環(huán)等。 關(guān)于如何寫高效的 Android 代碼的文章將會(huì)給你提供寫快速、高效 Android 代碼的所有信息。編寫高效的 Android 代碼 ， 雖然如此說，但似乎并沒有什么好的辦法： Android 設(shè)備是嵌入式設(shè)備?，F(xiàn)代的手持設(shè)備，與其說是電話，更像一臺(tái)拿在手中的電腦。但是，即使是 “最快 ”的手持設(shè)備，其性能也趕不上一臺(tái)普通的臺(tái)式電腦。 這就是為什么我們?cè)跁鴮?Android 應(yīng)用程序的時(shí)候要格外關(guān)注效率。這些設(shè)備并沒有那么快，并且受電池電量的制約。這意味著，設(shè)備沒有更多的能力，我們必須把程序?qū)懙谋M量有效。 大連海洋大學(xué)本科畢業(yè)論文（設(shè)計(jì)） 第 5 章 設(shè)計(jì)思想 25 對(duì)于占用資源的系統(tǒng)，有兩條基本原則： 不要做不必要的事 不要分配不必要的內(nèi)存 。 . 設(shè)計(jì) 原則 所有 設(shè)計(jì) 的內(nèi)容都遵照這兩個(gè)原則。 有些人可能馬上會(huì)跳出來，把本節(jié)的大部分內(nèi)容歸于 “草率的優(yōu)化 ”(xing:參見 [The Root of All Evil])，不可否認(rèn)微優(yōu)化 (microoptimization。 xing:代碼優(yōu)化，相對(duì)于結(jié)構(gòu)優(yōu)化 )的確會(huì)帶來很多問題，諸如無法使用更有效的數(shù)據(jù)結(jié)構(gòu)和算法。但是在手持設(shè)備上，你別無選擇。假如你認(rèn)為 Android 虛擬機(jī)的性能與臺(tái)式機(jī)相當(dāng)，你的程序很有可能一開始就占用了系統(tǒng)的全部?jī)?nèi)存 (xing:內(nèi)存很小 )，這會(huì)讓你的程序慢得像蝸牛一樣，更遑論做其他的操作了。 Android 的成功依賴于你的程序提供的用戶體驗(yàn)。而這種用戶體驗(yàn)，部分依賴于你的程序是響應(yīng)快速 而靈活的，還是響應(yīng)緩慢而僵化的。因?yàn)樗械某绦蚨歼\(yùn)行在同一個(gè)設(shè)備之上，都在一起，這就如果在同一條路上行駛的汽車。而這篇文檔就相當(dāng)于你在取得駕照之前必須要學(xué)習(xí)的交通規(guī)則。如果大家都按照這些規(guī)則去做，駕駛就會(huì)很順暢，但是如果你不這樣做，你可能會(huì)車毀人亡。這就是為什么這些原則十分重要。 當(dāng)我們開門見山、直擊主題之前，還必須要提醒大家一點(diǎn)：不管 VM 是否支持實(shí)時(shí)(JIT)編譯器 (xing:它允許實(shí)時(shí)地將 Java 解釋型程序自動(dòng)編譯成本機(jī)機(jī)器語(yǔ)言，以使程序執(zhí)行的速度更快。有些 JVM 包含 JIT 編譯器。 )，下面提到的這些 原則都是成立的。假如我們有目標(biāo)完全相同的兩個(gè)方法，在解釋執(zhí)行時(shí) foo()比 bar()快，那么編譯之后， foo()依然會(huì)比 bar()快。所以不要寄希望于編譯器可以拯救你的程序。 原則一 世界上沒有免費(fèi)的對(duì)象。雖然 GC 為每個(gè)線程都建立了臨時(shí)對(duì)象池，可以使創(chuàng)建對(duì)象的代價(jià)變得小一些，但是分配內(nèi)存永遠(yuǎn)都比不分配內(nèi)存的代價(jià)大。 如果你在用戶界面循環(huán)中分配對(duì)象內(nèi)存，就會(huì)引發(fā)周期性的垃圾回收，用戶就會(huì)覺得界面像打嗝一樣一頓一頓的。 所以，除非必要，應(yīng)盡量避免盡力對(duì)象的實(shí)例。下面的例子將幫助你 理解這條原則： 當(dāng)你從用戶輸入的數(shù)據(jù)中截取一段字符串時(shí)，盡量使用 substring 函數(shù)取得原始數(shù)據(jù)的一個(gè)子串，而不是為子串另外建立一份拷貝。這樣你就有一個(gè)新的 String 對(duì)象，它與原始數(shù)據(jù)共享一個(gè) char 數(shù)組。 如果你有一個(gè)函數(shù)返回一個(gè) String 對(duì)象，而你確切的知道這個(gè)字符串會(huì)被附加到一個(gè)StringBuffer，那么，請(qǐng)改變這個(gè)函數(shù)的參數(shù)和實(shí)現(xiàn)方式，直接把結(jié)果附加到 StringBuffer中，而不要再建立一個(gè)短命的臨時(shí)對(duì)象。 一個(gè)更極端的例子是，把多維數(shù)組分成多個(gè)一維數(shù)組。 int 數(shù)組比 Integer 數(shù)組好，這也概括了一個(gè)基本事實(shí)，兩個(gè)平行的 int 數(shù)組比 (int,int)大連海洋大學(xué)本科畢業(yè)論文（設(shè)計(jì)） 第 5 章 設(shè)計(jì)思想 26 對(duì)象數(shù)組性能要好很多。同理，這試用于所有基本類型的組合。 如果你想用一種容器存儲(chǔ) (Foo,Bar)元組，嘗試使用兩個(gè)單獨(dú)的 Foo[]數(shù)組和 Bar[]數(shù)組，一定比 (Foo,Bar)數(shù)組效率更高。 (也有例外的情況，就是當(dāng)你建立一個(gè) API，讓別人調(diào)用它的時(shí)候。這時(shí)候你要注重對(duì) API 借口的設(shè)計(jì)而犧牲一點(diǎn)兒速度。當(dāng)然在 API 的內(nèi) 部，你仍要盡可能的提高代碼的效率 ) 總體來說，就是避免創(chuàng)建短命的臨時(shí)對(duì)象。減少對(duì)象的創(chuàng)建就能減少垃圾 收集，進(jìn)而減少對(duì)用戶體驗(yàn)的影響。 當(dāng)你在處理字串的時(shí)候，不要吝惜使用 (), ()等特殊實(shí)現(xiàn)的方法 (specialty methods)。這些方法都是使用 C/C++實(shí)現(xiàn)的，比起 Java 循環(huán)快 10 到100 倍。 假設(shè)你有一個(gè) HashMap 對(duì)象，你可以將它聲明為 HashMap 或者 Map: Map myMap1 = new HashMap()。 HashMap myMap2 = new HashMap()。 哪個(gè)更好呢 ? 按照 傳統(tǒng)的觀點(diǎn) Map 會(huì)更好些，因?yàn)檫@樣你可以改變他的具體實(shí)現(xiàn)類，只要這個(gè)類繼承自 Map 接口。傳統(tǒng)的觀點(diǎn)對(duì)于傳統(tǒng)的程序是正確的，但是它并不適合嵌入式系統(tǒng)。調(diào)用一個(gè)接口的引用會(huì)比調(diào)用實(shí)體類的引用多花費(fèi)一倍的時(shí)間。 如果 HashMap 完全適合你的程序，那么使用 Map 就沒有什么價(jià)值。如果有些地方你不能確定，先避免使用 Map，剩下的交給 IDE 提供的重構(gòu)功能好了。 (當(dāng)然公共 API 是一個(gè)例外：一個(gè)好的 API 常常會(huì)犧牲一些性能 ) 用靜態(tài)方法比虛方法好 如果你不需要訪問一個(gè)對(duì)象的成員變量，那么請(qǐng)把方法聲明成 static。 虛方法執(zhí)行的更快，因?yàn)樗梢员恢苯诱{(diào)用而不需要一個(gè)虛函數(shù)表。另外你也可以通過聲明體現(xiàn)出這個(gè)函數(shù)的調(diào)用不會(huì)改變對(duì)象的狀態(tài)。 不用 getter 和 setter 在很多本地語(yǔ)言如 C++中，都會(huì)使用 getter(比如： i = getCount())來避免直接訪問成員變量 (i = mCount)。在 C++中這是一個(gè)非常好的習(xí)慣，因?yàn)榫幾g器能夠內(nèi)聯(lián)訪問，如果你需要約束或調(diào)試變量，你可以在任何時(shí)候添加代碼。 在 Android 上，這就不是個(gè)好主意了。虛方法的開銷比直接訪問成員變量大得多。在通用的接口定義中，可以依 照 OO 的方式定義 getters 和 setters，但是在一般的類中，你應(yīng)該直接訪問變量。 將成員變量緩存到本地 訪問成員變量比訪問本地變量慢得多，下面一段代碼： ? or (int i = 0。 i ? 。 i++) dumpItem([i])。 再好改成這樣： ? int count = 。 ? Item[] items = 。 大連海洋大學(xué)本科畢業(yè)論文（設(shè)計(jì)） 第 5 章 設(shè)計(jì)思想 24 ? for (int i = 0。 i ? count。 i++) dumpItems(items[i])。 (使用 ”this”是為了表明這些是成員變量 ) 原則二 永遠(yuǎn)不要在 for 的第二個(gè)條件中調(diào)用任何方法。如下面方法所示，在每次循環(huán)的時(shí)候都會(huì)調(diào)用 getCount()方法，這樣做比你在一個(gè) int 先把結(jié)果保存起來開銷大很多。 ? for (int i = 0。 i ()。 i++)同樣如果你要多次訪問一個(gè)變量，也最好先為它建立一個(gè)本地變量，例如： ? protected void drawHorizontalScrollBar(Canvas canvas, int width, int height) { ? if (isHorizontalScrollBarEnabled()) { ?? int size = (false)。 ?? if (size= 0) { ?? size = mScrollBarSize。 ?? } ?? (0, height ? size, width, height)。 ?? ( ?? puteHorizontalScrollRange(), ?? puteHorizontalScrollOffset(), ?? puteHorizontalScrollExtent(), false)。 ?? (canvas)。 ?? } ?? } 這里有 4 次訪問成員變量 mScrollBar，如果將它緩存到本地， 4 次成員變量訪問就會(huì)變成4 次效率更高的棧變量訪問。 另外就是方法的參數(shù)與本地變量的效率相同。 使用常量 讓我們來看看這兩段在類前面的聲明： ?? static int intVal = 42。 ?? static String strVal = “Hello, world!”。 必以其會(huì)生成一個(gè)叫做的初始化類的方法，當(dāng)類第一次被使用的時(shí)候這個(gè)方法會(huì)被執(zhí)行。方法會(huì)將 42 賦給 intVal，然后把一個(gè)指向類中常量表的引用賦給 strVal。當(dāng)以后要用到這些值的時(shí)候，會(huì)在成員變量表中查找到他們。下面我們做些改進(jìn)，使用 “final”關(guān)鍵字： ?? static final int intVal = 42。 ?? static final String strVal = “Hello, world!”。 現(xiàn)在，類不再需要方法，因?yàn)樵诔蓡T變量初始化的時(shí)候，會(huì)將常量直接保存到類文件中。用到 intVal 的代碼被直接替換成 42，而使用 strVal 的會(huì)指向一個(gè)字符串常量，而不是使用成員變量。 大連海洋大學(xué)本科畢業(yè)論文（設(shè)計(jì)） 第 5 章 設(shè)計(jì)思想 26 將一個(gè)方法或類聲明為 ”final”不會(huì)帶來性能的提升，但是會(huì)幫助編譯器優(yōu)化代碼。舉例說，如果編譯器知道一個(gè) ”getter”方法不會(huì)被重載，那么編譯器會(huì)對(duì)其采用內(nèi)聯(lián)調(diào)用。 你也可以將本地變量聲明為 ”final”，同樣，這也不會(huì)帶來性能的提升。使用 ”final”只能使本地變量看起來更清晰些 (但是也有些時(shí)候這是必須的，比如在 使用匿名內(nèi)部類的時(shí)候 )(xing:原文是 or you have to, . for use in an anonymous inner class) 謹(jǐn)慎使用 foreach 可以用在實(shí)現(xiàn)了 Iterable 接口的集合類型上。 foreach 會(huì)給這些對(duì)象分配一個(gè) iterator，然后調(diào)用 hasNext()和 next()方法。你最好使用 foreach 處理 ArrayList對(duì)象，但是對(duì)其他集合對(duì)象， foreach 相當(dāng)于使用 iterator。 下面展示了 foreach 一種可接受的用法： ?? public class Foo { ?? int mSplat。 ?? static Foo mArray[] = new Foo[27]。 ?? public static void zero() { ?? int sum = 0。 ?? for (int i = 0。 i 。 i++) { ?? sum += mArray[i].mSplat。 ?? } ?? } ?? public static void one() { ?? int sum = 0。 ?? Foo[] localArray = mA