Android Service
所谓的service有Local Service和Remote Service区分：
LocalService：就是client和Service在同一个进程当中。
RemoteService：就是client 和Service在不同的进程中。
我们通常的用法是自己建一个.java文件中通过继承Service来实现一个子Service。然后在通过其他的Activity来连接实现的那个Service就有点像网络编程中的链接服务器一样。但是这里的Service不是独立的一个服务器端，它可以说是手机app的一个实现模块。所以不是像传统的网络编程一样，首先启动服务器，然后在从client去访问。android中的Service要通过访问端通过传递消息(Intent)去开启Service。通常有两种方法去启动一个Service。
一）context.startService()启动方式
public abstract ComponentName startService(Intent service)
通过函数的原型我们可以看出是一个Component去调用的，参数就是一个Intent，在该Intent中去指定一些规则和消息来启动符合条件的Service。
The Intent can either contain the complete class name of a specific service
implementation to start, or an abstract definition through the action and other fields of the
kind of service to start（by gg doc）.
此时我们明确了client端发出去Intent去启动Service的过程，但是Service端是怎么来响应的？然后怎么启动你实现的子Service的呢？
Every call to this method（startService(Intent intent)） will result in a corresponding call to
the target service's
onStartCommand(Intent, int, int)(by gg doc)就是each component调用startService(Intent intent）来启动Service的时候，service端作出的响应就是call onStartCommand(Intent,int,int)函数
public int onStartCommand (Intent intent, int flags, int startId)
当调用该函数的时候intent对象就是startService(Intent intent)红传递过来的intent对象。flags：start request的额外请求，可以是：0,
START_FLAG_REDELIVERY,START_FLAG_RETRY. startId:an unique integer 来展示这次请求
目前gg doc给出了四种返回值类型。
START_STICKY:如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，由于服务状态为开始状态，所以创建服务后一定会调用onStartCommand(Intent,int,int)方法。如果在此期间没有任何启动命令被传递到service，那么参数Intent将为null。
START_NOT_STICKY:返回该返回值时，如果在执行完onStartCommand后，Service被一场kill掉后，系统不会重启该Service。
START_REDELIVER_INTENT:但返回这个返回值的时候，从startService传过来的intent对象将保存它的数据，当Service被异常kill掉的后，Service会重启，然后再将Intent传入。
START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启
这个函数不能人为的去直接调用，而是由Android system在Service的main thread中有系统去调用。
所以一般情况下继承Service的子类都要重写Service类的：OnCreate(),onStartCommand(),onBinder(),onStart(),onDestory()，onRebind(),onUnbind()方法，然后在编写其他自己要是想的功能实现函数。
所以通过context.startService(Intent intent)来启动Service时将是一个:
client端 Service端
startService()---------------->onCreate()--->onStart().当stopService的时候Service端就会调用onDestroy()方法来Destroy
stopService()----------------->onDestory()--->Service stop
如果是调用者自己直接退出而没有调用stopService的话，Service会一直在后台运行。下次调用者再起来可以stopService。
二）context.bindService()启动方式
模型说明：
client端 Service端
bindService()------------------->onCreate()-->onBind()-->Service running
onUnBind()---------------------->onDestroy()-->Service stop
函数原型：public boolean bindService (Intent service, ServiceConnection conn, int
flags)
参数说明：intent：就是client端定义的参数，和startService中的intent作用一样
conn是一个ServiceConnection实例，ServiceConnection是一个public interface，一个用于监视app service状态的Interface，必须去实现ServiceConnection的两个抽象函数。
onServiceConnected(ComponentName name, IBinder service)和onServiceDisconnected(ComponentName name)这两个函数就是决定
链接和断开Service。
flags:绑定操作选项
返回值：绑定成功返回true，失败false。
public abstract IBinder onBind (Intent intent)
intent:该参数由bindService()函数传递过来，用于绑定指定的Service。
所以调用bindService的生命周期为：onCreate --> onBind(只一次，不可多次绑定) --> onUnbind --> onDestory。
在Service每一次的开启关闭过程中，只有onStart可被多次调用(通过多次startService调用)，其他onCreate，onBind，onUnbind，
onDestory在一个生命周期中只能被调用一次。
绑定一个运行的Service
可以创建一个即是运行的又是绑定的service，也就是通过startService()来让这个Service运行，然后client通过bindService()来绑定到Service。那么当service启动后，系统不会在所有客户端解除绑定unBindService()后销毁service，而是，你必须通过调用stopSelf()或stopService()显示地停止这个service。
多个client可以同时连接到一个service，当地一个Client绑定到Service的时候Service的onBinder()方法才接受到IBinder，之后Service将把同一个IBinder传递给其他的client，之后其他Client的连接service时service就不再会调用自身的onBind()方法了。
当最后一个client取消绑定到Service时，系统就会销毁这个Service
进程间通信
每一个进程都有自己独立的内存，一个进程的1000地址也许是另一个进程的100000地址，所以如何在进程间通信就变得复杂了，对于基本类型的数据比如整数直接传递过去就行了，但是要是字符串的话就要先目的进程空间中分配一快能容纳该字符串内存，然后在复制到内存中。再如果要传递一个类的实例，也是先为类分配内存，然后复制一份再传递可以吗？我认为不可以，我至少可以找到一个理由：类中成员除了属性还有方法，即使属性能完整传过去，但还有方法呢？方法是独立于类对象存在的，所以到另一个进程中再引用同一个方法就要出错了，还是因为独立地址空间的原因。Android中通常要在Activity之间专递数据，而根据Android的设计，即使同一个Activity都不一定运行在同一个进程中，所以就要进程间传递数据了，那么到底如何在进程之间传递类对象呢？简单来说可以这样做：在进程Ａ中把类中的非默认值的属性和类的唯一标志打成包（这就叫序列化），把这个包传递到进程Ｂ，进程Ｂ接收到包后，跟据类的唯一标志把类创建出来，然后把传来的属性更新到类对象中，这样进程Ａ和进程Ｂ中就包含了两个完全一样的类对象。
android 中的Parcel是一个容器，主要作用于存储序列化数据，然后通过Binder在进程间传递这些数据。Parcel可以包含原始数据类型（用各种对应的方法写入，比如writeInt(),writeFloat()等），可以包含Parcelable对象，它还包含了一个活动的IBinder对象的引用，这个引用导致另一端接收到一个指向这个IBinder的代理IBinder。
注：Parcel不是一般目的的序列化机制。这个类被设计用于高性能的IPC传输。因此不适合把Parcel写入永久化存储中，因为Parcel中的数据类型的实现的改变会导致旧版的数据不可读。
