模块边界定义与职责

模块边界是架构设计的核心骨架。边界不清晰时，调用链会无规则地穿越模块内部，导致主线程阻塞难以定位，ANR 治理沦为“打地鼠”游戏。本章从划分原则、契约机制、接口抽象、依赖倒置四个维度，构建可落地的模块边界体系，使其能承载 ANR 调用链的追踪与阻断需求。

4.1 模块划分原则

模块划分决定了 ANR 调用链的可追踪粒度。原则如下：

• 单一职责：一个模块只承担一个业务或技术关注点，避免“上帝模块”拖慢主线程。
• 按线程域分层：UI 模块、工作线程模块、后台任务模块严格分离，阻断阻塞传播。
• 按变化速率切分：业务变化快的模块与基础设施稳定模块分属不同边界，降低回归风险。
• 高内聚低耦合：模块内部高度相关，对外暴露最小依赖，减少调用链穿透深度。

4.2 边界契约

边界契约是模块间协作的“法律文件”。它定义了三要素：

4.3 接口抽象

接口抽象是隔离变化、阻断 ANR 传播的关键手段。核心设计原则：

• 面向接口编程：调用方只依赖抽象，不依赖具体实现类。
• 接口隔离：客户端不应依赖它不需要的方法；胖接口拆分为多个细粒度接口。
• SPI / API 分离：服务提供接口（SPI）供实现方继承，应用编程接口（API）供调用方使用，两类接口分属不同包路径。

// 边界契约示例：异步任务执行器接口
public interface TaskExecutor {
    @WorkerThread
    void execute(@NonNull Runnable task,
                 @Nullable TaskCallback callback);

    boolean isCurrentThreadWorker();

    long getMaxExecutionTimeMs();
}

4.4 依赖倒置

依赖倒置原则（DIP）是模块边界解耦的底层保障。其核心含义是：

• 高层模块不依赖低层模块：两者都依赖抽象接口。
• 抽象不依赖细节：细节依赖抽象。

在 Android 架构中，这意味着 ViewModel 不直接依赖 OkHttp 或 Room，而是依赖 UserRepository 接口；具体实现通过依赖注入框架（如 Hilt）在模块初始化时提供。

// 依赖倒置：ViewModel 只依赖抽象
public class HomeViewModel extends ViewModel {
    private final UserRepository userRepo;

    @Inject
    public HomeViewModel(UserRepository userRepo) {
        this.userRepo = userRepo;  // 运行时注入具体实现
    }
}

4.5 数据流 / 控制流 / 信任链路

模块边界内三种流的设计决定了 ANR 调用链的可观测性：

4.6 选型权衡

模块边界的具体实现需要根据项目阶段和团队规模做出选择：

• 接口 vs 消息队列：同步接口适合低延迟、强一致场景；消息队列适合解耦、削峰场景，但增加异步追踪复杂度。
• 编译期依赖 vs 运行时路由：编译期依赖（Java 接口）类型安全、重构成本低；运行时路由（ARouter / 事件总线）更灵活，但调用链隐式，不易追踪。
• 集中式 DI 容器 vs 手动注入：大型项目推荐 Hilt / Dagger 统一管理依赖；小型项目手动注入更轻量，避免编译期开销。

4.7 风险点

1. 循环依赖：模块 A 依赖 B，B 依赖 A 导致编译失败或运行时栈溢出。必须通过引入抽象层或事件总线打破循环。
2. 边界泄漏：实现类被错误地暴露给外部模块，导致调用方直接依赖具体实现，绕过契约。
3. 抽象泄漏：接口中抛出底层异常（如 SQLException）或使用底层类型，导致调用方感知实现细节。
4. 信任链断裂：跨模块调用时未做降级处理，底层故障直接导致上层 ANR。

4.8 落地步骤

4.9 验收标准

• 依赖方向验证：使用 ArchUnit 检查所有模块依赖方向与架构图一致，不存在反向依赖或循环依赖。
• 接口稳定性：契约接口在 2 个迭代周期内无破坏性变更（新增方法不破坏兼容性）。
• 边界测试通过率 100%：所有跨模块调用的契约测试、线程归属测试、超时熔断测试全部通过。
• 调用链可追踪：在模块边界处打印跨模块调用摘要日志，可在 5 分钟内定位到具体模块及调用堆栈。