一：學(xué)會(huì)懶惰

沒(méi)搞錯(cuò)吧？竟然讓程序開(kāi)發(fā)人員學(xué)會(huì)懶惰？程序開(kāi)發(fā)人員可能是世界上最為忙碌的一類人啦！對(duì)，沒(méi)錯(cuò)，學(xué)會(huì)懶惰！正因?yàn)槌绦蜷_(kāi)發(fā)人員忙碌，正因?yàn)槌绦蜷_(kāi)發(fā)人員可能會(huì)在客戶無(wú)限變化的需求之下沒(méi)日沒(méi)夜的加班，所以要學(xué)會(huì)懶惰，這樣，你就可以把更多的時(shí)間浪費(fèi)在美好的事物身上！

如何懶惰：

1，Don’t?Reinvent?the?Wheel（不要重復(fù)發(fā)明輪子）。

2，Inventing?the?Wheel(發(fā)明輪子)。

1 ，Don’t?Reinvent?the?Wheel（不要重復(fù)發(fā)明輪子）。

“輪子理論”，也即“不要重復(fù)發(fā)明輪子”，這是西方國(guó)家的一句諺語(yǔ)，原話是：Don’t?Reinvent?the?Wheel?！安灰貜?fù)發(fā)明輪子?”意思是企業(yè)中任何一項(xiàng)工作實(shí)際上都有人做過(guò)，我們所需要做的就是找到做過(guò)這件事情的人。拿到軟件領(lǐng)域中就是指有的項(xiàng)目或功能，別人已經(jīng)做過(guò)，我們需要用的時(shí)候，直接拿來(lái)用即可，而不要重新制造。

Android號(hào)稱是首個(gè)為移動(dòng)終端打造的真正開(kāi)放和完整的移動(dòng)軟件。Android發(fā)布后不久Google公司就發(fā)布了操作系統(tǒng)核心（Kernel）與部分驅(qū)動(dòng)程序的源代碼，到目前位置除了Google?Map等Google公司的核心組件沒(méi)有開(kāi)放源代碼外，Android基本完成了完全的開(kāi)源，這就極大的促進(jìn)了Android的普及和移植。受到Android開(kāi)放行為和開(kāi)源精神的影響，在世界各地，有成千上萬(wàn)的程序員喜歡和別人分享自己的聰明才智和自己編寫(xiě)的代碼。你可以在Google的Android討論組或者Google搜索引擎上搜索到很多優(yōu)秀的程序代碼。這樣做并不是鼓勵(lì)大家整天等著讓別人為你編寫(xiě)代碼，而是你可以“站在偉人的肩膀上”，充分發(fā)揚(yáng)“拿來(lái)主義”，聰明地應(yīng)用別人的程序代碼可以節(jié)省你大量的時(shí)間。
下面筆者為大家介紹幾個(gè)通用的類，這些類來(lái)自筆者平日的收集，如果你能把它們加入到你自己的類庫(kù)中，遲早你會(huì)發(fā)現(xiàn)自己在進(jìn)行Android開(kāi)發(fā)的時(shí)候受益無(wú)窮：

2 ，Inventing?the?Wheel(發(fā)明輪子)。

發(fā)明輪子？不錯(cuò)，發(fā)明輪子！我們不僅要發(fā)明輪子，更要成為努力成為世界上發(fā)明輪子的主導(dǎo)力量，唯有這樣，才能談的上中華名族軟件大業(yè)的真正強(qiáng)大。在Android，要發(fā)明輪子，就是我們要主動(dòng)的是解決一些世界上他人未解決的難題或者創(chuàng)造新的編程框架或者對(duì)Android進(jìn)行深度的改造以適合自己的業(yè)務(wù)發(fā)展需要。Google發(fā)布了Android后不久，中國(guó)移動(dòng)便投入了大量的人力和物力，在Android的基礎(chǔ)上創(chuàng)建融入自己業(yè)務(wù)并開(kāi)發(fā)、封裝了新的功能的和框架的OMS，這是Android中發(fā)明輪子的一個(gè)非常重要的例子。可能你會(huì)說(shuō)，這發(fā)明輪子也太難了吧，別急，我們慢慢來(lái)，開(kāi)發(fā)一個(gè)框架特定領(lǐng)域的框架吧！你可能會(huì)一臉無(wú)辜的說(shuō)，開(kāi)發(fā)一個(gè)框架是說(shuō)的那么容易嗎？當(dāng)然不是啦。但是也并非不可能，首先，我們分析一下框架的魅力的源泉，看看Spring、Struts等Java?EE框架，在看看.NET框架，當(dāng)然也可以看看發(fā)展的如火如荼、層出不窮的PHP框架，她們的強(qiáng)大和魅力的源泉都在于：IoC(Inversion?of?Control)。

Don’t?call?us,?we’ll?call?you（別找我，我會(huì)來(lái)找你的）。我們下面就自己發(fā)明一個(gè)輪子的模型，實(shí)際展示一個(gè)框架最初核心的類，讓你一飽眼福：

二：精通Android體系架構(gòu)、MVC、常見(jiàn)的設(shè)計(jì)模式、控制反轉(zhuǎn)（IoC）

1，請(qǐng)看某個(gè)著名的IT公司一則招聘信息的其中一條要求：“熟悉Android系統(tǒng)架構(gòu)及相關(guān)技術(shù)，1年以上實(shí)際Android平臺(tái)開(kāi)發(fā)經(jīng)驗(yàn)；”，里面非常明確的說(shuō)道要求熟練Android系統(tǒng)架構(gòu)，這從某種程度上說(shuō)明了對(duì)Android體系架構(gòu)的理解的重要性，下面我們看看Android體系結(jié)構(gòu)圖，該圖源自Android的文檔：

很明顯，上圖包含四個(gè)主要的層次：

Linux?Kernel：負(fù)責(zé)硬件的驅(qū)動(dòng)程序、網(wǎng)絡(luò)、電源、系統(tǒng)安全以及內(nèi)存管理等功能。

Libraries和Android?Runtime：Libraries：即C/C++函數(shù)庫(kù)部分，大多數(shù)都是開(kāi)放源代碼的函數(shù)庫(kù)，例如WebKit，該函數(shù)庫(kù)負(fù)責(zé)Android網(wǎng)頁(yè)瀏覽器的運(yùn)行，例如標(biāo)準(zhǔn)的C函數(shù)庫(kù)Libc、OpenSSL、SQLite等，當(dāng)然也包括支持游戲開(kāi)發(fā)2D?SGL和3D?OpenGL?|?ES，在多媒體方面有MediaFramework框架來(lái)支持各種影音和圖形文件的播放與顯示，例如MPEG4、H.264、MP3、AAC、AMR、JPG和PNG等眾多的多媒體文件格式。Android的Runtime負(fù)責(zé)解釋和執(zhí)行生成的Dalvik格式的字節(jié)碼。

