前言

设计、编码、测试是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应用开发工程师提高设计和测试能力，开启通往高级工程师、架构师之路。

王家林