处理程序处理器与信使在Android的信使通信 [英] Handler to Handler VERSUS Messenger to Messenger communication in Android
问题描述
的问题：
它是更好（=速度更快，开销更少）来使用处理程序到处理器通信相比，使用使者到Messenger通讯在Android中？
的情况：
Android的应用程序，有一堆的活动和一个服务运行（启动服务）。在服务的几个线程在运行该服务旁边的主线程。 应用程序启动时，第一个活动启动服务，服务启动，第一个活动转发到第二个活动，第二个活动结合服务，...
处理程序来处理程序：的
...服务转手出去参照服务处理器，第二个活动定义了它自己的处理程序，第二个活动现在可以使用通信服务处理器直接服务。为了让服务处理器知道它有回复的活动处理程序，在 msg.obj 的讯息对象可用于设置回复处理器（=活动中的处理程序）。现在的双向通信是活动和服务之间成功地设置。
使者到Messenger：的
...服务转手出去参照服务信使，第二个活动定义了自己的信使，第二个活动现在可以使用通信服务的使者，后者将消息（Message对象）为间接服务一个Parcelable对象，然后重新翻译的Parcelable对象返回到一个新的（但相等）Message对象，这是交给服务的处理程序。为了让服务信使知道它有回复到活动使者，在 msg.replyTo 字段可以设置在活动中的使者。双向通信成功地安装。
的问题：
为什么需要信使到Messenger安装时，我只需要在我的应用程序直接沟通，这只是一个进程的范围内？在一个进程中的所有线程可以很容易地通过使用他们的处理程序（假设这些线程都建立自己正确的处理程序）进行通信。我不想使者第一平整消息对象之间共享两个处理程序，这只是额外开销，除了没有盲目跟随了Android服务指南的任何目的。
可能的解决方法：
在活动中启动该服务，绑定一次吧，让服务的手出了当地的粘合剂对象时，ServiceConnection实施onServiceConnected内设置（）服务处理器，让活性存储在某个地方在全局内存空间，切换到第三，第四，第五个活动，你从来没有在其他所有活动再次绑定，因为所有的活动，知道自己的处理器（安装在每个单独的活动）和可以从全局内存空间中的服务处理器。如果该服务需要第四活动的处理函数做出响应，第四活动只是增加了自己的处理程序（fourthHanlder）到msg.obj领域和服务知道必须向其中发送回复信息。就是这样。
除此之外：活动运行的ui线程/主线程上和服务还运行UI线程/主线程上，所以实际上它们是相同的主题的一部分，只对不同的处理程序。或者，这是不正确的思想在我的部分？
这意味着整个信使件事是本地（内部）在同一进程线程之间的通信只额外的开销！这是不需要的，除非Android系统计算出在内部，如果使者在同一进程中相互沟通，绕过邮件的扁平化，并跳过翻译成Parcelable对象，从而使使者实际上是处理程序本身之间进行通信sortof直接（不用户/程序员实际上是意识到了这一点。嗯，至少我没有意识到这一点，如果这是真的什么，我想现在）。
我看到有只有三个，你可以通过创建活动和服务之间的异步通信方式：
- 意图（不能发送与意向对象！）
- 使者（以相对于直接使用处理程序，例如可能是有限的：你不能排队一个消息队列的前面）
- 处理程序（仅当该处理程序所属的线程在同一进程内，否则你需要使者）
我相信处理程序的线程间通信最快的方式，跟进的使者，最后的意图。这是真的？？？
请在这个问题上分享您的见解和经验，甚至当我看到这个错误:) 谢谢你。
我看到有只有三个，你可以创建活动和服务之间的异步通信方式
废话。
今天，我会用一个事件总线服务 - >活动通信（ LocalBroadcastManager ，广场的的奥托，greenrobot的 EventBus ）。无需绑定，无需为自己的处理程序，没必要为自己的使者，和更大的灵活性。
除此之外，如果您使用绑定，创建自己的监听器接口，比你如何使用 OnClickListener 来听按钮点击没有什么不同。唯一的变化是，你会得到提高，除了事件（调用监听器方法）来接收事件。
和，另外还有 ResultReceiver ，虽然我没有看到，使用了将近这么多了。
The question:
Is it "better" (= faster and less overhead) to use Handler to Handler communication compared to using Messenger to Messenger communication in Android?
The situation:
Android App that has a bunch of activities and one service running (started service). Within the service a few threads are running next to the main thread of the service. Application is started, first activity starts the service, service starts, first activity forwards to second activity, second activity binds to service,...
Handler to Handler:
...service hands out reference to service handler, second activity defines its own handler, second activity can now communicate to service directly using the service handler. To let the service handler know it has to reply to an activity handler, the msg.obj field within a Message object can be used to set the "reply-to" handler (= the handler within the activity). Now a two-way communication is sucessfully setup between activity and service.
Messenger to Messenger:
...service hands out reference to service messenger, second activity defines its own messenger, second activity can now communicate to service indirectly using the service messenger, which translates the message (Message object) into a Parcelable object, then re-translates the Parcelable object back into a new (but equal) Message object, which is handed over to the handler of the service. To let the service messenger know it has to reply to the activity messenger, the msg.replyTo field can be set with the messenger within the activity. Two-way communication sucessfully setup.
The "problem":
Why do I need Messenger to Messenger setup when I only need direct communication in my App that is within the boundaries of only one process? All threads within one process can easily communicate through the use of their Handlers (assuming these threads all have setup their own handlers correctly). I don't want messengers first flattening the Message objects shared between to two Handlers, that is just added overhead without any purpose besides "following the Android Service tutorial blindly".
Possible solution:
Start the service, bind once to it, let the service hand out a local binder object, set within the ServiceConnection implementation of onServiceConnected() the service handler within the activity, let the activity store it somewhere in a global memory space, switch to a third, forth, fifth activity and you never have to bind again in all the other activities, because all activities know their own handler (setup in each activity separate) and the can get the service handler from the global memory space. If the service needs to respond to the handler of the fourth activity, the fourth activity just adds its own handler (fourthHanlder) to the msg.obj field and the service knows whereto the reply message must be sent. That's it.
Besides that: the activity runs on the ui-thread/main-thread and the service runs also on the ui-thread/main-thread, so actually they are part of the same thread, only different handlers. Or is this incorrect thinking on my part?
This means the whole Messenger thing is only extra overhead for local (internal) communication between threads in the same process! It is not needed, unless the Android system figures out internally if the Messengers mutually communicate within the same process and bypass the flattening of the Messages and skip the translation into Parcelable objects, so that the Messengers actually communicate sortof directly between the Handlers themselves (without the user/programmer actually being aware of this. Well at least I am not aware of this if this is true what I am thinking right now).
I see that there are only three ways you can create asynchronous communication between activities and services by using:
- Intents (can't send objects with an Intent!)
- Messengers (are limited in possibilities compared to using Handlers directly, for example: you can't queue a message to the front of the queue)
- Handlers (only possible when the threads to which the handlers belong are within the same process, otherwise you DO need Messengers)
I believe the handlers are the fastest way to communicate between threads, followed up by the messengers and last are intents. Is this TRUE???
Please share your insights and experiences on this matter, even when I am seeing this incorrectly :) Thank you.
I see that there are only three ways you can create asynchronous communication between activities and services
Nonsense.
Nowadays, I would use an event bus for service->activity communications (LocalBroadcastManager, Square's Otto, greenrobot's EventBus). No need to bind, no need for your own Handler, no need for your own Messenger, and greater flexibility.
Beyond that, if you are using binding, just create your own listener interface, no different than how you use an OnClickListener to listen to button clicks. The only change is that you would be raising the event (calling the method on the listener) in addition to receiving the event.
And, there's also ResultReceiver, though I do not see that used nearly so much.
这篇关于处理程序处理器与信使在Android的信使通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
