Android 应用开发编译框架流程与 IDE 及 Gradle 概要

1 背景

建议阅读本文之前先阅读《Android Studio入门到精通》和《Groovy脚本基础全攻略》及《Gradle脚本基础全攻略》三篇博客作为背景知识，这样才能更好、更系统的串起来。本文的核心就是下图：

关于Gradle的Android插件本文不会过多的说明，只给一个抛砖引玉的提示，详细使用参见文档API及Gradle配置，其实个性化的构建配置一般都是Gradle与Groovy的编写，与Android插件没太多关系，所以重点还在Groovy与Gradle构建。

不过在构建之前还需要先了解一些构建的流程和相关IDE及编译特性，具体下面会说到。

【工匠若水 blog.csdn.net/yanbober 未经允许严禁转载，请尊重作者劳动成果。私信联系我】

2 Android应用编译框架

在我们开发App时大多数时候的编译流程都是直接通过IDE的按钮或者命令行一步到位apk的生成，直观上的感觉好像源码到Apk的生成只有一步，实质不是这样的。从我们点击按钮那一刻到生成apk的过程实际是非常复杂的，涉及到很多步骤，下面我们来粗略看看。

2-1 Android应用源码到生成Apk流程

Android应用的编译其实就是打包为.apk文件，这个被打包的zpk文件实质其实是一个压缩包（譬如你可以重命名后缀解压），这个压缩包至少包含编译为.class文件转换的.dex文件、一个二进制的AndroidManifest.xml文件、编译的资源文件resources.arsc、未编译的资源文件等，然后在运行前再对这个压缩包进行签名操作即可。具体流程如下图：

Android构建系统是用来构建、测试、运行和封装应用程序的一个工具箱，整个构建系统我们可以通过已经集成OK的AS或者命令行来使用，构建过程会涉及许多工具和流程，通过这些工具和流程生成了许多中间文件，然后最终生成了APK。下图描述了构建过程中涉及的不同工具和过程：

构建系统将依据配置的product flavors、build types和dependencies合并所有的资源，如果此时不同文件夹含有相同名称或设置的资源则会按照如下规则进行覆盖：dependencies覆盖build types，build types覆盖product flavors，product flavors覆盖main资源文件夹。下面是对上图典型构建过程的详细描述：

1. Android资源打包工具（AAPT）将应用的资源文件（譬如AndroidManifest.xml文件和Activity相关的XML文件等）进行编译，生成的一个R.java文件就是关联我们Java代码与资源文件的基础。

2. aidl工具将应用中所有.aidl的文件转换为Java接口。

3. Java编译器将应用中所有Java代码（包括R.java和aidl接口）编译输出为class类文件。

4. dex工具将应用编译输出的类文件（包括第三方jar包）转换为Dalvik字节码，.dex文件就可以最终被打包如.apk文件。

5. apkbuilder工具将所有非编译资源（譬如images）、编译资源和DEX文件打包成一个APK文件。

6. 一旦.apk文件生成以后就必须进行签名（debug或者release签名）才能在设备上运行。

7. 通过zipalign工具对齐APK，减少APP在设备上运行时的内存占用。

整个构建过程生成的东东默认都在app/build目录下（包括中间产物和最终产物）。

特别注意： 应用程序构建有一个64K方法限制说法，超过64K会抛出如下构建信息：

Unable to execute dex: method ID not in [0, 0xffff]: 65536.

如果撞上该问题（一般是超大型项目或者疯狂使用开源框架等就会越界）请点我参考解决。

下面这幅图就是整个Android应用（不包含NDK部分）的构建编译框架详细流程说明（来源于官方）：

通过这幅图可以明显看出来Android应用程序编译源码到最终的apk产物过程实际是十分复杂的，我们平时只是把这些细则交给了IDE和构建框架而已，所以察觉不到这些细则过程。

2-2 Android应用编译流程相关主要工具

上面简单说明了从源码到APK的编译框架过程，下面简单说说这一过程中涉及的几个重要的编译相关工具，具体如下文。

