android工程编译过程

Android Studio安装
下载地址:https://developer.android.google.cn/studio/
android studio安装完后要在安装jdk(1.8)和sdk版本(24)
1、.gradle gradle编译系统,版本由wrapper决定
.idea AndroidStudio IDE所需要的文件 IntelliJ IDEA 同样有这个文件
这两个目录下文件都是Android Studio 自动生成的一些文件,我们无需关心,也不要手动去编辑
2、app app项目的代码、资源等内容几乎都是放在这个目录下,我们后期的开发也基本都是在这个目录下进行
3、build build代码编译后生成的文件存放的位置
4、gradle wrapper的jar和配置文件所在位置,这个目录下包含了gradle wrapper的配置文件使用gradle wrapper的方式不需要提前将gradle下载好,而是会自动根据vending的缓存情况决定是否需要联网下载gradle
5、.gitgnore git使用的ignore文件 这个文件是用来将指定的目录或者文件排除在版本控制之外的
6、build.gradle gradle编译的相关配置文件,这是项目全局的gradle构建脚本,通常这个文件中的内容是不需要修改的
7、gradle.properties gradle相关的全局属性设置,这个文件是全局的gradle配置文件,在这里配置的属性将会影响到项目中所有的gradle编译脚本
8、gradlew Unix下的gradle wrapper 可执行文件
gradlew.bat windows下的gradle wrapper 可执行文件
这两个文件是用来在命令行界面中执行gradle命令的,其中gradlew是在Linux或者Mac系统使用的,gradle是windows下使用的
9、项目名.iml iml文件是所有Android Studio项目自动生成的文件,我们不需要关心或者修改这个文件的内容
10、local.projecties 本地属性设置(key设置,android ndk sdk 位置等属性),这个文件是不推荐上传到VCS中去的
11、settings.gradle 这个文件用于指定项目中所有引入的模块。
3.app目录分析
build 编译后的文件存在的位置(包括最终生成的apk也在这里面)
libs 依赖的库所在的位置(jar和aar)
src 源代码所在的目录
src/main 主要代码所在位置
src/main/assets android中附带的一些文件
src/main/java java代码所在的位置
src/main/jniLibs jni的一些动态库所在的默认位置(.so文件)
src/main/res android资源文件的所在位置
src/main/AndroidManifest.xml 清单文件
build.gradle 和这个项目有关的gradle配置,相当于这个项目的Makefile,一些项目的依赖就写在这里
proguard.pro 代码混淆配置文件

gradle
build.gradle(Project).png

