Eclipse项目迁移到Android Studio记录

前言

这个标题就说明了这篇文章是一个踩坑之旅，相当蛋疼的一周。虽说这一周也不是只做这一件事，全力做的话，差不多两天这样子。我只想说一句话：珍爱生命，远离Eclipse，前提是还是作为一个Android开发者的角度，Eclipse不管从哪方面来说，都是一个优秀的IDE，但是仅就对Android来说，我们拥有更好的选择， 那就是Android Studio。

填坑之旅

其实我已经不知道如何开始讲起了，碰到的坑太多了，我也不能说全部回忆起来，只能说，按照我当时的做法进行回忆记录吧。

大家都知道Eclipse有个export功能，其中有这么一个选项：

这么导出的话会得到一个gradle构建的project，但是我个人是不推荐这么做的，因为看似直接导入这么一个project会大大缩短移植的时间，但是就我的经验来说，这么引入之后，只会带来更多的问题与坑，所以我所推荐的做法是先新建一个Android Studio Project：

随便说一下，关于文件树，最好是选择project这个选项，这也是最直观，最详细的。
在建立好一个新的project之后，就可以根据文件夹的对应关系。开始将Eclipse之中的文件一一对应对Android Studio的项目之中了，当然AS在这期间，无数的错误会报出来，但是没有关系，在全部的文件都导入完毕之后再说。

在导入完毕之后，我首先遇到的问题就是R文件的问题，原因在于我新建AS的project的时候，目录结构和原来的Eclipse工程不一样造成的，后面必须一一更正。所以，这里要提醒一点，如果想要简化操作，代码全部移植过来就可以使用，最好在创建包名时，同原Eclipse工程保持一致。

再接下来，对于从Eclipse上移植过来的工程，十有八九会 报关于XX.9.png这样的错误。报错的原因在于AS对于图片的检查要比Eclipse严格许多，所以不标准的.9.png图是不能逃过AS的法眼的，既然是因为严格的原因造成的，那么我们可以自定义让AS不那么严格，在build.gradle中配置如下：

aaptOptions{
cruncherEnabled = false
useNewCruncher = false
}

配置完成之后，对于大部分这方面的问题，我认为应该是能够解决了，但是就我个人而言，这么做还是不够，还是会报错，这时候，只能采取最直接的办法：使用AS自带的.9.png处理工具将不标准的图重新绘制一次，至于哪些图不标准，AS会提示我们的，这个不用担心。还比较好的是，虽然工程中有这么多的图片资源，实际上需要改的就那么几张，我并没有花费太多的精力在这上面。可是若是你的project需要修改的量有点大，那还是最好找美工进行确认，重新切图比较好。

上一步完成之后，继续重新build，如果你的项目和我一样，有不同的依赖库依赖了相同的Jar包，那么AS在这里会提示关于包重复，冲突的问题，这个问题我也烦恼了好久。这个问题主要就是gradle本身的机制规定不能重复造成，也不是就是这么做有错，就是如果想要使用gradle构建，那么就必须遵守它的规定罢了。解决的方法有两种：

• 使用AS 提供的包
  以support.v4包为例，先将重复依赖v4包的module中的v4.jar删除：

  

将此包删除之后，必然又是报错，但是没有关系，我们先不理会，在将重复依赖的v4包都删除之后，进行如下的操作：

选择Project Structure之后，切换到Dependencies中，选择’+’号，导入AS自带的v4包即可。对于其余重复依赖的module，也都采取此种办法来进行依赖。

这里多说一句，以上的所有操作都是可以在build.gradle中使用代码进行构建的，完全没有问题，我也是一般会采用代码来构建。这里AS提供了相应的图形化的配置，更加直观。这里没有哪种方式更好的分别，开发者自己选择适合自己的方式就可以了。

• 自定义Library module依赖
  我个人是比较推荐这一种方式的，因为比较灵活，适用于多种情况。
  同样以v4包为例进行说明。在删除了module中重复的v4.jar之中，按如下操作：

点击选择新建module，然后新建一个module，类型为Android Library。接下来的按照提示操作即可。正如我之前所说的那样，这一步同样可以在build.gradle进行配置。只需输入以下代码：

apply plugin: 'com.android.library'

然后将v4.jar导入到这个module的libs目录下即可。
最后，打开Project Structure之后，切换到Dependencies，选择’+’号，选择导入module依赖，选择我们导入v4.jar包的module即可。

在进行了如上的操作之后，包依赖重复的问题英应该就能够得到解决了。

jar，module依赖完成之后，肯定就轮到了.so动态链接库的依赖的，在现在版本的AS之中，这是一个非常简单的步骤，如下：

在如下所示的固定的目录层级下，将.so文件直接拷入就可以了。这里顺带说一句，AS中的aidl文件是单独存放的，和主代码文件夹java平级。同时，你也可以自定义你的.so的目录：

sourceSets {
main {
jniLibs.srcDirs = ['libs']
}
}

这样就可以自定义你的.so目录了，但是实际上不是很推荐自己去自定义.so的目录文件夹，一般来说，直接在AS规定的文件夹下导入即可。

按照常理来说，都这一步应该没有问题了，但是就我遇到的问题，即使这样也没有解决.so的注入问题，后来我发现是我在armeabi/armeabi-v7a包下的处理有问题导致的。同时还有一点需要提示，如果以上均不能解决你的.so问题的话，要大胆进行尝试，将.so文件夹导入libs包下，有时候你可能会发现惊喜。

到这里的话，基本来说，构建就已经基本完成了，剩下的就是编译相关的问题。对于编译相关问题，感觉问题就比较独特了，对于不同的人，不同的项目，AS虽然可能报同样的错误，但是实际上的错误可能有着大大的区别。

比如，遇到编译莫名其妙的问题，你可以尝试在build,gradle中添加如下语句:


dexOptions{
javaMaxHeapSize"4g"
}

增加可使用的内存可解决一些莫名其妙的问题。

再举个例子，如果你的项目是大型项目，那么极有可能你的方法数超过了65k的限制，那么现在这个问题的解决在AS中的解决也显得如此简单：

defaultConfig {

        multiDexEnabled true

    }

编译中出现的错误可以说是最恶心人的，没有一种非常通用的解决方法，所以需要具体分析，这里我推荐大家在编译的时候都加上 –debug选项进行编译，然后就可以在gradle 控制台看到打印的编译日志了，我们的工作就是在这些编译日志中，找到各种错误的蛛丝马迹，这是一个枯燥的过程却也是解决问题最直接可行的解决方式。

添加debug选项，有两种方式

• gradlew 命令行

• 在AS中使用图形化全局配置

同样地，选择自己喜欢的方式即可。

最后，忘了说 关于proguard混淆的事情。对于Eclipse移植过来的项目，一般来说，proguard配置文件是直接可以使用的，但是或多或少会出现一些错误，但是都不是什么大问题的，观察编译日志一般都可以比较轻松的解决。还有一个点需要注意的，若是你的build.gradle已经声明依赖了jar包了，那么就不要在proguard中再次进行声明了。

以上就是我能回忆到的一些东西，我感觉我遇到的坑应该远不止以上的问题，但是主要问题就是以上这些问题吧，具体问题需要具体分析，对于编译错误一定要仔细查看编译日志，这样做是非常好的解决问题的方式。