2-2-1 aapt工具

aapt（Android Asset Packaging Tool）是Android资源打包工具，在SDK的tools目录下，我们可以使用该工具查看、创建、更新ZIP格式的文件（zip、jar、apk等)，也可以将资源文件编译成二进制文件。平时我们很少直接使用这个工具，通常都向前面编译流程图介绍的一样，编译框架会自动帮助我们调运这个工具。下面是aapt命令配置OK后运行的情况：

关于aapt命令工具的用法我们直接在终端输入aapt回车即可看见相关help文档，这里只给出几个我们比较常用的命令，其他的参见help文档。

列出压缩包的内容 #aapt l[ist] [-v] [-a] file.{zip,jar,apk}

查看APK包中指定内容 #aapt d[ump] file.{zip,jar,apk}

这个比较实用，有时候想快速知道一个app的包名等信息时可以通过该命令快捷获取。

aapt其他操作命令参数

aapt命令还可以进行打包生成资源压缩包、给压缩包删除或者添加指定文件等操作，这也是编译构建系统中生成R.java等流程使用的核心工具命令。感兴趣的可以自行google通过aapt命令行去手动打包资源文件。

2-2-2 aidl工具

AIDL（Android Interface Definition Language）是一种IDL语言，用来生成可以在Android设备上两个进程间通信（IPC）的代码。如果在一个进程中要调用另一个进程的对象则可以使用AIDL生成可序列化的参数进行传递。我们通常开发中都会依据AIDL规则编写相应的aidl文件，然而我们会发现在build目录下会出现我们aidl对应的java接口文件，这就是因为编译框架通过了aidl编译工具将.aidl文件转换为.java接口文件。

下面就是在SDK的tools目录下将aidl文件转为java文件的aidl工具：

关于aidl工具的用法很简单，帮助文档说的很明白了，详细感兴趣的可以自己去尝试一下，这里不再详细说明；基本不怎么手动去用，我反正没仔细研究过。

2-2-3 dx工具

我们通过aapt将资源打包同时生成R.java，通过aidl将aidl文件编译生成对应的java文件，再通过Java编译器将R.java、Java源码文件、aidl的Java文件编译为相关的class文件。这时候对于纯Java来说class字节码就是JVM虚拟机可执行的文件了，然而对于Android的Dalvik和ART虚拟机来说class文件是无法直接执行的，他们可执行的文件其实是dex格式的文件，所以我们需要通过SDK/tools目录的dx工具将class字节码编译为dex执行文件。如下是dx工具命令基本情况：

说到了dx工具就不得不再强调几个比较重要的概念和基本原理，具体如下详情。

apk、dex、odex文件关系：

dex是Dalvik VM Executes（Android Dalvik执行程序，现在ART也继续兼容使用此格式执行程序）的全称，dex格式文件通常在Android虚拟机中执行时都会先进行优化 ，优化后的文件大小一般都会比原dex文件大。这种优化的发生时机会分两种情况：

• 系统预置应用：在系统编译后直接生成以odex为后缀的优化文件，启动app时不用再解包取dex，效率高，所以在发布系统预置应用时可以看见一个不包含dex文件的apk文件和一个相应的odex文件。

• 非预置应用：编译直接生成包含dex文件的apk，包含在apk文件里的dex文件会在运行时被优化，优化后的文件将被保存在缓存中。

这也就是为何系统编译预置app源码后会看到odex和不含dex的apk文件，而独立app编译后只看见内含dex的apk文件的原因。之前在上家公司做盒子开发时有人曾经有过这个疑惑，当然我也有过！

dex文件65535异常方法限制原因：

Android的Dalvik和ART运行时环境都能够执行dx工具生成的.dex文件，也就是说Dalvik和ART使用了同一套Dalvik指令集。通过相关资料查询可以知道Dalvik指令集使用了16位寄存器来保存项目中所有的方法引用，2的16次方是65536，也就是说一个dex文件最多只能引用65536个方法，所以对于Dalvik和ART运行时环境来说都有这个局限性。我勒个去！！！这不就是我们有时候编译项目时抛出Android Dex方法限制异常的原因么（上面也有介绍，不明白上翻回看），也就是说编译时抛出这个异常是因为项目包含的方法太多导致的，好在Google官方也意识到了这个缺陷，所以他们给出了解决方案，如下：

