下载地址：https://developer.android.google.cn/studio/
android安装完后要在安装jdk（1.8）和sdk版本（24）
目录分析：
1、.gradle gradle编译系统，版本由wrapper决定
.idea AndroidStudio IDE所需要的文件 IntelliJ IDEA 同样有这个文件
这两个目录下文件都是Android Studio 自动生成的一些文件，我们无需关心，也不要手动去编辑
2、app项目的代码、资源等内容几乎都是放在这个目录下，我们后期的开发也基本都是在这个目录下进行
3、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系统使用的
项目名.iml iml文件是所有IntelliJIDEA项目自动生成的文件，我们不需要关心或者修改这个文件的内容
9、local.projecties 本地属性设置（key设置，android.sdk 位置等属性），这个文件是不推荐上传到VCS中去的
10、settings.gradle 这个文件用于指定项目中所有引入的模块。
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
Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化建构工具。它使用一种基于Groovy的特定领域语言(DSL)来声明项目设置，抛弃了基于XML的各种繁琐配置。
面向Java应用为主。当前其支持的语言限于Java、Groovy和Scala，计划未来将支持更多的语言
下面进入主题在as中主要是配置gradle和android gradle插件，注意了gradle和（android gradle插件）一定不能混为一谈，2者是有区别的。
其实原始的Gradle默认情况下并不包含Android功能。Google为Gradle提供了Android插件，允许用户很容易的配置android工程编译脚本。编译脚本(buildscript)在编译工程的根目录，构建文件(build.gradle)用来告知Gradle去哪里下载对应的插件。
从上面列出的代码中我们可以看到插件的默认下载是从jcenter中，意味着jcenter就是当前的目标库。虽然jcenter仓库是当前默认的，但是其它的仓库也是支持的，尤其是mavenCenteral()作为maven的远端默认仓库。JCenter仓库的所有内容通过一个CDN经由HTTPS连接传输，速度也是很快的。
上面代码中的allprojects部分表示当前的根目录工程和所属的子工程默认情况下都使用jcenter()远端仓库用来支持java库的依赖。
gradle-wrapper
Wrapper是对Gradle的一层包装，便于在团队开发过程中统一Gradle构建的版本号，这样大家都可以使用统一的Gradle版本进行构建。
上面我们看到的图就是Gradle提供内置的Wrapper task帮助我们自动生成Wrapper所需的目录文件。再看看我们Android项目里面自动生成的文件
这几个自动生成的文件原来是Gradle Wrapper创建出来的。
那下面我们看看gradle-wrapper.properties这个文件的作用
看到项目里面的各个属性，下面再看看每个属性的作用
我们其实最关心的应该是distributionUrl这个属性，他是下载Gradle的路径，它下载的东西会出现在以下的文件夹中
这个文件夹包含了各个版本你下载的Gradle。
导入项目的时候一直会停留在这个界面，这是为什么？其实原因很简单，就是你常用项目的Gradle版本跟你新导入项目的Gradle版本不一致造成的
1、网速好或者科学上网的时候，由它自己去下载，不过下载时间有长有短，不能保证。
2、当你在公司被限网速的时候，当然也是我最常用的，就是把你最近常用项目的gradle-wrapper.properties文件替换掉你要导入项目的该文件，基本上我是这样解决的，当然有时候也会遇到替换掉报错的情况，不过比较少。
settings.gradle
下面我们讲讲settings.gradle文件，它其实是用于初始化以及工程树的配置的，放在根工程目录下。
设置文件大多数的作用都是为了配置自工程。在Gradle众多工程是通过工程树表示的，相当于我们在Android Studio看到的Project和Module概念一样。根工程相当于Android Studio的Project，一个根工程可以有很多自工程，也就是很多Module，这样就和Android Studio定义的Module概念对应上了。
build.gradle（Project）
1.buildscript
buildscript中的声明是gradle脚本自身需要使用的资源。可以声明的资源包括依赖项、第三方插件、maven仓库地址等
2.repositories
顾名思义就是仓库的意思啦，而jcenter()、maven()和google()就是托管第三方插件的平台
3.dependencies
当然配置了仓库还不够，我们还需要在dependencies{}里面的配置里，把需要配置的依赖用classpath配置上，因为这个dependencies在buildscript{}里面，所以代表的是Gradle需要的插件。
allprojects
allprojects块的repositories用于多项目构建，为所有项目提供共同所需依赖包。而子项目可以配置自己的repositories以获取自己独需的依赖包。
buildscript和allprojects的作用和区别
buildscript中的声明是gradle脚本自身需要使用的资源，而allprojects声明的却是你所有module所需要使用的资源，就是说每个module都需要用同一个第三库的时候，你可以在allprojects里面声明
下面该说说build.gradle（Project）文件的最后一个一段代码了
运行gradle clean时，执行此处定义的task。该任务继承自Delete，删除根目录中的build目录。相当于执行Delete.delete(rootProject.buildDir)。其实这个任务的执行就是可以删除生成的Build文件的，跟Android Studio的clean是一个道理。
build.gradle（Module）
Android Gradle插件的分类其实是根据Android工程的属性分类的。在Andriod中有3类工程，一类是App应用工程，它可以生成一个可运行的apk应用：一类是Library库工程，它可以生成AAR包给其他的App工程公用，就和我们的Jar一样，但是它包含了Android的资源等信息，是一个特殊的Jar包；最后一类是Test测试工程，用于对App工程或者Library库工程进行单元测试。
App插件id：com.android.application.
Library插件id：com.android.library.
Test插件id：com.android.test.
一般一个项目只会设置一个App插件，而module一般是会设置为Library插件。
android{}
是Android插件提供的一个扩展类型，可以让我们自定义Android Gradle工程，是Android Gradle工程配置的唯一入口。
compileSdkVersion
是编译所依赖的Android SDK的版本，这里是API Level。
buildToolsVersion
是构建该Android工程所用构建工具的版本。
defaultConfig{}
defaultConfig是默认的配置，它是一个ProductFlavor。ProductFlavor允许我们根据不同的情况同时生成多个不同的apk包。
applicationId
配置我们的包名，包名是app的唯一标识，其实他跟AndroidManifest里面的package是可以不同的，他们之间并没有直接的关系。
package指的是代码目录下路径；applicationId指的是app对外发布的唯一标识，会在签名、申请第三方库、发布时候用到。
minSdkVersion
是支持的Android系统的api level，这里是15，也就是说低于Android 15版本的机型不能使用这个app。
targetSdkVersion
表明我们是基于哪个Android版本开发的，这里是22。
versionName
表明我们的app应用的版本名称，一般是发布的时候写在app上告诉用户的，这样当你修复了一个bug并更新了版本，别人却发现说怎么你这个bug还在，你这时候就可以自信的告诉他自己看下app的版本号。（亲身经历在撕逼的时候可以从容的应对）
multiDexEnabled
用于配置该BuildType是否启用自动拆分多个Dex的功能。一般用程序中代码太多，超过了65535个方法的时候。
ndk{}
多平台编译，生成有so包的时候使用，包括四个平台'armeabi', 'x86', 'armeabi-v7a', 'mips'。一般使用第三方提供的SDK的时候，可能会附带so库。
buildType
构建类型，在Android Gradle工程中，它已经帮我们内置了debug和release两个构建类型，两种模式主要车别在于，能否在设备上调试以及签名不一样，其他代码和文件资源都是一样的。一般用在代码混淆，而指定的混淆文件在下图的目录上，minifyEnabled=true就会开启混淆：
signingConfigs
签名配置，一个app只有在签名之后才能被发布、安装、使用，签名是保护app的方式，标记该app的唯一性。如果app被恶意删改，签名就不一样了，无法升级安装，一定程度保护了我们的app。而signingConfigs就很方便为我们提供这个签名的配置。storeFile签名文件，storePassword签名证书文件的密码，storeType签名证书类型，keyAlias签名证书中秘钥别名，keyPassword签名证书中改密钥的密码。
默认情况下，debug模式的签名已经被配置好了，使用的就是Android SDK自动生成的debug证书，它一般位于$HOME/.android/debug.keystore,其key和密码是已经知道的，一般情况下我们不需要单独配置debug模式的签名信息。
productFlavors
在我看来他就是Gradle的多渠道打包，你可以在不同的包定义不同的变量，实现自己的定制化版本的需求。
manifestPlaceholders
占位符，我们可以通过它动态配置AndroidManifest文件一些内容
buildConfigField
他是BuildConfig文件的一个函数，而BuildConfig这个类是Android Gradle构建脚本在编译后生成的。而buildConfigField就是其中的自定义函数变量，看下图我们分别定义了三个常量：
我们可以在BuildConfig文件中看到我们声明的三个变量
然后我们就可以在代码中用这些变量控制不同版本的代码：
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中依赖implementation、api的区别：
其实api跟以前的compile没什么区别，将compile全部改成api是不会错的；
而implementation指令依赖是不会传递的，也就是说当前引用的第三方库仅限于本module内使用，其他module需要重新添加依赖才能用，下面用两个图说明：
debug 和release 包的区别
榕树项目区别就是混淆问题
1.对于混淆~ 简单理解为一种加密的方式,一般使用导入的三方包配置好后,它可以将代码中的java字节按照一定规则重新规划,这样即使被反编译也无法看懂混淆后的东西
2.混淆还有缩减apk大小的作用,因为它会将不影响程序运行的代码删减掉,一些变量名,函数名,类名进行简化处理,可以减少apk大小的25%~50%
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文件头添加了一些数据，在文件尾部添加了程序运行时需要的依赖库和辅助数据，使得程序运行速度更快。