我什么时候应该使用 Android 的每种不同消息类型？
我使用 Android 已有一年多了，但我仍然无法确定何时应在进程/线程之间使用不同类型的消息传递/通信。 我主要讨论广播 Intents、使用 AIDL 进行服务、使用 Handler 发送消息和套接字通信。
其中许多工具可用于完成类似的任务，但哪个更适合特定情况？
I've been working with Android for well over a year now, but I still have trouble determining when different types of messaging/communication between processes/threads should be used. I'm mainly talking about broadcasting Intents, using AIDL for services, using Handlers to send messages and socket communication.
Many of these tools can be used to accomplish similar tasks, but which is better suited to particular situations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是一个非常开放式的问题，但让我尝试描述一下我如何看待应用程序内/间通信工作得最好。
Android 消息传递的关键方面之一是所有应用程序组件松散绑定的概念。 由于所有应用程序都在单独的进程中运行，并且一个“应用程序”实际上可能由多个应用程序（负责提供不同的活动或服务）组成，因此消息传递技术均基于跨进程边界编组消息的思想。
Intent
作为消息传递的首选技术，只要有可能，请始终尝试使用 Intent。 这是 Android 中最“原生”的消息传输方式。
优点
使用 Intent 进行消息传递可以保持应用程序组件的松散绑定，使您可以在多个应用程序之间无缝传输消息。 意图在核心系统中被大量使用来启动活动和服务，以及广播和接收系统事件。
使用 extras Bundles，您可以将基元的键/值对作为有效负载数据包含在 Intents 中，以便轻松地将信息从一个应用程序组件传递到另一个应用程序组件 - 即使这些组件在不同的进程中运行。
缺点
由于 Intent 被设计为在进程之间传递，因此额外负载仅支持原始类型。 如果您需要使用 Intent 发送对象，则需要在一端将其解构为基元，并在另一端将其重建。
应用程序类
如果您只想在单个进程中运行的单个应用程序中进行通信，那么这是一个方便的解决方案。
优点
通过扩展
Application类（并将其实现为单例），您将获得一个对象，只要您的任何应用程序组件存在，该对象就会存在，从而提供一个集中的位置来存储和在应用程序组件之间传输复杂的对象数据。缺点
这种技术将消息传递限制在单个应用程序中的组件。
服务绑定、IPC 和 AIDL
通过绑定到服务，您可以访问其方法并与其交换对象。 AIDL 是一种定义如何将对象序列化为操作系统原语的方法，以便在您绑定的服务在单独的应用程序中运行时可以跨进程边界对其进行编组。
优点
当您绑定到服务时，您可以访问它，就好像它是调用类中的对象一样。 这意味着您可以在服务上执行方法并与其交换丰富的对象。
请注意，如果您要绑定到不同应用程序进程中的服务，则需要创建 AIDL 定义来告诉 Android 如何序列化/反序列化您想要在应用程序之间传递的任何对象。
缺点
为 IPC 创建 AIDL 类需要一些额外的工作，并且绑定会在服务和活动之间创建额外的依赖关系，这会使内核在其他应用程序资源匮乏时更难以清理资源。
不过，跨进程边界编组消息的成本很高。 因此，如果您不在服务上执行方法，那么使用绑定和 IPC 可能有点过分 - 看看您是否可以使用 Intents 实现相同的目标。
套接字
如果您使用套接字在单个设备上运行的应用程序内部或之间进行通信，那要么是因为没有其他方法，要么是您在某个地方错过了一个技巧。 如果您的消息要离开设备，那么套接字是一个很好、快速的替代方案。 如果您继续使用设备，则 Intents 或 IPC 可能是更好的选择。
This is a pretty open ended question, but let me take a shot at describing how I see the intra/inter application communication working best.
One of the key aspects of Android messaging is the concept of all application components being loosely bound. Because all applications run in a separate process, and one 'app' may actually consist of several applications (responsible for providing different Activities or Services), the messaging techniques are all based around the idea of marshaling messages across process boundaries.
Intents
The preferred technique for messaging, always try to use an Intent whenever possible. It is the most 'native' way to transfer messages within Android.
Advantages
Using Intents for messaging maintains the loose binding of application components, letting you transfer messages seamlessly between several applications. Intents are used heavily within the core system to start Activities and Services, and to broadcast and receive system events.
Using extras Bundles you can include key/value pairs of primitives as payload data within Intents to easily pass information from one application component to another - even if those components are running in different processes.
Disadvantages
Because Intents are designed to go between processes, the extras payload only supports primitive types. If you need to send an object using an Intent you'll need to deconstruct it into primitives at one end and reconstruct it at the other.
Application Class
If you only want to communicate within a single application running in a single process this is a handy solution.
Advantages
By extending the
Applicationclass (and implementing it as a Singleton) you get an object that will exist whenever any of your application components exist, providing a centralized place to store and transfer complex object data between application components.Disadvantages
This technique limits your messaging to components within a single application.
Service Binding, IPC, and AIDL
Binding to a service lets you access its methods and exchange objects with it. AIDL is a way of defining how to serialize an object into OS primitives so that it can be marshalled across process boundaries if the Service you're binding to is running in a separate application.
Advantages
When you bind to a Service you have access to it as though it was an object within the calling class. That means you can execute methods on the Service and exchange rich objects with it.
Note that if you're binding to a Service in a different application process you'll need to create the AIDL definitions that tell Android how to seralize / deserialize any objects you want to pass between applications.
Disadvantages
Creating the AIDL classes for IPC is a bit of extra work, and binding creates additional dependencies between Services and Activities which can make it harder for the kernel to clean up resources when other applications are being starved.
Marshelling messages across process boundaries is expensive though. So if you're not executing methods on a Service, using binding and IPC is probably overkill - see if you can achieve the same thing using Intents.
Sockets
If you're resorting to sockets to communicate within or between applications running on a single device, it's either because there's no other way or you've missed a trick somewhere. If your messages are leaving the device then sockets are a good, fast, alternative. If you're staying on the device chances are Intents or IPC is going to be a better option.
这完全取决于您的应用程序的用例和类型。 如果应用程序始终运行，最好使用 AIDL 方法，因为它是最安全的通信方式。 如果应用程序不需要一直运行，那么您可以使用广播意图或挂起意图方法在应用程序之间进行通信。
It all depends on the use case and kind of your application. If the application is running all the time better to go with AIDL approach as it is most secure way to communicate. If application need not run all the time, then you can go with either broadcast intent or pending intent approach to communicate between applications.
我的2美分
似乎有点矫枉过正，因为你必须这样做
生成并解析数据。
其他应用程序可能想做的事（启动
我在撰写窗口中或选择
一些东西）
GUI 与无头进程对话
正在不断运行。 根据
该应用程序有很多实际数据
传输可能会使用内容进行
提供商，但我倾向于有一些数据
需要转移到外面的
该频道的。
My 2 cents
Seems like overkill since you have to
generate and parse the data.
other apps might want to do (launch
me in a compose window or to pick
something out)
GUI talk to a headless process that
is running constantly. Depending on
the app a lot of the actual data
transfer might happen using a content
provider but I tend to have some data
that needs to be transferred outside
of that channel.
这是一篇很好的文章，我发现它有助于寻找 Cocoa 的 NSUserDefaults 类的替代品：
http://developer.android.com/guide/appendix/faq/framework.html
This is a good article I found helpful in trying to find a substitute for Cocoa's NSUserDefaults class:
http://developer.android.com/guide/appendix/faq/framework.html