• 使用ProGuard清除项目中无用方法，使用相关脚本对项目中没用到的第三方库中的方法进行清除处理；

• 由于Dalvik运行时环境限制一个apk只能包含一个classes.dex文件，所以我们可以使用Multidex Support Library支持包让一个apk里支持多个.dex文件，这样就可以突破65536的限制。

dx过程中这个错误非常经典，一般都出现在大量使用了第三方库的情况下，所以需要注意一下。

2-2-4 apkbuilder工具

关于apkbuilder工具这个叫法其实已经有些过时了，因为比较新版本的SDK中已经将apkbuilder工具去掉了，不过apkbuilder工具的实质其实是对/android-sdk-linux/tools/lib/sdklib.jar中ApkBuilderMain等的一个封装而已，所以即使没有了该工具我们也可以自己实现封装，不过新的编译框架会自动帮助我们解决这一过程，我们无需手动处理。该过程的实质其实和压缩工具的性质差不多，只是它将相关资源、dex文件等打包压缩成了一个指定压缩方式和深度等的apk文件而已。

2-2-5 keytool与jarsigner工具

对apkbuilder打包压缩出来的apk进行签名的实质其实是在应用程序的特定字段写入特定的标记信息，以便用来表示该软件已经通过了签署者审核。签名的作用主要是识别应用的作者、检测应用程序是否已经改变、检测是否为同一个应用等。

一般我们可以通过keytool工具生成签名私钥，然后通过jarsigner工具使用私钥对应用进行签名。不过这一过程非常简单，这里就不再啰嗦了，自行脑补。

2-2-6 zipalign工具

zipalign工具可以对打包的应用进行优化，优化过的应用在运行时执行效率可以达到最大限度且会占用更少的RAM（Random Access Memory）内存。zipalign对apk文件中数据进行4字节对齐，也就是说编译器把4个字节作为一个单位来进行操作，这样CPU就能对代码进行高效访问，因为对齐后Android系统可以通过调用mmap函数读取文件，也就是说进程可以像读写内存一样操作我们apk中普通文件，所以当对齐的应用在系统中执行时通过共享内存IPC读取资源就能得到较高的性能，如果没有对齐处理则必须显示的调运read等方法去操作数据，也就是说运行过程会比较缓慢且会花费更多的内存，从而导致性能下降。

关于zipalign工具的使用这里也不再啰嗦了，因为通常编译框架允许我们直接配置脚本而不用手动执行命令。

2-2-7 ProGuard工具

ProGuard是一个压缩、优化和混淆Java字节码class文件的工具，它可以删除无用的类、字段、方法、属性及没用的注释等，最大限度地优化class字节码文件。它还可以使用简短的无意义名称来重命名已经存在的类、字段、方法和属性。我们通常用它来混淆最终的项目，然后稍微增加项目被反编译的难度，当然了，对于现在的技术来说反编译难度这个已经不是问题了，我们还是重点关注他的优化无用资源和简洁替代吧。

关于ProGuard工具的使用这里也不再啰嗦了，因为通常编译框架允许我们直接配置脚本而不用手动执行命令。

2-2-8 jobb工具

其实这个工具不属于正常编译框架的流程，算是Android的一个拓展特性而已。从Android 2.3版本开始系统增加了一个OBB文件系统（权限访问限制隔离文件系统）和StorageManager类用来管理外部存储上的数据安全。

