1. Better devex. The toolchain for binder properly checks that you are writing and reading transactions correctly and if you don't you get a compile time error. Meanwhile using dbus you can call things wrong and it will still compile.
2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process.
3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.
2. Better latency. When you send a Binder transaction to another process Linux will immediately schedule the binder thread of the other process, unless it's a oneway transaction that does not block executon. Then once the other process replies, the original process is immediately rescheduled. Dbus does not affect Linux's scheduling of processes. When you send a dbus message any other process can be scheduled and run instead of the bus. And then anything can run in-between the bus sending the message to the target process.
3. Having the message go through the bus also results in extra copying. Not just cheap copying of memory. Since it's through a UNIX socket it has to use extra system calls to read out of and into another socket. As opposed to binder where it's able to simply copy the memory of the parcel from one process to another.