1.buildscript
buildscript中的声明是gradle脚本自身需要使用的资源。可以声明的资源包括依赖项、第三方插件、maven仓库地址等
2.repositories
顾名思义就是仓库的意思啦,而jcenter()、maven()和google()就是托管第三方插件的平台
3.dependencies
当然配置了仓库还不够,我们还需要在dependencies{}里面的配置里,把需要配置的依赖用classpath配置上,因为这个dependencies在buildscript{}里面,所以代表的是Gradle需要的插件。
4.allprojects
allprojects块的repositories用于多项目构建,为所有项目提供共同所需依赖包。而子项目可以配置自己的repositories以获取自己独需的依赖包。
5.buildscript和allprojects的作用和区别
buildscript中的声明是gradle脚本自身需要使用的资源,而allprojects声明的却是你所有module所需要使用的资源,就是说每个module都需要用同一个第三库的时候,你可以在allprojects里面声明
6.task clean
运行gradle clean时,执行此处定义的task。该任务继承自Delete,删除根目录中的build目录。相当于执行Delete.delete(rootProject.buildDir)。其实这个任务的执行就是可以删除生成的Build文件的,跟Android Studio的clean是一个道理。
1.android{}
是Android插件提供的一个扩展类型,可以让我们自定义Android Gradle工程,是Android Gradle工程配置的唯一入口。
2.compileSdkVersion
是编译所依赖的Android SDK的版本,这里是API Level。
3.buildToolsVersion
是构建该Android工程所用构建工具的版本。
4.defaultConfig{}
defaultConfig是默认的配置,它是一个ProductFlavor。ProductFlavor允许我们根据不同的情况同时生成多个不同的apk包。
5.applicationId
配置我们的包名,包名是app的唯一标识,其实他跟AndroidManifest里面的package是可以不同的,他们之间并没有直接的关系。
package指的是代码目录下路径;applicationId指的是app对外发布的唯一标识,会在签名、申请第三方库、发布时候用到。
6.minSdkVersion
是支持的Android系统的api level,这里是15,也就是说低于Android 15版本的机型不能使用这个app。
7.targetSdkVersion
表明我们是基于哪个Android版本开发的,这里是22。
8.versionName
表明我们的app应用的版本名称,一般是发布的时候写在app上告诉用户的
9.versionCode
表明我们的app应用的版本,一般app升级基于versionCode(应用市场)
10.multiDexEnabled
用于配置该BuildType是否启用自动拆分多个Dex的功能。一般用程序中代码太多,超过了65535个方法的时候。
11.ndk{}
多平台编译,生成有so包的时候使用,包括四个平台'armeabi', 'x86', 'armeabi-v7a', 'mips'。一般使用第三方提供的SDK的时候,可能会附带so库。
12.manifestPlaceholders
占位符,我们可以通过它动态配置AndroidManifest文件一些内容
builde(module).png
13.buildType
构建类型,在Android Gradle工程中,它已经帮我们内置了debug和release两个构建类型,两种模式主要车别在于,能否在设备上调试以及签名不一样,其他代码和文件资源都是一样的。一般用在代码混淆,而指定的混淆文件在下图的目录上,minifyEnabled=true就会开启混淆,shrinkResources=true 缩小APK大小,删除没有引用的资源文件(drawable和layout)
image.png
16.dependencies{}
我们平时用的最多的大概就这个了,
首先第一句compile fileTree(include: ['.jar'], dir: 'libs')*,这样配置之后本地libs文件夹下的扩展名为jar的都会被依赖,非常方便。
如果你要引入某个本地module的话,那么需要用compile project('×××')。
如果要引入网上仓库里面的依赖,我们需要这样写compile group:'com.squareup.okhttp3',name:'okhttp',version:'3.1.0',当然这样是最完整的版本,缩写就把group、name、version去掉,然后以":"分割即可。
compile 'com.squareup.okhttp3:okhttp:3.1.0'
但是到了gradle3.0以后build.gradle中的依赖默认为implementation,而不是
之前的compile。另外,还有依赖指令api。
gradle 3.0中其实api跟以前的compile没什么区别,将compile全部改成api是不会错的;而implementation指令依赖是不会传递的,也就是说当前引用的第三方库仅限于本module内使用,其他module需要重新添加依赖才能用
5.文件编译及打包
Make Project:编译Project下所有Module,一般是自上次编译后Project下有更新的文件,不生成apk。
Clean Project:删除之前编译后的编译文件,并重新编译整个Project,比较花费时间,不生成apk。
Rebuild Project:先执行Clean操作,删除之前编译的编译文件和可执行文件,然后重新编译新的编译文件,不生成apk,这里效果其实跟Clean Project是一致的,这个不知道Google搞什么鬼~~
Build APK:前面4个选项都是编译,没有生成apk文件,如果想生成apk,需要点击Build APK。
Generate Signed APK:生成有签名的apk。
打包过程
不管使用什么IDE,Android 打包生成Apk主要都是由以下几步完成:
1、根据资源文件和AndroidManifest.xml生成R.java文件
2、处理aidl,生成对应的java文件,如果没有aidl,则跳过
3、编译工程源码(主项目,库)src目录下所有的源码,同时上边生成的R.java和aidl生成的java文件也会被编译生成相应的class文件
4、将第3步生成的class文件打包生成.dex文件
5、将资源文件打包,生成初始的apk
6、将第4步生成的.dex文件加入到apk中生成未签名的包
7、apk签名
一、生成R.java
R.java对于Android开发同学,肯定非常熟悉,它是一个非常重要的一个类,并且它是自动生成的,主要是包含了res目录下所有资源的ID,我们可以在程序中通过它来获取资源ID,然后通过Android Api来获取具体的资源。
TextView tv = (TextView) findViewById(R.id.tv_text);
tv.setText(R.string.app_name);
R.java是由SDK中提供的aapt(sdk/build-tools/ 中对应的版本下,本文使用的26.0.2,那么具体的路径就是sdk/build-tools/26.0.2)工具生成的。
一、生成R.java
R.java对于Android开发同学,肯定非常熟悉,它是一个非常重要的一个类,并且它是自动生成的,主要是包含了res目录下所有资源的ID,我们可以在程序中通过它来获取资源ID,然后通过Android Api来获取具体的资源。
TextView tv = (TextView) findViewById(R.id.tv_text);
tv.setText(R.string.app_name);
R.java是由SDK中提供的aapt(sdk/build-tools/ 中对应的版本下,本文使用的26.0.2,那么具体的路径就是sdk/build-tools/26.0.2)工具生成的。
二、javac 编译所有java文件
这一步其实就是使用jdk的javac将项目中所有的java文件编译成class文件。
三、打包生成.dex文件
dex文件是Android虚拟机可运行文件,可以使用dx工具生成。
dx工具会将上一步app/src/main/build/中生成的class文件全部打包,得到classes.dex,apk包中包含的classes.dex就是这样生成的,当然实际项目可能类会很多,但是过程是一样的。
有了classes.dex,开始要打包apk了
四、打包资源文件
apk包中的资源文件都是经过编译过的,是二进制文件。我们还是使用aapt工具:
将AndroidManifest.xml与res目录除了assets目录以为的文件进行编译,生成resource.arsc和若干二进制的xml文件。
资源ID和资源文件的对应关系都是在resource.arsc中的。这些文件都会被打包到res.apk中。
五、将.dex打包到apk
直接使用apkbuilder的实现类,该类是sdk/tools/lib/sdklib.jar文件中的
com.android.sdklib.build.ApkBuilderMain
如果没有出错,会在out目录下得到app.apk,解压后可以看到classes文件以及被打进去了。
到此,已经得到了未签名的apk,剩下的就是apk签名了。
六、签名apk
apk用安装必须要签名,我们使用jarsigner给apk手动签名
APK文件结构和安装过程
APK文件结构
Android应用是用Java编写的,利用Android SDK编译代码,并且把所有的数据和资源文件打包成一个APK (Android Package)文件,这是一个后缀名为.apk的压缩文件,APK文件中包含了一个Android应用程序的所有内容,是Android平台用于安装应用程序的文件。APK就是一个zip压缩包,解开这个APK包我们可以看到以下的结构:

