Android Studio（以下均简称为AS）是Google在2013年5月16日的I/0大会上推出的Android开发环境。
从最初的AS 1.5（我是从这个版本开始使用） 到现在的AS 2.1，这款开发工具有了很大的进步，而且更新频率也是非常高。相较于Eclipse+ADT的开发环境；在某些方面，对开发者来说的确是方便了许多。
我待AS如初恋，AS虐我千百遍
但是，这样一个开发环境，毕竟还很“年轻”，所以自身也会存在很多或大或小的bug,加上我们对它不是很熟悉（尤其是Gradle语法），给我们日常开发带来了很多坑爹的问题，在此做个记录，方便以后遇到时可以快速找到解决方法，同时分享给遇到同样问题的同学一些解决思路。
操作环境：Windows10 + Android Studio 2.1
这里只列举解决方有共性的问题，有时候会遇到一种AS重启（或者电脑重启）之后就没有问题的问题，这里不再列出。重启大法，真是时时刻刻都有用啊。
Gradle sync/building/refreshing 很长时间##
相信大部分人和我一样，第一次使用AS的体验并不是很好，一方面它很占内存，导致自己电脑特别卡，尤其是在构建过程中，另一方面，对Gradle构建方式及其语法的陌生，导致初次用AS创建工程费了很大劲，所以对他并不是很看好。
我们选择的AS的原因无非就是几乎所有的人都开始用了，你在Github或者是一些论坛上找到的源码，几乎都是AS版本的。而且有些很棒的三方库，在AS上引入也许就是一行代码的事情，可是在Eclipse上几乎是无法实现的，即便实现也得费很大的功夫。
有时候，我们从github上clone了一份大神的源码，想去解读一下，结果导入AS后就一直在哪里building，也许等待很长一段时间后，可以building完成，但是我们完全可以省下这部分时间。
AS长时间的building，一般来说是去下载gradle文件，也许你会说，我电脑文件里有gradle啊，就在下面这个目录。
C:\Users\username\.gradle\wrapper\dists
的确，如果我们用AS正常的构建并编译运行过一个工程的话，那么这个文件夹下至少会有一个gradle-xx-all或gradle-xx-bin的文件夹，这个文件下的内容其实就是AS用来构建工程所用到的东西。
所以，当我们clone到一份AS版本的源码时，不应该急着打开，而是应该先去预览一下两个文件：
build.gradle（这个是整个项目的gradle文件）####
这个文件里有一行很重要的配置代码：
dependencies {
classpath 'com.android.tools.build:gradle:2.1.2'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
这个指定了我们整个项目要构建所需的Android Plugin版本。
这个地方我的经验是，如果你clone到的源码里所使用到的版本比这里低，建议改成当前最新的版本。当然，如果你使用AS2.0及以上版本，它会自动提示你将Plugin版本升级为最新的。
gradle-wrapper.properties####
这个文件，位于你所创建项目
XXApplication\gradle\wrapper
这个目录下，我们可以看一下这个文件
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-2.10-all.zip
最重要的就是最后一行配置，他决定了你整个项目构建时所需要用到的gradle文件的版本，到这里你应该明白了，当我们使用AS打开clone到的源码时，他会按照这里的配置gradle-2.10-all.zip，去之前所说的
C:\Users\username\.gradle\wrapper\dists
这个目录下寻找gradle文件，如果刚好找到了，那么很幸运，你的项目不会build很长时间。如果没有找到，那么就得去下载gradle-wrapper.properties里所配置的gradle版本了，这就解释了我们第一次用AS创建Hello Wrold时为什么等待了那么长时间，因为要去下载一个文件（而且得是翻墙）。
明白这些，这个问题就很好解决了。第一种办法，很简单，提前从这里下载gradle-wrapper.properties里所指定的gradle版本文件，解压后放在\dists\目录下；这也是一种比较乖的方法，因为大神总是走在我们之前，他们当时写下这些源码时候，所使用的gradle文件版本可能比较老，所以为了保持源码不被更改，只能这样做了。
第二种，比较讨巧，你可以修改gradle-wrapper.properties的配置内容，将最后一行gradle版本修改为.gradle\wrapper\dists这个目录下包含的版本，或者是你可以打开你手头正常运行的项目文件，看看它的这个gradle-wrapper.properties是如何配置的，可做参考。
对于gradle-wrapper.properties里所用到的gradle文件和build.gradle中所依赖的gradle版本是否有严格的对于关系，尚不明确。
关于Instant Run的使用##
Instant Run 是AS 2.0之后提供的一种一边修改代码，一边在模拟器或者实际设备上看到 修改代码后的结果的高大上功能。
说白了，就是Activity可以不用重新启动，而你代码修改的内容就可以直接呈现出来，就是最近很火的热更新。关于他的运行原理，可以看看这篇文章，已经做了很详细的解释。
其实，对于这个功能来说真是又爱又恨。爱是因为，这种Instant Run的确是可以节省一点时间，毕竟AS 编译运行速度还是有点长，即便你的电脑是8G内存，i5处理器也是枉然。而恨，也恰恰是因为这种所谓的Instant Run，在刚开始使用AS 2.0的那段时间，常常有这样一种体验，代码明明改了为什么不生效，TextView的颜色明明代码里已经改成了绿色，为什么一运行还是黑色。甚至，有时候导致我们开始怀疑自己代码的逻辑性，所以在很长一段时间里都不能适应这个所谓的Instant Run，觉得完全就是添乱的。
但是，用的时间久了，当你渐渐熟悉了他的规律，理解了他的原理，你还是会觉得这个功能挺好的。
你可以通过设置，开启或者关闭这个功能
布局文件无法预览Exception raised during rendering##
有时候，我们会遇到layout下xml 布局文件无法查看的情况，而出现的提示也是很简单，就是一句话Exception raised during rendering。
这种AS无法渲染出视图，而且xml代码没有错误，无论怎样修改，就是绘制不出布局文件的视图。
这个一般是由于选择的Android SDK 版本不稳定所导致的问题 ，切换成低版本即可。
Element layer-list must be declared问题##
这个问题的解决方法源自网络
项目从Eclipse转到Android Studio。项目中使用了环信demo中的一些xml资源，转换后发现color资源文件夹下诸如layer-list或者shape等标签报Element xxx must be declared错误，大意就是layer-list或者shape这些标签没有定义。
layer-list或者shape等这些标签是常用的标签，Android Studio居然报没有定义错误，在Eclipse中却没有这个问题。网上不少人说这是Android Studio的一个bug，事实正相反，这是Android Studio的优点。
对于这个问题，首先要了解layer-list、shape等这些标签是什么东西。每一种标签都有对应的资源类，layer-list、shape等等标签代表的其实是个drawable资源。layer-list最终会解析为LayerDrawable，shape会解析为ShapeDrawable，其它的标签类似。由此可以看出layer-list或者shape等资源是drawable资源，应该放到drawable资源文件夹下。color资源不包括drawable资源，当然没有定义drawable类型的标签。
Eclipse不像Android Studio，对资源类型的检查没有那么严格，所以没有报错误。我觉得这倒是Android Studio的优点，是什么资源就应该放到什么位置，不容易让人产生疑惑。
所以在Android Studio下的解决方法就是把这些资源文件移动到drawable资源文件夹下
Duplicate file copy in apk##
出现这个问题，一般是由于引用了重复的jar包，而且会在报错日志中提示两个重复类的路径。这种情况在引用了外部工程（在Android Studio中就是新建了Module），或者是导入的第三方（如友盟）的SDK时很容易出现，因为外部引用的工程，一般是Github 上大神们写的一些库，方便我们使用。不同的外部工程中，使用了相同的jar包，这个情况时很有肯能发生的，列如support-v4的jar包，这个jar包几乎成了应用的标配，这个时候我们只需删掉其中的一个工程中的jar包即可。
Error:failed to find Build Tools revision xx.x.x##
我们从网络上clone一份源码，Sync时会提示这种问题。这个问题，其实很简单就是app的
build.gradle 所声明的编译项目的SDK 版本我们没有通过SDK Manager 下载，这个时候，你当然可以按照他给出的提示
Install Build Tools xx.x. and sync project 安装所需的SDK版本，进行下载安装，但这样一般都会耗时，所以最简单的方法就是修改app的build.gradle 中的buildToolsVersion 的内容，改成我们已经安装过的SDK版本，如果不知道怎么写具体的版本号，完全可以参考电脑里可以正常运行项目的这个配置信息。
或者是如图所示，在Project Structure 菜单中选择可用的SDK.
2016年7月27日更新
SSL peer shut down incorrectly##
这个问题的原因也很简单，和之前提到的第一种情况是一样的，就是下载gradle.xxx.zip文件失败了，这个时候，如果条件允许的话，就直接翻墙下载，如果条件不允许，可以考虑之前的办法，从这里手动下载gradle-wrapper.properties里所指定的gradle版本文件，解压后放在\dists\目录下，或者是直接修改gradle-wrapper.properties的内容。
