android server介绍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. 此时我们明确了client端发出去Intent去启动Service的过程，但是Service端是怎么来响应的？然后怎么启动你实现的子Service的呢？ Every call to this method 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可以包含原始数据类型，可以包含Parcelable对象，它还包含了一个活动的IBinder对象的引用，这个引用导致另一端接收到一个指向这个IBinder的代理IBinder 注：Parcel不是一般目的的序列化机制这个类被设计用于高性能的IPC传输因此不适合把Parcel写入永久化存储中，因为Parcel中的数据类型的实现的改变会导致旧版的数据不可读 Bundles类 Bundles是一种类型安全的Map容器，可用于存储任何不同类型的数据它具有很多对讀写数据的性能优化，并且它的类型安全机制避免了当把它的数据封送到Parcel中时由于类型错误引起的BUG的调试的麻烦，可以使用的方法为： writeBundle(Bundle), readBundle, and readBundle(ClassLoader)。
活动对象 Parcel的一个非同寻常的特性是读写活对象的能力对于活动对象，它们的内容实际上并没有写入，而是仅写入了一个令牌来引用这个对象当从Parcel中读取这个对象时，你不会获取一个新的对象实例，而是直接得到那个写入的对象有两种活动对象可操作： Binder对象 它是Android跨进程通讯的基础这种对象可被写入Parcel，并在读取时你将得到原始的对象或一个代理对象可以使用的方法们是： writeStrongBinder(IBinder), writeStrongInterface(IInterface), readStrongBinder, writeBinderArray(IBinder[]), readBinderArray(IBinder[]), createBinderArray, writeBinderList(List), readBinderList(List), createBinderArrayList FileDescriptor对象 它代表了原始的Linux文。