【轉(zhuǎn)載請注明出處】
作者：DrkCore (http://blog.csdn.net/DrkCore)
原文鏈接：(http://blog.csdn.net/drkcore/article/details/52079371)

近日因為工作的原因筆者開始接觸Unity3D游戲引擎，該引擎的一大特色就是支持多種平臺，其中自然不能少了我們Android。在Unity3D和Android Studio交互中其實有不少坑，不過踩坑向來是學(xué)習(xí)的一部分，在這里筆者和大家分享一下今天的踩坑經(jīng)驗。

一、 將項目作為lib導(dǎo)入Unity打包

Eclipse的時代說到打包那必然指的是JAR包，其缺點是res資源文件不好處理，而隨著Android Studio一同到來的AAR包解決了這個問題。

將源碼和資源文件一同打包等到實際編譯的時候再解壓，這些事情Build Tool都幫我們做了，這也是為什么Android Studio中我們只需一句話就能搞定依賴管理。在Unity3D工程中我們同樣能夠通過AAR來導(dǎo)入Android部分的邏輯。

基本的導(dǎo)出姿勢以及與Unity3D之間的交互可以參照這位博主的博客：
Android Studio 2.1 和 Unity3D 5.3.4 交互
Android Studio 2.1 和 Unity3D 5.3.4 交互（二）

博文介紹了如何導(dǎo)出AAR，但是在你真正將自己的項目移植的時候你仍然會遇到不少問題。如果你將自己的AAR包用壓縮軟件打開時就會發(fā)現(xiàn)Build Tool似乎將你整個Module都打包進(jìn)去，唯獨沒有打包的就是你的依賴！

比如你在Android中使用了ToolBar，RecyclerView等由support-v7提供的控件，或者類似xUtils3的第三方框架等，這些東西都是不會被打包進(jìn)你的AAR中。我們必須手動將這些依賴的AAR一同添加到Unity3D工程。

大部分的第三方庫都會提供AAR包文件，實在沒有也可以從GitHub上clone下來自己打包。Google官方提供的support庫等都可以在SDK目錄下的extras子目錄中找到，比如support-v7的AAR在如下位置可以找到：

看到這里你以為就能順利完成往Unity3D導(dǎo)入Android的工作嗎？

Naive，這里還有兩個坑你沒跳呢！

如果你的SDK中存在版本為24的Build Tool的話會爆出錯誤：

具體原因可能是Build Tool的Bug。要解決的話很簡單，就是把24的Build Tool藏起來：

到這里你應(yīng)該能夠順利地將Unity3D工程順利打包成APK。

這個時候如果你還覺得包的版本越高越好就會遇到第二個坑，這個坑在24號版本的support-v7包中。

報錯截圖如下：

compile ‘com.android.support:appcompat-v7:24.x.x’只是一句依賴但是其導(dǎo)入的包并不只有一個，如果你打開module的build\intermediates\exploded-aar目錄去看的話就會發(fā)現(xiàn)其實他有4個包。報錯中提到的VectorDrawableCompat就在其中：

然而這個時候就算你導(dǎo)入了這兩個包問題依舊存在。

筆者猜測24的VectorDrawable包必須使用24的Build Tool來打包，而上面我們說過了24的Build Tool和Unity3D不太兼容。

解決方案很簡單，就是使用23的support包。

筆者測試過使用23的support無需導(dǎo)入VerctorDrawable可以正常運(yùn)行。

1、 使用Gradle腳本簡化導(dǎo)包操作

踩過以上的這些坑之后想必大家都已經(jīng)掌握了新姿勢，但如果你像筆者一樣是個懶惰的程序員的話就會覺得，每次編譯都手動復(fù)制來復(fù)制去好麻煩啊，而通過Gradle的腳本我們可以分分鐘解決這個問題。

以下是筆者寫的腳本，當(dāng)成偽代碼來看的話相信有點經(jīng)驗的開發(fā)者都能看懂：

// 刪除舊的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'
}

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

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

//添加任務(wù)依賴
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導(dǎo)入Android Studio

如果你實際將工程作為libs導(dǎo)出的Unity3D導(dǎo)出的話你會發(fā)現(xiàn)這種方法帶有太多的限制了：

• 項目所在的Module必須為設(shè)為library
  如果你的項目使用了比如xUtils中的基于注解和反射實現(xiàn)的視圖注入框架的話，你就會發(fā)現(xiàn)將module設(shè)置為library后框架的視圖注入功能就無法使用了，甚至連switch(view.getId())這樣的代碼都用不了。究其原因無論是注解還是switch語句其需要參數(shù)都必須是常量，而library的R.id.xxx要在打包成apk的時候才能確定，于是開發(fā)者就不得不寫繁瑣的findViewById了。

• 不方便管理依賴庫
  如果項目依賴了某些庫那么在打包的時候要一并將這些庫的jar/aar一并導(dǎo)入到Unity目錄之中，升級依賴或者添加依賴全部都要手動進(jìn)行。人為操作難免會出問題而Unity打包的速度也是慢的可以，每一次打包都像是在拷問著程序員一般。

如果反過來想，不是將工程導(dǎo)出而是將Unity作為lib導(dǎo)入到Android Studio的話這一切都將迎刃而解。

打開Unity的IDE，通過File->Build Settings打開打包設(shè)置

選中Google Android Project并且簽名（不簽名無法導(dǎo)出工程，身為Android開發(fā)者我表示不解?。?，導(dǎo)出后我們就會看到Eclipse項目結(jié)構(gòu)的工程，如下：

assets存放的是編譯后的Unity腳本等東西，這部分是導(dǎo)出部分的核心，日后如果要更新Unity的lib的話，只覆蓋assets下的東西就夠了。其他的部分相信大家都十分熟悉了，不再贅述。

我們將導(dǎo)出的東西作為library導(dǎo)入到Android Studio，build之后我們就能在module的輸出目錄下找到對應(yīng)的AAR文件了：

之后我們就可以直接使用AAR文件進(jìn)行開發(fā)了，是不是很方便。

1、 更新Unity的AAR

隨著項目的不斷研發(fā)Unity的部分總是需要更新的，如果導(dǎo)出一個AAR要重復(fù)上述的步驟的話那依然是很麻煩的。好在我們可以繞過Android Studio直接更新AAR文件。

如前文所說Unity導(dǎo)出工程的核心都在Assets目錄下，而我們用壓縮軟件打開對應(yīng)的AAR文件就會發(fā)現(xiàn)Assets下的內(nèi)容只是被原封不動地打包進(jìn)去了而已，所以我們完全可以用新導(dǎo)出的Unity工程中的Assets來替換AAR包下的東西。