Application?Framework（應(yīng)用軟件架構(gòu)），Java應(yīng)用程序開(kāi)發(fā)人員主要是使用該層封裝好的API進(jìn)行快速開(kāi)發(fā)。

Applications:該層是Java的應(yīng)用程序?qū)樱珹ndroid內(nèi)置的Google?Maps、E-mail、即時(shí)通信工具、瀏覽器、MP3播放器等處于該層，Java開(kāi)發(fā)人員開(kāi)發(fā)的程序也處于該層，而且和內(nèi)置的應(yīng)用程序具有平等的位置，可以調(diào)用內(nèi)置的應(yīng)用程序，也可以替換內(nèi)置的應(yīng)用程序。

上面的四個(gè)層次，下層為上層服務(wù)，上層需要下層的支持，調(diào)用下層的服務(wù)，這種嚴(yán)格分層的方式帶來(lái)的極大的穩(wěn)定性、靈活性和可擴(kuò)展性，使得不同層的開(kāi)發(fā)人員可以按照規(guī)范專心特定層的開(kāi)發(fā)。

Android應(yīng)用程序使用框架的API并在框架下運(yùn)行，這就帶來(lái)了程序開(kāi)發(fā)的高度一致性，另一方面也告訴我們，要想寫(xiě)出優(yōu)質(zhì)高效的程序就必須對(duì)整個(gè)Application?Framework進(jìn)行非常深入的理解。精通Application?Framework，你就可以真正的理解Android的設(shè)計(jì)和運(yùn)行機(jī)制，也就更能夠駕馭整個(gè)應(yīng)用層的開(kāi)發(fā)。

2 ，Android的官方建議應(yīng)用程序的開(kāi)發(fā)采用MVC模式。何謂MVC？先看看下圖

MVC是Model,View,Controller的縮寫(xiě)，從上圖可以看出MVC包含三個(gè)部分：

1.模型（Model）對(duì)象：是應(yīng)用程序的主體部分，所有的業(yè)務(wù)邏輯都應(yīng)該寫(xiě)在該層。

2.視圖（View）對(duì)象：是應(yīng)用程序中負(fù)責(zé)生成用戶界面的部分。也是在整個(gè)MVC架構(gòu)中用戶唯一可以看到的一層，接收用戶的輸入，顯示處理結(jié)果。

3.控制器（Control）對(duì)象：是根據(jù)用戶的輸入，控制用戶界面數(shù)據(jù)顯示及更新Model對(duì)象狀態(tài)的部分，控制器更重要的一種導(dǎo)航功能，想用用戶出發(fā)的相關(guān)事件，交給M哦得了處理。

Android鼓勵(lì)弱耦合和組件的重用，在Android中MVC的具體體現(xiàn)如下：

1)?視圖層（View）：一般采用XML文件進(jìn)行界面的描述，使用的時(shí)候可以非常方便的引入，當(dāng)然，如何你對(duì)Android了解的比較的多了話，就一定可以想到在Android中也可以使用JavaScript+HTML等的方式作為View層，當(dāng)然這里需要進(jìn)行Java和JavaScript之間的通信，幸運(yùn)的是，Android提供了它們之間非常方便的通信實(shí)現(xiàn)。

2)?控制層（Controller）：Android的控制層的重任通常落在了眾多的Acitvity的肩上，這句話也就暗含了不要在Acitivity中寫(xiě)代碼，要通過(guò)Activity交割Model業(yè)務(wù)邏輯層處理，這樣做的另外一個(gè)原因是Android中的Acitivity的響應(yīng)時(shí)間是5s，如果耗時(shí)的操作放在這里，程序就很容易被回收掉。

3)?模型層（Model）：對(duì)數(shù)據(jù)庫(kù)的操作、對(duì)網(wǎng)絡(luò)等的操作都應(yīng)該在Model里面處理，當(dāng)然對(duì)業(yè)務(wù)計(jì)算等操作也是必須放在的該層的。

3 ，設(shè)計(jì)模式和IoC(控制反轉(zhuǎn))

毫無(wú)疑問(wèn)，Android的之所以能夠成為一個(gè)開(kāi)放的氣象萬(wàn)千的系統(tǒng)，與設(shè)計(jì)模式的精妙應(yīng)用是分不開(kāi)的，只要你稍微用心觀察，就會(huì)發(fā)現(xiàn)在Android中到處都是A設(shè)計(jì)模式或者設(shè)計(jì)模式的聯(lián)合運(yùn)用，以下的設(shè)計(jì)模式是您游刃有余的駕馭Android所必須掌握的：

1.? Template?Method模式 ：(模板模式)

定義一個(gè)操作中算法的骨架，而將一些步驟延遲到子類中。不改變算法的結(jié)構(gòu)而重新定義它的步驟。

2.? Factory?Method模式：(工廠模式)

FactoryMethod是一種創(chuàng)建性模式,它定義了一個(gè)創(chuàng)建對(duì)象的接口,但是卻讓子類來(lái)決定具體實(shí)例化哪一個(gè)類.當(dāng)一個(gè)類無(wú)法預(yù)料要?jiǎng)?chuàng)建哪種類的對(duì)象或是一個(gè)類需要由子類來(lái)指定創(chuàng)建的對(duì)象時(shí)我們就需要用到Factory Method 模式了.簡(jiǎn)單說(shuō)來(lái),Factory Method可以根據(jù)不同的條件產(chǎn)生不同的實(shí)例,當(dāng)然這些不同的實(shí)例通常是屬于相同的類型,具有共同的父 類.Factory Method把創(chuàng)建這些實(shí)例的具體過(guò)程封裝起來(lái)了,簡(jiǎn)化了客戶端的應(yīng)用,也改善了程序的擴(kuò)展性,使得將來(lái)可以做最小的改動(dòng)就可以加入新的待創(chuàng)建的類. 通常我們將Factory Method作為一種標(biāo)準(zhǔn)的創(chuàng)建對(duì)象的方法,當(dāng)發(fā)現(xiàn)需要更多的靈活性的時(shí)候,就開(kāi)始考慮向其它創(chuàng)建型模式轉(zhuǎn)化

3.? Observer模式：(觀測(cè)者模式)
observer模式定義對(duì)象間的一對(duì)多的依賴關(guān)系,當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí), 所有依賴于它的對(duì)象都得到通知并被自動(dòng)更新。JDK里提供的observer設(shè)計(jì)模式的實(shí)現(xiàn)由java.util.Observable類和java.util.Observer接口組成。從名字上可以清楚的看出兩者在Observer?設(shè)計(jì)模式中分別扮演的角色：Observer是觀察者角色，Observable是被觀察目標(biāo)(subject)角色。

