unity安卓内存分析

---

一、诡异，Unity在安卓运行崩溃问题，求助在整个开发和测试阶段，发生了很多意想不到的事情，比如解析超过1M大小的json文件、高清图片导致OOM、莫名其妙的崩溃等等，这些意外都影响了开发计划，增加了压力。最直接的表现就是晚上和周末加班。编写和修改代码远比你想象的更难控制。用户体验增加了代码细节和逻辑处理的难度，而android莫名其妙的崩溃增加了解决bug的难度。针对这一发展，总结了一些经验。测试者经常报告小米1手机在运行壁纸软件时会崩溃。崩溃日志为：eException:RegisterInputChannel(NativeMethod)erInputChannel()w()w()w()$Show()$TN$()Callback()chMessage()()根据日志推测崩溃与Toast有关。但问题很奇怪。我只在代码中调用st(...).show()。为什么会导致这次崩溃？然后根据测试人员的反馈，当壁纸设置成功后，就会导致这个崩溃的情况，并且测试人员在频繁操作的情况下反映了这个问题。根据这一现象，推测可能是由以下两个原因造成的。首先，设置壁纸会导致桌面发生变化，桌面变化时弹出toast会导致崩溃；其次，频繁、不间断的弹出吐司也会导致这个问题。后来，测试人员报告了一个新现象。当在新浪微博上分享失败时（前提是新浪微博账号有问题），浏览壁纸图片也会导致崩溃，只有出现这种现象。一次就再也不会了。该错误最终作为遗留问题得到解决。这种问题在以后版本的开发中肯定会出现。我们怎样才能避免类似情况再次发生呢？我从几个方面总结了我的努力。首先借一部小米1手机把玩，了解手机爱好者的习惯和测试者的思维，然后体验小米1手机，对小米1有更深入的了解；与小米交流，不认识小米有什么牛逼的朋友进行开发，可以先在小米论坛上做一个活跃用户，积极与对方和网友交流；了解inputchannel的功能和机制是什么，并研究anroid2.3的原生代码。刚进入测试阶段时，测试人员每天都会报告壁纸软件频繁崩溃。对于一些简单的崩溃问题，通常是由空指针引起并重复发生的，我们在这里不讨论它们。测试报告显示，浏览壁纸图片、保存壁纸、预览壁纸、设置壁纸时经常出现崩溃的情况。这种崩溃没有规律重现，但经常发生。这个问题的原因是OOM。例如在MX2手机上，用于桌面预览的位图大小1280存在等）会导致内存占用飙升至50M以上。当超过64M左右时，软件会报OOM错误。OOM没有完整的解决方案。网上有很多避免OOM的方法，比如延迟加载图片、及时回收内存、弱引用等。另外，在生成bitmap的地方应该使用try来解决这些crash问题，以后还会有新的崩溃的原因。测试人员表示，当他吃完午饭回来时，壁纸软件在打开时突然崩溃了。经过分析这个现象，发现原因是Android在手机长时间闲置时杀死了壁纸软件进程。但有一个问题出现了。进程被终止并单击应用程序的图标后，进程将重新打开并重新运行。怎么会崩溃呢？经过分析，我发现一个奇怪的事情是，Android待机后，壁纸进程被杀死了，但是软件的Activity并没有从任务中删除，所以当再次点击应用程序的图标时，顶部的任务将被执行。onCreate，但是onCreate中有些东西还没有初始化，会因为空指针而崩溃。后来，测试人员报告了一个奇怪的错误。安装后首次打开软件时，未显示欢迎界面图片。不过以后每次打开软件时，都能显示欢迎界面的图片。图片是raw格式的jpg文件。最后发现原因是decodebitmap和scalebitmap时，其中一个要操作的变量imagewidth第一次为0，没有赋值。后来就不为0了，被赋值了。但为什么会出现这种情况呢？我终于找到原因了。imagewidth是一个全局静态变量，它会在另一个线程中被赋值（分配给屏幕的宽度）。由于线程异步问题，第一个图像宽度为0。后来每次打开软件，都不是重启进程，而是重启activity，分配给imagewidth的值还在。

---

二、unity批量释放资源卡顿Unity批量释放资源因为设备内存有限而挂起。加载和释放游戏资源导致的内存泄漏问题一直是Unity游戏开发中的黑洞。主要原因是，一方面，游戏设备，尤其是Unity擅长的移动设备，运行内存非常有限。另一方面，如果释放有些不足，那将是一个巨大的负担，一方面是由于Unity不明确的加载和释放策略以及神秘的GC（垃圾收集）机制，这给Unity带来了“垃圾收集”的美誉。引入了“内存杀手”和“低效引擎”。不过，如果你能清楚地了解Unity的资源负载和共享机制，你就可以根据自己的情况一步步管理存储。使用时，Unity游戏可以完全摆脱内存泄漏陷阱。