记一次eclipse到android studio 的项目迁移记录

记一次eclipse到android studio 的项目迁移记录

因为从2016年开始谷歌，就放弃支持ADT插件，转向支持androidStudio，这也意味着我们要把项目开发从eclipse转向as。
之前就用过as，但是都是在工作室的小型项目，公司的项目，依赖库比较复杂，eclipse下作为库工程做依赖，是比较简单的，但是在as上是有点难度的，这也是我写这篇文章的目的，花了两天多的时间，碰到了各种问题，异常，可以将这些问题记录下来，方便大家看。

1.如何将eclipse的工程兼容到as中去：

先给大家一篇教程，将eclipse工程移植到as中去的教程 ，这里采取的是兼容模式，其实这里问题应该不大，我主要分析下为什么这样做as就可以导入eclipse的工程。
原因有以下几点：

1. 生成了gradle配置文件：build.gradle 文件（根目录下的)以及gradle文件夹，为什么要将这两个变化列成一点呢？我们先看两个文件的内容首先是build.gradle文件,然后是gradle文件夹下的gradle-wrapper.properties文件的内容
   我们可以看到，这两个文件有些属性，那就是配置androidStudio的gradle工具的配置：build.gradle文件里面classpath指的是as的gradle插件的版本号，gradle-wrapper.properties 指的是gradle的工具的版本号。这两个是文件其实就是指定了as建立项目的gradle基础配置（大家知道as都是基于gradle脚本进行配置的）

2. 我们再一次看每个项目中的改变都是些什么？这里我们要导出的项目的工程图：其中，i-medical是主工程，libray，pullToRefresh,cordrva,plib,appcompat_v7都是库工程，我们先看库工程的变化：其实，到库工程，就是多了一个gradle文件，说白了，其实就是构建的脚本变化了，这也很明确，as的构建工具都是gradle，那么自然会使用gradle文件构建。 主工程呢？同样也是多了一个gralde文件，不过内部需要添加对gradle的依赖而已。

   综上所述，我们可以确定，从eclipse的android工程转入as，最大的特点就是增加了gradle脚本文件。

2.在as上配置依赖（依赖library指示器库）

好吧，当我们把eclipse的中的项目都构建成了as可以导入的项目包了，那么，我们可以开始逐渐配置依赖了，我们首先建立一个demo工程，as新建工程的默认的build.gradle是这样的:,这是所有的as的项目中都会出现的基本配置，OK，那么，我们现在导入哪个库呢？我们先导入library库吧，这个库主要是指示器（就是轮播空间的指示器），那么，我们import module，OK，然后呢，我们添加依赖，如图所示：,OK,现在我们编译下呢？

然后果然不通，什么异常呢？

    Android Studio：Multiple dex files define Landroid/support/annotation/AnimRes

好像说的是有重复的v4和v7包，为什么呢？分析了下原因：
因为library库中，libs文件夹下，是含有supportv4包的，而library中的build.gralde文件中，,我们的主工程已经配置了v7包的依赖，而库工程又有v4包的依赖，库工程的中的v4包很可能和主工程的版本不一致，导致的冲突。
oK,现在分析完成原因之后，怎么解决呢？提出以下几种方案：

1. 把库工程的v4包去掉 -> 显然不行，库工程会编译不过的
2. 将主工程的v7包去掉 -> 显然不行，主工程的万一有些style属性需要用到v7包呢？
3. 看来两者必须共存了，那么怎么办呢?
4. 将v4包和v7包的版本改成一样的 ->这是可行的，但是人家库工程的是依赖的v4包是jar包啊，这可怎么玩？
5. 去掉library中的关于v4包的引用，在gradle中动态添加依赖，如图所示：,这样编译后，就可以通过。binggo！！！！
6. 还有一种解决方案，就是动态在gradle文件中，去添加v4包的依赖，同时和主工程的的版本依赖一致。

这就是我在遇到的问题的时候思考方式，找到原因之后，逐渐提出解决方案，这里也有个链接，是关于这个异常如何解决的，大家可以参照： Android Studio：Multiple dex files define Landroid/support/annotation/AnimRes

3.在as上配置依赖（依赖appcompat_v7库）

接下来我们配置依赖库appcompat_v7，其实appcommpatv7库就是libs中的两个jar包，如图所示：,所以我们还是一来先配置依赖，让主工程依赖关系如下所示：,来，再让我们编译，哦，好像出现了另一个异常：

   Error:Execution failed for task ':app:processDebugResources'.
 com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command 'F:\Android studio\SDK\android-sdk_r23.0.5-windows\android-sdk-windows\build-tools\21.1.2\aapt.exe'' finished with non-zero exit value 1

好吧，引起这个异常的原因是什么呢？搜了下，stackoverflow上说是好像说项目中有重复的v4或者v7包的引入。看来解决这个问题不是那么难啊，我们直接让主工程中的v7包依赖转为依赖appcompatv7,让library也依赖appcompatv7,OK，这样应该可以了吧,因为确实已经消除了所有的v4和v7的冲突了，依赖关系v4，v7只有一个源头。
重新编译后，还是报错啊，仍然是这个异常，这里卡了我好久，按理说，已经没有v4或者v7的依赖冲突，为什么还会报错呢？后来我终于在无意中找到问题，问题的原因在这里：sdk build tools ：原来的sdk的buildtools如图所示：,这里使用的buildtools的版本号是21.1.2,我们尝试改成高的版本号试试：比如这样
我们再次编译一下呢？果然通过了！！！！不过为什么呢？我大致在网上查了，也根据自己的一些方法验证，大概是版本号在22.0.1以下的sdk build tools 都是自动含有v7包的，但是没有显式地指出依赖，因此，会导致主工程的和appcompat_v7之间产生v4/7的重复的依赖。所以，这里，我们将版本号改高就可以了解决这个问题了。

