码迷,mamicode.com
首页 > 其他好文 > 详细

将基于Dagger-1开发的项目迁移到Dagger-2中

时间:2015-05-31 11:02:03      阅读:428      评论:0      收藏:0      [点我收藏+]

标签:android   依赖注入   

我相信每一个 Android 开发者都听说过依赖注入框架,事实上几乎所有 Android 官方会议都讨论过软件设计模式。虽然我是依赖注入的脑残粉,但我不得不承认也有人不喜欢依赖注入,主要原因如下:

  • 依赖注入框架很慢 - 好吧,在使用 RoboGuice 的时代里,整个依赖图表会在运行时被创建和验证,使依赖注入框架确实会存在这样的问题。但现在,Dagger 让这一切发生了改变。在 Dagger 1 框架中,大量的工作(图表验证)在编译时被完成,而且对象创建也不需要通过反射机制完成(值得一提的是:最近发布的 Roboguice 3 也在编译时完成了大量的工作)。虽然 Dagger 1 框架的效率还是不如工程师亲自写的代码,但在大部分 App 里这都是可以接受的。

  • 依赖注入框架需要大量的模板 - 可以说它是对的,也可以说不是。确实,我们需要为提供依赖的类和注入添加额外的代码,但正因为我们完成了这样的工作,使我们不必在每次需要使用它们的时候通过构造器处理它们。我不否认依赖注入框架会在影响小型 App 的性能,但随着 App 内部结构变得复杂,依赖注入的好处会越来越明显。

  • 其他缺点就是较差的溯源性,已生成代码的可读性差等等……

但我已经说了:我是依赖注入框架的脑残粉,刚刚提到的种种缺点并不会让我放弃在项目中使用它。直到最近我使用 Dagger 1 都没产生什么问题,但当我们决定完全重写 Azimo (我的新项目),并将它运行在依赖注入框架时,Dagger 1 中存在的一些问题渐渐显现。这些问题到底是什么呢?且听我娓娓道来。

不过好消息是,Dagger 2 虽然还没有发布正式版,但 Dagger 2 已经有一个稳定,特征完备的版本了。

Dagger 2

说实话,我并没有太深入地了解 Dagger 2 的实现细节,我只是稍微看了看官网的一些说明 Dagger 2 website 和 Jake Wharton 的随笔-The Future of Dependency Injection with Dagger 2

毕竟对我来说最重要的是,Dagger 2 几乎自动地帮我解决了 Dagger 1 中大量的长耗时任务。

对项目使用 Proguard

我不得不承认,Azimo 应用的方法数已经超过了 65536 个了(Android Dex’s 64k 限制)。刚开始开发 Azimo 的时候我们使用的是 MultiDex solution,但随着应用的迭代我们发现 MultiDex solution 存在一些缺陷,因此我们必须考虑使用 Proguard。为什么我们必须要作出这样的决定呢?

译者注:ProGuard是一个压缩、优化和混淆Java字节码文件的免费的工具,它可以删除无用的类、字段、方法和属性。可以删除没用的注释,最大限度地优化字节码文件。它还可以使用简短的无意义的名称来重命名已经存在的类、字段、方法和属性。常常用于Android开发用于混淆最终的项目,增加项目被反编译的难度。

仅有在 MultiDexApplication 类的 onCreate() 方法中调用的 MultiDex.install(this) 在使用 Android 4.4 系统的 Nexus 7 设备中花费大约 4000ms 的时间(Lollipop 对 MultDex 的支持是基于内核的,所以在相同的设备中只需要1ms)。此外,应用的构建时间戏剧性地不降反增(即使我们只修改了一行代码,每一个 Gradel assembleDebug 仍需要2分钟左右的时间)。为什么耗时这么长?简单来说:每一次我们修改代码决定将哪些代码放到第一个 .dex 文件中以及哪些代码能够移动到其他 .dex 文件时,MultiDex 插件都需要扫描资源文件。

所以我们决定使用 Proguard,然后就爆炸了……因为在 Proguard 规范下没有用来处理 Dagger 自动生成代码的简单办法。所以我们得使用 Squad leader 的 @Keep 注解来简化这个问题,但我们还是需要花费一定的时间更新代码,并将这条规范在注释中标注。

Dagger 2 回应:Proguard 中不存在 Dagger 2 所需要的单一原则。一切都是自然而然发生的。因为 Dagger 2 产生完全可溯源的代码,而且不需要使用反射 - 这对 Proguard 的友好度简直爆表。

其他事项