4.? Abstract?Factory模式：(抽象工廠模式)

為創(chuàng)建一組相關(guān)或相互依賴的對(duì)象提供一個(gè)接口，而且無(wú)需指定它們的具體類。大致意思是說(shuō)：我們?cè)趧?chuàng)建這些對(duì)象的時(shí)候，并不需要指定它們的具體類，這些具體類的對(duì)象是由工廠對(duì)象負(fù)責(zé)實(shí)例化的。

5.? Adapter模式：(適配器模式)

把一個(gè)類的接口變換成客戶端所期待的另一種接口，從而使原本因接口不匹配而無(wú)法在一起工作的兩個(gè)類能夠在一起工作。

6. Composite模式：(合成模式)

定義： 將對(duì)象組合成樹(shù)形結(jié)構(gòu)以表示“整體—部分”的層次結(jié)構(gòu)。Composite模式使單個(gè)對(duì)象和組合對(duì)象的使用具有一致性。

合成模式將對(duì)象組織到樹(shù)結(jié)構(gòu)中，可以用來(lái)描述整體和部分的關(guān)系。合成模式可以使客戶端將單純的元素和復(fù)合的元素同等看待。
注意：用文件系統(tǒng)來(lái)理解合成模式可以說(shuō)是個(gè)很好的方式。

7.? Strategy模式：(策略模式)

定義一系列算法，把他們封裝起來(lái)，并可相互替換，使算法可獨(dú)立于使用他的客戶而變化。

8.? State模式：(聲明模式)

定義一系列算法，把他們封裝起來(lái)，并可相互替換，使算法可獨(dú)立于使用他的客戶而變化。

State模式主要解決的是在開(kāi)發(fā)中時(shí)常遇到的根據(jù)不同的狀態(tài)需要進(jìn)行不同的處理操作的問(wèn)題,而這樣的問(wèn)題,大部分人是采用switch-case語(yǔ)句進(jìn)行處理的,這樣會(huì)造成一個(gè)問(wèn)題:分支過(guò)多,而且如果加入一個(gè)新的狀態(tài)就需要對(duì)原來(lái)的代碼進(jìn)行編譯。State模式采用了對(duì)這些不同的狀態(tài)進(jìn)行封裝的方式處理這類問(wèn)題,當(dāng)狀態(tài)改變的時(shí)候進(jìn)行處理然后再切換到另一種狀態(tài),也就是說(shuō)把狀態(tài)的切換責(zé)任交給了具體的狀態(tài)類去負(fù)責(zé).同時(shí),State模式和Strategy模式有很多相似的地方,需要說(shuō)明的是兩者的思想都是一致的,只不過(guò)封裝的東西不同:State模式封裝的是不同的狀態(tài),而Stategy模式封裝的是不同的算法。

9.? Proxy模式：(代理模式)

定義為其他對(duì)象提供一種代理以控制這個(gè)對(duì)象的訪問(wèn)。

Proxy代理模式是一種結(jié)構(gòu)型設(shè)計(jì)模式，主要解決的問(wèn)題是：在直接訪問(wèn)對(duì)象時(shí)帶來(lái)的問(wèn)題，比如說(shuō)：要訪問(wèn)的對(duì)象在遠(yuǎn)程的機(jī)器上。在面向?qū)ο笙到y(tǒng)中，有些對(duì)象由于某些原因（比如對(duì)象創(chuàng)建開(kāi)銷很大，或者某些操作需要安全控制，或者需要進(jìn)程外的訪問(wèn)），直接訪問(wèn)會(huì)給使用者或者系統(tǒng)結(jié)構(gòu)帶來(lái)很多麻煩，我們可以在訪問(wèn)此對(duì)象時(shí)加上一個(gè)對(duì)此對(duì)象的訪問(wèn)層,這個(gè)訪問(wèn)層也叫代理。Proxy模式是最常見(jiàn)的模式，在我們生活中處處可見(jiàn)，例如我們買火車票不一定非要到火車站去買，可以到一些火車票的代售點(diǎn)去買。寄信不一定是自己去寄，可以把信委托給郵局，由郵局把信送到目的地，現(xiàn)實(shí)生活中還有很多這樣的例子，就不一一列舉了。

10. Bridge模式：(橋梁模式)

定義 : 將抽象和行為劃分開(kāi)來(lái),各自獨(dú)立,但能動(dòng)態(tài)的結(jié)合.

橋梁模式的用意是 “將抽象化(Abstraction)與實(shí)現(xiàn)化(Implementation)脫耦，使得二者可以獨(dú)立地變化”。這句話有三個(gè)關(guān)鍵詞，也就是抽象化、實(shí)現(xiàn)化和脫耦。

11. Iterator模式：(迭代器模式)

定義：提供一個(gè)方法順序訪問(wèn)一個(gè)聚合對(duì)象的各個(gè)元素，而又不暴露該對(duì)象的內(nèi)部表示。
這個(gè)模式在java的類庫(kù)中已經(jīng)實(shí)現(xiàn)了，在java中所有的集合類都實(shí)現(xiàn)了Conllection接口，而Conllection接口又繼承了Iterable接口，該接口有一個(gè)iterator方法，也就是所以的集合類都可以通過(guò)這個(gè)iterator方法來(lái)轉(zhuǎn)換成Iterator類，用Iterator對(duì)象中的hasnext方法來(lái)判斷是否還有下個(gè)元素，next方法來(lái)順序獲取集合類中的對(duì)象。

12. Memento 模式：（備忘錄模式）

定義：在不破壞封裝的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。這樣就可以將該對(duì)象恢復(fù)到原先保存前的狀態(tài)。

在程序運(yùn)行過(guò)程中，某些對(duì)象的狀態(tài)處在轉(zhuǎn)換過(guò)程中，可能由于某種原因需要保存此時(shí)對(duì)象的狀態(tài)，以便程序運(yùn)行到某個(gè)特定階段，需要恢復(fù)到對(duì)象之前處于某個(gè)點(diǎn)時(shí)的狀態(tài)。如果使用一些公有接口讓其它對(duì)象來(lái)得到對(duì)象的狀態(tài)，便會(huì)暴露對(duì)象的實(shí)現(xiàn)細(xì)節(jié)。

13. Facade模式：(外觀模式)

定義：為子系統(tǒng)中的一組接口提供一個(gè)一致的界面，F(xiàn)acade模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。

