从Android 16的qpr2版本开始Launcher3全面引入了Dagger，为什么要引入Dagger，我们看一下引入Dagger的架构对比。

引入前：

idea1

引入后：

idea1

再来一张放一起的图，更清晰：

idea1

Dagger2 的引入核心目标是：

  1. 减少传统静态单例依赖
    • 旧版 Launcher 大量使用 LauncherAppState.getInstance()、SomeSingleton.INSTANCE 等静态单例，这导致：
      • 生命周期难以控制
      • 测试难以替换依赖
      • 进程或 Activity 生命周期边界不清
    • 通过 引入Dagger2，将对象的创建与依赖关系交由 编译期生成的 Component/Module 管理。
  2. 明确依赖边界和作用域
    • Dagger2 的 Scope 注解用于划分对象生命周期：
      • @LauncherAppSingleton：App 级单例，与进程生命周期绑定
      • @ActivityContextSingleton：ActivityContext 级单例，与 Activity 生命周期绑定
    • 通过 Scope，保证不同层级的对象不会滥用或跨层泄露。
  3. 解耦 AOSP Launcher 与 Quickstep / OEM 派生实现
    • Dagger2 允许在 Module 中将公共接口绑定到不同实现：
      • 例如 ModelDelegate → QuickstepModelDelegate
      • MainProcessInitializer → QuickstepProcessInitializer
    • 这样 AOSP Launcher 公共代码无需直接依赖 Quickstep 实现，派生 app 可以在 Module 中替换绑定。
  4. 集中管理对象创建与依赖图
    • 所有依赖通过 Root Component → AppModule → Subcomponent 构建
    • ActivityContextComponent 作为 Subcomponent 管理 per-Activity 对象
    • 对象图清晰、可追踪、便于调试和扩展。