Service那些事儿

一.生命周期：

        使用context.startService() 启动Service是会会经历：

　　context.startService() ->onCreate()- >onStart()->Service running

　　context.stopService() | ->onDestroy() ->Service stop

　　如果Service还没有运行，则android先调用onCreate()然后调用onStart();如果Service已经运行，则只调用onStart()，所以一个Service的onStart方法可能会重复调用多次。

　　stopService的时候直接onDestroy，如果是调用者自己直接退出而没有调用stopService的话，Service会一直在后台运行。该Service的调用者再启动起来后可以通过stopService关闭Service。

　　所以调用startService的生命周期为：onCreate --> onStart(可多次调用) --> onDestroy

　　使用使用context.bindService()启动Service会经历：

　　context.bindService()->onCreate()->onBind()->Service running

　　onUnbind() -> onDestroy() ->Service stop

　　onBind将返回给客户端一个IBind接口实例，IBind允许客户端回调服务的方法，比如得到Service运行的状态或其他操作。这个 时候把调用者(Context，例如Activity)会和Service绑定在一起，Context退出了，Srevice就会调用 onUnbind->onDestroy相应退出。

　　所以调用bindService的生命周期为：onCreate --> onBind(只一次，不可多次绑定) --> onUnbind --> onDestory。

　　在Service每一次的开启关闭过程中，只有onStart可被多次调用(通过多次startService调用)，其他onCreate，onBind，onUnbind，onDestory在一个生命周期中只能被调用一次。

--------------------------------------------------------------------------

        对你的应用而言，通过在manifest里声明Service，把需要后台相对长期运行的逻辑放在Service里，你便获得了这样的保障：只要系统内存不是极端不够用，你的Service一定不会被kill掉。对系统而言，当看到一个进程里有Service在运行，这个进程就具有较高的优先级，会在内存不足被杀的行列里排得比较靠后。

        什么时候选择local service（即不指定额外的进程），什么时候选择remote service（额外的进程）？通常我们会把真的需要长期运行的service（例如IM之类）放在单独的进程里，这样UI所在的进程在必要的时候仍然可 以被系统kill掉来腾出内存。而local service通常用来处理一些需要短期运行但仍然超出activity活动周期的任务，打个比方，发送短信或彩信。这样的任务执行完以 后，service就可以stop自己，仍然不妨碍整个UI进程被回收掉。

--------------------------------------------------------------------------

        既然在Service里也要创建一个子线程，那为什么不直接在Activity里创建呢？这是因为Activity很难对Thread进行控制，当Activity被销毁之后，就没有任何其它的办法可以再重新获取到之前创建的子线程的实例。而且在一个Activity中创建的子线程，另一个Activity无法对其进行操作。但是Service就不同了，所有的Activity都可以与Service进行关联，然后可以很方便地操作其中的方法，即使Activity被销毁了，之后只要重新与Service建立关联，就又能够获取到原有的Service中Binder的实例。因此，使用Service来处理后台任务，Activity就可以放心地finish，完全不需要担心无法对后台任务进行控制的情况。

--------------------------------------------------------------------------