Facade外觀模式，是一種結(jié)構(gòu)型模式，它主要解決的問(wèn)題是：組件的客戶和組件中各種復(fù)雜的子系統(tǒng)有了過(guò)多的耦合，隨著外部客戶程序和各子系統(tǒng)的演化，這種過(guò)多的耦合面臨很多變化的挑戰(zhàn)。在這里我想舉一個(gè)例子：比如，現(xiàn)在有一輛汽車，我們（客戶程序）要啟動(dòng)它，那我們就要發(fā)動(dòng)引擎（子系統(tǒng)1），使四個(gè)車輪（子系統(tǒng)2）轉(zhuǎn)動(dòng)。但是實(shí)際中我們并不需要用手推動(dòng)車輪使其轉(zhuǎn)動(dòng)，我們踩下油門，此時(shí)汽車再根據(jù)一些其他的操作使車輪轉(zhuǎn)動(dòng)。油門就好比系統(tǒng)給我們留下的接口，不論汽車是以何種方式轉(zhuǎn)動(dòng)車輪，車輪變化成什么牌子的，我們要開(kāi)走汽車所要做的還是踩下油門。

14. Mediator 模式: (中介者模式)

定義：用一個(gè)中介者對(duì)象來(lái)封裝一系列的對(duì)象交互。中介者使各對(duì)象不需要顯式的相互引用，從而使其耦合松散，而且可以獨(dú)立的改變他們之間的交互。

15. Chain of Responsibility模式 : (責(zé)任鏈模式)

定義: 為了避免請(qǐng)求的發(fā)送者和接收者之間的耦合關(guān)系，使多個(gè)接受對(duì)象都有機(jī)會(huì)處理請(qǐng)求。將這些對(duì)象連成一條鏈，并沿著這條鏈傳遞該請(qǐng)求，直到有一個(gè)對(duì)象處理它為止。

Struts2、tomcat的過(guò)濾器采用的模式（過(guò)濾器是它們的核心機(jī)制）

16. Command模式 : (命令模式)

定義：將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使你不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或記錄請(qǐng)求日志，以及支持可撤銷的操作。

Commad模式是一種對(duì)象行為模式，它可以對(duì)發(fā)送者(sender)和接收者(receiver)完全解耦(decoupling)。（”發(fā)送者” 是請(qǐng)求操作的對(duì)象，”接收者” 是接收請(qǐng)求并執(zhí)行某操作的對(duì)象。有了 “解耦”，發(fā)送者對(duì)接收者的接口一無(wú)所知。）這里，”請(qǐng)求”(request)這個(gè)術(shù)語(yǔ)指的是要被執(zhí)行的命令。Command模式還讓我們可以對(duì) “何時(shí)” 以及 “如何” 完成請(qǐng)求進(jìn)行改變。因此，Command模式為我們提供了靈活性和可擴(kuò)展性。

17. Builder模式 : (建造者模式)

定義：將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離,使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示。

建造模式是一步一步創(chuàng)建一個(gè)復(fù)雜的對(duì)象,它允許用戶可以只通過(guò)指定復(fù)雜對(duì)象的類型和內(nèi)容就可以構(gòu)建它們，用戶不知道內(nèi)部的具體構(gòu)建細(xì)節(jié)。

18. Prototype模式 （原型模式）

通過(guò)給出一個(gè)原型對(duì)象來(lái)指明所要?jiǎng)?chuàng)建的對(duì)象類型，然后用復(fù)制這個(gè)原型對(duì)象的辦法創(chuàng)建出更多的同類型對(duì)象。

在java的類庫(kù)中已經(jīng)實(shí)現(xiàn)了這一模式，只要你定義的類實(shí)現(xiàn)了Cloneable接口，用這個(gè)類所創(chuàng)建的對(duì)象可以做為原型對(duì)象進(jìn)而克隆出更多的同類型的對(duì)象。

19. Singleton 模式: ?(單例模式) —–最簡(jiǎn)單的模式

定義：保證一個(gè)類只有一個(gè)實(shí)例，并提供一個(gè)訪問(wèn)它的全局訪問(wèn)點(diǎn)。

20. Visitor模式 : (訪問(wèn)者模式)

定義：表示一個(gè)作用于某對(duì)象結(jié)構(gòu)中各元素的操作。它可以使你不修改各元素類的前提下定義作用于這些元素的新操作，也就是動(dòng)態(tài)的增加新的方法。

21. FlyWeight模式：（享元模式）

定義：運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度對(duì)象。

也就是說(shuō)在一個(gè)系統(tǒng)中如果有多個(gè)相同的對(duì)象，那么只共享一份就可以了，不必每個(gè)都去實(shí)例化一個(gè)對(duì)象。在Flyweight模式中，由于要產(chǎn)生各種各樣的對(duì)象，所以在Flyweight(享元)模式中常出現(xiàn)Factory模式。Flyweight的內(nèi)部狀態(tài)是用來(lái)共享的,Flyweight factory負(fù)責(zé)維護(hù)一個(gè)對(duì)象存儲(chǔ)池（Flyweight Pool）來(lái)存放內(nèi)部狀態(tài)的對(duì)象。Flyweight模式是一個(gè)提高程序效率和性能的模式,會(huì)大大加快程序的運(yùn)行速度。

22.Decorator 模式： （裝飾模式）

定義：動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)。就增加功能來(lái)說(shuō)，Decorator模式比生成子類更為靈活。

也就是說(shuō)：動(dòng)態(tài)地給對(duì)象添加一些額外的功能。它的工作原理是：創(chuàng)建一個(gè)始于Decorator對(duì)象（負(fù)責(zé)新功能的對(duì)象）終止于原對(duì)象的一個(gè)對(duì)象的“鏈”。例如，我們要為超市的收銀臺(tái)設(shè)計(jì)一個(gè)打印票據(jù)的程序，有的需要打印票據(jù)的頭信息，有的需要打印票據(jù)的頁(yè)腳信息，有的只需要打印票據(jù)的內(nèi)容。如果針對(duì)每一種情況都修改一次程序，勢(shì)必會(huì)很麻煩。這時(shí)我們可以考慮使用Decorator模式。

23. Ioc 模式：(控制反轉(zhuǎn)模式)

IoC是一種用來(lái)解決組件（實(shí)際上也可以是簡(jiǎn)單的Java類）之間依賴關(guān)系、配置及生命周期的設(shè)計(jì)模式，其中對(duì)組件依賴關(guān)系的處理是IoC的精華部分。IoC的實(shí)際意義就是把組件之間的依賴關(guān)系提?。ǚ崔D(zhuǎn)）出來(lái)，由容器來(lái)具體配置。這樣，各個(gè)組件之間就不存在hard-code的關(guān)聯(lián)，任何組件都可以最大程度的得到重用。運(yùn)用了IoC模式后我們不再需要自己管理組件之間的依賴關(guān)系，只需要聲明由容器去實(shí)現(xiàn)這種依賴關(guān)系。就好像把對(duì)組件之間依賴關(guān)系的控制進(jìn)行了倒置，不再由組件自己來(lái)建立這種依賴關(guān)系而交給容器（例如PicoContainer、Spring）去管理。

Android框架魅力的源泉在于IoC，在開(kāi)發(fā)Android的過(guò)程中你會(huì)時(shí)刻感受到IoC帶來(lái)的巨大方便，就拿Activity來(lái)說(shuō)，下面的函數(shù)是框架調(diào)用自動(dòng)調(diào)用的：

protected?void?onCreate(Bundle?savedInstanceState)?；

不是程序編寫(xiě)者主動(dòng)去調(diào)用，反而是用戶寫(xiě)的代碼被框架調(diào)用，這也就反轉(zhuǎn)了！當(dāng)然IoC本身的內(nèi)涵遠(yuǎn)遠(yuǎn)不止這些，但是從這個(gè)例子中也可以窺視出IoC帶來(lái)的巨大好處。此類的例子在Android隨處可見(jiàn)，例如說(shuō)數(shù)據(jù)庫(kù)的管理類，例如說(shuō)Android中SAX的Handler的調(diào)用等。有時(shí)候，您甚至需要自己編寫(xiě)簡(jiǎn)單的IoC實(shí)現(xiàn)，上面展示的多線程現(xiàn)在就是一個(gè)說(shuō)明。

三：編寫(xiě)可重用、可擴(kuò)展、可維護(hù)、靈活性高的代碼

Android應(yīng)用程序的開(kāi)發(fā)是使用Java編寫(xiě)，在架構(gòu)上使用MVC，鼓勵(lì)組件之間的若耦合。開(kāi)發(fā)出編寫(xiě)可重用、可擴(kuò)展、可維護(hù)、靈活性高的代碼需要經(jīng)歷遵循以下原則：

l?” 開(kāi)-閉”原則(OCP)： 一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。這個(gè)原則說(shuō)的是，在設(shè)計(jì)一個(gè)模塊的時(shí)候，應(yīng)當(dāng)使這個(gè)模塊可以在不被修改的前提下被擴(kuò)展。換言之，應(yīng)當(dāng)可以在不必修改源代碼的情況下改變這個(gè)模塊的行為。

l 里氏代換原則（LSP） ：一個(gè)軟件實(shí)體如果使用的是一個(gè)基類的話，那么一定使用于其子類，而且它根本不能察覺(jué)出基類對(duì)象和子類對(duì)象的區(qū)別。

l?依賴倒轉(zhuǎn)原則(DIP)：要依賴于抽象,不要依賴于具體。

l?接口隔離原則（ISP）：使用多個(gè)專門的接口比使用單一的總接口要好。一個(gè)類對(duì)另外一個(gè)類的依賴性應(yīng)當(dāng)是建立在最小的接口上的。

l?合成/聚合復(fù)用原則（CARP）：又稱合成復(fù)用原則(CRP),就是在一個(gè)新的對(duì)象里面使用一些已有的對(duì)象，使之成為新對(duì)象的一部分；新的對(duì)象通過(guò)向這些對(duì)象的委派達(dá)到復(fù)用已有功能的目的。簡(jiǎn)而言之就是：要盡量使用合成/聚合，盡量不要使用繼承。

l?迪米特法則（LoD）：又稱最少知識(shí)原則（LKP），就是說(shuō)一個(gè)對(duì)象應(yīng)當(dāng)對(duì)其他對(duì)象盡可能少的了解。狹義的迪米特法則是指如果兩個(gè)類不必彼此直接通信,那么這兩個(gè)類就不應(yīng)當(dāng)發(fā)生直接的相互作用.如果其中一個(gè)類需要調(diào)用另一個(gè)類的方法的話,可以通過(guò)第三者轉(zhuǎn)發(fā)這個(gè)調(diào)用.。廣義的迪米特法則是指一個(gè)模塊設(shè)計(jì)得好壞的一個(gè)重要的標(biāo)志就是該模塊在多大的程度上將自己的內(nèi)部數(shù)據(jù)與實(shí)現(xiàn)有關(guān)的細(xì)節(jié)隱藏起來(lái)。信息的隱藏非常重要的原因在于,它可以使各個(gè)子系統(tǒng)之間脫耦,從而允許它們獨(dú)立地被開(kāi)發(fā),優(yōu)化,使用閱讀以及修改.。

靈活的使用設(shè)計(jì)模式可以在面對(duì)千變?nèi)f化的業(yè)務(wù)需求是編寫(xiě)出可重用、可擴(kuò)展、可維護(hù)、靈活性高的代碼。

當(dāng)然，由于Android是運(yùn)行在移動(dòng)設(shè)備上的，而移動(dòng)設(shè)備的處理能力是有限的，所以有時(shí)間必須在編寫(xiě)可重用、可擴(kuò)展、可維護(hù)、靈活性高的代碼與高效的代碼之間做出適當(dāng)?shù)钠胶狻?

四：高效的編寫(xiě)高效的代碼

高效快速的編寫(xiě)代碼和編寫(xiě)高效率執(zhí)行的代碼很多時(shí)候都是對(duì)立的死敵，很多時(shí)候，你想快速的開(kāi)發(fā)，代碼的執(zhí)行效率往往就會(huì)慢下來(lái)；你想編寫(xiě)高效的代碼，開(kāi)發(fā)速度就會(huì)慢下來(lái)。

不重復(fù)發(fā)明輪子和發(fā)明新的輪子是高效的編寫(xiě)高效的代碼的正確是道路。

關(guān)于高效的代碼，下面網(wǎng)絡(luò)的一篇文章，直接轉(zhuǎn)載（不知道是哪位哥們寫(xiě)的）如下：

“現(xiàn)代的手持設(shè)備，與其說(shuō)是電話，更像一臺(tái)拿在手中的電腦。但是，即使是“最快”的手持設(shè)備，其性能也趕不上一臺(tái)普通的臺(tái)式電腦。

這就是為什么我們?cè)跁?shū)寫(xiě)Android應(yīng)用程序的時(shí)候要格外關(guān)注效率。這些設(shè)備并沒(méi)有那么快，并且受電池電量的制約。這意味著，設(shè)備沒(méi)有更多的能力，我們必須把程序?qū)懙谋M量有效。
本文討論了很多能讓開(kāi)發(fā)者使他們的程序運(yùn)行更有效的方法，遵照這些方法，你可以使你的程序發(fā)揮最大的效力。
對(duì)于占用資源的系統(tǒng)，有兩條基本原則：

