腾讯游戏分享汇：天天飞车六大研发经验(3)

编译为IL中间代码，以JIT模式在mono虚拟机中运行的，所以一旦C#层出现异常，RQD报上来的调用栈反映的都是虚拟机自身发生了异常，无法定位异常发生的具体位置，然而Android崩溃率大大高于iOS，是需要更多关注的。

后来通过猜测和试验，我们发现其实在C#层产生异常时，Unity可以通过回调的方式把异常类型和调用栈告知应用，这正是我们需要的，但如何把这些信息上报又成了问题，因为一旦RQD捕捉到异常就会立即kill掉应用，可能应用都没有机会处理这些信息，我们把情况反馈给了RQD的研发组，但短时间内他们也很难有比较完善而系统的解决方案。后来通过和RQD开发同事不断的探讨终于找到了一种看起来简陋但却行之有效的方案：由他们提供一个发生异常时延迟kill掉进程的定制版本，在异常发生时我们把需要额外上报的异常信息以追加的方式写入会上报的tomb文件。采用这种方法，我们所需的C#异常信息在Android平台也能有效地通过RQD上报了，而且能在后台页面比较方便的查看。

安装包容量缩减方案分享，多种方法协力显功效

天天飞车属于最早那一两批上线的微信/手Q游戏，为了尽量降低玩家进入的门槛，当时对安装包体积的要求还是蛮严格的，至少要控制到40M以下，而当时我们的安装包体积已经突破50M了。

第一步，我们还是检查梳理了一遍资源，看看有没有资源没按照规范来制作，有没有资源是冗余的，这应该是最基本的，这项工作的一部份可以通过自动化的工具来完成，利用Unity提供的编辑器扩展接口来实现还是很方便的。

我们分析过安装包的具体构成，其实还是贴图资源占比最大，所以很自然地应用了TinyPNG之类的减色工具来减少贴图的信息量，实际结果表明这个优化对决大多数贴图表现的影响都是可以接受的，仅有少量的UI贴图需要区别对待一下。

渲染中文字符所使用的矢量字体文件ttf的体积对于手游安装包来说实在是有点大，一个最基本的优化手段就是使用精简字库，但精简过渡又会导致很多字符无法正常渲染，所以最后依然会占用5M左右的空间，当时的一个想法就是可否直接把移动设备操作系统的字体文件拿来用，感谢iOS这个封闭的系统，字库很统一，这个方案确实是可行的，游戏首次运行时通过系统API直接从系统字库提取出字形信息组装成了ttf文件，但Android系统就不行了，各种系统版本字库五花八门，只能还是老实地把精简字体文件打进安装包。

还有一个大头是在音频上，在PC端上游戏音频一般直接采用mp3/ogg等流行的压缩格式就可以了，但终端设备尤其是安卓设备很多不具备音频的硬件解码能力，CPU运算能力又相对较弱，在做性能分析的时候发现，一些中低端设备，甚至某些比较高端的设备，在音频解压这一块都有相当大的性能消耗。为了流畅的帧率我们最初不得不采用非压缩的wav格式。但问题很明显，非压缩格式的音频文件体积太大了，因为信息量特别大，打进安装包里也缩减不了太多。后来我们采取了一个两全其美的方案，安装包里依然存放压缩格式的音频，游戏第一运行时，把音频解压成非压缩格式来播放，这块当时节省了8M多空间。

经过这些努力，我们的首发安装包体积成功的控制在了30M的水平，但需要注意的是苹果会对可执行文件加密，这会导致AppStore中的版本会比提交审核的原始包大一些．手游与省电似乎天生存在矛盾，小技巧暗藏客观效果与普通的App相比，手游耗电确实要厉害得多，大家也都比较关注这一块，影响手机耗电的因素很多，CPU的占用率，GPU的运算量，屏幕的亮度，网络模式和通讯量等等，都会影响到电量消耗的快慢，然而手机网游是这些硬件资源的消耗大户，而且消耗的更多往往就能给用户带来更绚丽的表现，更流畅的操作体验。

一方面，我们要做好游戏的性能优化，这是最基础的，因为这样就能以更少的硬件资源消耗带来基本相同的游戏体验，另一方面，我们也可以采取一些小策略，小技巧来达到相对省电的效果，比方说我们将游戏刷新率最高限制在了30帧，因为这对于天天飞车这种类型的3D游戏的流畅体验来说基本足够了，又比如在大厅里面挂机或者暂停游戏的时候， 其实不需要保持比较高的刷新率，这时候就完全可以把帧率降下来，自然而然就获得了省电的效果。当然这只是两个很小的例子，具体游戏可以根据自身情况仔细挖掘，