《 Android 高性能编程》——第 5 章：多线程

1、进程 P176 - 177

这里写图片描述

可以为组件指定进程，通过在 manifest 文件中使用特殊的属性：

<service
    android:name=".MyService"
    android:process=".MyProcess">
<service/>

只需要指定进程的名字即可。如果进程的名字以冒号: 开头，那么该进程是应用程序的私有进程（即实际的进程名为 应用程序的包名+冒号后面的字符），当进程名以小写开头时，那么该进程名可被其他应用程序所共享。

2、Loader 框架 P187 - 190

这里写图片描述

缺点：只能在 Activity 或 Fragment 中使用。

3、Service P190 - 199

(1) Started Service

onStartCommand() 的三个参数：
这里写图片描述

flags 取值的含义：
这里写图片描述

当 Service.onStartCommand() 方法的返回值被设置为 START_REDELIVER_INTENT ，且 Service 由于意外被终止，那么 Service 重启时，Service.onStartCommand() 方法中的 flags 参数的值即为 START_FLAG_REDELIVERY 。

onStartCommand() 的返回值：
这里写图片描述

(2) Bound Service

只通过 bindService() 启动的服务（即没有执行过 startService() ）当最后一个被服务引用的 context 失效后，服务会自动销毁。

并在多次进行 bindService() 的时候，Service.onBind() 只会在第一次的时候调用，但是在客户端使用的 ServiceConnection 接口实例的 onServiceConnected() 的方法会被调用相应的次数。而 ServiceConnection 接口实例的 onServiceDisconnected() 的方法只有在服务的链接已经丢失时才被调用，通常发生在托管的服务崩溃或者被杀死，而 unbindService() 的时候是不会被调用的。

(3) IntentService

当内部的消息队列为空时，IntentService 会自动销毁。因为其内部的 Handler 在每次处理 message 后会调用 stopSelf() 方法。

private final class ServiceHandler extends Handler {
    public ServiceHandler(Looper looper) {
        super(looper);
    }
    @Override
    public void handleMessage(Message msg) {
        onHandleIntent((Intent)msg.obj);
        stopSelf(msg.arg1);
    }
}

这里就需要注意，有时候在某一个线程中就连续多次调用 startService() 来调用某一 IntentService，但是此时 IntentService 只会在最后一次调用后被销毁，那是因为每在 handleMessage() 中调用了 onHandleIntent((Intent)msg.obj) 后再调用 stopSelf(msg.arg1) 时消息队列都不为空（因为添加 message 的逻辑比较快，当第一个 message 被处理后调用 stopSelf(msg.arg1) 时下一个 message 已经被添加到消息队列了），所以 IntentService 不会被成功销毁。
而当在多个线程中多次调用 startService() 来调用某一 IntentService 时，如果之间时间间隔较大，就可能出现 IntentService 被销毁后又被重启启动的情况。就像下面的示例：
这里写图片描述

4、先进的技术 205 - 210

(1) BroadcastReceiver 异步技术

这里写图片描述

(2) ContentProvider 异步技术

有关API：AsyncQueryHandler

4、重复性任务 P210 - 212

(1) Timer

Timertask 并非执行于主线程。当执行完毕后，必须使用 Timer.cancel() 方法将 Timer 取消，以释放资源。该 API 适用于短时间周期性任务。

(2) ScheduledExecutorService

这里写图片描述

(3) AlarmManager

AlarmManager 可用于在某个特殊的时间启动一个新的组件，以开启一些周期性操作。
AlarmManager 相对于其他类更高校，因为它依赖于系统的闹铃服务，但它不适合短期任务，存在一些限制，应尽可能用前面两个 API 代替。
另外，不要忘记在设备重启后，恢复闹铃，对于获知设备重启的事件，可监听 ACTION_BOOT_COMPLETED 广播。