近日因为工作的原因笔者开始接触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在如下位置可以找到:
看到这里你以为就能顺利完成往Unity3D导入Android的工作吗?
Naive,这里还有两个坑你没跳呢!
如果你的SDK中存在版本为24的Build Tool的话会爆出错误:
具体原因可能是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的脚本我们可以分分钟解决这个问题。
以下是笔者写的脚本,当成伪代码来看的话相信有点经验的开发者都能看懂:
- 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打开打包设置
选中Google Android Project并且签名(不签名无法导出工程,身为Android开发者我表示不解啊),导出后我们就会看到Eclipse项目结构的工程,如下:
assets存放的是编译后的Unity脚本等东西,这部分是导出部分的核心,日后如果要更新Unity的lib的话,只覆盖assets下的东西就够了。其他的部分相信大家都十分熟悉了,不再赘述。
我们将导出的东西作为library导入到Android Studio,build之后我们就能在module的输出目录下找到对应的AAR文件了:
之后我们就可以直接使用AAR文件进行开发了,是不是很方便。
1、 更新Unity的AAR
随着项目的不断研发Unity的部分总是需要更新的,如果导出一个AAR要重复上述的步骤的话那依然是很麻烦的。好在我们可以绕过Android Studio直接更新AAR文件。
如前文所说Unity导出工程的核心都在Assets目录下,而我们用压缩软件打开对应的AAR文件就会发现Assets下的内容只是被原封不动地打包进去了而已,所以我们完全可以用新导出的Unity工程中的Assets来替换AAR包下的东西。
三、 可能出现的其他问题
如果你出现了各种打包的异常,可以依次按照如下的点来检查:
-
是否选择了签名文件,并输入了正确的密码
-
如果你是使用Eclipse打包的话,检查存在多个unity提供的classes.jar
-
检查插件目录中及aar包中是否重复申明了组件
Android打包apk时会将多个lib的 AndroidManifest.xml 文件合并到一起,如果重复声明了组件并且声明的属性存在冲突就可能导致打包失败。 -
检查bin目录及aar包中是否存在重复的jar文件
常见于项目开发中改变了项目名,并且每次打包都是直接解压到插件目录的情况,因为名称不同所以不会覆盖旧的jar包。 -
检查资源是否存在重复的索引
比如同时存在
bg_main.png
和bg_main.9.png
两个图片但二者的索引都是R.drawable.bg_main
。
作者:DrkCore (http://blog.csdn.net/DrkCore)
原文链接:(http://blog.csdn.net/drkcore/article/details/52079371)