Android - sendBroadcast() 和 onReceive() - 进程间通信的同步解决方案

Question

我想制作一个库，以同步方式(从客户端)执行一些 Intent 发送/接收的东西。这样我图书馆的客户就不必关心接收器的实现了。

图书馆会在某处发送 Intent 并接收响应。然后将结果同步返回给客户端。

用例是使用 Intent 在我自己的应用程序之间传输一些数据。通常我异步使用 intents 和 receiver(因为它们应该工作)，但这是规则的异常(exception)。

建议的解决方案(简化!)。图书馆:

public class Helper {
private Context context;
private BroadcastReceiver tempReceiver;
private int result = 0;

int getResult() {

    tempReceiver = new BroadcastReceiver() {
        @Override
        public void onReceive(Context context, Intent intent) {
            Helper.this.result = 1;
        }
    };
    context.registerReceiver(tempReceiver);
    context.sendBroadcast(/* ask for smth */);

    Thread.sleep(5000);

    context.unregisterReceiver(tempReceiver);
    return result; 
}
}

客户端是一个想要从库中获取一些数据的应用程序，就像这样:

int timeout = 5000;
Helper lib = new Helper(timeout);
lib.getData();

你怎么看？有哪些威胁？我知道调用 getReturn() 会阻塞并且不能在 GUI 线程中调用。 sleep 解决方案是否可以接受的问题。

Answer 1

我认为您已经了解标准同步与异步的权衡，以及它们有利与不利的情况。

IMO，只有当广播也由您自己的应用程序发送时，您的方法才可行。如果您对系统广播感兴趣，那么 5 秒的延迟可能会在可接受和灾难性之间变化。想象一下，注册了一个“已拍照”广播，然后 5 秒后当用户正在拍摄另一张照片时，您的同步调用返回并且您显示了一些让用户无休止烦扰的东西。

此外，您建议如何处理广播不是一次性而是连续的情况？

我曾尝试在幕后使用 AsyncTask 设计一个 API；并以同步方式公开它。但事实证明，使用此 API 会使客户端代码更加困惑。我得出结论，某些事情不应该同步完成；并继续采用基于回调的异步方法。我想说的是，广播并不意味着同步。

只是我的 2 美分。