膳绫擎只是举个例子，Crushlytics 为崩溃上报分析对象，在开辟的时刻我们可能不须要，是以不须要打开，在我们实际开辟中，像崩溃上报SDK，数据统计SDK等(如 友盟统计、GrowingIO、百度统计)在开辟阶段都设置为弗采取，来晋升构建速度。

4 . 用静态的构建设备值来构建你的Debug版

一般地，在你的debug 构建时，为manifest文件或者资本文件设备应用静态/硬编码的值。如不雅你的manifest或者资本文件的值每次构定都须要动态更新，那么Instant Run 无法履行代码交换-它必须从新构建和安装新的APK。

例如，应用动态的version codes ,version names ,resources或者其他更改manifest文件的构建逻辑，每次你想履行一个修改都邑构建全部APK，即使实际的修改可能仅仅只须要热交换。如不雅这些构建设备是须要动态设备的，那么将它们大年夜你的release 构建变体平分别出来，并且在你的debug 构建中保存它们的静态值。像下面build.gradle 文件显示的┞封样：

int MILLIS_IN_MINUTE = 1000 * 60 
int minutesSinceEpoch = System.currentTimeMillis() / MILLIS_IN_MINUTE 
 
android { 
    ... 
    defaultConfig { 
        // Making either of these two values dynamic in the defaultConfig will 
        // require a full APK build and reinstallation because the AndroidManifest.xml 
        // must be updated (which is not supported by Instant Run). 
        versionCode 1 
        versionName "1.0" 
        ... 
    } 
 
    // The defaultConfig values above are fixed, so your incremental builds don't 
    // need to rebuild the manifest (and therefore the whole APK, slowing build times). 
    // But for release builds, it's okay. So the following script iterates through 
    // all the known variants, finds those that are "release" build types, and 
    // changes those properties to something dynamic. 
    applicationVariants.all { variant -> 
        if (variant.buildType.name == "release") { 
            variant.mergedFlavor.versionCode = minutesSinceEpoch; 
            variant.mergedFlavor.versionName = minutesSinceEpoch + "-" + variant.flavorName; 
        } 
    } 
}  

5 . 用静态的版本依附

当你在build.gradle文件中声明依附的时刻，你应当避免在版本号停止的处所应用+号，比如：com.android.tools.build:gradle:2.+ 因为Gradle的检查更新，用动态的版本号会导致未知的版本更新、使解决版本的差别变得艰苦和更慢的构建。你应当应用静态或者硬编码版本号来代替。如：com.android.tools.build:gradle:2.2.2 。

6 . 使>