Android：AS与Unity3D之间打包的各种坑及解决方案

小飞苑 2017-02-22

展开全文

【转载请注明出处】
作者：DrkCore (http://blog.csdn.net/DrkCore)
原文链接：(http://blog.csdn.net/drkcore/article/details/52079371)

一将项目作为lib导入Unity打包
- 1 使用Gradle脚本简化导包操作
二将Unity作为lib导入Android Studio
- 1 更新Unity的AAR

近日因为工作的原因笔者开始接触Unity3D游戏引擎，该引擎的一大特色就是支持多种平台，其中自然不能少了我们Android。在Unity3D和Android Studio交互中其实有不少坑，不过踩坑向来是学习的一部分，在这里笔者和大家分享一下今天的踩坑经验。

一、将项目作为lib导入Unity打包

Eclipse的时代说到打包那必然指的是JAR包，其缺点是res资源文件不好处理，而随着Android Studio一同到来的AAR包解决了这个问题。

将源码和资源文件一同打包等到实际编译的时候再解压，这些事情Build Tool都帮我们做了，这也是为什么Android Studio中我们只需一句话就能搞定依赖管理。在Unity3D工程中我们同样能够通过AAR来导入Android部分的逻辑。

基本的导出姿势以及与Unity3D之间的交互可以参照这位博主的博客：
Android Studio 2.1 和 Unity3D 5.3.4 交互
 Android Studio 2.1 和 Unity3D 5.3.4 交互（二）

博文介绍了如何导出AAR，但是在你真正将自己的项目移植的时候你仍然会遇到不少问题。如果你将自己的AAR包用压缩软件打开时就会发现Build Tool似乎将你整个Module都打包进去，唯独没有打包的就是你的依赖！

比如你在Android中使用了ToolBar，RecyclerView等由support-v7提供的控件，或者类似xUtils3的第三方框架等，这些东西都是不会被打包进你的AAR中。我们必须手动将这些依赖的AAR一同添加到Unity3D工程。

大部分的第三方库都会提供AAR包文件，实在没有也可以从GitHub上clone下来自己打包。Google官方提供的support库等都可以在SDK目录下的extras子目录中找到，比如support-v7的AAR在如下位置可以找到：

v7包

看到这里你以为就能顺利完成往Unity3D导入Android的工作吗？

Naive，这里还有两个坑你没跳呢！

如果你的SDK中存在版本为24的Build Tool的话会爆出错误：

Build-tools为24时的报错截图

具体原因可能是Build Tool的Bug。要解决的话很简单，就是把24的Build Tool藏起来：

躲猫猫

到这里你应该能够顺利地将Unity3D工程顺利打包成APK。

这个时候如果你还觉得包的版本越高越好就会遇到第二个坑，这个坑在24号版本的support-v7包中。

报错截图如下：

报错截图

compile ‘com.android.support:appcompat-v7:24.x.x’只是一句依赖但是其导入的包并不只有一个，如果你打开module的build\intermediates\exploded-aar目录去看的话就会发现其实他有4个包。报错中提到的VectorDrawableCompat就在其中：

然而这个时候就算你导入了这两个包问题依旧存在。

笔者猜测24的VectorDrawable包必须使用24的Build Tool来打包，而上面我们说过了24的Build Tool和Unity3D不太兼容。

解决方案很简单，就是使用23的support包。

笔者测试过使用23的support无需导入VerctorDrawable可以正常运行。

1、使用Gradle脚本简化导包操作

踩过以上的这些坑之后想必大家都已经掌握了新姿势，但如果你像笔者一样是个懒惰的程序员的话就会觉得，每次编译都手动复制来复制去好麻烦啊，而通过Gradle的脚本我们可以分分钟解决这个问题。

以下是笔者写的脚本，当成伪代码来看的话相信有点经验的开发者都能看懂：

// 删除旧的aar
task deleteOldAar(type: Delete) {
    //删除Unity工程下的Android资源
    delete '你的Unity3D工程/Assets/Plugins/Android/lib-release.aar'
    //由于AndroidManifest文件可以能有更新，一并删除
    delete '你的Unity3D工程/Assets/Plugins/Android/AndroidManifest.xml'
    //删除Android工程下的编译资源
    delete 'build/intermediates/bundles/release/'
    delete 'build/outputs/aar/lib-release.aar'
}

// 导出AndroidManifest.xml
task exportManifest(type: Copy) {
    from('src/main/')
    into('你的Unity3D工程/Assets/Plugins/Android/')
    include('AndroidManifest.xml')
}

//导出aar
task exportAar(type: Copy) {
    from('build/outputs/aar/')
    into('你的Unity3D工程/Assets/Plugins/Android/')
    include('lib-release.aar')
}

//添加任务依赖
exportAar.dependsOn(deleteOldAar, build, exportManifest)1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

二、将Unity作为lib导入Android Studio

如果你实际将工程作为libs导出的Unity3D导出的话你会发现这种方法带有太多的限制了：

项目所在的Module必须为设为library
如果你的项目使用了比如xUtils中的基于注解和反射实现的视图注入框架的话，你就会发现将module设置为library后框架的视图注入功能就无法使用了，甚至连switch(view.getId())这样的代码都用不了。究其原因无论是注解还是switch语句其需要参数都必须是常量，而library的R.id.xxx要在打包成apk的时候才能确定，于是开发者就不得不写繁琐的findViewById了。
不方便管理依赖库
如果项目依赖了某些库那么在打包的时候要一并将这些库的jar/aar一并导入到Unity目录之中，升级依赖或者添加依赖全部都要手动进行。人为操作难免会出问题而Unity打包的速度也是慢的可以，每一次打包都像是在拷问着程序员一般。

如果反过来想，不是将工程导出而是将Unity作为lib导入到Android Studio的话这一切都将迎刃而解。

打开Unity的IDE，通过File->Build Settings打开打包设置