image

  1. assets目录:用于存放需要打包到APK中的静态文件,和res的不同点在于,assets目录支持任意深度的子目录,用户可以根据自己的需求任意部署文件夹架构,而且res目录下的文件会在.R文件中生成对应的资源ID,assets不会自动生成对应的ID,访问的时候需要AssetManager类。
  2. lib目录:这里存放应用程序依赖的native库文件,一般是用C/C++编写,这里的lib库可能包含4中不同类型,根据CPU型号的不同,大体可以分为ARM,ARM-v7a,MIPS,X86,分别对应着ARM架构,ARM-V7架构,MIPS架构和X86架构,这些so库在APK包中的构成如下图Figure2:

image

其中,不同的CPU架构对应着不同的目录,每个目录中可以放很多对应版本的so库,且这个目录的结构固定,用户只能按照这个目录存放自己的so库。目前市场上使用的移动终端大多是基于ARM或者ARM-V7a架构的,X86和MIPS架构的移动智能终端比较少,所以有些应用程序lib目录下只包含armeabi目录或者armeabi-v7a目录,也就是说,这四个目录要根据CPU的架构来选,而市面上ARM架构的手机占大多数,所以一般的APK只包含ARM和ARM-V7a的so。

  1. res目录:res是resource的缩写,这个目录存放资源文件,存在这个文件夹下的所有文件都会映射到Android工程的.R文件中,生成对应的ID,访问的时候直接使用资源ID即R.id.filename,res文件夹下可以包含多个文件夹,其中anim存放动画文件;drawable目录存放图像资源;layout目录存放布局文件;values目录存放一些特征值,colors.xml存放color颜色值,dimens.xml定义尺寸值,string.xml定义字符串的值,styles.xml定义样式对象;xml文件夹存放任意xml文件,在运行时可以通过Resources.getXML()读取;raw是可以直接复制到设备中的任意文件,他们无需编译。
  2. META-INF目录:保存应用的签名信息,签名信息可以验证APK文件的完整性。AndroidSDK在打包APK时会计算APK包中所有文件的完整性,并且把这些完整性保存到META-INF文件夹下,应用程序在安装的时候首先会根据META-INF文件夹校验APK的完整性,这样就可以保证APK中的每一个文件都不能被篡改。以此来确保APK应用程序不被恶意修改或者病毒感染,有利于确保Android应用的完整性和系统的安全性。META-INF目录下包含的文件有CERT.RSA,CERT.DSA,CERT.SF和MANIFEST.MF,其中CERT.RSA是开发者利用私钥对APK进行签名的签名文件,CERT.SF,MANIFEST.MF记录了文件中文件的SHA-1哈希值。
  3. AndroidManifest.xml:是Android应用程序的配置文件,是一个用来描述Android应用“整体资讯”的设定文件,简单来说,相当于Android应用向Android系统“自我介绍”的配置文件,Android系统可以根据这个“自我介绍”完整地了解APK应用程序的资讯,每个Android应用程序都必须包含一个AndroidManifest.xml文件,且它的名字是固定的,不能修改。我们在开发Android应用程序的时候,一般都把代码中的每一个Activity,Service,Provider和Receiver在AndroidManifest.xml中注册,只有这样系统才能启动对应的组件,另外这个文件还包含一些权限声明以及使用的SDK版本信息等等。程序打包时,会把AndroidManifest.xml进行简单的编译,便于Android系统识别,编译之后的格式是AXML格式,如下图Figure3所示:
  4. classes.dex:

