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

存的合理使用，对象池，资源加载卸载管理等。

作为一款3D游戏，我们也一直在寻找游戏表现和性能的最佳平衡点。一个基本的取舍原则可能就是性价比，看性能的损耗带来的效果提升到底大不大，是不是用户比较关注的。另外在这点上程序和美术之间也经常会出现一些意见分歧，这很正常。对于程序同学来说希望客户端特别省，轻巧而快速。对于美术同学来说希望画面足够精细，能够最大程度的保留设计初衷可能是非常重要的。这个问题目前看来我们处理的还是比较好的，站在客户端程序的角度，一方面有些原则我们必须要坚持，比方说不能使用复杂的实时动态光影，后处理效果等确实与当前大多数移动设备硬件性能不相匹配的技术，另一方面我们也应该和美术同学一起为游戏的表现品质努力，比方说我们实现了一个效果自适应模块，能够根据用户的设备性能选择合适的效果等级，既能让配置较差的设备以比较流畅的帧率运行游戏，高端机型也能够表现出更精细的纹理，更真实的光照，更多的场景细节，更华丽的特效等等，避免了画面品质一刀切的情况，给了美术同学多一些的发挥空间。当然总的来讲，我们的资源规范还是比较严苛的，不得不赞叹我们的美术oa，在如此多的限制下，依然让我们的游戏有很不错的画面品质。

车库

高配画面

低配画面

端游经验用于反外挂，安全问题早作预案

相比端游而言手游面临的网络环境更严峻，我们不可能做到实时通过服务器校验玩家的每一步操作，从延迟，稳定性，流量上讲都不允许。单局的玩法逻辑大都是在客户端完成在结算时才统一上报服务器的，玩家就有可能修改一些关键数据，比方说分数，金币，Buf持续时间等等，从而获得非法收益，这就必然牵扯到令人头疼的反外挂问题。

基于以前端游的积累我们初期就预想到了这个情况，比较早地开始了对抗准备。我们的外挂对抗体系大体分为三层，第一层是客户端的防御，除了必不可少的协议加密之外，客户端对内存中的关键数据也都是密文存储的并且加上了校验码，这样通过烧饼之类的通用内存修改工具就比较难定位数据的具体位置了，而且就算真的找到了内存地址，修改之后也会导致校验失败，这样客户端就能侦测到内存数据的非法篡改。第二层是我们自己服务器的即时对抗，客户端在单局结算时上报的数据中不光有最终的结果还有一些和结果有关联的中间数据，比方说实际生成了多少金币，是否有出现某种特殊车等等，如果外挂只是修改了部份数据，服务器就可以根据校验公式检测出数据被非法篡改过了，服务端kenny以前在QQ飞车 (微博)就做过类似的对抗，经验非常丰富。最后一层是互娱安全组的后校验，他们采用的检测方法和我们服务器的类似，只是不会对作弊行为进行实时处罚。

还有一个要特别注意的是，在Android平台上，Unity的C#脚本是以JIT方式运行的，apk包里的程序集dll文件很容易被Reflector等工具反编译，一旦被别有用心的人知道了客户端逻辑到底如何运作的，就可能做出一些比较逆天的外挂来。当时我们想了很多办法，一开始是做混淆，但发现执行起来不是很方便，对开发存在一定的限制。后来我们想到一个方法，我们可以对程序集dll文件进行加密，这样通用的反编译工具就打不开了，但苦于我们没有Unity及其修改过的mono组件的源代码， 也不擅长逆向工程，我们把这个需求提给Unity的开发商，可能出于某些原因，他们也没有太积极的反馈，后来还是安全组给了我们支持，他们通过逆向工程实现了对程序集文件的加解密，之后公司开发/代理的Unity手游应该都有采用这个加密方案。

崩溃上报灵活处理是解决之道

针对移动应用，MIG研发了一套叫做RQD的崩溃上报系统，MSDK对它作了统一接入，所以凡是接入了MSDK组件的移动端游戏在客户端发生崩溃时都会自动捕捉上报异常的现场信息，对分析崩溃来说最有用的可能就莫过于调用栈了。

RQD虽然很强大，不光支持C/C++，ObjC这些原生语言的调用栈的还原，也支持Java的调用栈还原，但可惜的是Unity开发的游戏大多的异常其实发生在C#层，iOS平台还好，C#是以AOT方式预先编译成了原生代码，调用栈会被当作C语言的对待，从函数名上也能基本定位到C#中具体发生崩溃的地方。但Android平台就没这么幸运了，C#是被预先