1.Android Studio安装
下载地址：https://developer.android.google.cn/studio/
android studio安装完后要在安装jdk（1.8）和sdk版本（24）
2.目录分析
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 代码混淆配置文件
4.gradle
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文件一些内容
13.buildType
构建类型，在Android Gradle工程中，它已经帮我们内置了debug和release两个构建类型，两种模式主要车别在于，能否在设备上调试以及签名不一样，其他代码和文件资源都是一样的。一般用在代码混淆，而指定的混淆文件在下图的目录上，minifyEnabled=true就会开启混淆,shrinkResources=true 缩小APK大小，删除没有引用的资源文件（drawable和layout）
14.signingConfigs
签名配置，一个app只有在签名之后才能被发布、安装、使用，签名是保护app的方式，标记该app的唯一性。如果app被恶意删改，签名就不一样了，无法升级安装，一定程度保护了我们的app。而signingConfigs就很方便为我们提供这个签名的配置。storeFile签名文件，storePassword签名证书文件的密码，storeType签名证书类型，keyAlias签名证书中秘钥别名，keyPassword签名证书中改密钥的密码。
默认情况下，debug模式的签名已经被配置好了，使用的就是Android SDK自动生成的debug证书，它一般位于$HOME/.android/debug.keystore,其key和密码是已经知道的，一般情况下我们不需要单独配置debug模式的签名信息。
15.productFlavors
Gradle的多渠道打包，你可以在不同的包定义不同的变量，实现自己的定制化版本的需求。
buildConfigField是BuildConfig文件的一个函数，而BuildConfig这个类是Android Gradle构建脚本在编译后生成的
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)工具生成的。
二、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包我们可以看到以下的结构：
assets目录：用于存放需要打包到APK中的静态文件，和res的不同点在于，assets目录支持任意深度的子目录，用户可以根据自己的需求任意部署文件夹架构，而且res目录下的文件会在.R文件中生成对应的资源ID，assets不会自动生成对应的ID，访问的时候需要AssetManager类。lib目录：这里存放应用程序依赖的native库文件，一般是用C/C++编写，这里的lib库可能包含4中不同类型，根据CPU型号的不同，大体可以分为ARM，ARM-v7a，MIPS，X86，分别对应着ARM架构，ARM-V7架构，MIPS架构和X86架构，这些so库在APK包中的构成如下图Figure2：
其中，不同的CPU架构对应着不同的目录，每个目录中可以放很多对应版本的so库，且这个目录的结构固定，用户只能按照这个目录存放自己的so库。目前市场上使用的移动终端大多是基于ARM或者ARM-V7a架构的，X86和MIPS架构的移动智能终端比较少，所以有些应用程序lib目录下只包含armeabi目录或者armeabi-v7a目录，也就是说，这四个目录要根据CPU的架构来选，而市面上ARM架构的手机占大多数，所以一般的APK只包含ARM和ARM-V7a的so。
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是可以直接复制到设备中的任意文件，他们无需编译。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哈希值。AndroidManifest.xml：是Android应用程序的配置文件，是一个用来描述Android应用“整体资讯”的设定文件，简单来说，相当于Android应用向Android系统“自我介绍”的配置文件，Android系统可以根据这个“自我介绍”完整地了解APK应用程序的资讯，每个Android应用程序都必须包含一个AndroidManifest.xml文件，且它的名字是固定的，不能修改。我们在开发Android应用程序的时候，一般都把代码中的每一个Activity，Service，Provider和Receiver在AndroidManifest.xml中注册，只有这样系统才能启动对应的组件，另外这个文件还包含一些权限声明以及使用的SDK版本信息等等。程序打包时，会把AndroidManifest.xml进行简单的编译，便于Android系统识别，编译之后的格式是AXML格式，如下图Figure3所示：classes.dex：
传统的Java程序，首先先把Java文件编译成class文件，字节码都保存在了class文件中，Java虚拟机可以通过解释执行这些class文件。而Dalvik虚拟机是在Java虚拟机进行了优化，执行的是Dalvik字节码，而这些Dalvik字节码是由Java字节码转换而来，一般情况下，Android应用在打包时通过AndroidSDK中的dx工具将Java字节码转换为Dalvik字节码。dx工具可以对多个class文件进行合并，重组，优化，可以达到减小体积，缩短运行时间的目的
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文件头添加了一些数据，在文件尾部添加了程序运行时需要的依赖库和辅助数据，使得程序运行速度更快。
