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