对象的传递为什么要 序列化 呢

Intent在启动其他组件时，会离开当前应用程序进程，进入ActivityManagerService进程（intent.prepareToLeaveProcess()），

这也就意味着，Intent所携带的数据要能够在不同进程间传输。

首先我们知道，Android是基于Linux系统，不同进程之间的java对象是无法传输，

所以我们此处要对对象进行序列化，从而实现对象在 应用程序进程 和 ActivityManagerService进程 之间传输。

IPC是指两个进程之间进行数据交互的过程，即：跨进程通信。

进程是一个执行单，在移动设备上指一个程序或者一个应用。一个进程可以有多个线程，也可以只有一个线程，即主线程。在Android里边，主线程也叫作UI线程，要是在主线程执行大量耗时任务，就会造成界面无法响应，ANR问题，解决这类问题，把耗时 *** 作放在子线程就好。

在Android中，最有特色的进程间通信就是Binder，Binder轻松的实现了进程间的通信。

给四大组件 Activity、Service、Receiver、ContentProvider 在AndroidMenifeist中指定 android:process 属性，可以指定其运行的进程。

: 开头的线程是当前应用的私有进程，其它应用不可以和它跑在同一个进程中，而不以 : 开头的属于全局进程，其他应用通过ShareUID方式可以和它跑在一个进程中。

Android为了每一个应用（进程）都分配了独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间。

多进程会造成如下几个反面方面的问题：

为了解决这些问题，系统提供了跨进程通信方法，虽然不能直接共享内存，但是可以实现数据共享。Intent来传递数据，共享文件，基于Binder的Messenger，ContentProvider，AIDL和Socket。

当我们需要通过Intent和Binder传输数据，或者我们需要把对象持久化到存储设备上，再或者通过网络传输给其它客户端时，Serializable和Parcelable接口可以完成对象的序列化过程。

Serialzable是java提供的序列化接口，是一个空接口，为对象同序列化和反序列化 *** 作。

想让一个类对象实现序列化，只需要这个类实现Serialzable接口，并声明一个serialVersionUID即可，serialVersionUID可以声明成1L或者IDE根据当前类接口自动生成它的hash值。

没有serialVersionUID不影响序列化，但是可能会影响反序列化。序列化时，系统当前类的serialVersionUID写入序列化文件中，当反序列化时，回去检测文件中的serialVersionUID，看它是否和当前类的serialVersionUID一致，如果不一致，无法完成反序列化。

Seriallizable用起来简单但是开销大，序列化和反序列过程需要大量的I/O *** 作，而Parcelable是Android序列化方式，更适合Android平台，效率更高。Parcelable主要用于内存序列化上，而Seriallizable更适用于序列化到本地存储设备，或者将对象序列化后通过网络传输到别的客户端。

Activity、Service、Receiver都支持在 Intent中传递Bundle数据，Bundle实现了Pareclable接口,所以它可以方便地在不同进程间传输。

Android基于Linux，使得其并发读写文件可以没有限制的进行，两个进程可以通过读写一个文件来交换数据。共享数据对文件格式没有要求，双反约定就行。使用文件共享很有可能出问题。

SharedPreferences是个特例，虽然也是属于文件的一种，但是由于系统对它的读写有一定的缓存策略，即在内存中会有一份SharedPreferences文件的缓存，因此在多进程模式下，系统对他的读写变得不可靠，高并发的时候，很大可能会丢失数据。

Messenger可以在不同的进程中传递Message对象，在Message中存入我们需要传递的数据，就可以实现数据的跨进程传递。它是一种轻量级的IPC方案，底层实现是AIDL。

Messenger对AIDL做了封装，使得我们可以更便捷的实现跨进程通信，它一次只处理一个请求，在服务端不用考虑线程同步问题，在服务端不存在并发执行的情形。实现一个Messenger有如下几个步骤：

在服务端创建一个Service，同时创建一个Handler，并通过它来创建一个Messenger对象，然后再Service的onBind中返回这个Messenger对象底层Binder即可。

绑定服务端Service，绑定成功后用服务端返回的IBinder对象创建一个Messenger。通过这个对象就可以向服务端发消息了。如果需要服务端回应客户端，就需要和服务端一样，创建一个Handler，并通过它来创建一个Messenger对象，然后把这个Messenger对象通过Message的replyTo参数传给服务端，服务端可以通过这个replyTo参数回应客户端。

首先要创建一个Service用来监听客户端的连接请求，然后创建一个AIDL文件，将暴露给客户端的接口在这个AIDL文件中声明，最后在Service中实现AIDL接口即可。

绑定服务端的Service，将服务端返回的Binder对象转成AIDL接口所属的类型，接着就可可以范文AIDL里边的方法了。

在AIDL文件中，并不是所有的额数据类型都是可以使用的。

以上6种数据就是AIDL所支持的所有类型，其中自定义的Parecelable对象和AIDL对象必须显示的import，不管是否和当前的AIDL文件位于同一个包。

AIDL文件中用到了自定义的Parcelable对象，必须新建一个同名的AIDL文件，在其中声明它为parcelable类型。

AIDL中除了基础数据类型，其它类型参数都需要标上方向：in、out、inout，in是输入型参数，out是输出型参数，inout是输入输出型参数。

上面是远程服务端示例，AIDL方法在服务端的Binder线程池中执行，因此各个客户端同时连接的时候，会存在多个线程同时访问的情形，所以要在AIDL中处理线程同步，这个CopyOnWriteArrayList支持并发的读写。

AIDL所支持的是一个抽象的List，只是一个接口，因此虽然服务端返回的是CopyOnWriteArrayList，当时Binder会按照List规范去范文数据并最终形成一个ArrayList传递给客户端。

ServiceConnection 的回调方法在UI线程中运行，服务端的方法有可能很久才能执行完毕，需要考虑ANR的问题。

服务的方法本省就运行再Binder线程池中，本身可以执行大量耗时 *** 作，不要去服务端方法中开县城去进行异步任务。

客户端

服务端

RemoteCallbackList是系统提供专门用于删除跨进程listener的，它的内部有一个Map结构，用来保存所有的AIDL回调，这个Map的key就是Binder类型，value是CallBack类型。

客户端解注册的时候，我们只需要遍历服务端所有的listener，找出那个和接注册listener具有相同的Binder对象的服务端listener并把它删除即可。

RemoteCallbackList的beginBroadcast和finishBroadcast必须配对使用。

ContentProvider是Android专门提供不同应用间进行数据共享的方式。底层实现一样是Binder。

系统预置了许多ContentProvider，比如通讯录，日程信息表，只需要通过ContentResolver的query、update、insert、delete方法即可。

---