Question

我读了一篇关于android的活页夹的文章。文章说，进程交换共享内存中的对象引用，并且它比编组和解组更有效......但实际上在IPC机制中是否有编组和解组？我有点困惑......

任何人都可以解释粘合剂机制或链接到详细的文章吗？

Answer 1

Binder是一种在内核中运行的优化编组方法。

关于它的几个链接：

http://www.cubrid.org/blog/dev-platform/binder-communication-mechanism-of-android-processes/ http://lukejin.wordpress.com/2011/03/13/android%E4%B8%AD%E7%9A%84binder/

Answer 2

http://marakana.com/s/post/1340/Deep_Dive_Into_Binder_Presentation.htm

此链接提供了有关Binder如何作为架构工作的非常有用的概述，并提供了使用Binder与应用程序开发人员相关的各个方面的示例代码（Intents，Messenger，AIDL）。

Answer 3

文章说过程交换了对象引用共享内存

Binder不使用共享内存（ashmem也不是pmem）。它使用具有固定大小缓冲区的内核驱动程序。数据以安全的方式复制进出内核。也许文章松散地使用“共享内存”。

我认为混淆是在Binder协议和Android的“Binder”RPC机制之间。就proto而言，它只是被复制进出的字节。 Android平台使用Binder内核驱动程序实现类似OO的RPC机制。这当然会将对象“编组”为字节，并将另一侧的对象解组为一个对象。这是在Parcel类和Parcelable接口的帮助下完成的。

Answer 4

一个古老的问题，但值得一个最新答案：

Binder工具使用了手柄，可以更快，更轻松地处理对象。在某些情况下，仅返回对象句柄，而不必通过封送整个对象，然后可以通过其方法对其进行操作。这意味着该对象的大部分（可能很大）完全不需要编组-节省了CPU和开销。

作为示例，请考虑如何执行屏幕捕获。（q.v.屏幕截图实用程序的来源），或（作为另一个示例）MediaPlayer的工作方式。活页夹将获取远程对象的句柄，但该对象实际上并没有“通过电线”。调用“创建”方法

   virtual sp<IMediaPlayer> create(const sp<IMediaPlayerClient>& client,
            audio_session_t audioSessionId = AUDIO_SESSION_ALLOCATE) 

flame:/ $ service call media.player 1
Result: Parcel(
  0x00000000: 73682a85 00000113 00000002 00000000 '.*hs............'
  0x00000010: 00000000 00000000 0000000c          '............    '

“ * hs”（实际上是* sh）是Binder STRONG HANDLE，这意味着与其关联的描述符（在这种情况下为“ 2”）随后可用于后续的直接调用中，以调用IMediaPlayer功能。如果随后针对该接口探测了返回的描述符，则可以证明这一点：

flame:/ $ /data/local/tmp/bdsm call media.player 1                                                                                     
Got handle to android.media.IMediaPlayerService
Object 0 (desc 2) is a handle to android.media.IMediaPlayer

与预期的一样（sp）。这意味着现在可以直接调用IMediaPlayer实例的方法。

顺便说一句，虽然Binder确实不使用共享内存，但是上述关于ashmem的答复并不完全准确。 ashmem将Anonymous SHared MEMory映射到文件描述符上，然后该文件描述符通过Binder从进程A移到B（这可以像UN * X域套接字一样移动文件描述符）。此外，每当您看到IBinderToken项目“封送”到该项目时，包裹都可以保留这些* SH（强力手柄）。

Android - Binder

4 个答案: