[转]Android 设计思想

原文地址 http://www.cnmsdn.com/html/201006/1276745370ID6171_17.html

 

设计思想

　　一个声明解释一些对Android开发者有用的技术思想和观点。通过阅读这一页，你将了解如何写出在嵌入式设备(比如，手机)上性能良好，并且与系统其他部分协作出色的应用。

　　设计思想

　　学习如何在一个新的API上创建应用的过程都是类似的，即便平台本身存在很大差异性。通常，有两个步骤：首先，你学习如何使用API来做你想做的事情;然后，你学习平台的细微差别。还句话说，你首先要学习如何才能够构建应用，然后再学习应该如何来构建它们。

　　第二个步骤——学习如何正确构建应用——通常需要花费更长的时间，并且通常意味着犯错误并从错误中学习。那不是一个高效率的过程，所以本页和下面的链接就是立足于为你提供相关帮助。

　　在我们开始之前，还要简短说几句。成功地应用会提供出色的终端用户体验。尽管Android团队已经构造了一个强健的内核系统，但用户更多的体验是来自于与你应用的交互。因此，我们鼓励你花时间来构造出色的用户体验。

　　出色的用户体验有三个特征：速度快;响应及时以及无缝。当然从早期计算机到现在的计算机，每个平台都曾不只一次地引用过这三个特征。然而，每个平台实现它们的方法不同;下面的信息解释了你的应用如何能够在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，但是在一般的类中，你应该直接访问变量。

　　将成员变量缓存到本地

　　访问成员变量比访问本地变量慢得多，下面一段代码：

　　for (int i = 0; i

　　< this.mCount; i++) dumpItem(this.mItems[i]);

　　再好改成这样：

　　int count = this.mCount;

　　Item[] items = this.mItems;

　　for (int i = 0; i

　　< count; i++) dumpItems(items[i]);

　　(使用”this”是为了表明这些是成员变量)

　　另一个相似的原则是：永远不要在for的第二个条件中调用任何方法。如下面方法所示，在每次循环的时候都会调用getCount()方法，这样做比你在一个int先把结果保存起来开销大很多。

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

　　dumpItems(this.getItem(i));

　　同样如果你要多次访问一个变量，也最好先为它建立一个本地变量，例如：

　　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次成员变量访问就会变成4次效率更高的栈变量访问。

 

 

另外就是方法的参数与本地变量的效率相同。

　　使用常量

　　让我们来看看这两段在类前面的声明：

　　static int intVal = 42;

　　static String strVal = “Hello, world!”;

　　必以其会生成一个叫做的初始化类的方法，当类第一次被使用的时候这个方法会被执行。方法会将42赋给intVal，然后把一个指向类中常量表的引用赋给strVal。当以后要用到这些值的时候，会在成员变量表中查找到他们。下面我们做些改进，使用“final”关键字：

　　static final int intVal = 42;

　　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一种可接受的用法：

　　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

　　sum += localArray[i].mSplat;

　　}

　　}

　　public static void two() {

 

int sum = 0;

　　for (Foo a: mArray) {

　　sum += a.mSplat;

　　}

　　}

　　}

　　在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时性能很好，但是运用于其他集合对象时要小心，因为它会产生额外的对象。

　　避免使用枚举

　　枚举变量非常方便，但不幸的是它会牺牲执行的速度和并大幅增加文件体积。例如：

　　public class Foo {

　　public enum Shrubbery { GROUND, CRAWLING, HANGING }

　　}

　　会产生一个900字节的.class文件(Foo$Shubbery.class)。在它被首次调用时，这个类会调用初始化方法来准备每个枚举变量。每个枚举项都会被声明成一个静态变量，并被赋值。然后将这些静态变量放在一个名为”$VALUES”的静态数组变量中。而这么一大堆代码，仅仅是为了使用三个整数。

　　这样:

　　Shrubbery shrub = Shrubbery.GROUND;会引起一个对静态变量的引用，如果这个静态变量是final int，那么编译器会直接内联这个常数。

　　一方面说，使用枚举变量可以让你的API更出色，并能提供编译时的检查。所以在通常的时候你毫无疑问应该为公共API选择枚举变量。但是当性能方面有所限制的时候，你就应该避免这种做法了。

