Android真正独特的地方在于它允许多个任务同时运行。由于开发者们来自不同的平台，对这样的运行机制可能会感到惊讶。深入理解它的行为对你的应用程序设计是很重要的，因为这样可以无缝的（seamlessly）集成到android的其他版本/平台。本文涵盖了android多任务设计的原因，和它是怎样影响（impact on）你的应用程序工作的以及你要怎样才能最好的发挥出android的优势特色。
设计要素
移动设备有技术局限性，并且用户体验需求不同于桌面或web系统。下面是我们设计android多任务时的4个关键的约束条件（constraints）：
我们不想要求用户在“完成”的时候关闭程序。那样的使用模式（指完成后立即关闭程序）在移动（mobile）环境工作的不是很好，特别是每天都要大频率反复使用的程序。
移动设备没有那么奢侈（luxury）的交换空间（指的内存RAM），在内存使用上又有很严格的限制。Robert Love（此人写了很多linux的书籍，本人有一本《linux系统编程》）写过一篇关于本主题的非常好的文章。
应用程序在移动设备上切换启动（switching on）是极其受到挑剔的，我们的目标是显著的减少到少于1秒钟来启动一个新的程序。当用户在很少的程序中切换时，这点尤为重要，比如说当观看视频时切换出来查看一个条新短信，然后再退回观看视频。一个显而易见的（noticeable）等待在此种状况下会很快引起用户对你的憎恨。
可用的API对编写内置的Google应用程序来说应该必须足够（be sufficient for），这也是我们的“所有程序生来平等”哲学的一部分。这就是说后台的音乐播放，数据同步，GPS导航，应用下载等必须可以让第三方开发人员用同样的API来实现。
前两点需求强调了一个有意思的冲突（conflict）。我们并不是要让使用者担心关闭他们的应用，宁可让所有的应用一直运行着。但同时，移动设备的内存使用却很有限，以至于系统会降低性能或者当它需要比可用更多的RAM时，很快就启动失败，而台式电脑，可以交换（指空间），相比起来就很简单的启动（运行）缓慢，来用页面RAM交换空间。这些相互矛盾的约束就成了android设计的动机。
什么时候应用程序“停止”呢？
一个Android多任务普遍的误解是关于一个进程（process，也可以译为程序）和一个应用（application，也可以译为程序）之间的不同之处。在Android中这两者并不是紧密联系的一个实体：应用出现在用户面前可能并不需要实际的进程运行在程序中；多个应用可以共享同一个进程，或者一个应用可能使用多个进程，这些都取决于你是否需要；当应用并不积极的做什么事情的时候，它的进程就会由Android保存。
实际上你看一个应用的进程“运行”不是说这个应用在运行或做什么事情。它简单的在那里可能只是因为Android在某些时候需要它，并且让它最好还是在那里因为可能还要再次需要它。同样地，你可能会离开一个应用一会儿，并从停止的地方回来，在这段时间，Android可能需要取消（get rid of）进程的其他事情。
Android此时处理应用的一个关键是进程不会干净的关闭。当用户离开一个应用程序，它的进程一直在后台存在着，如果需要的话，允许它继续运行（例如下载网页），当用户返回的时候能够立刻回到前台。如果一个设备不出现内存溢出的话，Android将保证所有的进程都在，真正的让所有应用永远“运行”。
当然，这里有个内存的限制，为了解决（accommodate）这个问题，Android必须决定何时移除不再需要的进程。这引出了Android进程的生命周期，这个规则用来决定每个进程的重要程度，哪些进程需要被抛弃。这些规则基于两点，一个是用户当前使用中的进程的重要级别，另一个是进程从上次用户需要到现在经过了多长时间。
一旦Android决定要移除一个进程，它会残忍的（brutally）、简单的强制杀掉它。内核会立刻回收再利用（reclaim）进程的所有资源，不需要应用程序良好的编码和礼貌的响应退出请求。允许内核立即回收再利用资源就可以很容易避免一系列的内存溢出问题。
如果一个用户要回到一个程序，而这个程序恰巧被杀掉了，Android需要一种途径重新加载它并回到最后看到的状态，来保持“所有的程序永远运行”的用户体验。通过记录（is keep track）用户知道（is aware of）的程序的一部分（activity）的信息，就是他们看到的最后状态，重新启动它们。这里说的最后的状态是指用户离开程序时的状态，并不是它被杀掉时的状态，所以内核不用依赖程序在某一点的正确响应而自由的杀掉它。