Android 任务、进程和线程

相比之下，singleInstance显得更为极端一些。在大部分时候singleInstance 与singleTask完全一致，唯一的不同在于，singleInstance的Activity，是它所在栈中仅有的一个Activity，如果涉及到的其他Activity，都移交到其他Task中进行。这使得singleInstance的Activity，像一座孤岛，彻底的黑盒，它不关注请求来自何方，也不计较后续由谁执行。在Android默认的各个应用中，很少有这样的Activity，在我个人的工程实践中，曾尝试在有道词典的快速取词 Activity中采用过，是因为我觉得快速取词入口足够方便(从notification中点选进入)，并且会在各个场合使用，应该做得完全独立。

除了launchMode可以用来调配Task，的另一属性 taskAffinity，也是常常被使用。taskAffinity，是一种物以类聚的思想，它倾向于将taskAffinity属性相同的 Activity，扔进同一个Task中。不过，它的约束力，较之launchMode而言，弱了许多。只有当中的 allowTaskReparen ting设置为true，抑或是调用方将Intent的flag添加FLAG_ACTIVITY_NEW_TASK属性时才会生效。如果有机会用到 Android的Notification机制就能够知道，每一个由notification进行触发的Activity，都必须是一个设成 FLAG_ACTIVITY_NEW_TASK的Intent来调用。这时候，开发者很可能需要妥善配置taskAffinity属性，使得调用起来的 Activity，能够找到组织，在同一taskAffinity的Task中进行运行。

进程

在大多数其他平台的开发中，每个开发人员对自己应用的进程模型都有非常清晰的了解。比如，一个控制台程序，你可以想见它从main函数开始启动一个进程，到 main函数结束，进程执行完成退出;在UI程序中，往往是有一个消息循环在跑，当接受到Exit消息后，退出消息循环结束进程。在该程序运行过程中，启动了什么进程，和第三方进程进行通信等等操作，每个开发者都是心如明镜一本帐算得清清楚楚。进程边界，在这里，犹如国界一般，每一次穿越都会留下深深的印迹。