IPC学习笔记（二）

4，多进程造成的问题：

    （1）静态成员和单例模式完全失效

    （2）线程同步机制完全失效

    （3）SharePreferences的可靠性下降（底层是通过读/写xml文件来实现的）

    （4）Application会被多次创建

5，Serializable接口实现序列化注意：

     首先静态成员变量属于类不属于对象，不会参与序列化过程

     其次用transient关键字标记的成员变量不参与序列化过程

     备注：系统已经为我们提供了许多实现了Parcelable接口的类，他们都是可以直接序列化的，比如Intent、Bundle、Bitmap等，同时List、Map也可以序列化，前提是它们里面的每个元素都是可序列化的。1，Serializable是JAVA中的序列化接口，其使用起来简单但是开销很大，序列化和反序列化过程需要大量的I/O操作。而Parcelable是Android中的序列化方式，因此更适合再Android平台上，它的缺点是使用起来稍微麻烦点，但是它的效率很高，这是Android推荐的序列化方式，因此我们要首选Parcelable。Parcelable主要用在内存序列化上，通过Parcelable将对象序列化到存储设备中或将对象序列化后通过网络传输也都是可以的，但是这个过程会稍显复杂，因此在这两种情况下建议大家使用Serializable。以上就是Serializable和Parcelable的区别。

6，Binder

     实现了IBinder接口，从AndroidFramework角度来说，Binder是ServiceManager连接各种Manger和相应MangerService的桥梁；从Android应用层来说，Binder是客户端和服务端进行通信的媒介，当bindService的时候，服务端会返回一个包含了服务端业务调用的Binder对象，通过这个Binder对象，客服端就可以获取服务端提供的服务或者数据，这里的服务包括普通服务和基于AIDL的服务。

    Binder主要用在service中，包括AIDL和Messager，Messager底层就是AIDL

7，Messenger

    Messenger是一种轻量级的IPC方案，它的底层实现是AIDL。由于它一次处理一个请求，因此在服务端我们不用考虑线程同步的问题，这是因为在服务端中不存在并发执行的情形。

8，ContentProvider

    ContentProvider主要以表格的形式来组织数据，并且可以包含多个表，除了表格的形式，ContentProvider还支持文件数据，比如图片、视频等。对底层的数据存储方式没有任何要求，我们既可以使用SQLite数据库，也可以使用普通的文件，甚至可以采用内存中的一个对象来进行数据的存储。

    (1)ContentProvider注册时，其中android:authorities是ContentProvider的唯一标识，通过这个属性外部应用就可以访问我们的ContentProvider，因此，android:authorities必须是唯一的，这里建议读者在命名的时候加上包名前缀。

     (2)需要注意的是，query、update、insert、delete四大方法是存在多线程并发访问的，因此方法内部要做好线程同步。如果采用SQLite并且只有一个SQLiteDatabase的连接，所以可以正确应对多线程的情况。具体原因是SQLiteDatabase内部对数据库的操作是有同步处理的，但是如果通过多个SQLiteDatabase对象来操作数据库就无法保证线程同步，因为SQLiteDatabase对象之间无法进行线程同步，如果ContentProvider的底层数据集是一块内存的话，比如是List，在这种情况下同List的遍历、插入、删除操作就需要进行线程同步，否则会引起并发错误，这点是尤其需要注意的。

9，Socket

    Socket也称为“套接字”，是网络通信中的概念，它分为流式套接字和用户数据报套接字两种，分别对应于网络的传输控制层中的TCP和UDP协议。

    TCP： 是面向连接的协议，提供稳定的双向通信功能，连接的建立需要经过“三次握手”才能完成，为了提供稳定的数据传输功能，其本身提供了超时重传机制，因此具有很高的稳定性；接收方法是accept();

    UDP： 无连接的，提供不稳定的单向通信功能，当然UDP也可以实现双向通信功能，在性能上，UDP具有更好的效率，其缺点是不保证数据一定能够正确传输，尤其是在网络拥塞的情况下；接收方法是receive();