同步调用与异步调用选择

在 SystemUI 的 Binder 通信中，选择同步还是异步调用直接影响线程模型、响应延迟和 ANR 触发概率。本章从 oneway 标记、blocking 行为、回调方式 和 ANR 避免策略 四个维度展开，帮助你作出正确的设计决策。

4.1 同步与异步核心对比

特性 同步调用（非 oneway） 异步调用（oneway）
调用线程阻塞 是，直至返回或超时 否，立即返回
服务端返回数据 支持（通过返回值或 out 参数） 不支持，void 返回
Binder 线程池占用 调用期间占用客户端线程 + 服务端线程 仅占用短暂发送时间
触发 ANR 风险 高（若服务端慢或网络阻塞） 低（不阻塞主线程）
典型场景 查询配置、读取状态、同步操作 通知事件、请求更新、日志上报

4.2 oneway 标记

在 AIDL 接口中，oneway 关键字声明该方法是异步调用。声明后 Binder 驱动将事务发送到目标进程后立即返回，不等待回复。服务端仍然会串行处理该事务，但调用方不会阻塞。

定义范例： 
// IStatusBar.aidl
oneway void notifyPanelStateChanged(int state);
void getSystemUiState(out int state);  // 同步

客户端调用 notifyPanelStateChanged 时不会阻塞，而 getSystemUiState 会等待服务端返回结果。注意：oneway 方法不能有返回值，也不能有 out 参数。

4.3 blocking 行为与线程模型

同步调用发生时，调用线程会进入 Binder 事务等待状态，直至服务端回复或超时（默认 5 秒）。若该线程是 SystemUI 的主线程（即 UI 线程），等待期间无法处理触摸事件、绘制等，超过 5 秒将触发 ANR。

以下日志片段展示了同步调用阻塞主线程的情形：

// logcat 中可见主线程 stuck
I/Binder: Binder call to com.android.systemui: IStatusBar.getSystemUiState
D/ANRManager: Input dispatching timed out (Waiting because no window has focus...)
W/ActivityManager: ANR in com.android.systemui (main thread of process...)
  Reason: Input dispatching timed out (No focused window)

解决方案：主线程尽量避免同步 Binder 调用；若确实需要，应使用异步回调或切到工作线程。

4.4 回调方式

对于必须异步获得结果的场景，可以设计 回调接口。客户端注册一个 binder 回调对象，服务端在完成操作后调用回调方法传递结果。

回调设计示例： 
// IStatusBarCallback.aidl
interface IStatusBarCallback {
    void onResult(int code, in Bundle data);
}

// IStatusBar.aidl（新增异步方法）
oneway void requestConfigurationUpdate(in IStatusBarCallback callback);

客户端实现：

// 客户端注册回调
IStatusBarCallback.Stub callback = new IStatusBarCallback.Stub() {
    @Override public void onResult(int code, Bundle data) {
        // 此处运行在 Binder 线程池，不可直接更新 UI
        // 可通过 Handler 切回主线程
    }
};
mStatusBar.requestConfigurationUpdate(callback);

回调方式既避免了主线程阻塞，又实现了结果传递，是 SystemUI 中推荐的异步模式。

4.5 ANR 避免策略

  • 主线程禁止同步调用：除非服务端在本进程内且快速返回（如 <1ms），否则必须使用 oneway 或回调。
  • 设置合理超时：同步调用可通过设置 Binder.setThreadStrictMode 或自定义 timeout，但不能阻止 ANR（系统超时固定）。
  • 批量合并 oneway 请求：多个频繁 oneway 通知可合并成一个事务，减少 Binder 驱动压力。
  • 使用线程池隔离：将可能阻塞的同步调用放到 AsyncTask 或 HandlerThread 中执行。
  • 监控 Binder 事务延迟：结合 dumpsys binder 和 systrace 分析服务端响应耗时。
常见错误：
  1. 将 oneway 方法误用于需要返回值的场景（编译器报错或设计缺陷）。
  2. 在回调中直接更新 UI 导致崩溃（应在回调中 post 到主线程 Handler）。
  3. 忽略 oneway 调用的顺序性：虽然 oneway 不阻塞，但同一 Binder 对象上的 oneway 调用在服务端串行执行，不会乱序。

4.6 同步与异步调用流程图

同步 vs 异步 Binder 调用流程 同步调用 vs 异步调用（oneway）Binder 通信流程 同步调用（非 oneway） 客户端（主线程） 调用 transact() 阻塞 Binder 驱动 服务端（处理中） 回复（返回数据/异常） 客户端继续执行 ⚠ 主线程阻塞 5s → ANR 异步调用（oneway） 客户端（任意线程） 调用 transact(oneway) 立即返回 Binder 驱动 服务端（排队处理中） 无回复，调用方不等待 客户端继续执行 ✓ 主线程立即返回，无 ANR 风险 核心原则：主线程只允许 oneway 调用；同步调用必须放到工作线程或使用回调。

4.7 小结

同步调用与异步调用的选择直接决定 SystemUI 的稳定性和流畅度。建议遵循以下优先顺序：

  1. 能 oneway 则 oneway（通知、请求、事件）。
  2. 需要结果时使用回调方式，避免主线程阻塞。
  3. 必须同步获取数据时，确保调用发生在非主线程（如 HandlerThread 或 WorkThread）。
  4. 始终监控 binder 事务耗时，结合 systrace 和 log 排查潜在的 ANR 风险。
← 上一章 📖 返回目录 下一章 →