这里再补充下：v7包重复依赖之后，还会出现：这个异常：

Error while making module Android Studio: “showDividers” has already been defined

也是v7包冲突产生的。

4.在as上配置依赖（依赖plib库）

现在我们导入最难的plib库，plib库是公司内部的框架（leader和partner自己花了很多心血写的，既有网上很多开源库的封装，也有公司内部常用业务逻辑的封装），我们引入plib，发现plib下也有v4，v7的依赖，再次按照上面的做法，让plib中对appcompat_v7的依赖就可以。这里说下，只要保证全局有一个v4,v7的依赖就不会发生moudle依赖冲突。
OK，我们再次修改主工程的依赖关系,如下图所示:,现在我们再次编译，这里可能会出现一些eclipse上编译不严格的失误，但是as通不过的问题：比如资源文件中，color，string等重复定义，mainfast文件中出现了多余activity或者service。这些都是编译不严格的错误，修改下编译报错的问题的就好了。这里遇到的最大的问题是这个异常：
出现这个问题的原因，是因为主程序module清单文件中,application节点的android:icon属性引用了@mipmap/ic_launcher图片资源，而依赖module的清单文件中，同样的android:icon属性却引用了@drawable/ic_launcher这个图片资源
这里按照这篇博客解决就可以了：解决Android Studio添加依赖时出现“Manifest merger failed”

另外，如果还有类似与这样的异常出现，比如：

Error:Execution failed for task ':i-medical:processDebugManifest'.
> Manifest merger failed with multiple errors, see logs

可能是主题（theme）上的冲突，因此，也可以参照这个链接Android Studio 编译报错：Manifest merger failed with multiple errors, see logs

OK,解决了以上的问题，之后，我们终于完成了eclipse的库在android studio上的迁移。。。。

后续补充一些AS常见的错误：
1 . 关于AS的使用中，如果出现compileSdkVersion的版本号同 Android SDK platform tools 的版本号高，会在每个java文件中，对package 进行警告，但是不会影响构建，这时，需要升级SDK manager 中Android SDK platform tools 的版本号，或者在gradle配置文件中，下调compileSdkVersion 的版本号
2. 关于AS中gradle插件配置的问题：
一般来说，每个AS都会自带一个gradle插件的版本，在其安装目录上就有一个，如图所示：
然后在使用每个AS新建的project中，一般都在根目录下，都有一个build.gradle 文件，这个文件主要指明了AS 使用的插件的版本号以及依赖仓库的地址。我现在使用过三个版本的AS：1.0RC4，1.5，2.0Beta，其中每次构建gradle都是不一样的。其中：
1.0RC4 对应的是：classpath ‘com.android.tools.build:gradle:1.0.0RC4’
1.5 对应的是：classpath ‘com.android.tools.build:gradle:1.5’
2.0 beta版本对应的是 classpath ‘com.android.tools.build:gradle:2.0.0-beta2’

这些插件的配置，直接决定了用这个AS建立的project的gradle文件中的gradle-wrapper.properties指定的gradle插件的版本号
可以看出，每个不同的版本的AS，使用的gradle的插件的版本都是不一样的。那么，问题来了，如果有两个开发人员，使用的AS的版本号不同，那么，gradle插件的版本也不同，那不会出现构建的问题吗？
这就是要看android studio 的File的setting->gradle 中的是否选择了 default gradle wrapper 这个选项，如果是选择了这个选项，那么，这个选项表示默认project的中gradle文件中gradle-wrapper.properties 文件中设定的gradle插件版本号。
所以，如果发现没有对应的gradle的版本，就会从指定的中心库上去下载（建议使用翻墙来下载）这个下载好的文件，windows下，都是缓存在C:\Users.gradle 文件夹下。如图：。所以，这就是不同版本的AS的也可以兼容构建的原因。

3 . 建议AS选择稳定的正式版本，不要选择beta版本： 原因是这样的：最近我看到AS 2.0 的版本 蛮新的，就使用了下载了AS 2.0 beta2 版本的，开始构建的时候都没有问题，后来突然有一天，构建的时候，抛出异常：Error:(1, 0) Plugin is too old, please update to a more recent version, or set ANDROID_DAILY_OVERRIDE environment variable to “893d40cf6cad41657491cd35c3c4668f6b9bfd94” 。我开始解决这个问题，是将 classpath ‘com.android.tools.build:gradle:2.0.0-beta2’改成了classpath ‘com.android.tools.build:gradle:2.0.0-beta7‘ ,虽然构建能成功，但是编译仍然过不了，最好的办法是，下载一个新的AS 2.0 beta7 版本，才能彻底解决这个问题。所以嘛，最好就选择版本低一点的，1.5版本，等2.0正式版本发不了，我们再去使用，不然，每次官方一旦更新，就可能出现这个问题。

总结

这次项目的迁移，耗时两天多，之间碰上了各种问题，上面的文章中提到的问题，都是花了很多时间在stackoverflow，百度，谷歌上搜到的。经过这两天的锻炼，对我而言，收货很大，一个是对as的依赖配置更加熟悉，还有一个是锻炼我解决问题的思维
当你遇到一个问题的时候，不要着急，先去百度，谷歌上搜，先看看引起问题的原因，然后想想看如何解决，提出一些解决方案。然后依次尝试。在尝试解决的问题的过程中，一定要有耐心，坚信可以调试出来的，同时头脑也要清晰，有可能会有其他的问题，在解决的时候出现。问题解决后，一定要去看原因，和解决的原理，这样，对以后碰到诸如此类问题，才会有思路,并且记录下来
我想，一个优秀的程序员应该不断的适应这样的困境，并且不断地成长下去!