　　有些情况下，使用ordinal()方法获取枚举变量的整数值会更好一些，举例来说，将：

　　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

　　}

　　替换为:

　　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

　　}

　　会使性能得到一些改善，但这并不是最终的解决之道。

　　将与内部类一同使用的变量声明在包范围内

　　请看下面的类定义：

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

　　}

　　}

　　}

　　这其中的关键是，我们定义了一个内部类(Foo$Inner)，它需要访问外部类的私有域变量和函数。这是合法的，并且会打印出我们希望的结果”Value is 27″。

　　问题是在技术上来讲(在幕后)Foo$Inner是一个完全独立的类，它要直接访问Foo的私有成员是非法的。要跨越这个鸿沟，编译器需要生成一组方法：

　　/*package*/ static int Foo.access$100(Foo foo) {

　　return foo.mValue;

　　}

　　/*package*/ static void Foo.access$200(Foo foo, int value) {

　　foo.doStuff(value);

　　}

　　内部类在每次访问”mValue”和”doStuff”方法时，都会调用这些静态方法。就是说，上面的代码说明了一个问题，你是在通过接口方法访问这些成员变量和函数而不是直接调用它们。在前面我们已经说过，使用接口方法(getter、setter)比直接访问速度要慢。所以这个例子就是在特定语法下面产生的一个“隐性的”性能障碍。

　　通过将内部类访问的变量和函数声明由私有范围改为包范围，我们可以避免这个问题。这样做可以让代码运行更快，并且避免产生额外的静态方法。(遗憾的是，这些域和方法可以被同一个包内的其他类直接访问，这与经典的OO原则相违背。因此当你设计公共API的时候应该谨慎使用这条优化原则)

 

 

 

避免使用浮点数

　　在奔腾CPU出现之前，游戏设计者做得最多的就是整数运算。随着奔腾的到来，浮点运算处理器成为了CPU内置的特性，浮点和整数配合使用，能够让你的游戏运行得更顺畅。通常在桌面电脑上，你可以随意的使用浮点运算。

　　但是非常遗憾，嵌入式处理器通常没有支持浮点运算的硬件，所有对”float”和”double”的运算都是通过软件实现的。一些基本的浮点运算，甚至需要毫秒级的时间才能完成。

　　甚至是整数，一些芯片有对乘法的硬件支持而缺少对除法的支持。这种情况下，整数的除法和取模运算也是有软件来完成的。所以当你在使用哈希表或者做大量数学运算时一定要小心谨慎。

　　一些关于性能的数据

　　为了说明我们的观点，我们列了一个表格，指明一些基本操作所用的时间。这些时间并不是绝对值，而是CPU时间和时钟时间的混合体，随着系统的提升，运行时间肯定会缩短的。但是我们需要注意这些值之间的比例，比如增加一个成员变量会比增加一个本地变量多花费四倍的时间。

　　结束语

　　要为嵌入式系统编写优雅高效的代码最根本的是要明白你的这些代码究竟要做什么。如果你真的想分配一个iterator，那么就对List使用foreach好了。它是你的选择而不是什么无心之过。

　　有备则无患。知道你想要做什么。倾注你最大的热情，清楚的了解你的代码，然后尽力让它跑得更快。

　　响应及时

　　你可以写出通过世界上所有性能测试的代码，但是当用户使用它时还是会感到恼火。这就是那些无法及时响应的应用 ——在特定阶段它们会变慢、挂起乃至冻结，或者需要用户等太久才来处理输入。在Android的术语中，不能及时响应的应用会频繁地导致系统弹出“应用没有响应”(ANR)消息。

　　通常，这种情况发生在你的应用无法响应用户输入时。例如，如果你的应用在一些I/O操作上阻塞了(通常是网络访问)，那么应用主线程就无法处理用户的输入事件。一段时间以后，系统会判定你的应用挂起了，并且可以让用户终止它。类似地，如果你的应用在构建一个内存结构或者在计算下一步如何走时花费了太长时间，那么系统也会判定你的程序挂起了。确认计算过程才用了提高效率的技巧是十分重要的，尽管如此，在高效的代码也是需要花时间来运行的。