现在还有一些不是非常重要(但又有用)的事项让我们确信将基于 Dagger 1 框架开发的代码转移到 Dagger 2 中:

  • Dagger 1 自动生成的代码非常难度,虽然 Dagger 1 他爹值得信赖,但了解 Dagger 1 在底层到底留下了什么对我们也有好处。由于这些代码并不是完全可溯源的,那就意味着我们不能用 IDE 中类似 “find usages” 的功能。

Dagger 2 生成了和程序员亲手实现的依赖注入代码几乎一样的整个栈。使代码具有完全可溯源性,便于我们更好地理解代码的运行机制。

  • 或许 Dagger 2 的拓展性变差了些许,但 Dagger 2 的 API 比 Dagger 1 清晰易用得多。我们的团队仍然在发展,在我们重写应用的时候,理解整个应用的架构过程必须尽可能快, Bug 要尽可能地少是很重要的。幸亏 Dagger 2 的学习曲线并不陡峭,这为我们节省了学习成本。

  • 依赖图的构建时间。或许现在它对我们来说不是什么大问题 - 因为在 Nexus 7(Android 4.4 系统)构造应用的依赖图大概需要 80ms 的时间。但使用了 Dagger 2,只需要 40ms 依赖图就构建完成了。

将基于 Dagger 1 开发的项目迁移到 Dagger 2 中

Antonio Leiva 曾在几个月前写了有关如何在 Android 基于 MVP 模式开发的项目中使用依赖注入的系列博文(post 1, post 2, post 3)。我觉得这个项目挺好的,于是将它下了下来,并让它的依赖注入框架更新为 Dagger 2。

依赖图

为了更好地理解 Dagger 1 是如何在范例中运行的,我用 DaggerExample 项目创建了依赖图:

技术分享

现在我们来看看在相同的项目中使用 Dagger 2 创建的依赖图:

技术分享

你能看到其中的相似之处吗?

Dagger 1 和 Dagger 2 两者中最值得一提的区别就是 Compontents。简单来说,它们把调用者可能请求的所有类型都枚举出来了。但组件接口只声明它为调用者提供了某些东西,以及这些东西由 Module 提供,所以 Module 仍然负责创建对象。组件只是依赖图的公有 API。

迁移过程

创建依赖

首先,为了添加新的依赖,我们要更新 build.gradle 文件。当我在写这篇博文的时候,只有一个快照版本是可用的。这也是我们必须添加 Sonatype snapshot 库的原因:

build.gradle:

    buildscript {
        repositories {
            mavenCentral()
            maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
        }
        dependencies {
            classpath ‘com.android.tools.build:gradle:1.1.3‘
            classpath ‘com.neenbedankt.gradle.plugins:android-apt:1.4‘
        }
    }

    allprojects {
        repositories {
            mavenCentral()
            maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
        }
    }

Android-ADT 插件与注解处理器协作,并仅在注解处理器为依赖时允许配置编译时间而不把 artifact 添加到最后的 APK 中。当然了,它还为自动生成的代码生成了相应的原路径,在 Android Studio 中它们都是可见的并且可溯源的。

Dagger 的 app/build.gradle 文件和 Android-ADT 中的信息应该大致如下:

    apply plugin: ‘com.android.application‘
    apply plugin: ‘com.neenbedankt.android-apt‘

    android {
        compileSdkVersion 22
        buildToolsVersion "22.0.1"

        defaultConfig {
            minSdkVersion 14
            targetSdkVersion 22
            versionCode 1
            versionName "1.0"
        }

        compileOptions {
            sourceCompatibility JavaVersion.VERSION_1_7
            targetCompatibility JavaVersion.VERSION_1_7
        }
        buildTypes {
            release {
                minifyEnabled false
                proguardFiles getDefaultProguardFile(‘proguard-android.txt‘), ‘proguard-rules.txt‘
            }
        }
    }

    dependencies {
        compile fileTree(dir: ‘libs‘, include: [‘*.jar‘])
        compile ‘com.google.dagger:dagger:2.0-SNAPSHOT‘
        apt ‘com.google.dagger:dagger-compiler:2.0-SNAPSHOT‘
        provided ‘org.glassfish:javax.annotation:10.0-b28‘
    }

Modules

接下来这一步可以说是迁移过程中最简单的一步了。Module 将尽可能变得简单,它们只需要为将要提供的对象添加 @Module(不需要任何额外的参数) 和 @Provides 注解。

这是 AppModule 类:

Dagger 1:

    @Module(
            injects = {
                    App.class
            },
            includes = {
                    DomainModule.class,
                    InteractorsModule.class
            }
    )
    public class AppModule {

        private App app;

        public AppModule(App app) {
            this.app = app;
        }

        @Provides public Application provideApplication() {
            return app;
        }
    }

