前言

設計、編碼、測試是Android項目實施的三個黃金階段。

Android應用開發人員如何提升功力，從而成功地成為高級工程師或者架構師呢？

這是任何一個渴望提升Android應用的開發人員都很關心的問題。

那么，您精通UML嗎？您精通設計原則和設計模式嗎？您精通Android的測試驅動開發嗎？

UML和設計原則、設計模式是成為架構師的必備基本功，某種程度上來說，一個Android應用開發工程師如果開始學習UML和設計原則、設計模式，就已經表明他想成為一位架構師了。Android測試驅動開發可以極大地推動他成為Android高級工程師，他編寫的代碼將更加有效、精確、強壯，將更利于您的團隊協作。

本書即是為滿足Android開發人員上述渴求而著的。

1）上篇對UML在Android開發過程中的應用進行了細致的分析

UML是面向對象分析與設計時的行業標準，在談面向對象的分析、設計時就不能不談UML。

解讀Android的最佳指導思想就是面向對象思想，無論是應用程序框架還是HAL，都是在面向對象思想的指導下來實施的。

Android的產品開發已經有四年多的時間，在這四年多的時間里，全球的各大廠商和工程師全力投入，創造出了無數多姿多彩的產品和應用程序。然而遺憾的是，一直以來，Android產品開發（尤其是應用程序的開發）的混亂是眾所周知的，現在是要改變的時候了。

Google已經為改變而做出了重大行動，尤其是Android 4.0的推出，制定了很多產品和程序開發的標準。對軟件工程師而言，使用UML規范整個程序的開發，是最佳的選擇。

本書上篇以一個重量級的案例——Android多線程斷點續傳下載器為例，細致剖析了每一個細節，讀者稍加改造即可做出Android平臺上的文件下載器。書中以Android多線程斷點續傳下載器為例，細致入微地講解了UML的9種圖（Diagram）：用例圖、類圖、對象圖、組件圖、部署圖、時序圖、協作圖、狀態圖、活動圖。

對上述9種Diagram細致的學習，可使讀者在分析、設計、開發Android程序時如虎添翼，游刃有余。

2）中篇的核心在于設計原則和設計模式

歷史已經證明：Android是一個“氣象萬千”的開放式系統。就技術角度而言，對模式淋漓盡致的應用無疑是其內在的最為重要的原因之一。

Alexander在《建筑的永恒之道》中給出的模式的經典定義是：每個模式都描述了一個在我們的環境中不斷出現的問題，并描述了該問題的解決方案的核心。通過這種方式，你可以無數次地使用那些已有的解決方案，無須再重復相同的工作。

從一般意義上講，模式包括架構模式、設計模式、編碼模式或者語言慣例。

何謂設計模式？設計模式是在某種情境下，針對某種問題的典型、通用的解決方案。這里的關鍵詞如下。

● 情境：在特定情境下反復出現的情況，要求使用模式必須分析清楚事實；

● 問題：一般來說，就是你要實現目標或要解決的目標；

● 解決方案：典型的、通用的解決方案，應是引人深思和舉一反三的解決方案。

設計模式是被發現的，不是被創造的。

設計模式來自哪里？當然是來自人類和宇宙相互的作用。它是人類長期為追求更加美好的生活而獲得的經驗和智慧的結晶。

其實，模式理論的基本思想起源于中國。每一個炎黃子孫的身體里都流淌著模式的血液。模式充斥于中國歷史和現實生活中各個方面，無孔不入！

《孫子兵法》中到處都是模式，當然也包括設計原則。“置之死地而后生”就是其中的一種模式，三十六計中的“美人計”、“欲擒故縱”都是模式。現在這些模式都成了古今中外各行各業研究學習的對象。據說美軍攻打伊拉克的時候就使用了《孫子兵法》中的很多戰爭模式。

醫學中也是如此，如扁鵲的“望聞問切”。望，指觀氣色；聞，指聽聲息；問，指詢問癥狀；切，指摸脈象——合稱“四診”。“望聞問切”是中醫看病的一般步驟。這是不是很像模板模式呢？

當然諸多模式也可以聯手，開發中如日中天的MVC模式就是設計模式聯合優化的一種模式。當然，準確地說，MVC不能說是設計模式，因為MVC劃分的維度過大，MVC屬于架構模式。

在模式中，在一些比較重要的場合或者一個比較重量級的書中，你可能時不時地聽到“力”這個關鍵字，不要被“力”搞糊涂了！按照筆者的理解，“力”是實現目標的約束條件，這種約束條件可能把你帶向光明的一面——實現目標，也可能帶入痛苦的深淵——遠離目標。

其實每一種事物都是在各種力的相互作用下存在和發展或者毀滅的。正如地球的外貌是各種相互作用的結果一樣，軟件分析、設計、開發、測試及維護的各個階段也都是各種力相互平衡的結果。

Android就是一個淋漓盡致地應用了各種模式的系統，如Facade Pattern、監聽器模式、適配器模式、單例模式、代理模式，等等；正是由于這些模式的應用，為Android增添了無限的風韻，也支撐了Android自身的開放性。

3）下篇對Android開發中的測試問題進行了詳細的闡述

JUnit的口號：Keep the bar green to keep the code clean。

（1）單元測試只是證明你沒有錯，但并不能夠證明你是對的；

（2）要想最大程度地證明你是對的，必須精心設計和編寫測試用例（Test Case），尤其要注意測試時的邊界值和特殊情況等；

（3）單元測試主要用來判斷程序執行的結果與預期的結果是否一致；

（4）單元測試不能夠改變源代碼。

任何規模稍大的公司，它在軟件部門都至少會有兩個至關重要的子部門：

● 軟件開發部門；

● 軟件測試部門。

一般而言，開發和測試是由不同的人負責的，這是傳統意義上的測試。隨著測試驅動開發理念的發展和普及，尤其是敏捷思想的風靡，測試的重要性日益增長。在測試驅動開發的實踐中，先由軟件開發工程師編寫好測試代碼，然后才編寫真正的實現代碼。

由上面的內容可知，測試是何等的重要！

對測試還不了解的朋友可能會感覺非常奇怪：為什么是先編寫好測試代碼，然后才編寫真正的代碼呢？一般情況下不是先編寫好代碼，然后才對代碼進行測試的嗎？如果連代碼都沒有編寫，那測試什么呢？

答案：此處的測試主要指以單元測試為基礎的測試。

單元測試是需要軟件開發部門去完成的，而不是測試部門。

在開發軟件的時候，我們通常都是多人協作去完成一個項目。既然是多人協作，就必然涉及分工，具體到每個人會完成該項目的不同部分，而且部分和部分之間會有交互關系，一個工程師要完成的部分可能需要另外的工程師提供的代碼服務。

基于協作的團隊工作，就提出一個要求：如何確保我提交給其他工程師的代碼是正確的？

答案：單元測試。

對，在把自己的代碼提交給項目組的其他人之前，必須編寫單元測試，來測試自己所提供的接口和功能的正確性。

單元測試的另外一個好處：這是最好的代碼使用說明書。

本書代碼包可在電子工業出版社官網（www.phei.com.cn）下載，也可通過微盤進行下載（關注http://weibo.com/pheicombook，進入微盤下載。）掃描封面二維碼，即可進入相關網址。

希望本書可以幫助Android應用開發工程師提高設計和測試能力，開啟通往高級工程師、架構師之路。

王家林