　　在这两个例子中，修补方法通常是创建一个子线程，在那里做大部分的工作。这能保持主线程(驱动用户界面抡询的进程)运行，并且防止系统认为你的代码冻结了。由于这种线程通常在class以及完成，你可以把响应问题作为一个class问题。(这一点主要是与基本性能的对比，基本性能主要与方法层面有关)

 

关于如何构造快速响应的Android应用的文章对此作了更详细的描述。

　　构造快速响应的Android应用

　　本文中，我们将讨论Android如何判断程序没有响应的情况(以下被称作ANR)，ANR产生的原因，以及确保你的程序能够快速响应的几条准则。这里有一些很好的实践?有助于书写快速响应的Android代码?能够帮助你建立款速响应的用户界面。在我们探寻细节之前，先来看一看Android 提示ANR的对话框是什么样子：

　　Image:Http://code.google.com/android/images/anr.png

　　“好”程序也会变成“坏”程序

　　在Android中，活动管理器和窗口管理器这两个系统服务负责监视应用程序的响应。当出现下列情况时，Android就会显示ANR对话框了：

　　对输入事件(如按键、触摸屏事件)的响应超过5秒

　　意向接受器(intentReceiver)超过10秒钟仍未执行完毕

　　如何避免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)。这开起来好像无害，程序员通常认为他们花了大量的实际测试和使用自己的应用，感觉还不错。然而，Android应用模型是明确地为用户在不同进程中任意切换而构造的。这意味着，当你的背景进程弹出UI时，用户可能正在系统其他部分中，做着其他的事情——比如接电话。设想一下如果SMS服务每次收到一个消息时都弹出对话框，马上就会惹恼用户。这就是为什么Android标准对这种事件使用 Notification;这样就可以让用户来控制。

　　这只是一个例子，还有很多例子。例如，如果Activities没有在onPause()或其他方法中正确实现，就会经常导致数据丢失。或者，如果你的应用要把数据暴露给其他应用使用，你应该通过ContentProvider，而不是直接使用全局刻度的原始文件或者数据库。

　　这写例子的共同之处在于，它们都涉及与系统和其他应用的友好协作。Android系统涉及为将应用看作松散耦合的组件联盟，而不是一堆黑箱代码。这允许作为开发者的你把整个系统看作是更大的组件联盟。这可以允许你整洁、无缝地将你的应用于其他应用集成，并且作为这种好处的回报，你可以自己设计代码。

 

 

这是一个组件级概念(与性能和响应性的类和方法级概念相对)。关于如何与Android系统集成的文章提供了写与系统其他部分友好协作代码的小贴士和最佳实践。

　　不要放弃数据

　　Always keep in mind that Android is a phone platform. It may seem obvious to say it, but it’s important to remember that another Activity (such as the “Incoming Phone Call” app) can pop up over your own Activity at any moment. This will fire the onFreeze() and onPause() methods, and will likely result in your application being killed.

　　If the user was editing data in your application when the other Activity appeared, your application will likely lose that data when your application is killed. Unless, of course, you save the work in progress first. The “Android Way” is to do just that: Android applications that accept or edit input should override the onFreeze() method and save their state in some appropriate fashion. When the user revisits the application, she should be able to retrieve her data.

　　A classic example of a good use of this behavior is a mail application. If the user was composing an email when another Activity started up, the application should save the in-process email as a draft.

　　请记住Andriod是一个电话平台。很明显可以这么说，最重要的是要记住,随时都有可能另外一个活动的程序抢占的当前活动的程序(比如:“来电” 程序)。这将会调用OnFreeze()和OnPause()方法，并将可能导致你的程序被关闭。如果用户正在你的程序中编辑数据，当另外一个行为出现，你的程序可能被关闭而丢失数据。当然，除非你在处理前就保存工作进度。“Android 的方法”是这样做的：Android程序接收或编辑输入需要重载OnFreeze(),在适当的时候并保存它们的状态。当用户再次打开应用时，能够重新恢复数据。一个经典的例子就是邮件程序。当另一个行为启动时，如果用户正在写一封邮件,程序将要保存当前的进度到草稿箱里。

　　没人想要数据是裸露的

　　(No One Wants to See Your Data Naked)

　　If you wouldn’t walk down the street in your underwear, neither should your

