虽然我对 Binder 用于跨进程通信的进程有些熟悉，但我想知道它们必须与内核上的 Binder 驱动程序交互这一事实是否显着增加了创建对象的内存开销。
此外，即使交易数量没有增加，创建大量 Binder 是否会限制现有 Binder 的交易速度？
最佳答案
您必须深入研究 libbinder 代码以及内核驱动程序代码才能真正分析内存消耗。然而，开销可能不是很多，因为在内部绑定(bind)驱动程序有它的驱动程序对象，然后链接到调用进程拥有的实际绑定(bind)程序。它还限制了调用进程可以用来处理同时事务的线程数。
就性能而言，主要限制因素将是通过给定 Binder 的交易数据的大小。每个 Binder 都有一个固定大小的缓冲区 (1MB) 来处理该 Binder 的所有事务。因此，如果针对特定 Binder 同时进行多个事务，则所有事务使用的总数据将计入此限制。由于发生的异常(Java 级别)不会指示它是事务的发送 部分还是接收 部分，因此要排除故障或妥善处理这可能非常棘手。经验法则是，通过 Binder 移动的数据需要很小，就像消息传递一样。它不太适合流数据之类的东西。 Android 使用 ashmem 驱动程序支持来更好地处理此问题以及跨绑定(bind)器共享文件描述符的能力。
Binder 本身在 btree 中进行跟踪，因此查找应该非常快。对于给定的进程以及系统中的 Binder 总数是否达到高水平，如果有一些关于此的统计数据会很有趣，但我不知道有任何此类数据。
关于android - Android Binders 的内存开销，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39581915/