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

沒搞錯(cuò)吧？竟然讓程序開發(fā)人員學(xué)會(huì)懶惰？程序開發(fā)人員可能是世界上最為忙碌的一類人啦！對(duì)，沒錯(cuò)，學(xué)會(huì)懶惰！正因?yàn)槌绦蜷_發(fā)人員忙碌，正因?yàn)槌绦蜷_發(fā)人員可能會(huì)在客戶無限變化的需求之下沒日沒夜的加班，所以要學(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ó)家的一句諺語，原話是：Don’t?Reinvent?the?Wheel。“不要重復(fù)發(fā)明輪子?”意思是企業(yè)中任何一項(xiàng)工作實(shí)際上都有人做過，我們所需要做的就是找到做過這件事情的人。拿到軟件領(lǐng)域中就是指有的項(xiàng)目或功能，別人已經(jīng)做過，我們需要用的時(shí)候，直接拿來用即可，而不要重新制造。

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

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ù)并開發(fā)、封裝了新的功能的和框架的OMS，這是Android中發(fā)明輪子的一個(gè)非常重要的例子。可能你會(huì)說，這發(fā)明輪子也太難了吧，別急，我們慢慢來，開發(fā)一個(gè)框架特定領(lǐng)域的框架吧！你可能會(huì)一臉無辜的說，開發(fā)一個(gè)框架是說的那么容易嗎？當(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ì)來找你的）。我們下面就自己發(fā)明一個(gè)輪子的模型，實(shí)際展示一個(gè)框架最初核心的類，讓你一飽眼福：

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

1，請(qǐng)看某個(gè)著名的IT公司一則招聘信息的其中一條要求：“熟悉Android系統(tǒng)架構(gòu)及相關(guān)技術(shù)，1年以上實(shí)際Android平臺(tái)開發(fā)經(jīng)驗(yàn)；”，里面非常明確的說道要求熟練Android系統(tǒng)架構(gòu)，這從某種程度上說明了對(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ù)都是開放源代碼的函數(shù)庫(kù)，例如WebKit，該函數(shù)庫(kù)負(fù)責(zé)Android網(wǎng)頁瀏覽器的運(yùn)行，例如標(biāo)準(zhǔn)的C函數(shù)庫(kù)Libc、OpenSSL、SQLite等，當(dāng)然也包括支持游戲開發(fā)2D?SGL和3D?OpenGL?|?ES，在多媒體方面有MediaFramework框架來支持各種影音和圖形文件的播放與顯示，例如MPEG4、H.264、MP3、AAC、AMR、JPG和PNG等眾多的多媒體文件格式。Android的Runtime負(fù)責(zé)解釋和執(zhí)行生成的Dalvik格式的字節(jié)碼。

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

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

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

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

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

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

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

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中寫代碼，要通過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))

毫無疑問，Android的之所以能夠成為一個(gè)開放的氣象萬千的系統(tǒng)，與設(shè)計(jì)模式的精妙應(yīng)用是分不開的，只要你稍微用心觀察，就會(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ì)象的接口,但是卻讓子類來決定具體實(shí)例化哪一個(gè)類.當(dāng)一個(gè)類無法預(yù)料要?jiǎng)?chuàng)建哪種類的對(duì)象或是一個(gè)類需要由子類來指定創(chuàng)建的對(duì)象時(shí)我們就需要用到Factory Method 模式了.簡(jiǎn)單說來,Factory Method可以根據(jù)不同的條件產(chǎn)生不同的實(shí)例,當(dāng)然這些不同的實(shí)例通常是屬于相同的類型,具有共同的父 類.Factory Method把創(chuàng)建這些實(shí)例的具體過程封裝起來了,簡(jiǎn)化了客戶端的應(yīng)用,也改善了程序的擴(kuò)展性,使得將來可以做最小的改動(dòng)就可以加入新的待創(chuàng)建的類. 通常我們將Factory Method作為一種標(biāo)準(zhǔn)的創(chuàng)建對(duì)象的方法,當(dāng)發(fā)現(xiàn)需要更多的靈活性的時(shí)候,就開始考慮向其它創(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è)接口，而且無需指定它們的具體類。大致意思是說：我們?cè)趧?chuàng)建這些對(duì)象的時(shí)候，并不需要指定它們的具體類，這些具體類的對(duì)象是由工廠對(duì)象負(fù)責(zé)實(shí)例化的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在程序運(yùn)行過程中，某些對(duì)象的狀態(tài)處在轉(zhuǎn)換過程中，可能由于某種原因需要保存此時(shí)對(duì)象的狀態(tài)，以便程序運(yùn)行到某個(gè)特定階段，需要恢復(fù)到對(duì)象之前處于某個(gè)點(diǎn)時(shí)的狀態(tài)。如果使用一些公有接口讓其它對(duì)象來得到對(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)型模式，它主要解決的問題是：組件的客戶和組件中各種復(fù)雜的子系統(tǒng)有了過多的耦合，隨著外部客戶程序和各子系統(tǒng)的演化，這種過多的耦合面臨很多變化的挑戰(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)車輪，車輪變化成什么牌子的，我們要開走汽車所要做的還是踩下油門。

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