1.?不要做不必要的事

2.?不要分配不必要的內(nèi)存

所有下面的內(nèi)容都遵照這兩個(gè)原則。

有些人可能馬上會(huì)跳出來(lái)，把本節(jié)的大部分內(nèi)容歸于“草率的優(yōu)化”（xing:參見(jiàn)[The?Root?of?All?Evil]），不可否認(rèn)微優(yōu)化（micro-optimization。xing:代碼優(yōu)化，相對(duì)于結(jié)構(gòu)優(yōu)化）的確會(huì)帶來(lái)很多問(wèn)題，諸如無(wú)法使用更有效的數(shù)據(jù)結(jié)構(gòu)和算法。但是在手持設(shè)備上，你別無(wú)選擇。假如你認(rèn)為Android虛擬機(jī)的性能與臺(tái)式機(jī)相當(dāng)，你的程序很有可能一開(kāi)始就占用了系統(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)我們開(kāi)門見(jiàn)山、直擊主題之前，還必須要提醒大家一點(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()快。所以不要寄希望于編譯器可以拯救你的程序。

避免建立對(duì)象

世界上沒(méi)有免費(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ì)覺(jué)得界面像打嗝一樣一頓一頓的。

所以，除非必要，應(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)對(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)部，你仍要盡可能的提高代碼的效率）

總體來(lái)說(shuō)，就是避免創(chuàng)建短命的臨時(shí)對(duì)象。減少對(duì)象的創(chuàng)建就能減少垃圾收集，進(jìn)而減少對(duì)用戶體驗(yàn)的影響。

使用本地方法

當(dāng)你在處理字串的時(shí)候，不要吝惜使用String.indexOf(),?String.lastIndexOf()等特殊實(shí)現(xiàn)的方法（specialty?methods）。這些方法都是使用C/C++實(shí)現(xiàn)的，比起Java循環(huán)快10到100倍。

使用實(shí)類比接口好

假設(shè)你有一個(gè)HashMap對(duì)象，你可以將它聲明為HashMap或者M(jìn)ap:

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就沒(méi)有什么價(jià)值。如果有些地方你不能確定，先避免使用Map，剩下的交給IDE提供的重構(gòu)功能好了。(當(dāng)然公共API是一個(gè)例外：一個(gè)好的API常常會(huì)犧牲一些性能）

用靜態(tài)方法比虛方法好

如果你不需要訪問(wèn)一個(gè)對(duì)象的成員變量，那么請(qǐng)把方法聲明成static。虛方法執(zhí)行的更快，因?yàn)樗梢员恢苯诱{(diào)用而不需要一個(gè)虛函數(shù)表。另外你也可以通過(guò)聲明體現(xiàn)出這個(gè)函數(shù)的調(diào)用不會(huì)改變對(duì)象的狀態(tài)。不用getter和setter

在很多本地語(yǔ)言如C++中，都會(huì)使用getter（比如：i?=?getCount()）來(lái)避免直接訪問(wèn)成員變量（i?=?mCount）。在C++中這是一個(gè)非常好的習(xí)慣，因?yàn)榫幾g器能夠內(nèi)聯(lián)訪問(wèn)，如果你需要約束或調(diào)試變量，你可以在任何時(shí)候添加代碼。

在Android上，這就不是個(gè)好主意了。虛方法的開(kāi)銷比直接訪問(wèn)成員變量大得多。在通用的接口定義中，可以依照OO的方式定義getters和setters，但是在一般的類中，你應(yīng)該直接訪問(wèn)變量。

將成員變量緩存到本地

訪問(wèn)成員變量比訪問(wèn)本地變量慢得多，下面一段代碼：

Java代碼?

for?(int?i?=?0;?i?<?this.mCount;?i++)

dumpItem(this.mItems[i]);

最好改成這樣：

Java代碼?

int?count?=?this.mCount;

Item[]?items?=?this.mItems;

for?(int?i?=?0;?i?<?count;?i++)

dumpItems(items[i]);

（使用”this”是為了表明這些是成員變量）
另一個(gè)相似的原則是：永遠(yuǎn)不要在for的第二個(gè)條件中調(diào)用任何方法。如下面方法所示，在每次循環(huán)的時(shí)候都會(huì)調(diào)用getCount()方法，這樣做比你在一個(gè)int先把結(jié)果保存起來(lái)開(kāi)銷大很多。

Java代碼?

for?(int?i?=?0;?i?<?this.getCount();?i++)

dumpItems(this.getItem(i));

同樣如果你要多次訪問(wèn)一個(gè)變量，也最好先為它建立一個(gè)本地變量，例如：

Java代碼?

protected?void?drawHorizontalScrollBar(Canvas?canvas,?int?width,?int?height)?{

if?(isHorizontalScrollBarEnabled())?{

int?size?=?mScrollBar.getSize(false);

if?(size?<=?0)?{

size?=?mScrollBarSize;

}

mScrollBar.setBounds(0,?height?-?size,?width,?height);

mScrollBar.setParams(computeHorizontalScrollRange(),computeHorizontalScrollOffset(),computeHorizontalScrollExtent(),?false);

mScrollBar.draw(canvas);

}

}

這里有4次訪問(wèn)成員變量mScrollBar，如果將它緩存到本地，4次成員變量訪問(wèn)就會(huì)變成4次效率更高的棧變量訪問(wèn)。

另外就是方法的參數(shù)與本地變量的效率相同。

使用常量

讓我們來(lái)看看這兩段在類前面的聲明：

Java代碼?

static?int?intVal?=?42;

static?String?strVal?=?”Hello,?world!”;

必以其會(huì)生成一個(gè)叫做<clinit>的初始化類的方法，當(dāng)類第一次被使用的時(shí)候這個(gè)方法會(huì)被執(zhí)行。方法會(huì)將42賦給intVal，然后把一個(gè)指向類中常量表的引用賦給strVal。當(dāng)以后要用到這些值的時(shí)候，會(huì)在成員變量表中查找到他們。

下面我們做些改進(jìn)，使用“final”關(guān)鍵字：

Java代碼?

static?final?int?intVal?=?42;

static?final?String?strVal?=?”Hello,?world!”;

現(xiàn)在，類不再需要<clinit>方法，因?yàn)樵诔蓡T變量初始化的時(shí)候，會(huì)將常量直接保存到類文件中。用到intVal的代碼被直接替換成42，而使用strVal的會(huì)指向一個(gè)字符串常量，而不是使用成員變量。

