Android: Android 设计思想

设计思想
学习如何在一个新的 API 上创建应用的过程都是类似的，即便平台本身存在很大差异
性。通常，有两个步骤：首先，你学习如何使用 API 来做你想做的事情 ; 然后，你学习平台
的细微差别 。 还句话说 ， 你首先要学习如何才能够构建应用 ， 然后再学习应该如何来构建它
们。
第二个步骤 —— 学习如何正确构建应用 —— 通常需要花费更长的时间 ， 并且通常意味着
犯错误并从错误中学习 。 那不是一个高效率的过程 ， 所以本页和下面的链接就是立足于为你
提供相关帮助。
在我们开始之前，还要简短说几句。成功地应用会提供出色的终端用户体验。尽 管
Androi d 团队已经构造了一个强健的内核系统 ， 但用户更多的体验是来自于与你应用的交互 。
因此，我们鼓励你花时间来构造出色的用户体验。
出色的用户体验有三个特征：速度快 ; 响应及时以及无缝。当然从早期计算机到现在的
计算机 ， 每个平台都曾不只一次地引用过这三个特征 。 然而 ， 每个平台实现它们的方法不同 ;
下面的信息解释了你的应用如何能够在 Android 上实现这些特征。
速度快
Android 应用应该是快速的 。 更准确的说他应该是高效的 。 现在 ， 在计算界中有一个趋
势，该趋势假设摩尔定律可以最终解决所有问题。然而对于嵌入式应用而言， Moor 定律会
变得有些复杂。
摩尔定律没有如同应用于桌面和服务器应用一样真正地应用于移动设备 。 摩尔定律实际
上是关于晶体管密度的定律 ， 它是说每隔一段时间后 ， 你可以在给定的芯片上部署更多电路 。
对于转面和服务器应用而言 ， 由于性能的提高 ， 这意味着你可以在一块差不多大小的芯片中
得到更高的速度 。 对于类似手机这样的嵌入式应用而言 ， 摩尔定律通常被用于造出更小的芯
片 。 在嵌入式界的趋势是利用这种晶体管密度的增加来造出更小 、 更节能的芯片 ， 从而使手
机更小 ， 电池待机时间更长 。 象手机这样的嵌入式设备在不断增加 ， 速度远远要慢于桌面系
统。对于嵌入式设备而言，摩尔定律意味着更多特性和更好的电池寿命 ; 而速度则是次要因
素。
这就是为什么需要写高效的代码 ： 你不能假设手机与桌面系统和服务器一样提速 。 一般
来讲 ， 写快速的代码意味着要是内存分配最小化 ， 代码紧凑 ， 并且避免可能影响性能的语言
和编程习惯 。 在面向对象的术语中 ， 很多类似情况都是发生在方法级 ， 关于实际的代码顺序 ，
循环等。
关于如何写高效的 Android 代码的文章将会给你提供写快速 、 高效 Android 代码的所有
信息。
编写高效的 Android 代码
虽然如此说 ， 但似乎并没有什么好的办法 ： Android 设备是嵌入式设备 。 现代的手持设
备 ， 与其说是电话 ， 更像一台拿在手中的电脑 。 但是 ， 即使是 “ 最快 ” 的手持设备 ， 其性能也
赶不上一台普通的台式电脑。
这就是为什么我们在书写 Android 应用程序的时候要格外关注效率 。 这些设备并没有那
么快 ， 并且受电池电量的制约 。 这意味着 ， 设备没有更多的能力 ， 我们必须把程序写的尽量有效。
本章讨论了很多能让开发者使他们的程序运行更有效的方法 ， 遵照这些方法 ， 你可以使
你的程序发挥最大的效力。
简介
对于占用资源的系统，有两条基本原则：
不要做不必要的事
不要分配不必要的内存
所有下面的内容都遵照这两个原则。
有些人可能马上会跳出来，把本节的大部分内容归于 “ 草率的优化 ” (xing: 参见 [The Root
of All Evil]) ，不可否认微优化 (micro-optimization 。 xing: 代码优化，相对于结构优化 ) 的确会
带来很多问题，诸如无法使用更有效的数据结构和算法。但是在手持设备上，你别无选择 。
假如你认为 Android 虚拟机的性能与台式机相当 ， 你的程序很有可能一开始就占用了系统的
全部内存 (xing: 内存很小 ) ，这会让你的程序慢得像蜗牛一样，更遑论做其他的操作了。
Android 的成功依赖于你的程序提供的用户体验 。 而这种用户体验 ， 部分依赖于你的程
序是响应快速而灵活的 ， 还是响应缓慢而僵化的 。 因为所有的程序都运行在同一个设备之上 ，
都在一起 ， 这就如果在同一条路上行驶的汽车 。 而这篇文档就相当于你在取得驾照之前必须
要学习的交通规则 。 如果大家都按照这些规则去做 ， 驾驶就会很顺畅 ， 但是如果你不这样做 ，
你可能会车毁人亡。这就是为什么这些原则十分重要。
当我们开门见山 、 直击主题之前 ， 还必须要提醒大家一点 ： 不管 VM 是否支持实时 (JIT)
编译器 (xing: 它允许实时地将 Java 解释型程序自动编译成本机机器语言 ， 以使程序执行的速
度更快 。 有些 JVM 包含 JIT 编译器 。 ) ， 下面提到的这些原则都是成立的 。 假如我们有目标
完全相同的两个方法 ， 在解释执行时 foo() 比 bar() 快 ， 那么编译之后 ， foo() 依然会比 bar() 快 。
所以不要寄希望于编译器可以拯救你的程序。
避免建立对象
世界上没有免费的对象 。 虽然 GC 为每个线程都建立了临时对象池 ， 可以使创建对象的
代价变得小一些，但是分配内存永远都比不分配内存的代价大。
如果你在用户界面循环中分配对象内存，就会引发周期性的垃圾回收，用户就会觉
得界面像打嗝一样一顿一顿的。
所以，除非必要，应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则：
当你从用户输入的数据中截取一段字符串时，尽量使用 substring 函数取得原始数据的
一个子串 ， 而不是为子串另外建立一份拷贝 。 这样你就有一个新的 String 对象 ， 它与原始数
据共享一个 char 数组。
如果你有一个函数返回一个 String 对象，而你确切的知道这个字符串会被附加到一 个
StringBuffer ， 那么 ， 请改变这个函数的参数和实现方式 ， 直接把结果附加到 StringBuffer 中 ，
而不要再建立一个短命的临时对象。一个更极端的例子是，把多维数组分成多个一维数组。
int 数组比 Integer 数组好，这也概括了一个基本事实，两个平行的 int 数组比 (int,int) 对
象数组性能要好很多。同理，这试用于所有基本类型的组合。
如果你想用一种容器存储 (Foo,Bar) 元组，尝试使用两个单独的 Foo[] 数组和 Bar[] 数组 ，
一定比 (Foo,Bar) 数组效率更高。 ( 也有例外的情况，就是当你建立一个 API ，让别人调用它
的时候。这时候你要注重对 API 借口的设计而牺牲一点儿速度。当然在 API 的内部，你仍
要尽可能的提高代码的效率 )
总体来说 ， 就是避免创建短命的临时对象 。 减少对象的创建就能减少垃圾收集 ， 进而减
少对用户体验的影响。
使用本地方法
当你在处理字串的时候，不要吝惜使用 String.indexOf(), String.lastIndexOf() 等特殊实现
的方法 (specialty methods) 。 这些方法都是使用 C/C++ 实现的 ， 比起 Java 循环快 10 到 100 倍 。
使用实类比接口好
假设你有一个 HashMap 对象，你可以将它声明为 HashMap 或者 Map:
Map myMap1 = new HashMap();
HashMap myMap2 = new HashMap();
哪个更好呢 ?
按照传统的观点 Map 会更好些，因为这样你可以改变他的具体实现类，只要这个类继
承自 Map 接口。传统的观点对于传统的程序是正确的，但是它并不适合嵌入式系统。调用
一个接口的引用会比调用实体类的引用多花费一倍的时间。
如果 HashMap 完全适合你的程序 ， 那么使用 Map 就没有什么价值 。 如果有些地方你不
能确定 ， 先避免使用 Map ， 剩下的交给 IDE 提供的重构功能好了 。 ( 当然公共 API 是一个例
外：一个好的 API 常常会牺牲一些性能 )
用静态方法比虚方法好
如果你不需要访问一个对象的成员变量 ， 那么请把方法声明成 static 。 虚方法执行的
更快 ， 因为它可以被直接调用而不需要一个虚函数表 。 另外你也可以通过声明体现出这个函
数的调用不会改变对象的状态。
不用 getter 和 setter
在很多本地语言如 C++ 中 ， 都会使用 getter( 比如 ： i = getCount()) 来避免直接访问成员变
量 (i = mCount) 。在 C++ 中这是一个非常好的习惯，因为编译器能够内联访问，如果你需要
约束或调试变量，你可以在任何时候添加代码。
在 Android 上 ， 这就不是个好主意了 。 虚方法的开销比直接访问成员变量大得多 。 在通
用的接口定义中 ， 可以依照 OO 的方式定义 getters 和 setters ， 但是在一般的类中 ， 你应该直
接访问变量。将成员变量缓存到本地
访问成员变量比访问本地变量慢得多，下面一段代码：
Java 代码：
1 for (int i = 0; i< this.mCount; i++) dumpItem(this.mItems[i]);
2 再好改成这样：
3 int count = this.mCount;
4 Item[] items = this.mItems;
5 for (int i = 0; i< count; i++) dumpItems(items[i]);
6 ( 使用 ” this ” 是为了表明这些是成员变量 )
另一个相似的原则是：永远不要在 for 的第二个条件中调用任何方法。如下面方法
所示，在每次循环的时候都会调用 getCount() 方法，这样做比你在一个 int 先把结果保存起
来开销大很多。
Java 代码：
7 for (int i = 0; i< this.getCount(); i++)
8 8 8 8 dumpItems(this.getItem(i));
同样如果你要多次访问一个变量，也最好先为它建立一个本地变量，例如：
Java 代码：
9 protected void drawHorizontalScrollBar(Canvas canvas, int width, int height) {
10 if (isHorizontalScrollBarEnabled()) {
11 int size = mScrollBar.getSize(false);
12 if (size<= 0) {
13 size = mScrollBarSize;
14 }
15 mScrollBar.setBounds(0, height ? size, width, height);
16 mScrollBar.setParams(computeHorizontalScrollRange(),computeHorizontalScrollOffset(),
17 computeHorizontalScrollExtent(), false);
18 mScrollBar.draw(canvas);
19 }
20 }
这里有 4 次访问成员变量 mScrollBar ，如果将它缓存到本地， 4 次成员变量访问就会
变成 4 次效率更高的栈变量访问。
另外就是方法的参数与本地变量的效率相同。
使用常量
让我们来看看这两段在类前面的声明：
Java 代码：
21 static int intVal = 42;
22 static String strVal = “ Hello, world! ” ;必以其会生成一个叫做的初始化类的方法，当类第一次被使用的时候这个方法会被执
行。方法会将 42 赋给 intVal ，然后把一个指向类中常量表的引用赋给 strVal 。当以后要用到
这些值的时候，会在成员变量表中查找到他们。下面我们做些改进，使用 “ final ” 关键字：
Java 代码：
23 static final int intVal = 42;
24 static final String strVal = “ Hello, world! ” ;
现在，类不再需要方法，因为在成员变量初始化的时候，会将常量直接保存到类文件
中 。 用到 intVal 的代码被直接替换成 42 ， 而使用 strVal 的会指向一个字符串常量 ， 而不是使
用成员变量。
将一个方法或类声明为 ” final ” 不会带来性能的提升 ， 但是会帮助编译器优化代码 。 举例
说，如果编译器知道一个 ” getter ” 方法不会被重载，那么编译器会对其采用内联调用。
你也可以将本地变量声明为 ” final ” ，同样，这也不会带来性能的提升。使用 ” final ” 只能
使本地变量看起来更清晰些 ( 但是也有些时候这是必须的，比如在使用匿名内部类的时
候 )(xing: 原文是 or you have to, e.g. for use in an anonymous inner class)
谨慎使用 foreach
foreach 可以用在实现了 Iterable 接口的集合类型上。 foreach 会给这些对象分配一 个
iterator ， 然后调用 hasNext() 和 next() 方法 。 你最好使用 foreach 处理 ArrayList 对象 ， 但是对
其他集合对象， foreach 相当于使用 iterator 。
下面展示了 foreach 一种可接受的用法：
Java 代码：
25 public class Foo {
26 int mSplat;
27 static Foo mArray[] = new Foo[27];
28 public static void zero() {
29 int sum = 0;
30 for (int i = 0; i< mArray.length; i++) {
31 sum += mArray[i].mSplat;
32 }
33 }
34 public static void one() {
35 int sum = 0;
36 Foo[] localArray = mArray;
37 int len = localArray.length;
38 for (int i = 0; i
39 sum += localArray[i].mSplat;
40 }
41 }
42 public static void two() {
43 int sum = 0;44 for (Foo a: mArray) {
45 sum += a.mSplat;
46 }
47 }
48 }
在 zero() 中 ， 每次循环都会访问两次静态成员变量 ， 取得一次数组的长度 。 retrieves the static
field twice and gets the array length once for every iteration through the loop.
在 one() 中，将所有成员变量存储到本地变量。 pulls everything out into local variables,
avoiding the lookups.
two() 使用了在 java1.5 中引入的 foreach 语法。编译器会将对数组的引用和数组的长度
保存到本地变量中 ， 这对访问数组元素非常好 。 但是编译器还会在每次循环中产生一个额外
的对本地变量的存储操作 ( 对变量 a 的存取 ) 这样会比 one() 多出 4 个字节，速度要稍微慢一
综上所述 ： foreach 语法在运用于 array 时性能很好 ， 但是运用于其他集合对象时要小心 ，
因为它会产生额外的对象。
避免使用枚举
枚举变量非常方便，但不幸的是它会牺牲执行的速度和并大幅增加文件体积。例如：
Java 代码：
1 public class Foo {
2 public enum Shrubbery {
3 GROUND, CRAWLING, HANGING
4 }
5 }
会产生一个 900 字节的 .class 文件 (Foo$Shubbery.class) 。 在它被首次调用时 ， 这个类会调
用初始化方法来准备每个枚举变量。每个枚举项都会被声明成一个静态变量，并被赋值 。 然
后将这些静态变量放在一个名为 ” $VALUES ” 的静态数组变量中。而这么一大堆代码，仅仅
是为了使用三个整数。
这样 :
Shrubbery shrub = Shrubbery.GROUND; 会引起一个对静态变量的引用 ， 如果这个静态变
量是 final int ，那么编译器会直接内联这个常数。
一方面说，使用枚举变量可以让你的 API 更出色，并能提供编译时的检查。所以在通
常的时候你毫无疑问应该为公共 API 选择枚举变量。但是当性能方面有所限制的时候，你
就应该避免这种做法了。
有些情况下，使用 ordinal() 方法获取枚举变量的整数值会更好一些，举例来说，将：
Java 代码：
6 for (int n = 0; n< list.size(); n++) {
7 if (list.items[n].e == MyEnum.VAL_X)
8 else if (list.items[n].e == MyEnum.VAL_Y)
9 }10 // 替换为 :
11 int valX = MyEnum.VAL_X.ordinal();
12 int valY = MyEnum.VAL_Y.ordinal();
13 int count = list.size();
14 MyItem items = list.items();
15 for (int n = 0; n< count; n++){
16 int valItem = items[n].e.ordinal();
17 if (valItem == valX)
18 else if (valItem == valY)
19 }
会使性能得到一些改善 ， 但这并不是最终的解决之道 。 将与内部类一同使用的变量声明
在包范围内请看下面的类定义：
Java 代码：
20 public class Foo {
21 private int mValue;
22 public void run() {
23 Inner in = new Inner();
24 mValue = 27;
25 in.stuff();
26 }
27 private void doStuff(int value) {
28 System.out.println( ” Value is ” + value);
29 }
30 private class Inner {
31 void stuff() {
32 Foo.this.doStuff(Foo.this.mValue);
33 }
34 }
35353535 }
这其中的关键是 ， 我们定义了一个内部类 (Foo$Inner) ， 它需要访问外部类的私有域变量
和函数。这是合法的，并且会打印出我们希望的结果 ” Value is 27 ″ 。
问题是在技术上来讲 ( 在幕后 )Foo$Inner 是一个完全独立的类，它要直接访问 Foo 的私
有成员是非法的。要跨越这个鸿沟，编译器需要生成一组方法：
Java 代码：
36 /*package*/ static int Foo.access$100(Foo foo) {
37 return foo.mValue;
38 }
39
40 /*package*/ static void Foo.access$200(Foo foo, int value) {
41 foo.doStuff(value);
42 }内部类在每次访问 ” mValue ” 和 ” doStuff ” 方法时 ， 都会调用这些静态方法 。 就是说 ， 上面的
代码说明了一个问题，你是在通过接口方法访问这些成员变量和函数而不是直接调用它们 。
在前面我们已经说过，使用接口方法 (getter 、 setter) 比直接访问速度要慢。所以这个例子就
是在特定语法下面产生的一个 “ 隐性的 ” 性能障碍。
通过将内部类访问的变量和函数声明由私有范围改为包范围，我们可以避免这个问题 。
这样做可以让代码运行更快，并且避免产生额外的静态方法。 ( 遗憾的是，这些域和方法可
以被同一个包内的其他类直接访问，这与经典的 OO 原则相违背。因此当你设计公共 AP I
的时候应该谨慎使用这条优化原则 )
避免使用浮点数
在奔腾 CPU 出现之前，游戏设计者做得最多的就是整数运算。随着奔腾的到来，浮点
运算处理器成为了 CPU 内置的特性 ， 浮点和整数配合使用 ， 能够让你的游戏运行得更顺畅 。
通常在桌面电脑上，你可以随意的使用浮点运算。
但是非常遗憾，嵌入式处理器通常没有支持浮点运算的硬件，所有对 ” float ” 和 ” double ”
的运算都是通过软件实现的。一些基本的浮点运算，甚至需要毫秒级的时间才能完成。
甚至是整数 ， 一些芯片有对乘法的硬件支持而缺少对除法的支持 。 这种情况下 ， 整数的
除法和取模运算也是有软件来完成的 。 所以当你在使用哈希表或者做大量数学运算时一定要
小心谨慎。
一些关于性能的数据
为了说明我们的观点 ， 我们列了一个表格 ， 指明一些基本操作所用的时间 。 这些时间并
不是绝对值，而是 CPU 时间和时钟时间的混合体，随着系统的提升，运行时间肯定会缩短
的 。 但是我们需要注意这些值之间的比例 ， 比如增加一个成员变量会比增加一个本地变量多
花费四倍的时间。
结束语
要为嵌入式系统编写优雅高效的代码最根本的是要明白你的这些代码究竟要做什么 。 如
果你真的想分配一个 iterator ， 那么就对 List 使用 foreach 好了 。 它是你的选择而不是什么无
心之过。
有备则无患 。 知道你想要做什么 。 倾注你最大的热情 ， 清楚的了解你的代码 ， 然后尽力
让它跑得更快。
响应及时
你可以写出通过世界上所有性能测试的代码，但是当用户使用它时还是会感到恼火 。 这
就是那些无法及时响应的应用 —— 在特定阶段它们会变慢、挂起乃至冻结，或者需要用户
等太久才来处理输入 。 在 Android 的术语中 ， 不能及时响应的应用会频繁地导致系统弹出 “ 应
用没有响应 ” (ANR) 消息。
通常 ， 这种情况发生在你的应用无法响应用户输入时 。 例如 ， 如果你的应用在一些 I/ O
操作上阻塞了 ( 通常是网络访问 ) ， 那么应用主线程就无法处理用户的输入事件 。 一段时间以
后 ， 系统会判定你的应用挂起了 ， 并且可以让用户终止它 。 类似地 ， 如果你的应用在构建一
个内存结构或者在计算下一步如何走时花费了太长时间，那么系统也会判定你的程序挂起
了 。 确认计算过程才用了提高效率的技巧是十分重要的 ， 尽管如此 ， 在高效的代码也是需要
花时间来运行的。在这两个例子中 ， 修补方法通常是创建一个子线程 ， 在那里做大部分的工作 。 这能保持
主线程 ( 驱动用户界面抡询的进程 ) 运行 ， 并且防止系统认为你的代码冻结了 。 由于这种线程
通常在 class 以及完成，你可以把响应问题作为一个 class 问题。 ( 这一点主要是与基本性能
的对比，基本性能主要与方法层面有关 )
关于如何构造快速响应的 Android 应用的文章对此作了更详细的描述。
构造快速响应的 Android Android Android Android 应用
本文中 ， 我们将讨论 Android 如何判断程序没有响应的情况 ( 以下被称作 ANR) ， AN R
产生的原因，以及确保你的程序能够快速响应的几条准则。这里有一些很好的实践 ? 有助于
书写快速响应的 Android 代码 ? 能够帮助你建立款速响应的用户界面。
“ 好 ” 程序也会变成 “ 坏 ” 程序
在 Android 中，活动管理器和窗口管理器这两个系统服务负责监视应用程序的响应 。 当
出现下列情况时， Android 就会显示 ANR 对话框了：
对输入事件 ( ( ( ( 如按键、触摸屏事件 ) ) ) ) 的响应超过 5 5 5 5 秒
意向接受器 (intentReceiver) (intentReceiver) (intentReceiver) (intentReceiver) 超过 10101010 秒钟仍未执行完毕
如何避免 ANR ANR ANR ANR
基于以上对 ANR 的定义，让我们来探寻一下产生 ANR 的原因，以及如何架构你的程
序以力求避免 ANR 的发生。
通常情况下 ， Android 应用程序完全运行在一个独立的线程中 ( 例如 main) 。 这就意味着 ，
任何在主线程中运行的，需要消耗大量时间的操作都会引发 ANR 。因为此时，你的应用程
序已经没有机会去响应输入事件和意向广播 (Intent broadcast) 。
因此 ， 任何运行在主线程中的方法 ， 都要尽可能的只做少量的工作 。 特别是活动生命周
期中的重要方法如 onCreate() 和 onResume() 等更应如此 。 潜在的比较耗时的操作 ， 如访问网
络和数据库 ; 或者是开销很大的计算，比如改变位图的大小，需要在一个单独的子线程中完
成 ( 或者是使用异步请求 ， 如数据库操作 ) 。 但这并不意味着你的主线程需要进入阻塞状态已
等待子线程结束 — 也不需要调用 Therad.wait() 或者 Thread.sleep() 方法。取而代之的是 ， 主
线程为子线程提供一个句柄 (Handler) ，让子线程在即将结束的时候调用它 (xing: 可以参 看
Snake 的例子，这种方法与以前我们所接触的有所不同 ) 。使用这种方法涉及你的应用程序 ，
能够保证你的程序对输入保持良好的响应，从而避免因为输入事件超过 5 秒钟不被处理而产
生的 ANR 。这种实践需要应用到所有显示用户界面的线程，因为他们都面临着同样的超时
问题。
IntentReciever 在这方面有特殊的要求。它强调在执行期间，它只在后台完成很小的、
细粒度的操作如保存一个设置或注册一个通知。所以如果其他在主线程中被调用的方法一
样， IntentReciever 也需要避免进行耗时的操作和计算。但与前面使用子线程的方法不同 ( 因
为 IntentReceiver 的生命周期很短 xing: 子线程没结束它就结束了，就无法回调句柄了 ) 。如
果在接受一个意向广播 (Intent broadcast) 。的时候会产生潜在的耗时操作，你需要为此启动
一个服务。顺便提醒一下，你也应该避免在意向接受器 (Intent Reciever) 中开始一个活动 ， 因
为这样会产生一个新的界面，夺取了正在运行的程序的焦点。如果你想在响应意向广播(Intent broadcast) 。的时候向客户显示一些东西，那么就用通知管理器吧。
进一步提高响应性
一般情况下 ， 100 到 200 毫秒是程序响应时间的阀值 ， 超过了这个阀值使用者就会感到程
序有延迟 。 因此 ， 除了你需要避免产生 ANR 之外 ， 还有几条建议能够使你的程序对用户的
响应性更好。
如果你的程序在后台处理用户的输入 ， 给出一个你正在工作的提示 (ProgressBar( 进度条 )
和 ProgressDialog( 进度对话框 ) 是很好的选择 )
如果是游戏，把计算步骤放在子线程中
如果你的程序在开始的时候要进行一系列的初始化活动 ， 最好显示一个闪现窗体 (splash
screen) 或者尽可能的先快速渲染主界面 ， 然后再通过异步的方式填充里面的内容 。 无论用哪
种方法，你都要标示出目前正在执行哪些过程，以免用户以为程序已经卡死了。
无缝
即便你的应用速度快并且响应及时 ， 它还可能会惹恼用户 。 一个一般的例子就是在响应
一些时间时弹出 UI 的背景进程 ( 比如 Android Service 或者 IntentReceiver) 。这开起来好像无
害 ， 程序员通常认为他们花了大量的实际测试和使用自己的应用 ， 感觉还不错 。 然而 ， Androi d
应用模型是明确地为用户在不同进程中任意切换而构造的 。 这意味着 ， 当你的背景进程弹 出
UI 时 ， 用户可能正在系统其他部分中 ， 做着其他的事情 —— 比如接电话 。 设想一下如果 SM S
服务每次收到一个消息时都弹出对话框 ， 马上就会惹恼用户 。 这就是为什么 Android 标准对
这种事件使用 Notification; 这样就可以让用户来控制。
这只是一个例子 ， 还有很多例子 。 例如 ， 如果 Activities 没有在 onPause() 或其他方法中
正确实现，就会经常导致数据丢失。或者，如果你的应用要把数据暴露给其他应用使用 ， 你
应该通过 ContentProvider ，而不是直接使用全局刻度的原始文件或者数据库。
这写例子的共同之处在于 ， 它们都涉及与系统和其他应用的友好协作 。 Android 系统涉
及为将应用看作松散耦合的组件联盟 ， 而不是一堆黑箱代码 。 这允许作为开发者的你把整个
系统看作是更大的组件联盟 。 这可以允许你整洁 、 无缝地将你的应用于其他应用集成 ， 并且
作为这种好处的回报，你可以自己设计代码。