Unity打android包时出现64K limitation

Android本身对于method和field的数量都有64k的限制，所以如果你的Unity工程很大的话，出现这个问题是正常的。不过我居然在一个小工程上遇到了这个问题，而这一切都是Unity的bug作祟。。。

---

首先工程的情况是这样的：
Unity版本 5.3.4
工程不大
android工程里引用了一堆android support和google play之类的Library Project

如果你的Unity工程和上面情况类似，并且打包的时候遇到了method或者field超过64k的问题，那可能你也遇到了这个bug。这个bug就是Unity在打包的时候每个工程下的R.java文件会错误的引用所有工程的资源文件，从而导致R.java中的field和method数量爆炸。。

对android有点了解的人都知道，android编译的时候会生成一个R.java，其中存有一堆final static的变量，存放着android的res目录下的各种资源id，包括layout，string，drawable等等。正常情况下，每个R.java都应该只引用本工程下的资源文件。但是在使用Unity打包的时候，会出现我上面说的那个问题。

举个栗子：
你的工程叫A，有两个引用D1和D2，A，D1，D2中各有10个资源，正常用android打包的话，只占30个field，但是Unity打包的话会出现30*3=90个field。。。而我引用了20多个包，20多个包总共有近三千个资源，随随便便就七万多了。而这个bug又十分隐蔽，从Eclipse或者AS上看不出任何迹象，所以一直没找到点子上，最后居然是把apk反编译才发现的。。。

那么如何解决呢，参考这里的讨论，最后是把不包含资源文件的Library Project中的manifest的PackageName给写成了主工程的PackageName，这样就不会在这个包下生成R文件，从而减少field和method的数量。注意是不包含资源文件的Library Project中的manifest，如果把包含资源文件的工程里的包名改了的话，运行时会找不到[PackageName].R文件而崩溃。

当然如果你把Unity升到5.5以上，似乎利用gradle也是可以解决的，具体可以参考我上面发的链接。

OK，android打包的问题真是不少，不过这个问题最坑爹，记下来供大家参考一下。