对android的binder机制的理解

1:对android的binder机制的理解

所谓的client和server都是通过binder驱动，然后由binder驱动去调用ServiceManager来通信的，之所以叫通信，是因为client和server之间都是获取一个object对象来通信而已。

也就是说，client通过binder渠道拿到了一个存放在server那边的Object，但是这个Object其实只是一个影子对象而已，想修改这个Object里面的值，只能通过binder驱动的方法去执行server那边的改动的方法。这个就是binder机制里面的client和server，binder渠道，serviceManager最直观的表现。

（

有一些技巧就是

AIDL的数据类型有限，又不想去做序列化，这时候可以在server那边的实现的代码把对象通过json转成string然后通过aidl通信返回给client，client再使用json的反序列化把字符串给解析出来就好，就不要在传递过程中强行去要求一定要返回的对象是什么类型了

再有就是带的值是个map的时候可以用bundle

）

1.2:知道上面最简单的一个通信过程之后，可以得知的就是，不同进程都可以看成是一个client，这些client都是通过binder渠道（内部再通过serviceManager）的方式，来获取同一个的进程的server进程里面的Binder这个Object对象。

也就是，不用的client其实都是拿到那个server那边的Object的引用，他们都可以对同一个对象做操作，

这时候的疑问就在于，

为什么可以不同的进程还来访问的是同一个对象呢？

因为操作系统里面每个进程都是分隔开的，但是操作系统系统了一种叫binder的通信方式，允许进行内核之间的进程进行数据的传递，所以就实现了进程间的通信。

Android里面的多进程访问同一个对象是因为，多个client进程都是对同一个server进程的数据进行访问，只要提供了binder保证进程间可以通信后，多个client访问同一份server数据，自然就访问的是同一个对象了。

怎么保证多进程同步的问题？：server获取的过程是阻塞式的，所以是进程同步的