Android译文系列(一)---设计哲学（中文）！

看到一些文章还没有翻译，自己也没有翻译任务，利用下班时间翻译了《Android设计哲学》，抛砖引玉吧！

------------------------------------------------------------------------------------------------------------------------------

docs\toolbox\philosophy.html

Android应用程序设计哲学(Philosophy)

即使是平台间有很大的不同，学习如何用新的API来构建应用程序的过程是大同小异的。一般来说，要经历两个阶段：

  第一，学习怎样用API来做你想做的事情。

  第二,学习平台的细微差别。

话又说回来，首先要学习以能够构建应用程序，然后学习要怎样构建。第二阶段-学习正确的方法来构建应用程序-这常常要花去很长的时间，而且这常常意味着为所得而努力,犯错,并从中学习。的确，那不是有效的学习过程，所以本文和下面的链接的目的就是要拉你一把。在你投入进来之前，先将一个要点：成功的应用程序应该提供显著的用户体验。当Android团队构建一个强壮的核心系统时，大多数的用户体验将来自用户和你的应用程序的交互。因此，我们鼓励你多花点时间在构建应用程序的用户体验上。

显著的用户体验体现在三个核心特征上：

  1.快速2.响应性3.无缝性。

当然，自从计算出现以来，每个平台都可能时不时的证明了这三个特征。然而，每个平台的实现方式不同。 下面的内容解释了Android是怎么样达到这些目标的。

Fast

 Android应用程序应该是快速的，确切的说应该是高效的。 过去，在计算世界有一种倾向：即假定摩尔定律最终会解决我们的所有问题，但是当摩尔定律遇到嵌入式应用程序时，情况变得有点复杂。摩尔定律并不真正的像适用于桌面应用那样适用于移动设备。摩尔定律确实是适用于晶体管的定律-也就是说随着时间的推移，你可以在一个固定尺寸的芯片上集成更多的电路。对于桌面和服务程序来说，这意味着你可以在相同大小的一片芯片上“打包”更多的速度，提高众所周知的性能。 然而，对嵌入式应用来说，比如手机，摩尔定律通常被用于使芯片更小。这种趋势就是用不断增长的密度来制造尺寸更小，功耗更低的芯片，以使手机更小巧，电池更耐用。结果，像手机一样的嵌入设备不断的在和桌面系统拉大性能差距。对于嵌入式设备来说，摩尔定律意味着更多的特性，更低的功耗。持续增加的速度仅仅是一种回想。 这就是为什么编写高效代码如此重要的原因：你不能假设电话的性能增长与桌面和服务器的性能增长是一样的。

通常来说，编写快速的代码意味着保持最小的内存分配，编写紧凑的代码，避免某种语言或者编程方言削弱了性能。用面向对象的话来说，这些工作的大部分都发生在方法层次上(method level)，与实际的代码，循环等相似。 Writing Efficient Android Code这篇文章将会详细的讲述为Android编写快速，高效代码所需的细节。

Responsive

 我们可以编写能够赢得世界上所有的性能测试的代码，但是当用户试图使用的时候，仍然会引起他们强烈的愤怒。这种感觉来自应用程序没有足够的响应性--让人感觉反应迟钝，在关键的时刻失灵，或者处理输入太慢。以Android的话来说，应用程序不能够响应将直接导致系统弹出恐怖的"Application Not Responding" (ANR)消息。通常，这会在你的应用程序不能响应用户的输入时发生。比如说，如果你的应用程序blocks on一些I/O操作(直接访问网络)，然后主要应用程序的线程不能够处理用户输入事件，一段时间后系统会会认为你的应用程序已经挂掉了，然后给用户一个可以结束应用程序的选择。 类似地，如果你的应用程序花费大量的时间去构建一个in-memory(?)结构，或者计算游戏中的下一个移动，系统也会再次认为你的应用程序已经挂掉，用上面的技术确保这些计算的高效性总是很重要，但是即使最高效的代码也需要时间运行。 在以上两个例子中，fix(?)通常创建一个子线程，并且完成大部分的工作。这让主线程（用于驱动用户界面时间循环）保存运行，防止系统认为你的代码已僵住。因此这样的线程常常伴随在类的级别，你可以将响应看作是类问题。(将它和基本的，以上所描述的与方法层次有关的性能做比较) Building Responsive Android Applications 这篇文章对响应做了详细的讨论。

Seamless

即使是你的应用程序很快速，并且具有响应性，它仍然有可能让用户困扰。一个常见的例子是后台处理(比如Android的Service或者 IntentReceiver)，对某些事件，可能会突然弹出一个UI响应。这看起来似乎是无害的，而且开发者常常假设这是正常的，因为他们花了很多时间测试和使用他们自己的程序。 然而，Android的应用程序模型明确地构造为能让用户在不同的应用程序间流畅的切换。这意味着当你的后台处理“引燃”了那个UI时，用户可能正在使用系统的其他功能，做其他的事情-比如在接电话。就像每次有文本消息进来，短消息服务就弹出一个对话框一样。这立刻会骚扰到用户。这就是为什么Android标准对这样的事件使用通知的方式来处理。这让用户可以控制。

这仅仅是一个例子，相似的例子数不胜数。比如，如果Activities没有正确的实现onPause()方法和其他生命周期方法，常常会导致数据丢失。或者如果你的应用程序有意的暴露数据给其他应用程序使用，那么应该通过ContentProvider(内容提供者)，而不是用一个路人皆可见的未加工过的文件或者数据库。 以上所有例子的共性是它们都涉及到精细的系统序协同操作和应用程序协同操作。系统被设计为将多个应用程序视为一种松耦合组件的联合，而不是大块的代码黑盒。这就允许作为开发人员的你将整个系统看作是一个组件的大联合。这允许你干净地封装，无缝地和其他应用程序结合，你会从中受益。所以你应该设计你自己的代码来回馈这种赐予! 这是一个组件级的概念(作为对以上提到的性能和响应概念的反对，他们是类和方法级别的) Integrating with the System这篇文章提供了编写与系统其他部分精细地协作的代码的小贴士和最佳实践。

 -------------------------------------------------------------------------------------------------------

由于时间有限，文章有的地方译的不好。如果对某个地方的翻译有更好的见解，欢迎一起讨论，我的邮箱是chopinwzc@gmail.com

 ------------------------------------------------------------------------------------------------------------------------------（）