戏说江湖静如水，游荡江湖才有情。我就是江湖中的一个戏子。
俗话说，入行先入门。作为一名android学习者，四大组件是android中的核心组件，岂有不学之理。然而，本人才疏学浅，叙述略有不当之处，敬请谅解。
Service是四大组件之一，使用的频率也非常高。Service相当于没有界面的Activity。为什么这样说呢？这就得明白Service几个重要的常识。
Service和Activity一样，都是作为应用的一部分运行在应用的主线程中。
这就说明，Service既不是一个独立的进程，也不是一个线程。所以如果要在Service中处理比较耗时或者长时间的任务，需要在Service中开启新的线程，避免阻塞主线程。
Service的特性
Service有两个非常重要的特性，这两个特性也和Service的生命周期有关。
- Service可以运行在后台，用户甚至不需要和其交互。这对应于应用调用startService方法，来告知系统对Service进行调度，直到调用stopService结束Service
- 应用可以向其他应用通过Service提供相应的功能。这对应于应用调用bindService，应用与Service进行长连接以便进行交互。
说了这么多，那么Service具体的生命周期又是什么样的呢？
Service的生命周期
Service的生命周期大致可以分为两个走向：
- 通过调用starService启动Service，并通过stopService或stopSelf来结束Service
onCreate——onStartCommand——onDestroy
- 通过调用bindService来与Service建立连接，然后通过unbindService来与Service取消连接
onCreate——onBind(Service返回Binder对象)——unBind——onDestory
注意：
多次调用startService只会在第一调用的时候，调用onCreate，后面只会调用onStartCommand方法。而多次调用bindService只会调用一次onBind方法，返回Binder对象
这两种生命周期的走向，指的是单一走向。当你不仅调用startService，还调用bindService的时候，那么生命周期会有不一样的结果。
- 如果你首先调用startService，然后调用bindService，那么生命周期如下：
onCreate——onStartCommand——onBind
这个时候如果你直接调用stopService是不会调用onDestroy方法，其实想想也明白了，这个时候Service已经绑定了，之后断开绑定了，这样才可以销毁Service。
- 如果你这个时候先调用unbindService，然后调用stopService，这个时候会按正常的生命周期走。
unBind——onDestroy
- 但是如果你先执行stopService，你会发现没有反应，然后调用unbindService，这个时候会走unBind然后走onDestroy。这个时候你可能很疑惑，因为已经调用了stopService，这个时候断开连接，那么该Service也就销毁了。
好了，生命周期就说这么多了。可能你会发现在bindService的时候需要传入一个ServiceConnection对象。
ServiceConnection对象
ServiceConnection顾名思义就是Service连接的操作类，该类有两个方法
onServiceConnected，onServiceDisconnected，这两个方法分别是Service连接和断开的时候回调的函数。一般通过onServiceConnected中传递的Binder来和Service进行通信。
在bindService的过程中，你会发现Service和其他组件进行交互的时候最重要的是IBinder对象，比如onBind返回的就是IBinder，在onServiceConnected中传递的第二个参数也是IBinder，IBinder是进程间通信和跨进程通信的桥梁，IBinder通过transact()和Binder的onTransact()来进行通信。来获得IBinder对象有两种方式，一种是通过AIDL，另外一种是通过Messenger，本质都一样，都是通过IBinder的transact()来传递Parcel类型对象，然后另外一个进程通过Binder对象的onTransact()方法来获取传输的对象，以达到通信的目的。
AIDL
AIDL全称叫接口调用语言，作用是简化IPC进程间通信和跨进程通信的实现，实际上AIDL是一个模板，避免了自己实现IPC进程通信的复杂。AIDL实现起来非常简单，只需要三步：
- 定义传输数据的接口，如要传输的数据不是parcel类型，则需要继承并实现。
- 在编译生成相应的类，并在Service中继承其stub接口，并实现其传输数据的方法。
- 在onServiceConnected中对出传输的Binder对象进行方法的调用，以实现数据的传输。
在这三步中，其中前两步是为了对transact方法的具体操作进行描述，第三步是为通过方法调用来通过onTransact来获取传输的数据，这样就实现了数据的互通。当然AIDL中还有许多细节需要注意，网上有很多这样的例子这里就不详细描述了。
Messenger
Messager是通过Handler，底层通过Binder对象来实现跨进程通信的方式，在构造Messenger对象的时候，需要传入Handler对象，通过Handler对象来获得MessengerImpl对象，其实现了IMessenger.stub对象，这看起来是不是很熟悉，对了，和上面的AIDL一样，实现了IMessenger.aidl生成的stub对象，用来进行跨进程通信。这样就很熟悉了，其实底层都一样，只不过上层表现的方式不一样罢了。那么我们来看一看Messenger进行跨进程通信的步骤。
- 构造一个Messenger对象，传入Handler对象，通过Message.repyTo.send方法传递数据，然后通过Service的onBind方法返回Messenger的IBinder对象(通过Messenger.getBinder方法)
- 在另一个进程与Service建立连接，并通过onServiceConnected来获得IBinder对象
- 同时再构造一个Messenger对象，通过Handler对象对传输过来的参数进行操作。
有的人也许看到过Service分为Local Service和Remote Service两种，其实这是因为Service启动方式不同而已，Local Service其实只需要通过startService就可以，然后Service就可以做自己的事了，用户不需要和Service进行交互。但是Remote Service就不行了，RemoteService的本质就是为了其他的进程提供相应的功能，这得需要交互，需要进行绑定，这就需要bindService。当然通过AIDL，Messenger都需要和Service进行绑定。目的不一样，结果就不一样。
当然Service还有许多其它有趣的功能，这里就先说这么多了。讲得不好大家可别见怪哦！