將一個(gè)方法或類聲明為”final”不會(huì)帶來(lái)性能的提升，但是會(huì)幫助編譯器優(yōu)化代碼。舉例說(shuō)，如果編譯器知道一個(gè)”getter”方法不會(huì)被重載，那么編譯器會(huì)對(duì)其采用內(nèi)聯(lián)調(diào)用。
你也可以將本地變量聲明為”final”，同樣，這也不會(huì)帶來(lái)性能的提升。使用”final”只能使本地變量看起來(lái)更清晰些（但是也有些時(shí)候這是必須的，比如在使用匿名內(nèi)部類的時(shí)候）（xing:原文是?or?you?have?to,?e.g.?for?use?in?an?anonymous?inner?class）

謹(jǐn)慎使用foreach
foreach可以用在實(shí)現(xiàn)了Iterable接口的集合類型上。foreach會(huì)給這些對(duì)象分配一個(gè)iterator，然后調(diào)用?hasNext()和next()方法。你最好使用foreach處理ArrayList對(duì)象，但是對(duì)其他集合對(duì)象，foreach相當(dāng)于使用?iterator。

下面展示了foreach一種可接受的用法：

Java代碼?

public?class?Foo?{

int?mSplat;

static?Foo?mArray[]?=?new?Foo[27];

public?static?void?zero()?{

int?sum?=?0;

for?(int?i?=?0;?i?<?mArray.length;?i++)?{

sum?+=?mArray[i].mSplat;

}

}

public?static?void?one()?{

int?sum?=?0;

Foo[]?localArray?=?mArray;

int?len?=?localArray.length;

for?(int?i?=?0;?i?<?len;?i++)?{

sum?+=?localArray[i].mSplat;

}

}

public?static?void?two()?{

int?sum?=?0;

for?(Foo?a:?mArray)?{

sum?+=?a.mSplat;

}

}

}

在zero()中，每次循環(huán)都會(huì)訪問(wèn)兩次靜態(tài)成員變量，取得一次數(shù)組的長(zhǎng)度。
retrieves?the?static?field?twice?and?gets?the?array?length?once?for?every?iteration?through?the?loop.
在one()中，將所有成員變量存儲(chǔ)到本地變量。
pulls?everything?out?into?local?variables,?avoiding?the?lookups.
two()使用了在java1.5中引入的foreach語(yǔ)法。編譯器會(huì)將對(duì)數(shù)組的引用和數(shù)組的長(zhǎng)度保存到本地變量中，這對(duì)訪問(wèn)數(shù)組元素非常好。但是編譯器還會(huì)在每次循環(huán)中產(chǎn)生一個(gè)額外的對(duì)本地變量的存儲(chǔ)操作（對(duì)變量a的存?。┻@樣會(huì)比one()多出4個(gè)字節(jié)，速度要稍微慢一些。
綜上所述：foreach語(yǔ)法在運(yùn)用于array時(shí)性能很好，但是運(yùn)用于其他集合對(duì)象時(shí)要小心，因?yàn)樗鼤?huì)產(chǎn)生額外的對(duì)象。
避免使用枚舉
枚舉變量非常方便，但不幸的是它會(huì)犧牲執(zhí)行的速度和并大幅增加文件體積。例如：
public?class?Foo?{public?enum?Shrubbery?{?GROUND,?CRAWLING,?HANGING?}}
會(huì)產(chǎn)生一個(gè)900字節(jié)的.class文件(Foo$Shubbery.class)。在它被首次調(diào)用時(shí)，這個(gè)類會(huì)調(diào)用初始化方法來(lái)準(zhǔn)備每個(gè)枚舉變量。每個(gè)枚舉項(xiàng)都會(huì)被聲明成一個(gè)靜態(tài)變量，并被賦值。然后將這些靜態(tài)變量放在一個(gè)名為”$VALUES”的靜態(tài)數(shù)組變量中。而這么一大堆代碼，僅僅是為了使用三個(gè)整數(shù)。
這樣:
Shrubbery?shrub?=?Shrubbery.GROUND;會(huì)引起一個(gè)對(duì)靜態(tài)變量的引用，如果這個(gè)靜態(tài)變量是final?int，那么編譯器會(huì)直接內(nèi)聯(lián)這個(gè)常數(shù)。

一方面說(shuō)，使用枚舉變量可以讓你的API更出色，并能提供編譯時(shí)的檢查。所以在通常的時(shí)候你毫無(wú)疑問(wèn)應(yīng)該為公共API選擇枚舉變量。但是當(dāng)性能方面有所限制的時(shí)候，你就應(yīng)該避免這種做法了。

有些情況下，使用ordinal()方法獲取枚舉變量的整數(shù)值會(huì)更好一些，舉例來(lái)說(shuō)，將：

Java代碼?

for?(int?n?=?0;?n?<?list.size();?n++)?{

if?(list.items[n].e?==?MyEnum.VAL_X)//?do?stuff?1

else?if?(list.items[n].e?==?MyEnum.VAL_Y)//?do?stuff?2

}

替換為:

Java代碼?

int?valX?=?MyEnum.VAL_X.ordinal();

int?valY?=?MyEnum.VAL_Y.ordinal();

int?count?=?list.size();

MyItem?items?=?list.items();

for?(int?n?=?0;?n?<?count;?n++)?{

int?valItem?=?items[n].e.ordinal();

if?(valItem?==?valX)//?do?stuff?1

else?if?(valItem?==?valY)//?do?stuff?2

}

會(huì)使性能得到一些改善，但這并不是最終的解決之道。

將與內(nèi)部類一同使用的變量聲明在包范圍內(nèi)

請(qǐng)看下面的類定義：

Java代碼?

public?class?Foo?{

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);

}

private?class?Inner?{

void?stuff()?{

Foo.this.doStuff(Foo.this.mValue);

}

}

}????? 這其中的關(guān)鍵是，我們定義了一個(gè)內(nèi)部類(Foo$Inner)，它需要訪問(wèn)外部類的私有域變量和函數(shù)。這是合法的，并且會(huì)打印出我們希望的結(jié)果”Value?is?27″。

問(wèn)題是在技術(shù)上來(lái)講（在幕后）Foo$Inner是一個(gè)完全獨(dú)立的類，它要直接訪問(wèn)Foo的私有成員是非法的。要跨越這個(gè)鴻溝，編譯器需要生成一組方法：

Java代碼?

static?int?Foo.access$100(Foo?foo)?{

return?foo.mValue;

}

static?void?Foo.access$200(Foo?foo,?int?value)?{

foo.doStuff(value);

}

