加快 vs调试速度_加快调试速度的9个步骤

加快 vs调试速度

Build time is every Android developer’s nightmare! How often, at the end of a long, tiring day at work, we look back only to realize that the most of our time, energy and patience has gone into building and rebuilding our apps! Something as simple as optimizing the build time can save us a lot of frustration and give us a few extra hours each day!

构建时间是每个Android开发人员的噩梦！ 在漫长而累人的工作结束时，我们多久回头一次才意识到，我们大部分时间，精力和耐心都花在了构建和重建应用程序上！ 诸如优化构建时间之类的简单操作可以为我们节省很多挫败感，并且每天给我们额外的几个小时！

Here are the steps we followed at Gradeup and GoPrep to reduce our debug build time by about 50%!

这是我们在Gradeup上遵循的步骤 和 GoPrep 将我们的调试构建时间减少了约50％ ！

1.分析构建 (1. Profile the build)

Before making any optimizations, let’s first run the a profiler on our app to get a detailed insight of build process and single out any bottlenecks.

在进行任何优化之前，让我们首先在我们的应用程序上运行一个探查器，以详细了解构建过程并找出任何瓶颈。

Run the following command in the terminal:

在终端中运行以下命令：

./gradlew android:assembleDebug --profile

Under the Task Execution section, you can see the breakdown of the tasks and the time taken by each. Analyze this for any loopholes e.g. upon analyzing our app profile, we noticed app:installApolloCodegen was executed for every build and was taking up around 1 minute of our build time! As a solution, we switched to pre-installed codegen by updating our Apollo version to 1.2.0, which removes the old NPM code generator.

在“ 询问执行”部分下，您可以查看任务的细分以及每个任务所花费的时间。 分析此漏洞是否存在，例如在分析我们的应用程序配置文件时，我们注意到app：installApolloCodegen在每次构建时都执行，并且占用了大约1分钟的构建时间！ 作为解决方案，我们通过将Apollo版本更新为1.2.0切换到预安装的代码生成器，从而删除了旧的NPM代码生成器。

2.按需配置 (2. Configure on Demand)

Gradle provides configure-on-demand flag, that will tell gradle to only build the projects that it really needs to build.

Gradle提供了按需配置标志，该标志将告诉gradle仅构建它真正需要构建的项目。

Configuration on demand mode attempts to configure only projects that are relevant for requested tasks, i.e. it only executes the build.gradle file of projects that are participating in the build. This way, the configuration time of a large multi-project build can be reduced.

按需配置模式尝试仅配置与所请求任务相关的项目，即，它仅执行参与构建的项目的build.gradle文件。 这样，可以减少大型多项目构建的配置时间。

To enable configure-on-demand for every build you can add org.gradle.configureondemand=true in your gradle.properties file or in your android studio, navigate to Preferences > Build, Execution, Deployment > Compiler and check configure on demand option.

要为每个构建启用按需配置，您可以在gradle.properties文件或android studio中添加org.gradle.configureondemand = true ，导航至“首选项”>“构建，执行，部署”>“编译器”，然后选中“按需配置”选项。

3.启用守护程序 (3. Enable Daemon)

Gradle has a great feature called Gradle Daemon that keeps the instance of the gradle up and running in the background even after your build finishes. This will remove the time required to initialize the Gradle and decrease your build timing significantly.

Gradle有一个很棒的功能，叫做Gradle Daemon 即使构建完成后，也可以使gradle实例保持在后台并在后台运行。 这将消除初始化Gradle所需的时间，并显着减少构建时间。

You won’t be able to see the time difference in your first build as gradle has to initialize and start the daemon, but build times will decrease in subsequent builds as gradle daemon is already initialized.

由于gradle必须初始化并启动守护程序，因此您将无法看到第一个构建中的时差，但是由于gradle守护程序已经初始化，因此在后续构建中构建时间将减少。

If you are using the gradle version 3.0 or above, the gradle daemon is by default enabled. But, if you are running on older versions of gradle, then you can enable it for every build by adding org.gradle.daemon=true in your gradle.properties file.

如果您使用gradle 3.0或更高版本，则默认情况下启用gradle守护程序。 但是，如果您在gradle的旧版本上运行，则可以通过在gradle.properties文件中添加org.gradle.daemon = true来为每个构建启用它。

4.模块化您的应用程序并启用并行化 (4. Modularize your app and enable parallelization)

If you have multiple modules in you project, then by enabling the gradle.parallel option, gradle can run build operations for independent modules parallelly. This may decrease the build time significantly for multi-module projects.

如果项目中有多个模块，则通过启用gradle.parallel选项，gradle可以并行运行独立模块的构建操作。 这可能会大大减少多模块项目的构建时间。

Look for code in your app that you can convert into an Android library module so as to efficienize the process.

在您的应用程序中查找可转换为Android库模块的代码，以简化流程。

You can enable parallelism by adding org.gradle.parallel=true in your gradle.properties file.

您可以通过在gradle.properties文件中添加org.gradle.parallel = true来启用并行性。

