IntentService 使用背景
IntentService 用来开启一个后台服务处理完以后并且可以马上停止服务。比如当我们在广播中的onRecive 方法中接收到广播马上就要去异步请求一个网络数据。(手机发出广播，天气应用接收到开机广播，在onReceive 方法里去获取天气数据)。首先我们Androidmanifest.xml通过静态相关广播，其他进程发出相关全局广播。当接收到广播时候，如果此时正在执行回调到onReceive 方法，那么此时的进程优先级可以看作是前台进程，不容易被系统回收。当执行完onReceive 方法以后，当前进程很可能马上被回收，而这时候马上去开启一个子线程去请求网络是不保险的。针对以上可能出现的缺陷问题，我们会交给Service 在后台处理，同时配合Handler 去更新UI。所以针对该问题，Google 为我们封装了IntentService 用来处理类似问题。 我们知道当开启一个Service 的方式有StartService 和BindService 两种方式。简单的说一下StartService 开启后Service 的生命周期。多次开启StartService 之后onCreate 只会调用一次，但是onStartCommand()方法会调用很多次，但
所以在开启IntentService 之后在onCreate 方法中 会初始化HandlerThread (集成自Thread 封装子线程)，开启线程初始化子线程Looper
当隐式调用或者显示调用StartService(XXXIntentService.class)的时候
紧接着走到onStartCommond（）
该方法中调用了onStart 方法，将传递Intent 对象封装成Message 数据，并主线程ServiceHandler 往子线程的MessageQueue中发送消息，因为发送消息的时候并没有给Message中的Callback赋值,所以消息最终会走到ServiceHandler 的handleMessage() 方法再调用 onHandleIntent（）抽象方法，
需要子类实现。客户端在HandIntent 方法中处理各种耗时操作，最后执行完以后StopSelf Service 。
服务被销毁的时候OnDestory 方法中，我们找到子线程的Looper 退出的方法，这很符合当前这个服务用完就走的特点，当然当我们多次调用StartService 的时候，启动该服务的线程会往子线程的MessageQueue 中发送消息，即使我们服务突然挂了，消息队列中还有等待被处理的消息，也不会有事，因为onDestroy 方法中的子线程Looper 已经退出了最终调用了MessageQueue 中的dispose() 方法