內(nèi)部類在每次訪問(wèn)”mValue”和”doStuff”方法時(shí)，都會(huì)調(diào)用這些靜態(tài)方法。就是說(shuō)，上面的代碼說(shuō)明了一個(gè)問(wèn)題，你是在通過(guò)接口方法訪問(wèn)這些成員變量和函數(shù)而不是直接調(diào)用它們。在前面我們已經(jīng)說(shuō)過(guò)，使用接口方法（getter、setter）比直接訪問(wèn)速度要慢。所以這個(gè)例子就是在特定語(yǔ)法下面產(chǎn)生的一個(gè)“隱性的”性能障礙。
通過(guò)將內(nèi)部類訪問(wèn)的變量和函數(shù)聲明由私有范圍改為包范圍，我們可以避免這個(gè)問(wèn)題。這樣做可以讓代碼運(yùn)行更快，并且避免產(chǎn)生額外的靜態(tài)方法。（遺憾的是，這些域和方法可以被同一個(gè)包內(nèi)的其他類直接訪問(wèn)，這與經(jīng)典的OO原則相違背。因此當(dāng)你設(shè)計(jì)公共API的時(shí)候應(yīng)該謹(jǐn)慎使用這條優(yōu)化原則）
避免使用浮點(diǎn)數(shù)
在奔騰CPU出現(xiàn)之前，游戲設(shè)計(jì)者做得最多的就是整數(shù)運(yùn)算。隨著奔騰的到來(lái)，浮點(diǎn)運(yùn)算處理器成為了CPU內(nèi)置的特性，浮點(diǎn)和整數(shù)配合使用，能夠讓你的游戲運(yùn)行得更順暢。通常在桌面電腦上，你可以隨意的使用浮點(diǎn)運(yùn)算。
但是非常遺憾，嵌入式處理器通常沒(méi)有支持浮點(diǎn)運(yùn)算的硬件，所有對(duì)”float”和”double”的運(yùn)算都是通過(guò)軟件實(shí)現(xiàn)的。一些基本的浮點(diǎn)運(yùn)算，甚至需要毫秒級(jí)的時(shí)間才能完成。
甚至是整數(shù)，一些芯片有對(duì)乘法的硬件支持而缺少對(duì)除法的支持。這種情況下，整數(shù)的除法和取模運(yùn)算也是有軟件來(lái)完成的。所以當(dāng)你在使用哈希表或者做大量數(shù)學(xué)運(yùn)算時(shí)一定要小心謹(jǐn)慎。?”

五，學(xué)會(huì)至少一門服務(wù)器端開(kāi)發(fā)技術(shù)

可能有朋友會(huì)問(wèn)：學(xué)習(xí)Android應(yīng)用程序開(kāi)發(fā)為什么還需要學(xué)習(xí)學(xué)會(huì)至少一門服務(wù)器端開(kāi)發(fā)技術(shù)呢？答案如下：一方面Android號(hào)稱是首個(gè)為移動(dòng)終端打造的真正開(kāi)放和完整的移動(dòng)軟件。作為一種移動(dòng)終端，必須與服務(wù)器端結(jié)合才能發(fā)揮巨大的作用。簡(jiǎn)言之，需要：云端+云的方式。Android是為移動(dòng)互聯(lián)網(wǎng)時(shí)代量身打造的，移動(dòng)互聯(lián)網(wǎng)時(shí)代的服務(wù)模式是“手機(jī)終端+互聯(lián)網(wǎng)絡(luò)+應(yīng)用軟件”，移動(dòng)互聯(lián)網(wǎng)時(shí)代應(yīng)用技術(shù)之一的Android只是用于開(kāi)發(fā)移動(dòng)終端軟件，而服務(wù)端技術(shù)用于開(kāi)發(fā)互聯(lián)網(wǎng)絡(luò)應(yīng)用，所以未來(lái)移動(dòng)互聯(lián)網(wǎng)時(shí)代軟件的主流應(yīng)用模式將是“手機(jī)客戶端+互聯(lián)網(wǎng)絡(luò)應(yīng)用服務(wù)端”，這種模式要求做移動(dòng)互聯(lián)網(wǎng)開(kāi)發(fā)的程序員不但要掌握像Android這樣的手機(jī)終端軟件技術(shù)還要掌握開(kāi)發(fā)互聯(lián)網(wǎng)絡(luò)應(yīng)用的服務(wù)器端技術(shù)。目前，軟件企業(yè)普遍存在這樣的問(wèn)題，做移動(dòng)互聯(lián)網(wǎng)開(kāi)發(fā)Android終端軟件的程序員不了解web應(yīng)用技術(shù)，而做web應(yīng)用的程序員不了解移動(dòng)終端技術(shù)，這樣就導(dǎo)致了客戶端與服務(wù)端在銜接上出現(xiàn)了問(wèn)題。目前的現(xiàn)狀是：既掌握移動(dòng)互聯(lián)網(wǎng)Android終端技術(shù)，又掌握web應(yīng)用技術(shù)的程序員比較稀缺，隨著中國(guó)步入移動(dòng)互聯(lián)網(wǎng)時(shí)代，企業(yè)對(duì)這種移動(dòng)互聯(lián)網(wǎng)時(shí)代綜合性人才的需求很旺盛。如果不了解web應(yīng)用技術(shù)，最終會(huì)遇到了技術(shù)和發(fā)展的瓶頸；另一方面，Google聯(lián)合OHA推出的真正優(yōu)勢(shì)之一也在于和和互聯(lián)網(wǎng)結(jié)合，Google的用意之一也是想開(kāi)辟新的終端去使用Google的優(yōu)勢(shì)服務(wù)。

服務(wù)器端開(kāi)發(fā)技術(shù)目前主流的有Sun的Java?EE、微軟的.NET，開(kāi)源的以PHP和MySQL為代表的LAMP體系，我們?cè)撨x擇哪一種呢？從理論上講，很多人傾向于選擇Java?EE，畢竟它們都是使用Java作為開(kāi)發(fā)語(yǔ)言的，但是很多人面對(duì)Java?EE眾多的框架就望而生畏，其實(shí)在學(xué)習(xí)Java?EE的時(shí)候可以從Struts入手，隨著業(yè)務(wù)的需求逐步深入。當(dāng)然，選擇微軟的.NET也行，畢竟該技術(shù)體系也占有很大?市場(chǎng)份額。其實(shí)，筆者認(rèn)為，選擇LAMP可以是會(huì)獲得最高的“性價(jià)比”的，一方面PHP是現(xiàn)在Web方面的主流語(yǔ)言，大多數(shù)新型的網(wǎng)站尤其是創(chuàng)業(yè)性質(zhì)的網(wǎng)站一般都會(huì)選用PHP作為服務(wù)端開(kāi)發(fā)語(yǔ)言，另一方面，前面也說(shuō)過(guò)，Android是為移動(dòng)互聯(lián)而生的，兩者達(dá)到了完美的契合。

如何成為android高手？？？（備用）