娘娘 奴才有了,谭阎网vfw8,天天2088
资源合并
如果项目引入了android support包，又或许依赖于其它第三方aar库，那构建前会将aar解压并与本地资源合并，这里的资源主要包括assets目录，res目录及androidmanifest.xml。
当第三方依赖中的assets或res文件与本地文件有冲突时，会优先选用本地文件。但res/values略有不同，此目录下的strings.xml、color.xml、styles.xml等文件会被整合到一个叫values.xml的文件中去，后与各第三方依赖中的values.xml进行内容上的合并，不会像res其它子目录文件一样直接舍弃第三方冲突文件。
androidmanifest.xml的合并相比来说则要复杂一些，除了第三方依赖中的manifest，项目还可以在不同目录下分别拥有manifest文件。构建过程中，会根据manifest中元素、属性及赋值来生成一个manifest文件，并应用于后续的打包过程。gradle为不同的manifest赋予了不同的优先级，其顺序如下：
buildtype 设置 > productflavor 设置 > src/main > dependency&library
xml元素及属性的冲突会根据以下规则进行解决：
当然也会有一些例外的：
uses-feature android:required与uses-library android:required默认为true，根据or规则合并；
如未指定uses-sdk，minsdkversion跟targetsdkversion将被设置为1。而冲突时会使用高优化级的设置；
若library的minsdkversion高于src/main的设置，则会引发error，但可通过overridelibrary解决。若未指定targetsdkversion，则其值与minsdkversion一致；
若library的targetsdkversion低于src/main的设置，需要添加一些额外的权限保证library能正常运行；
manifest元素只与子manifest元素合并；
intent-filter元素在合并中不会被改变，只会被添加到其父节点中去；
冲突发生时，可通过合并冲突标记进行解决，需要引入android tools命名空间，详情请参阅官方文档。另外，manifest在对文件进行合并后，还会根据build.gradle的设置覆盖相关属性。
aapt打包
资源合并后，即进入到编译阶段，先会把项目资源中的xml编译成二进制并生成r.java及资源索引表resources.arsc，其流程如下：
由图可见，assets是不需要做任何处理的，res/raw只需分配id后与assets一起直接打包到应用程序中；基于下述原因，其它xml文件则会被编译成二进制。
编译过程中，会把xml中的字符串进行收集去重，形成字符串资源池，元素中用到字符串的地方将被替换成相应的索引。另外，标签属性/値都会转换为资源id，进一步减少文件大小；
二进制格式的xml把标签属性/値转换为资源id后，避免了字符串解析，从而提高了解析速度；
经过aapt（android asset packaging tool）处理后，会输出2个文件：一个r.java，为项目各资源分配了不同的id，将和java源码一起参与到后续的编译过程，id为4字节无符号整数，最高字节表示package id，次高字节表示type id，后2字节表示资源在当前类型中出现的序号，如r.string.appname=0x7f07006b中的0x7f代表当前正在编译的资源包，0x07代表string类型，0x006b代表app_name在string类型中出现的序号；另一个为app.ap，实际上为一个压缩包，包含了assets、res、androidmanifest.xml与resources.arsc
资源索引表resources.arsc记录了从资源id到文件路径的转换关系，当应用通过resources类获取res文件资源时，会先从resources.arsc中拿到文件路径，然后通过assetmanager进行访问。
application component -> resources.arsc -> assetmanager -> apk
从上述流程中可以看到，若要进行资源的混淆，可在分析resources.arsc格式后，修改内容中文件路径的指向并对资源文件进行相应的重命名即可。
另外，aapt还可对png图进行优化、指定文件以stored还是deflated模式添加到压缩包中等操作。
源码编译
当项目中包含aidl时，会先调用aidl工具生成java代码；renderscript亦然，需要先调用llvm-rs-cc，只是它不仅会自动生成java文件，还会产生相应的.bc文件，.bc文件将打包到apk中
至此，java代码都已准备完毕。下一步要进行的是通过javac命令将java源码编译成.class字节码，用以编译的classpath包含以下内容：
android.jar，具体版本由targetsdkversion指定；
build.gradle中添加的第三方依赖；
编译后可对代码进行混淆处理，主要包括删除无用类、字节码优化、重命名等操作，只需在build.gradle中配置混淆规则即可
我要评论
buildtypes {
release {
minifyenabled true
proguardfiles getdefaultproguardfile('proguard-android.txt')
proguardfile 'proguard/proguard-rules.pro'
}
}
生成dex
如果项目涉及分dex，那在调用dx命令前，需要做一些准备的工作，把编译后的class文件打包成jar包allclasses.jar，然后生成主dex中必须包含的文件列表。主要包括collect、shrink及create 3个步骤。
首先会通过androidmanifest.xml过滤出项目中使用到的四大组件（activity、service、receiver、provider）、application及instrumentation，并写入manifest_keep.txt文件，这些都是会默认添加到主dex的，无须手动设置。除此之外，默认添加的还有继承于 backupagent 及 annotation 的类。若有额外的类需要被加入到主dex中，可以新建一个文件并以proguard的语法指定，然后在build.gradle中把此文件配置到multidexkeepproguard中去。此过程关键代码如下：
void generatekeeplistfrommanifest() {
saxparser parser = saxparserfactory.newinstance().newsaxparser()
writer out = new bufferedwriter(new filewriter(getoutputfile())) try {
parser.parse(getmanifest(), new manifesthandler(out)) // add a couple of rules that cannot be easily parsed from the manifest.
out.write("""-keep public class * extends android.app.backup.backupagent {<init>();}
-keep public class * extends java.lang.annotation.annotation {*;}
""") if (proguardfile != null) {
out.write(files.tostring(proguardfile, charsets.utf_8))
}
} finally {
out.close()
}
}
这个时候，会执行一个叫shrinkxxxmultidexcomponents（xxx为build types名称）的任务。实际上是调用了proguard，只是要比常规的proguard简单一些，不执行混淆、优化跟预检几个步骤，只需要shrink即可，以allclasses.jar为输入、manifest_keep.txt为混淆配置文件，把指定内容及其引用标记起来，然后添加到componentclasses.jar中去。
public void execute(proguardtask proguardcomponentstask) {
proguardcomponentstask.dontobfuscate();
proguardcomponentstask.dontoptimize();
proguardcomponentstask.dontpreverify(); // 方法未完，略过...}
到了createmaindexlist，会调用dx命令，传入allclasses.jar、componentclasses.jar，分析后者依赖，把它直接引用的类也添加到主dex中，并生成新的multidex配置文件maindexlist.txt，至此，准备工作完成。
经过上一阶段编译的处理，已经生成了标准的java字节码，可在标准的java虚拟机上运行。但android使用了它特有的dalvik虚拟机，这就需要我们为它提供另一不同的格式。dx工具为此而出现，可将.classes文件转换添加到dalvik可执行文件.dex中去。当项目发展到一定规模，需要进行分dex处理时，可通过上述步骤生成的maindexlist.txt指定dex该如何拆分。
遗憾的是，以上关于分dex的内容都是理想的情况，现实却很残酷。如果项目中开启了proguard，那它会在分dex的shrink处理前完成，导致allclasses.jar是混淆处理后的代码，而manifest_keep.txt却未曾混淆，后续生成componentclasses.jar 及 maindexlist.txt 的过程也就都不再可靠了。要解决这个问题，在shrink前通过混淆输出的符号表mapping.txt对manifest_keep.txt进行修正是个不错的选择。
打包签名
此时万事俱备，只要把资源包app.ap_、可执行文件classes.dex及项目（包含第三方依赖）中的非源码文件一起添加到压缩包中去，我们的安装包（.apk文件）也就生成了。
另外，apk需要经过签名才可以发布。可通过jarsigner工具完成。
zipalign
文件对齐并非android构建的必要步骤，但对齐处理后可提高系统访问安装包资源的效率。即使执行了zipalign，也只有以stored模式添加到apk中的文件是需要对齐的。如若对图片等资源进行了极限压缩或在aapt打包时选择了deflated，那可对齐的文件也就没多少了
通过build tools中的zipalign工具以下命令可对压缩包进行对齐
zipalign -f -v 4 app.apk toapp.apk
以下命令则起到了检验压缩包有没有对齐的作用：
zipalign -c -v 4 app.apk
总结
本文主要介绍了android构建的各个主要步骤，并重点讲述了资源合并打包与dex生成的过程。最后，用一张图概括下构建的总体流程：
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Android studio开发小型对话机器人app(实例代码)
Android通过Java sdk的方式接入OpenCv的方法
Android 通过cmake的方式接入opencv的方法步骤
Android Studio finish()方法的使用与解决app点击“返回”(直接退出)
Android 进度条 ProgressBar的实现代码(隐藏、出现、加载进度)
网友评论