Dagger 2:

    @Module
    public class AppModule {

        private App app;

        public AppModule(App app) {
            this.app = app;
        }

        @Provides public Application provideApplication() {
            return app;
        }
    }

两者的区别在哪里?区别在于:注入参数被移动到组件内,就像使用 include。所有 Module 参数都该尽快过时/移除。

组件

就像我刚刚说的,Dagger 2 中还添加了一些新的特性。简单来说把,就是依赖图的一些公有 API。大家不妨再回去看看刚刚 Dagger 2 的依赖图,这是每一个 @Componentclass 的实现:

AppComponent:

    @Singleton
    @Component(
            modules = {
                    AppModule.class,
                    DomainModule.class,
                    InteractorsModule.class
            }
    )
    public interface AppComponent {
        void inject(App app);

        AnalyticsManager getAnalyticsManager();
        LoginInteractor getLoginInteractor();
        FindItemsInteractor getFindItemsInteractor();
    }

LoginComponent:

    @ActivityScope
    @Component(
            dependencies = AppComponent.class,
            modules = LoginModule.class
    )
    public interface LoginComponent {
        void inject(LoginActivity activity);

        LoginPresenter getLoginPresenter();
    }

MainComponent:

    @ActivityScope
    @Component(
            dependencies = AppComponent.class,
            modules = MainModule.class
    )
    public interface MainComponent {
        void inject(MainActivity activity);

        MainPresenter getLoginPresenter();
    }

大家可以看到我使用了 @AcivityScope 注解。简单来说,它是本地子图中 @Singleton 注解的代替品。在 Dagger 1 里,假如我们有一个 LoginPresenter 类的单例对象,虽然这个对象确实是一个单例,但某种程度上它总像一个本地单例 - 因为它只存活于图的作用域中(示例代码中,该单例会在 onDestory() 方法中被设置为 null)。

@ActivityScope is used just for semantic clarity and it’s defined in our code:

@ActivtiyScope 只用于语境清晰的环境中,它在代码中的定义如下:

    @Scope
    @Retention(RetentionPolicy.RUNTIME)
    public @interface ActivityScope {
    }

对象图

Dagger 2 中不再有对象图,因为对象图被组件取代了。确切来说,Dagger 2 框架将自动生成以 DaggerComponent_ 为前缀的代码。这就意味着我们现在必须处理生成代码(但只在这里处理)。

我们必须记住:DaggerComponent_ 类只有在所有代码有效的情况下被生成,所以在你解决所有 Error 之前你不会看到它。

那它具体长什么样呢?

    public class App extends Application {

        private AppComponent component;

        @Inject
        AnalyticsManager analyticsManager;

        @Override
        public void onCreate() {
            super.onCreate();
            setupGraph();
            analyticsManager.registerAppEnter();
        }

        private void setupGraph() {
            component = Dagger_AppComponent.builder()
                    .appModule(new AppModule(this))
                    .build();
            component.inject(this);
        }

        public AppComponent component() {
            return component;
        }

        public static App get(Context context) {
            return (App) context.getApplicationContext();
        }
    }

我们的图将通过16-18行代码生成,取代了 Dagger 1 的 ObjectGraph.create(getModules()) 代码。

第19行代码将 App 对象注入到途中(而且此时类中所有 @Inject 注解都是可信的)

这是一个本地图(MainActivity)的范例:

    protected void setupComponent(AppComponent appComponent) {
        Dagger_MainComponent.builder()
                .appComponent(appComponent)
                .mainModule(new MainModule(this))
                .build()
                .inject(this);
    }

MainComponent 依赖于 AppComponent,使我们必须准确地提供这个对象。如果 Module 没有默认的构造器,你必须提供(就像 MainModule)。

那么迁移工作到这里就算完成了。提交完整的迁移过程的 pull request 能防止我们遗漏某些东西。大家必须记住:这篇文章没有讲解更多复杂的解决办法,以及 Dagger 2 的所有特性和功能。下面是一些能帮你更好地理解 Dagger 2 和依赖注入框架运行机制的链接:

The Future of Dependency Injection with Dagger 2
Dagger 2 doc by Gregory Kick
Dagger 2 official website

那这篇博文就到此为止啦,感谢你能耐心看完这篇文章,我希望能更深入地挖掘 Dagger 2 的技术细节,我相信大家很快会看到我的新博文的!??

源码

Github 上面有整个项目的源码。

将基于Dagger-1开发的项目迁移到Dagger-2中

标签:android   依赖注入   

原文地址:http://blog.csdn.net/u012403246/article/details/46285137

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!