Android Application Design Philosophy
Android应用程序设计理念
The process of learning how to build applications for a new API is pretty similar, even if the platforms themselves are wildly different. Generally, there are two phases: first, you learn how to use the APIs to do what you want to do; later, you learn the nuances of the platform. Put another way, first you learn how you can build applications; later, you learn how you should build them.
即使不同系统平台之间差别非常大，学习用一种新的API编写应用程序的过程通常也都是相似的。一般来说，这个过程分两个阶段：首先，你将学习如何使用这些API去完成你想实现的工作；然后，你就需要学习该平台独特的地方。换句话说，你第一步学习如何编写应用程序；然后，你就应该学习应该怎样来编写它们。
That second phase — learning the right way to build applications — can often take a long time, and frequently means "paying your dues", making mistakes, and learning from them. Well, that's not a very efficient process, so this page and the links below aim to give you a helping hand.
尤其第二点－－学习编写应用程序的正确方法－－可能需要经历比较长的时间，并且可能经常意味着“交学费”和不断地犯错误，然后你才能达到目的。也许这不是一个很有效率的过程，因此本篇和相关的链接将给你提供一些帮指引和帮助。
Before we dive into it, a quick word. Successful applications will offer an outstanding end-user experience. While the Android team has built a robust core system, the vast majority of the user experience will come from users interacting with your applications. As a result, we encourage you to take the time to build an outstanding user experience.
在我们深入讨论该问题之前，先作一个简单概括。优秀的应用程序来自于出色的用户体验。在Android团队构建起一个健壮的核心系统之后，用户体验很大程度上来自于用户与应用程序的交互上。因此，我们特别鼓励在实现出色的用户体验方面下更多的功夫。
An outstanding user experience has three key characteristics: it is fast; it is responsive; and it is seamless. Of course every platform since the dawn of computing has probably cited those same three qualities at one time or another. However, each platform achieves them in different ways; the information below explains how your apps can achieve them on Android.
出色的用户体验包括三个关键特性：快速；良好响应；无缝通信。然而，各个平台可能用不同的方式实现这些目标；以下信息将向你解释怎样才能在Android平台上实现这些特性。
Fast
快速
An Android application should be fast. Well, it's probably more accurate to say that it should be efficient. There is a tendency in the computing world these days to assume that Moore's Law will solve all our problems — eventually. When it comes to embedded applications, though, Moore's Law is a bit more complicated.
Android应用程序应该运行非常快速。也许，应该更准确一点说就是应该是有效率。目前，在计算领域有一个趋势，认为摩尔定律最终会解决所有问题。尽管对于嵌入式应用而言，摩尔定律可能会显得更复杂一些。
Moore's Law doesn't really apply to mobile devices in the same way as to desktop and server applications. Moore's Law is actually a law about transistor density — that is, it says that you can pack more circuitry into a given chip size, over time. For desktop and server applications, this means you can pack more "speed" into a chip of roughly the same size, resulting in the well-known performance increases. For embedded applications like cell phones, however, Moore's Law is usually exploited to make chips smaller. That is, the tendency is to use the increased density to make the same chip smaller and consume less power, to make phones smaller and make batteries last longer. As a result, embedded devices like phones are increasing in actual, raw speed much more slowly than desktop systems. For embedded devices, Moore's Law means more features and better battery life; increased speed is only an afterthought.
摩尔定律在移动设备领域与桌面系统和服务器应用方面实际并不太一样。摩尔定律实际上是关于晶体管密度的一种规则－－也就是说，随着时间往后推移，在同样的芯片尺寸上你可以放置更多的电路。对于桌面和服务器应用，这意味着在大约同样的芯片尺寸上你可以放置更多的“速度”，结果带来显著的性能提升。然而对于像手机之内的嵌入式应用，摩尔定律则通常是意味着更小的芯片尺寸。也就是说，这种趋势就是通过提高晶体管的密度使芯片更小，并消耗更少的电能，也就意味着可以将手机做得更小，电池续航时间更长。因此，如手机之内的嵌入式设备，实际在单纯速度方面比桌面系统增长远慢得多。对于嵌入式设备而言，摩尔定律就意味着更多的功能特性和更好的电池寿命（续航时间？）；速度的提高倒在其次了。
That's why it's important to write efficient code: you can't assume that phones will see the same speed increases as desktops and servers. Generally speaking, writing fast code means keeping memory allocations to a minimum, writing tight code, and avoiding certain language and programming idioms that can subtly cripple performance. In object-oriented terms, most of this work takes place at the method level, on the order of actual lines of code, loops, and so on.
这就是为何编写高效的代码是如此重要：你不要期望手机像桌面和服务器那样的速度增长。通俗点说，编写运行快速的代码意味着最小的内存分配、写更紧凑的代码、避免一些可能降低性能的程序设计语言和傻瓜式编程方法等。用面向对象的环境打比方，这些之中的大部分将工作在方法调用级上，这实际上包括很多行的代码和循环等等。
The article on Writing Efficient Android Code will give you all the detail you need to write fast, efficient code for Android.
这篇“编写高效的Android代码”将给你关于为Android平台编写快速、高效的代码的全部细节。
Responsive
及时响应
It's possible to write code that wins every performance test in the world, but that still sends users in a fiery rage when they try to use it. These are the applications that aren't responsive enough — the ones that feel sluggish, hang or freeze for significant periods, or take too long to process input. In Android terms, applications that are insufficiently responsive will frequently cause the system to pop up the dreaded "Application Not Responding" (ANR) message.
就算可以编写能通过全部可能的性能测试的代码能做到，但当用户不断使用软件的时候，还是任然可能给用户带来困惑和不满。这些就是应用响应不能做到足够快的结果，如反应迟钝、系统长时间挂起或冻结或是很久不能响应输入。用Android的话来说，不能够及时响应的应用经常使系统弹出令人恐惧的"应用没有响应"(ANR)的消息。
Generally, this happens if your application cannot respond to user input. For example, if your application blocks on some I/O operation (frequently a network access), then the main application thread won't be able to process incoming user input events. After a time the system will conclude that your application has hung, and give the user the option to kill it. Similarly, if your application spends too much time building an elaborate in-memory structure, or perhaps computing the next move in a game, then again the system will conclude that your application has hung. It's always important to make sure these computations are efficient using the techniques above, but even the most efficient code still takes time to run.
通常这种情况出现在应用不能及时响应用户输入上。例如，如果你的应用阻塞在IO操作（常常是网络访问的情况）上时，主应用线程就无法处理已经到达的用户输入事件。一定的时间过后，系统可能认为你的程序已经挂起，于是就发送消息允许用户终止该程序。同时，如果你在内存中创建一个复杂的数据结构花费太多时间，或是在游戏程序中可能正在计算下一副场景时，同样系统也可能认为你的程序已经挂起。这就是为什么运用上述技术进行有效率的运算总是如此重要，即使是最高效的代码任然需要时间去执行。
In both of these cases, the fix is usually to create a child thread, and do most of your work there. This keeps the main thread (which drives the user interface event loop) running, and prevents the system from concluding your code has frozen. Since such threading usually is accomplished at the class level, you can think of responsiveness as a class problem. (Compare this with basic performance, which was described above as a method-level concern.)
针对上述两类情况，解决方案通常就是创建一个子线程去执行这里的大多数工作。这样就可使主线程（响应用户接口的事件循环）能正常运行并避免系统误认为程序已经冻结。由于这些线程通常由类级别的代码实现，你可以想到程序响应不太好与类问题有关（在基本性能与前述方法级相对比而言。）。
The article on Building Responsive Android Applications discusses responsiveness in detail.
这篇关于“构建良好响应的Android应用”将详细讨论响应有关的问题。
Seamless
无缝通信
Even if your application is fast and responsive, it can still annoy users. A common example is a background process (such as an Android Service or IntentReceiver) that pops up a UI in response to some event. This may seem harmless, and frequently developers assume that this is okay because they spend most of their time testing and using their own application. However, Android's application model is constructed explicitly to allow users to fluidly switch between applications. This means that when your background process actually fires up that UI, the user could be way over in another part of the system, doing something else — such as taking a phone call. Imagine if the SMS service popped up a dialog box every time a text message came in; this would annoy users in no time. That's why the Android standard is to use Notifications for such events; this leaves the user in control.
即使应用运行快速和响应及时，这任然可能惹恼用户。一个通常的例子就是后台进程（如Android服务或IntentReceiver等）一收到某些事件就弹出一个用户界面。这种动作可能无害，而开发人员则常常认为这并无大碍，因为他们已经花了大量的时间测试和使用自己的程序。然而，Android的应用模型则允许用户随意在应用中进行切换。这就意味着当你的后台进程实际弹出一个用户界面时，用户可能已经切换到系统的例外部份并执行其他工作，如打电话等。设想如果 SMS服务在每收到一条消息就弹出一个对话框，这迟早会激怒用户。这就是为什么Android标准对这些事件使用通知方式；这使用户拥有自己的控制权。
That's just one example; there are many more. For example, if Activities don't correctly implement the onPause() and other lifecycle methods, this will frequently result in data loss. Or, if your application exposes data intended to be used by other applications, you should expose it via a ContentProvider, rather than (for example) using a world-readable raw file or database.
这仅是一个例子；还有很多这样的情况。举例来说，如果Activities不能正确地实现 onPause方法和其他的lifecycle方法，结构就会经常丢失数据。因此，如果你的应用要向其他程序开放数据，应该通过内容提供器进行，而不是使用诸如众所周知的原始文件或数据库。
What those examples have in common is that they involve cooperating nicely with the system and other applications. The Android system is designed to treat applications as a sort of federation of loosely-coupled components, rather than chunks of black-box code. This allows you as the developer to view the entire system as just an even-larger federation of these components. This benefits you by allowing you to integrate cleanly and seamlessly with other applications, and so you should design your own code to return the favor.
这些例子有一个共同点，那就是它们均需要与系统和其他应用之间有比较良好的协作。Androis系统的设计原则就是将每个应用看成是各种组件的一种松散耦合体，而不是一行行的黑盒子代码。这样就可以让作为开发者的你可以将整个系统看成仅仅是一个各种组件的更大的集合。这样做的好处就是能让你可以更清楚和无缝地与其他应用进行集成，因此你就应该很好地设计你的代码适应这种情况。
This is a component-level concept (as opposed to the class- and method-level concepts of performance and responsiveness, described above.) The article on Integrating with the System provides tips and best practices for writing code that cooperates nicely with the rest of the system.
这就是组件的概念（这点与前面描述的会带来性能和响应问题的类或方法级的概念）。“系统集成”这篇文章将为你编写可以与系统其他部分很好协作的代码提供指引和最好的实践经验。