如果你之前在Android手机上安装过《纪念碑谷》或者《机械迷城》游戏，那你就能对这里讲的jobb工具和OBB文件系统有一个很好的理解。还记不记得在安装几十兆大小的游戏后你还需要下载一个两百多兆的zip压缩包放到文件系统的Android/obb/[GamePackageName]目录下才能正常玩游戏。之所以这么做是因为我们的游戏工程中包含大量的资源（图片、视频、音乐等），直接编译为APK可能会高达好几百兆，系统在安装APK时又会对APK文件大小有一个限制，这么大的APK文件必定会导致Android系统无法正常安装该APK；相信此时机智的你指定会说，我们把这些资源直接放到SD卡上不就完了？哈哈，你想没想过一问题，如果直接放到SD卡，系统的音乐、视频、图片等管理器岂不是直接可以索引到这些东东了，那得多不好（插一句，还可以将这些资源去掉后缀保存，这样这些媒体库就无法索引了，譬如Android系统邮件应用的附件就是这么设计的，真机智！）。好在Android 2.3的OBB文件可以很牛叉的解决这一系列问题。

既然这样的话，想必OBB文件系统一定会要求存储的文件必须符合一定的格式，jobb就是解决这个问题的工具。jobb允许我们生成加密或不加密的OBB格式扩展文件，OBB文件可以作为Android应用程序的扩展资源文件，独立于APK文件存在。下面就是jobb工具的文档：

关于jobb工具这里就不深入说明了，一般游戏等大资源应用开发中才可能会考虑到这种设计，用到时再脑补也不迟，这里知道有这么回事就行了。

2-3 Android应用编译Jack和Jill新工具链

到这里其实大家对常规的应用编译框架已经有了一个不错的认识了，But问题来了，你是不是也觉得当前的Android编译构建流程相当蛋疼（编译构建巨慢）呢，其实Google官方似乎也意识到了这个问题，他们还在今年的Google IO大会上给出了当前阶段的一些优化交代，其中最值得尝试和一提的亮点是Jack和Jill两个新的编译器（当前官方声称还是Experimental试验性的编译器，还不够健壮，还在bug收集阶段，当前不支持注解处理，不支持Java 8等，所以还是慎重），官方说这两个编译器旨在简化安卓的编译流程，说白了也就是尝试加快编译构建速度。下面先来看下使用Jack和Jill编译器的构建流程：

可以看见，Jack是一个基于Java编译器和ProGuard的工具，但是目前版本还不支持ProGuard的一些高级功能（譬如移除日志代码）。Jill将Java库字节码转化成名为jayce的中间字节码.jack文件，Jack对Java源码和jayce字节码进行编译，生成经过优化的dex字节码。

想尝鲜使用Jack和Jill你需要保证你的Build Tools version是21.1.1版本或者更高。在Gradle中配置如下：

android {
    ...
    buildToolsRevision ‘21.1.2’
    defaultConfig {
      // Enable the experimental Jack build tools.
      useJack = true
    }
    ...
}

总归一句话，现在还年轻，有何成就还得观望，看后面的发展趋势吧，反正目前我是没咋使用他，只是试验性的尝鲜了一把而已。

【工匠若水 blog.csdn.net/yanbober 未经允许严禁转载，请尊重作者劳动成果。私信联系我】

3 Android应用IDE及编译相关特性

下面介绍一些使用IDE开发过程中高效的代码编写特性，同时包含一些编译相关的注意特性，具体如下会细说。

3-1 Android应用jar包与aar包

我们在Android Studio中对一个自己的库进行编译时会同时生成jar与aar两个包。他们的具体路径如下：

包类型	在AS中的输出路径
jar	/build/intermediates/bundles/debug[release]/classes.jar
aar	/build/outputs/aar/library.aar

他们两者的区别如下（实质都是压缩包）：

包类型	描述
jar	只包含class文件，不包含资源文件，用于纯Java编写的库。
aar	包含所有class及res等全部资源，类似UI库。

其实关于他们二者的区别我们通过解压缩即可直观的看出来，这里不再叙述。

关于Android应用编译框架中还需要知道一个有用的工具属性，那就是tools命名空间属性，他的命名空间URI是schemas.android.com/tools，可以说这个命名空间是专门为开发者设计的，只在设计阶段有效，运行阶段无效。

    ....

tools属性可以替换所有Android的属性，只在设计阶段有效，不会被带入最终的apk中，所以运行时无效。整个tools命名空间的属性分两大类，一类是Lint相关的、一类是设计相关的。下面我们列举一下tools相关的一些实用属性。

告诉Lint忽略xml中某些警告。如下用法：

All

用来指定API等级，功能和Java文件中的@TargetApi注释类似，值为整数或者含义字符串。如下用法：

默认情况下res/values/strings.xml文件中的字符串会进行拼写检查，如果本地不是英语则会给出警告，我们可以通过这样来指定本地语言然后忽略警告。如下：

这个属性其实就是关联Activity属性，在xml中添加该属性后预览该xml文件就能知道采用啥主题来预览，同时关联了Activity文件与xml文件，可以从java文件直接跳转索引。如下：

该属性用在xml的fragment节点中，在开发时告诉IDE该fragment在预览模式下显示的样子。如下：

很明显可以猜到用来给ListView、AdapterView、GridView、ExpandableListView指定预览时的item和头底。如下：

该属性被设置到一给被include的布局的根节点上，预览时可用。如下：

用来告诉IDE在预览时当前xml布局显示指定的menu样式。其实如果我们指定了tools:context属性，IDE会很智能的在我们指定Activity文件中的onCreateOptionsMenu方法中寻找menu样式预览。当然了，我们可以通过该属性覆盖Activity中的menu预览。如下：

指定actionbar的预览模式。可选值为”standard”、”list”、”tabs”。如下：

3-2-11 Designtime设计时属性

tools属性可以替换所有Android的属性，只在设计阶段有效，不会被带入最终的apk中，所以运行时无效。譬如我们最常见的在写一个TextView时不想在xml中给他初始文本内容，又想预览，这时候就可以用tools属性替代。如下：

可以看见，tools命名空间属性可以加速我们开发的灵活度和可预测度，同时在编译框架中又会忽略这些属性，不把他们带入最终产物apk中，我们可以在开发中酌情选择是否使用这些属性。

3-3 Android Annotations注解说明

在Android Support Library的19.1版本中加入了一个新的注解包，这个包用来注解代码，方便捕获程序中存在的问题和bug，这个包内部的代码就已经使用了该注解，在22.2版本中又增加了13个新的注解，这些注解可以方便我们代码开发与调运规范和bug检查，具体用法下面会一一讲解。

3-3-1 注解Library依赖引用

annotations注解包默认不会自动被包含，不过如果使用appcompat包则会自动包含，因为appcompat包里使用了注解。

在Android工程的Gradle文件中引入注解包如下：

dependencies {
    compile 'com.android.support:support-annotations:22.2.0'
}

如果不是Android工程中想使用该注解包则可以如下写法（url为本地android sdk的注解包路径）：

repositories {
   jcenter()
   maven { url '/extras/android/m2repository' }
}

3-3-2 执行注解

当我们在用Android Studio和IntelliJ时如果给使用了注解的方法传递错误类型参数，则IDE会实时标记提醒错误。如果使用的是Gradle 1.3.0版本以上且安装了Android M Preview Tools以上工具则可以通过命令行调用gradle的lint任务进行检查（nullness注解会被忽略检查）。

3-3-3 Null空类型判断注解

@Nullable 注解用来标注给定的参数或返回值可以为null。
@NonNull 注解用来标注给定的参数或返回值不能为null。

假设一个本地变量值为null，且把它作为参数传递给一个方法，且该方法的参数被@NonNull标注，则AS会提醒存在一个潜在的崩溃。如下：

import android.support.annotation.NonNull;
import android.support.annotation.Nullable;
...

    /**
     * Add support for inflating the  tag.
     */
    @Nullable
    @Override
    public View onCreateView(String name, @NonNull Context context, @NonNull AttributeSet attrs) {
        ...

3-3-4 资源类型注解

Android的资源值通常都是通过R文件映射的整型id来关联的，也就是说获取一个layout类型的资源参数很容易被误传递一个其他类型的资源参数，因为他们都是整型的资源id，编译器很难区分。为了解决这种问题可以使用资源类型注解，因为注解提供类型检查。譬如下面是一个被@LayoutRes注解的整型参数却传递了一个string类型的资源参数，此时IDE会给出错误提示：

调运setContentView方法时传递错误参数：

setContentView的资源注解实现方法：

实际上有很多不同的资源类型注解，譬如@AnimatorRes、@AnimRes、@AnyRes、@ArrayRes、@AttrRes、@BoolRes、@ColorRes、@DimenRes、@DrawableRes、@FractionRes、@IdRes、@IntegerRes、@InterpolatorRes、@LayoutRes、@MenuRes、@PluralsRes、@RawRes、@StringRes、@StyleableRes、@StyleRes、@XmlRes等，一般一个foo类型资源的相应资源类型注解就是@FooRes。除此之外，还有一个名为@AnyRes的特殊资源类型注解，它被用来标注一个未知特殊类型的资源，且必须是一个资源类型。譬如在Resources.getResourceName(@AnyRes int resId)上使用的时候，我们可以通过getResources().getResourceName(R.drawable.icon)和getResources().getResourceName(R.string.app_name)等方式来使用，但却不能通过getResources().getResourceName(42)来使用。

3-3-5 IntDef/StringDef类型注解

这种类型的注解是基于Intellij的魔数检查机制的，因为Android开发中很多时候出于性能考虑，我们会使用整型常量代替枚举类型。譬如AppCompat库里的一个例子：

import android.support.annotation.IntDef;
...
public abstract class ActionBar {
    ...
    @IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS})
    @Retention(RetentionPolicy.SOURCE)
    public @interface NavigationMode {}

    public static final int NAVIGATION_MODE_STANDARD = 0;
    public static final int NAVIGATION_MODE_LIST = 1;
    public static final int NAVIGATION_MODE_TABS = 2;

    @NavigationMode
    public abstract int getNavigationMode();

    public abstract void setNavigationMode(@NavigationMode int mode);

上面非注解的部分是原本的代码和API，我们通过@interface创建了一个新注解NavigationMode，并且用@IntDef标注它可能的取值，还添加了@Retention(RetentionPolicy.SOURCE)告诉编译器这个新定义的注解不需要被记录在生成的.class文件中；使用这个注解后，如果我们返回或传递的参数不在指定的常量值中则IDE会给出明显的错误提示。

我们也可以指定整型常量为一个标记性质的类型，因为这样就可以通过|、&等操作符同时传递多个整型常量。如下例子：

    @IntDef(flag=true, value={
            DISPLAY_USE_LOGO,
            DISPLAY_SHOW_HOME,
            DISPLAY_HOME_AS_UP,
            DISPLAY_SHOW_TITLE,
            DISPLAY_SHOW_CUSTOM
    })
    @Retention(RetentionPolicy.SOURCE)
    public @interface DisplayOptions {}

@StringDef和@IntDef的作用基本上一样，不同的是它针对的是字符串。关于类型注解更多信息点我获取。

3-3-6 线程注解@UiThread、@WorkerThread等

线程注解是在Support Library 22.2及更高版本中才被支持的，如果我们的方法只能在指定的线程类型中被调用，则就可以使用以下4个注解来标注它们：

• @UiThread

• @MainThread

• @WorkerThread

• @BinderThread

如果一个类中的所有方法都有相同的线程需求则可以注解类本身。

关于线程注解使用的一个例子是AsyncTask，如下：

    @WorkerThread
    protected abstract Result doInBackground(Params... params);

    @MainThread
    protected void onProgressUpdate(Progress... values) {
    }

如果在使用该方法时没有按照注解线程执行则会报错，如下：

3-3-7 约束值注解@Size、@IntRange、@FloatRange

如果我们的参数是float或double类型且限制在一个范围内，则可以使用@FloatRange注解，如下：

public void setAlpha(@FloatRange(from=0.0, to=1.0) float alpha) {

如果我们的参数是int或long类型则可以使用@IntRange注解来约束值的范围，如下：

public void setAlpha(@IntRange(from=0,to=255) int alpha) { … }

对于数据集合或字符串，我们可以用@Size注解来限定集合大小或字符串长度。譬如：

@Size(min=1)

@Size(max=23)

@Size(2)

@Size(multiple=2)

3-3-8 权限注解@RequiresPermission

如果我们的方法调用时需要特定权限，则可以用@RequiresPermission进行注解。如下：

@RequiresPermission(Manifest.permission.SET_WALLPAPER)
public abstract void setWallpaper(Bitmap bitmap) throws IOException;

如果方法至少需要权限集合中的一个则可以使用anyOf属性。如下：

@RequiresPermission(anyOf = {
    Manifest.permission.ACCESS_COARSE_LOCATION,
    Manifest.permission.ACCESS_FINE_LOCATION})
public abstract Location getLastKnownLocation(String provider);

如果方法同时需要多个权限则可以使用allOf属性。如下：

@RequiresPermission(allOf = {
    Manifest.permission.READ_HISTORY_BOOKMARKS, 
    Manifest.permission.WRITE_HISTORY_BOOKMARKS})
public static final void updateVisitedHistory(ContentResolver cr, String url, boolean real) {

对于Intent的权限可以直接在定义的Intent常量字符串字段上标注权限需求（通常都已经被@SdkConstant注解标注过了)。如下：

@RequiresPermission(android.Manifest.permission.BLUETOOTH)
public static final String ACTION_REQUEST_DISCOVERABLE =
            "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE";

有时对于ContentProvider的权限可能需要单独的标注读和写权限，所以可以用@Read或者@Write注解。如下：

@RequiresPermission.Read(@RequiresPermission(READ_HISTORY_BOOKMARKS))
@RequiresPermission.Write(@RequiresPermission(WRITE_HISTORY_BOOKMARKS))
public static final Uri BOOKMARKS_URI = Uri.parse("content://browser/bookmarks");

3-3-9 重写方法注解@CallSuper

如果想在重写方法中要求必须调运父类的super方法则可以用@CallSuper标注。如下：

    @CallSuper
    protected void onCreate(@Nullable Bundle savedInstanceState) {

3-3-10 @CheckResult、@VisibleForTesting、@Keep

如果我们的方法返回一个值且期望调用者用这个值做些事情则可以使用@CheckResult注解标注这个方法。

如果我们想在测试时使用一个类、方法或者字段则可以用@VisibleForTesting注解进行标明。

特别要说的就是我们还在注解库里添加了@Keep注解，但是Gradle插件目前版本支持的还不是很好，这个注解标注的东西不会被混淆。

3-3-11 其他注解相关

如果我们在自己的lib库中使用了上面这些注解，且通过Gradle构建生成了aar包，则在构建时Android Gradle插件会提取注解信息放在aar文件中供使用库的地方使用。在aar文件中你可以看到一个名为annotations.zip的文件，这个文件记录的就是使用IntelliJ扩展注解XML格式的注解信息。

PS一句，IntelliJ其实还有他自己的注解，这里不再详细说明。

可以看见，有了这种注解我们的IDE看起来就更加的智能便捷强大了，同时也帮助我们的编译框架及早的发现问题，给出警告或者错误提示。

【工匠若水 blog.csdn.net/yanbober 未经允许严禁转载，请尊重作者劳动成果。私信联系我】

4 Gradle Android构建

其实Android的Gradle构建没啥太多说的，掌握Groovy语法和Gradle框架后看看Gradle Android Plugs相关DSL特性就行了，用的时候去查API和Android DSL规则即可，重点明白结构和常用的DSL规则即可，这里给出一个常用模板，补充常用实战基础示例参见《Android Studio入门到精通》一文的第7小节。

4-1 Gradle Android编译构建配置基础

Android Studio的project在project树根和每个module根都包含一个叫build.gradle的文件，我们所谓的编译构建配置其实就是通过Gradle的Android插件进行编写脚本，大多数情况下我们一般只用修改相关module下的build.gradle文件就能满足需求。如下一个例子：

apply plugin: 'com.android.application'

android {
    
    
    compileSdkVersion 19
    
    buildToolsVersion "19.0.0"
    
    
    defaultConfig {
        
        applicationId "com.example.my.app"
        minSdkVersion 8
        targetSdkVersion 19
        versionCode 1
        versionName "1.0"
    }
    
    
    
    buildTypes {
        release {
        
            minifyEnabled true
        
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    
    compile project(":lib")
    
    compile 'com.android.support:appcompat-v7:19.0.1'
    
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

有时候你会在gradle脚本中发现repositories被声明两次，这时候你一定有过疑惑的，下面给出这个疑惑的答案：

buildscript块中的repositories声明：该声明的作用是声明gradle脚本自身要用的资源（譬如依赖项、第三方插件、maven地址等）。

build.gradle文件中的repositories声明：该声明作用是项目自身需要的资源声明。

如果想在Gradle脚本中使用第三方插件，且这些插件、类库又不用于项目，而是支持其它Gradle脚本运行的，此时我们就该把这种依赖声明放在buildscript代码块中，Gradle在执行脚本时会优先执行buildscript代码块中的内容，然后执行剩余的脚本。相反，如果我们在项目中需要使用一些插件、类库的话，就需要定义在buildscript块之外的dependencies中。

4-2 Gradle Android构建配置build variants

接下来我们来看看如何通过Gradle构建系统对一套项目工程编译多个版本（譬如适配多设备类型、不同应用Market发布等），这个构建功能非常简单、强大和实用。

使用Product flavors进行多版本apk生成的步骤如下：

1. 在build文件中定义product flavors；
2. 为每一个flavor创建额外的资源目录；
3. 把这些资源加入工程进行指定类型编译；

先看第一步，如下定义两中类型的编译配置：

...
android {
    ...
    defaultConfig { ... }
    signingConfigs { ... }
    buildTypes { ... }
    productFlavors {
        demo {
            applicationId "com.buildsystemexample.app.demo"
            versionName "1.0-demo"
        }
        full {
            applicationId "com.buildsystemexample.app.full"
            versionName "1.0-full"
        }
    }
}
...

上面例子创建了id与version不同的两个apk；特别注意，我们一般把不同product flavors相同的属性元素都统一定义在defaultConfig元素中，因为defaultConfig元素的属性值默认应用于所有build variant，除非我们在build variant中重写这些值才可以。

接着我们看下第二步和第三步，为每个flavor添加不同的资源。我们可以看见上一步中定义了不同的applicationId，主要区分是demo和full，也就是说我们可以在src目录下为这两种情况分别创建相关的资源目录（譬如这里创建demo和full目录，我们放置一些特定属于demo和full的区分资源），完事以后在AS的面板中选择Build Variants的不同类型编译即可。

4-3 Gradle Android Plugin DSL

哎呀，这个不说了，自己去看官方文档吧，Google官方和Gradle官方都有关于Android DSL的详细说明，心好累，请允许我矫情一回。

【工匠若水 blog.csdn.net/yanbober 未经允许严禁转载，请尊重作者劳动成果。私信联系我】

5 Android应用编译相关总结

这篇博客纯属难产，草稿箱睡了一两个月了，今天终于生下来了。一直断断续续没有激情，郁闷哇。

上面我们介绍了Android应用源码生成Apk的过程及其中涉及的相关工具，同时也介绍了应用新的编译工具Jack和Jill，接着简单说明了一下当下非常流行热火的Android Tools Attributes和Android Annotations注解，最后给出了一个简单的Gradle Android Plugin DSL规范说明。了解了这些流程和简单原理之后相信对于应用开发和构建会有本质的帮助。

总体来说本文难产，质量不高，凑合着看吧！

【工匠若水 blog.csdn.net/yanbober 未经允许严禁转载，请尊重作者劳动成果。私信联系我】