SAKA'S BLOG

(译)构建安卓工程

发表于

本文是翻译的谷歌官方文档，整合了一些零散的知识

module级别gradle

app/build.gradle

Androdi Studio 使用gradle来编译构建你的app。你的工程中每一个module中都有一个build.gradle文件，同样有一个build.gradle属于整个工程.通常情况下，你只需要关注module下的build.gradle文件。这是你的app构建的依赖的设置地方，还包含一些默认设置。

  • compileversion

是用来编译你的app的平台版本。默认情况下，会设置为你的开发机器上最新版本的sdk版本。你仍然可以使用老版本来构建你的应用，但是设置为最新版本允许你使用一些新特性并为你的app在新设备上的用户体验带来提升。

  • applicationId

你在新建项目的想到中合格的包名

  • minSdkVersion

你在新建项目向导中设置的最小sdk支持版本，是你的ap支持的最早的版本

-targetSdkVersion

表示你的应用测试的最高版本。假如新的安卓版本已经发布，你应该升级你的版本号到最新版本来体验新版本的优越。

支持不同版本平台

由于安卓新版本总是提供大量新API，你应该继续保持你的应用支持最低版本知道大多数设备都升级。这节向你展示了如何在支持老版本的同事利用最新的API。
经常升级的版本平台分布图根据访问PalyStore的设备数量展示了每个版本下活跃的设备的分布。把你的应用目标版本设定为最新，对支持90%的设备是一个良好的实践。

Tips：为了提供最好的特性并且功能横跨几个安卓版本，你最好在你的app中使用AndroidSupportLibrary，允许你在新版本和旧版本中使用

指定最小和目标API Level

在你的Manifest.xml文件中详细的描述了你的app支持的版本。

1
2
3
4
<manifest xmlns:android="http://schemas.android.com/apk/res/android" ... >
    <uses-sdk android:minSdkVersion="4" android:targetSdkVersion="15" />
    ...
</manifest>

上面的代码中uses-sdk标签中分别指定了你在测试阶段通过的支持的最小版本和最高版本。当新版本发布的时候，一些形式和方法可能会改变。你应该时刻保持你的targetSdkVersion最新来匹配。

在运行时检测系统版本号

安卓在Build常量文件中提供了一些特殊的代码来表示每个平台的版本。在你的app中用这些代码来确保只有在系统支持的高版本的api中才能执行。

1
2
3
4
5
6
7
private void setUpActionBar() {
    // Make sure we're running on Honeycomb or higher to use ActionBar APIs
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
        ActionBar actionBar = getActionBar();
        actionBar.setDisplayHomeAsUpEnabled(true);
    }
}

Note:当解析XML资源文件时，安卓会忽略那些当前设备不支持的属性，所以你可以安全的使用只有在新版本支持的XML属性，而不用担心老版本在遇到这些代码时中断。举个例子，如果你设置的”targetSdkVersion=11”，你的app包含只有在android3.0以上才能使用的Actionbar,然后为actionbar添加条目的时候，你需要设置 android:showAsAction=”ifRoom” 在你的XML文件中，这样做是安全的，因为老版本系统会忽略这个属性（也就是说你不必要单独创建一个版本文件夹“res/menu-v11/”）

使用样式和主题

安卓为用户提供了类似于底层操作系统的主题。这些主题可以在你的manifest中设置。使用这些样式和主题可以使你的app看起来更像安卓应用。

  • 让activity以dialog形式展现
1
<activity android:theme="@android:style/Theme.Dialog">
  • 让activity拥有透明背景
1
<activity android:theme="@android:style/Theme.Translucent">
  • 让activity使用你自己的主题样式
1
<activity android:theme="@style/CustomTheme">
  • 让整个应用使用你自己的主题样式
1
<application android:theme="@style/CustomTheme">

构建流程

image
一张图清晰表明了安卓构建的流程

  1. 编译器将你的源代码转换成DEX，将所有内容换成已编译资源
  2. apk打包器将DEX文件和已编译资源合并成单个APK（必须要签名）.
  3. 最终生成APK之前，打包器会使用zipalign工具对应用进行优化，减少在设备上使用时的内存占用

自定义构建配置（配置构建变体）

