（自己翻译的，转载请注明，谢谢。缺图、排版问题以及无效链接，我会慢慢修正，之前请和AndroidSDK文档对照来看）
无缝性设计
就算你的应用速度和响应都很快，一些设计仍然会带来问题。包括与其它Application或者Dialog的没有考虑到的交互不好，由于疏忽而丢失数据，意外的延迟，等等。为了避免这些问题，本文档将会让你明白你的应用会运行在什么样的上下文中，以及系统可能会如何影响你的应用。简而言之，你应该力争使你开发的应用能够无缝地与系统或者其它应用进行交互。
一个常见的无缝性问题，就是当一个应用的后台进程 — 例如，一个Service或者一个BroadCaseReceiver — 由于什么事件弹出了一个Dialog。这个似乎是无害的行为，尤其是当你在模拟器上独立运行和测试应用的时候。然而，当你的应用在真机上运行的时候，你的后台进程弹出对话框的时候用户并没有focus在你的应用上。所以，这可能导致你的应用弹出的对话框被活动的那个应用盖在后面，或者会把用户的注意力从他当前的应用（比如拨号打电话）上面吸引走。这种行为，无论是你的应用还是你的用户，都是不想要的。
为了避免这些问题，你的应用应该使用固有的系统能力 — Notification类 — 来通知用户。通过使用Notification，你的应用可以通过在StatusBar上面的一个小图标来提示用户某件事发生了，而不是打断用户并吸引用户的注意力。
另外一个无缝性问题的例子，就是一个Activity由于没有正确地实现onPause()之类的生命周期方法，导致不经意地丢失状态或者数据。或者，如果你的应用为了能让其它应用使用自己的数据而暴露数据的话，应该通过ContentProvider，而不是通过全局可读文件或数据库的方式。
通过这些，应用可以很nice地与系统和其它应用合作。 Android系统，被设计成了把Application作为一系列松耦合组件的组合，而不是一块黑盒代码。这就允许你作为一个开发者把整个系统仅仅当做一个大大的组件组合来考虑。于是你就可以把你的应用干净并且无缝地融入到其它应用中去。你自己的应用也应该努力做到不干扰其它应用。
本文档讨论了常见的无缝性问题以及如何避免它们。涉及以下方面：
别丢数据
永远不要忘了Android是一个移动平台。这貌似废话，但是一定要记住，在任何时候，另一个Activity（像是“有电话来了”）能够在你的Activity上弹出来，。这会触发onSaveInstanceState()和onPause()方法，并且可能会导致你的应用被杀掉。
假设，当另一个Activity弹出来的时候，用户正在你的应用上编辑文字。此时，如果你的应用被杀掉了，就可能会丢失数据。当然了，除非你在应用被杀掉前，抢救了数据和状态。抢救数据和状态的“Android方式”是：接受数据或者有编辑功能的应用，要重写onSaveInstanceState()方法，来通过某种合适的方式保存状态。当用户重新访问应用的时候，你的应用就能找回状态了。
以电邮应用为例，这是这种做法的一个经典的例子。用户正在写邮件，此时有一个其它的Activity弹出来了。此时应用应该把正在写的邮件保存到草稿里去。
不要暴露原始数据
你当然不想只穿着内衣走在大街上，你的数据当然也不想。虽然你的确可以把你应用的数据暴露成全局可见的，通常这并不是一个好主意。暴露原始数据需要其它应用了解你的数据格式；如果你改变了这些格式，依赖于这个格式的其它应用随之也就废了。
暴露数据给其它应用的“Android方式”，是通过一套干净的、精心考虑、可维护的api，创建一个ContentProvider。使用ContentProvider，有点像通过Java中的接口来分隔和组件化两块强耦合的代码。这意味着，你可以改变你的内部数据格式，但是不必影响通过ContentProvider暴露出去的接口，也就不会影响其它应用。
不要打断用户
如果用户正在运行一个应用（正在打电话之类），最好认为，他就是想做这件事。这就是为什么你应该避免弹出Activity。除非这个Activity是用户对当前Activity操作的直接响应。
就是说，不要在后台的BroadcastReceiver或者Service里面调用startActivity()。否则，你就有可能打断当前的应用，并且触怒用户。更糟的是，你的Activity有可能接收到用户在上一个Activity中正在进行的输入动作，从而成为“按键土匪”。这不是什么好事儿。
不能直接从后台弹Activity，你应该使用Notification。 Notification会出现在StatusBar上，用户可以在他空闲的时候点击，就可以看到你的应用想展示的东西了。
（注意，全部这些，在你的Activity在前台的时候，都不适用。这种情况下，用户希望看到你的Activity。）
有一堆事情要做？放到线程里
如果你的应用需要进行代价很高的耗时运算的话，你应该把它放到一个线程里。这会避免可怕的“ANR”对话框在用户面前出现，并导致用户在暴怒下删掉你的应用。
默认情况下，Activity中的所有代码，包括所有的View，都运行在同一个线程。这同样也是处理UI事件的线程。例如，当用户按键之后，一个key-down事件会被加到Activity的主线程的运行队列里。事件处理系统要很快地进行出列操作，并且处理事件。如果没能很快地处理完的话，几秒之后，系统会认为应用已经死了，并且提示用户，是否杀掉应用。
如果你把很耗时的代码放在Activity里的话，实际上会阻塞住事件处理线程。这会阻碍对输入的处理，从而导致ANR对话框。为了避免这个，把你的运算挪到一个线程里去。这里响应性设计进行了更详细的讨论。
别只用一个Activity
一个有使用价值的应用，一般会有很多不同的界面。当设计这些界面的时候，要保证使用了多Activity对象。
基于你的开发背景，你可能会把一个Activity简单地当做类似JavaApplet的东西，把Activity作为你应用的进入点。然而，这种看法并非很准确：Applet的子类是JavaApplet的唯一入口，一个Activity应该被认为是你应用的很多潜在入口之一。你的“主”Activity和任何其它Activity的唯一不同，是“主”的那个会在AndroidManifest.xml文件中，被描述为关心“android.intent.action.MAIN”这个动作。
所以，当你设计你的应用的时候，要把应用当做Activity对象的联合。这个将会使你的代码在长时间的运行中获得更多的可维护性，而且，一个很好的额外效果是，可以与Android的应用栈和后退栈很好地协作。
使用系统主题
当我们谈到UI视感的时候，把它打扮漂亮是很重要的。用户进入新的应用的时候，会跟已经进入过的那个进行比较，并且期望两个看起来差不多。当设计你自己的UI的时候，你应该尝试避免过分地使用你自己的风格。要使用主题。你可以重载或者扩展一部分你需要的主题，但是至少，你是从跟其它应用一样的主题开始的。详情请见Applying Styles and Themes。
设计UI的时候考虑不同的分辨率
不同的Adnroid设备可能支持不同的分辨率。一些设备，可以通过在空中横纵翻转，来转换分辨率。要保证你的Layout和Drawable足够灵活可以在不同的设备屏幕上显示。
幸运的是，要做到这一点很容易。简单说，你要做的，仅仅是为几个关键分辨率提供不同的图片，然后为不同的区域尺寸设计Layout。（不要把界面位置用坐标写死，最好使用RelativeLayout）。你做了这些之后，系统会接管剩下的，然后你的应用就会在任何设备上表现出色了。
网速是非常慢的
Android设备会支持不同种类的网络连接。这些网络连接都提供了数据访问的能力，但是其中一些会比较慢。速度最慢的标准，是GPRS，一个GSM网络下的非3G的数据服务。支持3G的设备，也会很长时间工作在非3G环境下，所以，网络慢这个现实将会持续相当长的时间。
这就是为什么你在编码你的应用的时候，总是应该使网络访问频率和带宽消耗最小化。既然你不能假设网络很快，你就应该认为它是很慢的。如果你的用户突然进入到了一个快的网络中，这非常好 — 这会改善用户的体验。你应该避免相反的情况：取决于用户所处的位置，应用在某些时间表现还行，但是其它时间令人沮丧地慢。这种应用是无论如何不得人心的。
当你使用模拟器调试应用的时候，更应该小心这类问题。因为模拟器是使用pc网络连接的。 PC的网络连接几乎必然比无线网络快。所以你应该在模拟器设置中，降低模拟器的联网速度。你可以通过在Eclipse的Configuration的“Emulator Settings”里面设置速度，或者在启动模拟器的时候通过 命令行选项来设置速度。
别假设设备有触屏或者有键盘
Android将支持非常多种的设备外形。可以想象的是，Android设备既可能有qwerty全键盘，也可能有40键、12键或者其它种类的键盘配置。同样地，一些设备可能有触屏，另一些可能没有。
当你构建你的应用的时候，要一直记住这些。不要假设特定的键盘配置 -- 除非，你真的希望你的应用仅仅能在某几种设备上运行。
注意省电
一个移动设备，如果总是需要插在墙上的话，就没那么移动了。移动设备是由电池供电的。我们让电池的续航时间越长，大家就越高兴（尤其是你的用户）。最耗电的两个，一个是处理器，一个是无线电。这就是为什么，你的应用应该尽可能少地做事，并且尽可能不那么频繁地使用网络。
你真的需要通过设计高效的代码来减少你应用的处理器使用。为了减少无线电的耗电，你应该优雅地处理错误，只发送必要的数据。举例来说，当一个网络操作失败后，不要频繁地重试。如果失败了一次，一般来说是因为用户没信号了，所以，就算你立即重试，基本上也会失败。你的重试只是在浪费电。
用户是很精明的：如果你的程序非常耗电的话，他们肯定会注意到。此时你唯一能够确定的就是，你的应用在用户的设备上待不了多长时间了。
682
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
