原 Unity发布错误的可能性问题整理
发表于2018-05-12
一、
做开发的同学相信都碰到这样的情况，Unity在编辑器模式下运行的时候都是好用的，但是一发布就出问题，造成这种原因有很多种，但是要找到最正确的哪一个却不是那么容易，为此，下面就将Unity发布错误的可能性问题在这里全部都整理了出来，希望可以帮到大家。
发布错误的可能性问题如下：
1.某些方法只能在编辑器模式下运行，因为它原本就是给编辑器来调试用的。
2.某些方法只能在固定的平台上运行，下面有具体讲解的一个例子
3.你程序的某些选项、某些值或者直接说你写的程序代码就有问题，就好比有一个类型你选了个EditorOnly，那就肯定之时EditorOnly了。
下面就针对的这些问题给出相应的解决方案。
1、最常见的编辑器运行没问题，但是发布出来就有问题的是屏幕自适应的问题，很容易出现位置偏差和大小问题。
解决办法：锚点的设置、图片规格也可以适当调，其实主要就是调啦。
2、.0.0版本C#的线程池在编辑器里运行没问题，在IOS、安卓也都可以，但是发布webgl之后，直接就会爆出线程错误。
解决办法：用协程。（发布webgl是html5，使用多线程初始化就崩了，可能跟unity自身有关）
3、编辑器里运行没问题，发布到安卓或者IOS平台后光影消失或者产生锯齿。
原因：a、跟硬件的渲染有关系，电脑的硬件渲染和手机的硬件渲染不同，底层相同的程序硬件的支持程度不一样，所以就会导致产生不同的效果。
b、本身的shader就有问题。
解决办法：重新做支持度差不多的光影以及修改调试shader。
4、编辑器内运行，贴图没问题，但是导出后出现闪烁的情况。
原因：模型有好几个面，角度稍微不同可能会导致几个面的切换。另外，htc vive的闪烁也有可能是这样。还有就是模型制作的时候重面、UV分的有问题、贴图中带透明通道信息或者是质量选择不对都可能造成这种错误。
5、发布安卓平台时出问题，可能还有如下的原因：
a、打包安卓的时候SD卡的权限没读。
b、C#Api版本没选好
c、代码优化的问题，需要的内存大于安卓剩余内存，内存溢出导致闪退
d、发布的时候各选项的勾选问题。
其实渲染里的问题居多，原因还是那个硬件的不同导致的，更换shader之类的就可以解决，但是过程是很费时的，要慢慢来。
二、
下面是查了一下Debug和Release的本质区别与调试和发布时出错的调试办法，在unity中可能用不上，但也放出来吧：
Debug和Release
作为程序员看到这两个词应该是很平常的事情吧，但是有多少程序员能够确切地清楚这两个之间的本质区别呢？
无独有偶，网上随便一搜，就会找到区别，不管懂不懂，先列出来：
Debug通常称为调试版本，它包含调试信息，并且不做任何优化，以便于程序员调试程序。
Release称为发布版本，它往往是进行了各种优化，使得程序在代码大小和运行速度上都是最优的，以便用户很好地使用。
Debug和Release的真正秘密，在于一组编译选项。下面列出了分别针对二者的选项。
Debug版本：
| /MDd /MLd 或/MTd | 使用Debug runtime library（调试版本的运行时刻函数库） |
| /Od | 关闭优化开关 |
| /D “_DEBUG” | 相当于 #define _DEBUG，打开编译调试代码开关（主要针对assert函数） |
| /ZI | 创建Edit and continue（编辑继续）数据库，这样在调试过程中如果修改了源代码不需要重新编译 |
| /GZ | 可以帮助捕获内存错误 |
| /Gm | 打开最小化重链接开关，减少链接时间 |
Release版本：
| /MD /ML 或 /MT | 使用发布版本的运行时刻函数库 |
| /O1 或 /O2 | 优化开关，使程序最小或最快 |
| /D “NDEBUG” | 关闭条件编译调试代码开关（即不编译assert函数） |
| /GF | 合并重复的字符串，并将字符串常量放到只读内存，防止被修改 |
Debug和Release没有本质的界限，他们只是一组编译选项的集合，编译器只是按照预定的选项行动。我们甚至可以修改这些选项，从而得到优化过的调试版本或者是带跟踪语句的发布版本。
其中每一项的具体解释就不多作评述了，其实我也不清楚，网上一查就有了。最近看到社区好多问题都是编辑模式下运行好好的，发布之后就挂了，所以这就需要我们来调试Release版程序，这样调试过了就和发布的基本上是一样的了。
怎么“调试”Release版的程序？
遇到Debug成功但Release失败，显然是一件很沮丧的事情，而且往往无从下手。那该用怎么样的策略来解决呢？我从网上搜集了以下几种：
1.修改Release版的编译选项来缩小错误范围。可以把Release的选项诸葛改为与之相对应的Debug选项，如/MD改为/MDd、/O1改为/Od，或运行时间优化改为程序大小优化。一次修改一个选项，看看修改哪个选项的时候错误消失，再对应针对性查找。主意：这些选项在Project\Settings中都可以直接通过列表选取，通常不要手动修改。这是最有效的方法。
2.在编程过程中就要时长注意测试Release 版本，以免最后代码太多，时间又很紧迫。
3.在Debug版中使用/W4警告级别，这样可以从编辑器获得最大限度的错误信息，比如 if(i = 0) 就会引起/W4警告。不要忽略这些警告，通常这时你程序中的Bug引起的。但有时/W4会带来很多冗余信息，如未使用的函数参数警告，而很多消息处理函数都会忽略某些参数。我们可以用
＃progma warning(disable:4702)//禁止
//…
#progma warning(default:4702)//重新允许来暂时禁止某歌警告，或使用
#progma warning(push,3)//设置警告级别为/W3
//…
#progma warning(pop)//重设为/W4来暂时改变警告级别，有时你可以只在认为可疑的那部分代码使用/W4。
4.你也可以像Debug一样调试你的Release版，只要加入调试符号。在Project/Settings...中，选Settings for “win32 Release”，选中C/C++标签，Category选General，Debug Info选Program Database。再再Link标签Project options最后加上“/OPT:REF”(引号不要输)。这样调试器就能使用pdb文件中的调试符号。但调试时，你会发现断点很难设置，变量也很难找到－－这些都被优化过了。不过令人庆幸的是，Call Stack窗口仍然工作正常，即使帧指针被优化，栈信息（特别是返回地址）仍然能找到。这对定位错误很有帮助。
来自：https://blog.csdn.net/yushengqi12345/article/details/77570238