定義：用一個(gè)中介者對(duì)象來封裝一系列的對(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的過濾器采用的模式（過濾器是它們的核心機(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ì)接收者的接口一無所知。）這里，”請(qǐng)求”(request)這個(gè)術(shù)語指的是要被執(zhí)行的命令。Command模式還讓我們可以對(duì) “何時(shí)” 以及 “如何” 完成請(qǐng)求進(jìn)行改變。因此，Command模式為我們提供了靈活性和可擴(kuò)展性。

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

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

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

18. Prototype模式 （原型模式）

通過給出一個(gè)原型對(duì)象來指明所要?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è)訪問它的全局訪問點(diǎn)。

20. Visitor模式 : (訪問者模式)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

l 里氏代換原則（LSP） ：一個(gè)軟件實(shí)體如果使用的是一個(gè)基類的話，那么一定使用于其子類，而且它根本不能察覺出基類對(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ì)象通過向這些對(duì)象的委派達(dá)到復(fù)用已有功能的目的。簡(jiǎn)而言之就是：要盡量使用合成/聚合，盡量不要使用繼承。

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

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

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

四：高效的編寫高效的代碼

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

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

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

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

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

1.?不要做不必要的事

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

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

有些人可能馬上會(huì)跳出來，把本節(jié)的大部分內(nèi)容歸于“草率的優(yōu)化”（xing:參見[The?Root?of?All?Evil]），不可否認(rèn)微優(yōu)化（micro-optimization。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ī)器語言，以使程序執(zhí)行的速度更快。有些JVM包含JIT編譯器。），下面提到的這些原則都是成立的。假如我們有目標(biāo)完全相同的兩個(gè)方法，在解釋執(zhí)行時(shí)foo()比bar()快，那么編譯之后，foo()依然會(huì)比bar()快。所以不要寄希望于編譯器可以拯救你的程序。

避免建立對(duì)象

世界上沒有免費(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)對(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í)候，不要吝惜使用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就沒有什么價(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

在很多本地語言如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)該直接訪問變量。

將成員變量緩存到本地

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

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é)果保存起來開銷大很多。

Java代碼?

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

dumpItems(this.getItem(i));

同樣如果你要多次訪問一個(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次訪問成員變量mScrollBar，如果將它緩存到本地，4次成員變量訪問就會(huì)變成4次效率更高的棧變量訪問。

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

使用常量

讓我們來看看這兩段在類前面的聲明：

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ì)帶來性能的提升，但是會(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,?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ì)訪問兩次靜態(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語法。編譯器會(huì)將對(duì)數(shù)組的引用和數(shù)組的長(zhǎng)度保存到本地變量中，這對(duì)訪問數(shù)組元素非常好。但是編譯器還會(huì)在每次循環(huán)中產(chǎn)生一個(gè)額外的對(duì)本地變量的存儲(chǔ)操作（對(duì)變量a的存取）這樣會(huì)比one()多出4個(gè)字節(jié)，速度要稍微慢一些。
綜上所述：foreach語法在運(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)用初始化方法來準(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ù)。

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

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

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)，它需要訪問外部類的私有域變量和函數(shù)。這是合法的，并且會(huì)打印出我們希望的結(jié)果”Value?is?27″。

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

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

可能有朋友會(huì)問：學(xué)習(xí)Android應(yīng)用程序開發(fā)為什么還需要學(xué)習(xí)學(xué)會(huì)至少一門服務(wù)器端開發(fā)技術(shù)呢？答案如下：一方面Android號(hào)稱是首個(gè)為移動(dòng)終端打造的真正開放和完整的移動(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只是用于開發(fā)移動(dòng)終端軟件，而服務(wù)端技術(shù)用于開發(fā)互聯(lián)網(wǎng)絡(luò)應(yīng)用，所以未來移動(dòng)互聯(lián)網(wǎng)時(shí)代軟件的主流應(yīng)用模式將是“手機(jī)客戶端+互聯(lián)網(wǎng)絡(luò)應(yīng)用服務(wù)端”，這種模式要求做移動(dòng)互聯(lián)網(wǎng)開發(fā)的程序員不但要掌握像Android這樣的手機(jī)終端軟件技術(shù)還要掌握開發(fā)互聯(lián)網(wǎng)絡(luò)應(yīng)用的服務(wù)器端技術(shù)。目前，軟件企業(yè)普遍存在這樣的問題，做移動(dòng)互聯(lián)網(wǎng)開發(fā)Android終端軟件的程序員不了解web應(yīng)用技術(shù)，而做web應(yīng)用的程序員不了解移動(dòng)終端技術(shù)，這樣就導(dǎo)致了客戶端與服務(wù)端在銜接上出現(xià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的用意之一也是想開辟新的終端去使用Google的優(yōu)勢(shì)服務(wù)。

服務(wù)器端開發(fā)技術(shù)目前主流的有Sun的Java?EE、微軟的.NET，開源的以PHP和MySQL為代表的LAMP體系，我們?cè)撨x擇哪一種呢？從理論上講，很多人傾向于選擇Java?EE，畢竟它們都是使用Java作為開發(fā)語言的，但是很多人面對(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方面的主流語言，大多數(shù)新型的網(wǎng)站尤其是創(chuàng)業(yè)性質(zhì)的網(wǎng)站一般都會(huì)選用PHP作為服務(wù)端開發(fā)語言，另一方面，前面也說過，Android是為移動(dòng)互聯(lián)而生的，兩者達(dá)到了完美的契合。

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