问题：
它是否更好＆＃34; （=更快，更少开销）与在Android中使用Handler进行Messenger通信相比，使用Messenger进行处理程序通信？
情况：
Android应用程序，其中包含一系列活动和一个正在运行的服务（已启动的服务）。在服务中，一些线程在服务的主线程旁边运行。 应用程序启动，第一个活动启动服务，服务启动，第一个活动转发到第二个活动，第二个活动绑定到服务，...
处理程序处理程序：
...服务分发对服务处理程序的引用，第二个活动定义自己的处理程序，第二个活动现在可以使用服务处理程序直接与服务通信。要让服务处理程序知道它必须回复活动处理程序，Message对象中的 msg.obj 字段可用于设置＆＃34;回复＆＃34 ; handler（=活动中的处理程序）。现在，在活动和服务之间成功地建立了双向沟通。
Messenger to Messenger：
...服务发出对服务信使的引用，第二个活动定义了自己的信使，第二个活动现在可以使用服务信使间接地与服务进行通信，服务信使将消息（消息对象）转换为一个Parcelable对象，然后将Parcelable对象重新转换回一个新的（但相等的）Message对象，该对象被移交给服务的处理程序。要让服务信使知道它必须回复活动信使，可以使用活动中的信使设置 msg.replyTo 字段。双向沟通成功完成。
＆＃34;问题＆＃34;：
当我只需要在我的应用程序中进行直接通信时，为什么我需要Messenger to Messenger设置？一个进程中的所有线程都可以通过使用其处理程序轻松进行通信（假设这些线程都已正确设置了自己的处理程序）。我不希望信使首先展平两个处理程序之间共享的Message对象，这只是在没有任何目的的情况下增加了开销，除了＆＃34;盲目地遵循Android服务教程＆＃34;。
可能的解决方案：
启动服务，绑定一次，让服务分发本地绑定对象，在onServiceConnected（）的ServiceConnection实现中设置活动中的服务处理程序，让活动将它存储在全局内存空间的某个地方，切换到第三个，第四个，第五个活动，你永远不必再在所有其他活动中绑定，因为所有活动都知道自己的处理程序（在每个活动中单独设置），并且可以从全局内存空间获取服务处理程序。如果服务需要响应第四个活动的处理程序，则第四个活动只是将自己的处理程序（fourthHanlder）添加到msg.obj字段，并且服务知道必须在何处发送回复消息。那就是它。
除此之外：活动在ui-thread / main-thread上运行，服务也在ui-thread / main-thread上运行，所以实际上它们是同一个线程的一部分，只有不同的处理程序。或者这是我的错误思考？
这意味着整个Messenger的东西只是同一进程中线程之间本地（内部）通信的额外开销！这是不需要的，除非Android系统在内部判断出信使是否在同一过程中相互通信并绕过消息的扁平化并跳过转换为Parcelable对象，以便信使实际上直接在处理程序之间进行排序（没有用户/程序员实际上已经意识到了这一点。至少我不知道这个，如果这正是我现在想的那样。）
我发现只有三种方法可以使用以下方法在活动和服务之间创建异步通信：
我相信处理程序是线程之间进行通信的最快方式，后续是信使，最后是意图。这是真的？？？
请分享您对此事的见解和经验，即使我看到的不正确:) 谢谢。
答案 0 :(得分：9)