传统的Java程序,首先先把Java文件编译成class文件,字节码都保存在了class文件中,Java虚拟机可以通过解释执行这些class文件。而Dalvik虚拟机是在Java虚拟机进行了优化,执行的是Dalvik字节码,而这些Dalvik字节码是由Java字节码转换而来,一般情况下,Android应用在打包时通过AndroidSDK中的dx工具将Java字节码转换为Dalvik字节码。dx工具可以对多个class文件进行合并,重组,优化,可以达到减小体积,缩短运行时间的目的

  1. resources.arsc:用来记录资源文件和资源ID之间的映射关系,用来根据资源ID寻找资源。Android的开发是分模块的,res目录专门用来存放资源文件,当在代码中需要调用资源文件时,只需要调用findviewbyId()就可以得到资源文件,每当在res文件夹下放一个文件,aapt就会自动生成对应的ID保存在.R文件,我们调用这个ID就可以,但是只有这个ID还不够,.R文件只是保证编译程序不报错,实际上在程序运行时,系统要根据ID去寻找对应的资源路径,而resources.arsc文件就是用来记录这些ID和资源文件位置对应关系的文件。

APK安装过程
首先,复制APK安装包到/data/app下,然后校验APK的签名是否正确,检查APK的结构是否正常,进而解压并且校验APK中的dex文件,确定dex文件没有被损坏后,再把dex优化成odex,使得应用程序启动时间加快,同时在/data/data目录下建立于APK包名相同的文件夹,如果APK中有lib库,系统会判断这些so库的名字,查看是否以lib开头,是否以.so结尾,再根据CPU的架构解压对应的so库到/data/data/packagename/lib下。
APK安装的时候会把DEX文件解压并且优化为odex
odex在原来的dex文件头添加了一些数据,在文件尾部添加了程序运行时需要的依赖库和辅助数据,使得程序运行速度更快。

你可能感兴趣的:(android工程编译过程)