构建变体是Gradle按照特定规则集合并在构建类型和产品中配置的设置、代码和资源所生成的结果。大概是同一个工程配置处收费和免费版本。

1.配置构建类型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
android {
    ...
    defaultConfig {...}
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }

        debug {
            applicationIdSuffix ".debug"
        }

        /**
         * The 'initWith' property allows you to copy configurations from other build types,
         * so you don't have to configure one from the beginning. You can then configure
         * just the settings you want to change. The following line initializes
         * 'jnidebug' using the debug build type, and changes only the
         * applicationIdSuffix and versionNameSuffix settings.
         */

        jnidebug {

            // This copies the debuggable attribute and debug signing configurations.
            initWith debug
            applicationIdSuffix ".jnidebug"
            jniDebuggable true
        }
    }
}

上面的代码中buildTypes表示构建类型共三个

  • release
  • debug
  • jnidebug

    ‘initwith’属性允许你从其他构建类型中复制到当前构建类型，只需要重写你需要改变的内容

常用的buildtype属性

image

配置产品风味（官方真是奇怪）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
android {
    ...
    defaultConfig {...}
    buildTypes {...}
    productFlavors {
        demo {
            applicationId "com.example.myapp.demo"
            versionName "1.0-demo"
        }
        full {
            applicationId "com.example.myapp.full"
            versionName "1.0-full"
        }
    }
}

将各种喜好添加到productFlavors{}代码块中。实际上defaultConfig属于ProductFlavor的类。通常这个用来配置渠道，替换manifest中的占位符。

创建用于buildtype的源集（其实就是不同的文件）

默认情况下AndrodiStudio会创建目录如下：E:Project/myapp//main文件夹，用于存储你想要的一切共享资源。你自己可以创建新的源集来确切控制gradle为特定类型包含的文件。
例如要求你的“调试”构建类型多特定的java文件位于src/debug/java/目录中，则代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
sourceSets {
        main {
            manifest.srcFile 'src/main/AndroidManifest.xml'
            java.srcDirs = ['src/main/java']
            resources.srcDirs = ['src/main/java']
            aidl.srcDirs = ['src/main/java']
            renderscript.srcDirs = ['src/main/java']
            res.srcDirs = ['src/main/res']
            assets.srcDirs = ['src/main/assets']
            jniLibs.srcDirs = ['src/main/jniLibs']

        }
    }

声明依赖项

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
android {...}
...
dependencies {
    // The 'compile' configuration tells Gradle to add the dependency to the
    // compilation classpath and include it in the final package.

    // Dependency on the "mylibrary" module from this project
    compile project(":mylibrary")

    // Remote binary dependency
    compile 'com.android.support:appcompat-v7:25.1.0'

    // Local binary dependency
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

模块依赖项

compile project(‘:mylibrary’) 行声明了一个名为“mylibrary”的本地 Android 库模块作为依赖项，并要求构建系统在构建应用时编译并包含该本地模块。

远程二进制依赖项

compile ‘com.android.support:appcompat-v7:25.1.0’ 行通过指定其 JCenter 坐标，针对 Android 支持库的 25.1.0 版本声明了一个依赖项。默认情况下，Android Studio 会将项目配置为使用顶级构建文件中的 JCenter 存储区。当您将项目与构建配置文件同步时，Gradle 会自动从 JCenter 中抽取依赖项。或者，您也可以通过使用 SDK 管理器下载和安装特定的依赖项。

本地二进制依赖项

compile fileTree(dir: ‘libs’, include: [‘*.jar’]) 行告诉构建系统在编译类路径和最终的应用软件包中包含 app/libs/ 目录内的任何 JAR 文件。如果您有模块需要本地二进制依赖项，请将这些依赖项的 JAR 文件复制到项目内部的 /libs 中。

配置签名

  1. 创建秘钥库
  2. 创建私钥
  3. 将签名配置到模块机build.gradlw文件中
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    android {
        ...
        defaultConfig {...}
        signingConfigs {
            release {
                storeFile file("myreleasekey.keystore")
                storePassword "password"
                keyAlias "MyReleaseKey"
                keyPassword "password"
            }
        }
        buildTypes {
            release {
                ...
                signingConfig signingConfigs.release
            }
        }
    }