4.0、Android Studio配置你的构建-白红宇

4.0、Android Studio配置你的构建

阅读量：6182 次

发布时间：2019-06-21

本文共 7541 字，大约阅读时间需要 25 分钟。

Android构建系统编译你的app资源和源码并且打包到APK中，你可以用来测试，部署，签名和发布。Android Studio使用Gradle，一个高级的构建套件，来自动化和管理构建进程，同时可以允许你灵活的自定义构建配置。每个构建配置可以定义它自己的代码和资源集合。

Gradle和Android插件独立于Android Studio运行。这就意味着你可以在你的机器上在命令行、Android Studio、或者没有安装Android Studio的机器中构建你的Android APP。

Android构建系统的灵活性允许你在不修改你的APP核心代码的情况下运行自定义的构建配置。

构建进程

构建进程包含很多工具和进程来帮助将你的项目转化为APK（Android Application Package）。构建进程非常灵活。

遵循如下几步：

1、编译器将你的源码转化为DEX（Dalvik Executable）文件，包含Android设备中可以运行的字节码和其他编译的资源文件。

2、 APK打包工具将DEX文件和编译后的资源打包到一个单独的APK中，但是在你安装和部署之前，APK必须进行签名。

3、 APK打包工具会用debug key或者release key对你的APK进行签名。

4、在你生成最终的APK之前，打包工具只用aipalign工具来优化你的代码。这可以在app运行时降低内存。

自定义构建配置

Build Types

构建类型定义在构建和打包app是Gradle使用的一些属性配置。在不同的开发周期是不同的。比如，debug 构建类型开启调试选项并且使用debug key对APK进行签名。而release 构建类型可能需要压缩、模糊并且使用release key对APK进行签名。为了构建你的app，你必须至少声明一种类型。

Product Flavors

Product flavors代表发布给用户的不同版本的APP。比如，免费和付费的APP版本。你可以通过定制Product flavors来使用不同的代码和资源，同时共用所有版本APP可复用的部分。Product Flavors是可选的，你必须手动创建它们。

Build Variants

Build variant是build type和product flavor混合的产物。这是Gradle用来构建你的app的相关配置。通过使用build variant，你可以在开发中构建你的product flavor的debug版本，或者product flavor的签名的发布版本。虽然你没有直接配置build variant，你可以通过配置build type和product flavor来实现对build variant的配置。创建额外的build type或者product flavor同样可以创建额外的build variant。

Mainfest Entries

你可以在build variant配置里声明manifest文件里的一些属性值。这些值会腹泻manifest文件中已经存在的值。

Dependencies

构建系统管理项目的依赖，从本地的依赖到远程的依赖。这个可以让你方便的对依赖进行管理。

Signing

构建系统允许你在构建配置中声明签名设置，这可以在你构建的时候自动的对你的APK进行签名。构建系统不会对release版本进行签名，除非你定义一个签名配置。

ProGuard

构建系统允许你为每一个build variant声明一个不同的ProGuard规则文件。

构建配置文件

创建自定义的配置需要你对一个或多个构建配置文件进行更改，或者build.gradle文件。这些文本使用DSL来描述和控制构建逻辑。

当你创建一个新的项目时，Android Studio自动为你创建一些文件，如图：

这是一些Gradle构建配置文件，作为Android应用标准项目结构的一部分。

Gradle设置文件

gradle.settings文件位于项目的根目录下，来通知Gradle在构建你的应用的时候需要包括哪些模块，大部分项目如下：

include ‘:app’

顶层的构建文件

位于项目根目录的build.gradle文件，定义了可以应用于你的项目的所有模块的构建配置。默认情况下，顶层的构建文件在buildscript{}中定义Gradle repositories和依赖，这可以应用到项目的所有的模块中。如下：

/** * The buildscript {} block is where you configure the repositories and * dependencies for Gradle itself--meaning, you should not include dependencies * for your modules here. For example, this block includes the Android plugin for * Gradle as a dependency because it provides the additional instructions Gradle * needs to build Android app modules. */buildscript { /** * The repositories {} block configures the repositories Gradle uses to * search or download the dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use local * repositories or define your own remote repositories. The code below defines * JCenter as the repository Gradle should use to look for its dependencies. */ repositories { jcenter() } /** * The dependencies {} block configures the dependencies Gradle needs to use * to build your project. The following line adds Android Plugin for Gradle * version 2.0.0 as a classpath dependency. */ dependencies { classpath 'com.android.tools.build:gradle:2.0.0' }}/** * The allprojects {} block is where you configure the repositories and * dependencies used by all modules in your project, such as third-party plugins * or libraries. Dependencies that are not required by all the modules in the * project should be configured in module-level build.gradle files. For new * projects, Android Studio configures JCenter as the default repository, but it * does not configure any dependencies. */allprojects { repositories { jcenter() }}

模块构建文件

模块的build.gradle文件，位于//目录下，允许你对特定的模块进行构建配置。配置这些构建设置允许你提供自定义的打包选项，比如额外的build type和product flavor，复写mainfies中的设置或者顶层build.gradle文件的配置。代码如下：

/** * The first line in the build configuration applies the Android plugin for * Gradle to this build and makes the android {} block available to specify * Android-specific build options. */apply plugin: 'com.android.application'/** * The android {} block is where you configure all your Android-specific * build options. */android { /** * compileSdkVersion specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. * * buildToolsVersion specifies the version of the SDK build tools, command-line * utilities, and compiler that Gradle should use to build your app. You need to * download the build tools using the SDK Manager. */ compileSdkVersion 23 buildToolsVersion "23.0.3" /** * The defaultConfig {} block encapsulates default settings and entries for all * build variants, and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { /** * applicationId uniquely identifies the package for publishing. * However, your source code should still reference the package name * defined by the package attribute in the main/AndroidManifest.xml file. */ applicationId 'com.example.myapp' // Defines the minimum API level required to run the app. minSdkVersion 14 // Specifies the API level used to test the app. targetSdkVersion 23 // Defines the version number of your app. versionCode 1 // Defines a user-friendly version name for your app. versionName "1.0" } /** * The buildTypes {} block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies Proguard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the Proguard settings file. */ release { minifyEnabled true // Enables code shrinking for the release build type. proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } /** * The productFlavors {} block is where you can configure multiple product * flavors. This allows you to create different versions of your app that can * override defaultConfig {} with their own settings. Product flavors are * optional, and the build system does not create them by default. This example * creates a free and paid product flavor. Each product flavor then specifies * its own application ID, so that they can exist on the Google Play Store, or * an Android device, simultaneously. */ productFlavors { free { applicationId 'com.example.myapp.free' } paid { applicationId 'com.example.myapp.paid' } }}/** * The dependencies {} block in the module-level build configuration file * only specifies dependencies required to build the module itself. */dependencies { compile project(":lib") compile 'com.android.support:appcompat-v7:22.0.1' compile fileTree(dir: 'libs', include: ['*.jar'])}