data. While it’s possible to expose certain kinds of application to the world to read, this is usually not the best idea. Exposing raw data requires other applications to understand your data format; if you change that format, you’ll break any other applications that aren’t similarly updated.

 

　　The “Android Way” is to create a ContentProvider to expose your data to other applications via a clean, well-thought-out, and maintainable API. Using a ContentProvider is much like inserting a Java language interface to split up and componentize two tightly-coupled pieces of code. This means you’ll be able to modify the internal format of your data without changing the interface exposed by the ContentProvider, and this without affecting other applications.

　　如果你穿着内裤是不会走在街上的，你的数据也是如此。或许可以暴露给确定的几种类型的程序，这通常不是最佳的方法。暴露有规律的数据需要其他程序能够知道你的数据格式。如果你改变了格式，你将破坏那些没有得到同步更新的程序。 ”Android 的方法“ 是通过一套简洁的、深思熟虑的、可维护的API来创建一个ContentProvider(内容提供者)来暴露你的数据给其他程序。使用 ContentProvider 很像插入Java 语言接口分割和组合两段紧密耦合的代码。这意味着您将是能修改您的内部数据格式而不用改变由ContentProvider 暴露接口, 你的改变不会影响其它应用。

　　不要打断正在通话中的用户

　　If the user is running an application (such as the Phone application during a call) it’s a pretty safe bet he did it on purpose. That’s why you should avoid spawning Activities except in direct response to user input from the current Activity.

　　That is, don’t spawn Activities from IntentReceivers or Services running in the background. Doing so will interrupt whatever application is currently running, and result in an annoyed user. Perhaps even worse, your Activity may become a “keystroke bandit” and receive some of the input the user was in the middle of providing to the previous Activity. Depending on what your application

does, this could be bad news.

 

　　Instead of spawning Activities directly from the background, you should instead use the NotificationManager to set Notifications. These will appear in the status bar, and the user can then click on them at his leisure, to see what your application has to show him.

　　(Note that all this doesn’t apply to cases where your own Activity is already in the foreground: in that case, the user expects to see your next Activity in response to input.)

　　不要打断正在通话中的用户

　　如果用户正在运行一个程序(如：通话期间的电话程序)，并需要高可靠性。这是为什么忽略新的活动除了用户在当前程序的输入的直接反馈。也就是说，不要让在后台的服务程序或接收程序产生行为。这样做会打断当前运行的程序，并会导致骚扰用户。可能更糟糕是，你的行为可能变成“键盘监视”去接收一些用户的输入。如果你的程序做了这些，这将是一个坏消息。

　　替换在后台直接产生活动，你需要用NotificationManager来设置通知。这些通知将出现在状态栏,等用户有空的时候可以点击他们，来查看你的程序要做的事前。

　　(注意：以上所说的不适合于你的活动已经运行在后台,在这样情况下，用户是想看看到输入的下个的活动的)

　　做大量的事，放到线程中去

　　If your application needs to perform some expensive or long-running computation, you should probably move it to a thread. This will prevent the dreaded “Application Not Responding” dialog from being displayed to the user, with the ultimate result being the fiery demise of your application.

　　By default, all code in an Activity as well as all its Views runs in the same thread. This is the same thread that also handles UI events. For example, when the user presses a key, a key-down event is added to the Activity’s main thread’s queue. The event handler system needs to dequeue and handle that event quickly; if it doesn’t, the system concludes after a few seconds that the application is hung and offers to kill it for the user.

　　If you have long-running code, running it inline in your Activity will run

it on the event handler thread, effectively blocking the event handler. This will delay input processing, and result in the ANR dialogs. To avoid this, move your computations to a thread; click here to learn how.

 

　　做大量的事，放到线程中去

　　如果你的程序需要执行高CPU占用或长时间的计算，你需要将它挪到线程中。这可以防止显示给用户”程序没反应”的对话框，最终的结果是，你的程序将让出系统的使用权。

　　默认的情况下，所有的代码是运行在同一个线程中的。处理UI就是在同一个线程中。比如，当用户按下一个按键，一个key-down事件被添加到主线程队列中。事件处理处理器必须出列，然后快速的处理事件。如果不是这样的话，在几秒中后系统推断程序正在挂起中，并提示用户去关掉它。