5.在调试版本中使用静态版本配置值 (5. Use static build config values with your debug build)

Always use static/hard-coded values for properties that go in the manifest file or resource files for your debug build type e.g. using dynamic version codes, version names, resources, or any other build logic that changes the manifest file requires a full APK build every time you want to run a change even when the actual change might otherwise require only a hot swap. If your build configuration requires such dynamic properties, then isolate them to your release build variants and keep the values static for your debug builds, as shown in the build.gradle file below.

始终对清单文件或资源文件中用于调试构建类型的属性使用静态/硬编码值，例如，使用动态版本代码，版本名称，资源或更改清单文件的任何其他构建逻辑都需要完整的APK构建每次您要运行更改时，即使实际更改可能只需要热交换也是如此。 如果您的构建配置需要这样的动态属性，则将它们隔离到发行版本的变体中，并使调试构建的值保持静态，如下面的build.gradle文件所示。

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. versionCode 1
             versionName "1.0" …
             }// 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.outputs.each { output ->
                     output.versionNameOverride = "8.84" }
                 }
        }
    }

6.避免编译不必要的资源 (6. Avoid compiling unnecessary resources)

Avoid compiling and packaging resources that you aren’t testing (such as additional language localizations and screen-density resources). You can do that by only specifying one language resource and screen density for your flavor.

避免编译和打包未测试的资源(例如，其他语言本地化和屏幕密度资源)。 您可以通过仅指定一种语言资源和您的口味的屏幕密度来做到这一点。

android {
     …
     productFlavors {
         dev {
             …// The following configuration limits the "dev" flavor to          //using English stringresources and xxhdpi screen-density resources. resConfigs "en", "xxhdpi" }
         …
         }
}

7.禁用Crashlytics / Firebase性能以及调试构建不需要的其他此类库 (7. Disable Crashlytics/Firebase performance and other such libraries that you don’t need for debug builds)

If you don’t need to run a Crashlytics report, speed up your debug builds by disabling the plugin as follows:

如果您不需要运行Crashlytics报告，请按以下步骤禁用插件来加快调试速度：

android {
     …
     buildTypes {
         debug {
             ext.enableCrashlytics = false }
    }

You also need to disable the Crashlytics kit at runtime for debug builds by changing the way you initialize support for Fabric in your app, as shown below:

您还需要通过更改在应用程序中初始化对Fabric的支持的方式，在运行时为调试版本禁用Crashlytics工具包，如下所示：

// Initializes Fabric for builds that don't use the debug build type.Crashlytics.Builder()
 .core(CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build())
 .build()
 .also { crashlyticsKit ->
     Fabric.with(this, crashlyticsKit)
     }

You can do the same for Firebase performance library:

您可以对Firebase性能库执行相同的操作：

debug {
     ext.alwaysUpdateBuildId = false multiDexEnabled true signingConfig signingConfigs.appconfig
     ext.enableCrashlytics = false ext.enableStability = falseFirebasePerformance {// Set this flag to 'false' to disable @AddTrace annotation processing and // automatic HTTP/S network request monitoring // for a specific build variant at compile time. instrumentationEnabled false }
}

Here is the document witj details.

这是文档详细信息。

8.使用静态依赖版本 (8. Use static dependency versions)

When you declare dependencies in your build.gradle files, you should avoid using version numbers with a plus sign at the end, such as ‘com.android.tools.build:gradle:2.+’. Using dynamic version numbers can cause unexpected version updates, difficulty resolving version differences, and slower builds caused by Gradle checking for updates. You should use static/hard-coded version numbers instead.

在build.gradle文件中声明依赖项时，应避免使用末尾带有加号的版本号，例如'com.android.tools.build:gradle:2.+'。 使用动态版本号可能会导致意外的版本更新，解决版本差异的困难以及由Gradle检查更新导致的构建速度变慢。 您应该改用静态/硬编码版本号。

9.将图像转换为WebP (9. Convert images to WebP)

WebP is an image file format that provides lossy compression (like JPEG) as well as transparency (like PNG) but can provide better compression than either JPEG or PNG. Reducing image file sizes, without having to perform build-time compression, can speed up your builds, especially if your app uses a lot of image resources. However, you may notice a small increase in device CPU usage while decompressing WebP images. Using Android Studio, you can easily convert your images to WebP. Refer to the this document for details.

WebP是一种图像文件格式，可以提供有损压缩(如JPEG)和透明性(如PNG)，但可以提供比JPEG或PNG更好的压缩率。 减少图像文件的大小而无需执行构建时压缩，可以加快构建速度，尤其是在您的应用程序使用大量图像资源的情况下。 但是，您可能会注意到在解压缩WebP图像时设备CPU使用率略有增加。 使用Android Studio，您可以轻松地将图像转换为WebP。 有关详细信息，请参阅本文档。

Cheers to faster builds!

为更快的构建加油！

翻译自: https://medium.com/gradeup/9-steps-to-faster-debug-builds-aba66fee47c5

加快 vs调试速度