　　如果你有长时间运行的代码，并运行在事件处理线程中，将会阻塞事件处理器。这使处理被延时，并会导致”程序为反应”对话框的出现。为了避免这样，需要把它移动程序中;[点击这里学习如何使用]

　　Avoid Huge Activities

　　Any application worth using will probably have several different screens. When partitioning your UI, be sure to make effective use of Activities.

　　Depending on your development background, you may interpret an Activity as similar to something like a Java Applet, in that it is the entry point for your application. However, that’s not quite accurate: where an Applet subclass is the single entry point for a Java Applet, an Activity should be thought of as one of potentially several entry points to your application. The only difference between your “main” Activity and any others you might have is that the “main” one just happens to be the only one that expressed an interest in the “android.intent.action.MAIN” action in your AndroidManifest..xml file.

　　So, when designing your application, think of your application as a federation of Activities. This will make your code a lot more maintainable in the long run, and as a nice side effect also plays nicely with Android’s application history and “backstack” model.

 

Extend Themes

　　When it comes to the look-and-feel of the user interface, it’s important to blend in nicely. Users are jarred by applications which contrast with the user interface they’ve come to expect. When designing your UIs, you should try and avoid rolling your own as much as possible. Instead, use a Theme. You can override or extend those parts of the theme that you need to, but at least you’re starting from the same UI base as all the other applications. For all the details, click here.

　　Make Being Flexible part of your Resolutions

　　Different Android devices will sport different resolutions. Some will even be able to change resolutions on the fly, such as by switching to landscape mode. It’s important to make sure your layouts and drawables are flexible.

　　Fortunately, this is very easy to do. Check out Implementing a User Interface for the full details, but in brief what you must do is provide different versions of your artwork (if you use any) for the key resolutions, and then design your layout to accommodate various dimensions. (For example, avoid using hard-coded positions and instead use relative layouts.) If you do that much, the system handles the rest, and your application looks great on any device.

　　Assume the Network is Slow

　　Android devices will come with a variety of network-connectivity options. All will have some data-access provision, though some will be faster than others. The lowest common denominator, however, is GPRS, the non-3G data service for GSM networks. Even 3G-capable devices will spend lots of time on non-3G networks, so slow networks will remain a reality for quite a long time to come.

　　That’s why you should always code your applications to minimize network accesses and bandwidth. You can’t assume the network is fast, so you should always plan for it to be slow. If your users happen to be on faster networks,

then that’s great — their experience will only improve. You want to avoid the inverse case though: applications that are usable some of the time, but frustratingly slow the rest based on where the user is at any given moment are likely to be unpopular.

 

　　One potential gotcha here is that it’s very easy to fall into this trap if you’re using the emulator, since the emulator uses your desktop computer’s network connection. That’s almost guaranteed to be much faster than a cell network, so you’ll want to change the settings on the emulator that simulate slower network speeds. You can do this in Eclipse, in the “Emulator Settings” tab of your launch configuration or via a command line option when starting the emulator.

　　Different Keystrokes for Different Folks

　　Android will support a variety of handset form-factors. That’s a fancy way of saying that some Android devices will have full “QWERTY” keyboards, while others will have 40-key, 12-key, or even other key configurations. Similarly, some devices will have touch-screens, but many won’t.

　　When building your applications, keep that in mind. Don’t make assumptions about specific keyboard layouts — unless, of course, you’re really interested in restricting your application so that it can only be used on those devices.

　　Don’t Assault the Battery

　　A wireless device isn’t very wireless if it’s constantly plugged into the wall. Handheld devices are battery-powered, and the longer we can make that battery last on a charge, the happier everyone is — especially the user. Two of the biggest consumers of battery power are the processor, and the radio; that’s why it’s important to write your applications to do as little work as possible, and use the network as infrequently as possible.

　　Minimizing the amount of processor time your application uses really comes down to writing efficient code. To minimize the power drain from using the

radio, be sure to handle error conditions gracefully, and only fetch what you need. For example, don’t constantly retry a network operation if one failed. If it failed once, it’s likely because the user has no reception, so it’s probably going to fail again if you try right away; all you’ll do is waste battery power.

 

　　Users are pretty smart: if your program is power-hungry, you can count on them noticing. The only thing you can be sure of at that point is that your program won’t stay installed very long.