Unity3D手游开发实践《腾讯桌球》客户端开发经验总结

04月

740 0 0

　　GameRes游资网授权发布文 / 吴秦（Tyler）

　　本次分享总结，起源于腾讯桌球项目，但是不仅仅限于项目本身。虽然基于Unity3D，很多东西同样适用于Cocos。本文从以下10大点进行阐述：

　　1.架构设计

　　2.原生插件/平台交互

　　3.版本与补丁

　　4.用脚本，还是不用？这是一个问题

　　5.资源管理

　　6.性能优化

　　7.异常与Crash

　　8.适配与兼容

　　9.调试及开发工具

　　10.项目运营

　　1、架构设计

　　好的架构利用大规模项目的多人团队开发和代码管理，也利用查找错误和后期维护。

框架的选择：需要根据团队、项目来进行选择，没有最好的框架，只有最合适的框架。
框架的使用：统一的框架能规范大家的行为，互相之间可以比较平滑切换，可维护性大大提升。除此之外，还能代码解耦。例如StrangeIOC是一个超轻量级和高度可扩展的控制反转(IoC)框架，专门为C#和Unity编写。已知公司内部使用StrangeIOC框架的游戏有：腾讯桌球、欢乐麻将、植物大战僵尸Online。

　　依赖注入（Dependency Injection，简称DI），是一个重要的面向对象编程的法则来削减计算机程序的耦合问题。依赖注入还有一个名字叫做控制反转（Inversion of Control，英文缩写为IoC）。依赖注入是这样一个过程：由于某客户类只依赖于服务类的一个接口，而不依赖于具体服务类，所以客户类只定义一个注入点。在程序运行过程中，客户类不直接实例化具体服务类实例，而是客户类的运行上下文环境或专门组件负责实例化服务类，然后将其注入到客户类中，保证客户类的正常运行。即对象在被创建的时候，由一个运行上下文环境或专门组件将其所依赖的服务类对象的引用传递给它。也可以说，依赖被注入到对象中。所以，控制反转是，关于一个对象如何获取他所依赖的对象的引用，这个责任的反转。

　　StrangeIOC采用MVCS（数据模型?Model，展示视图?View，逻辑控制?Controller，服务Service）结构，通过消息/信号进行交互和通信。整个MVCS框架跟flash的robotlegs基本一致，（忽略语言不一样）详细的参考< target=_blank>http://www.cnblogs.com/skynet/archive/2012/03/21/2410042.html>。

数据模型 Model：主要负责数据的存储和基本数据处理
展示视图 View：主要负责UI界面展示和动画表现的处理
逻辑控制 Controller：主要负责业务逻辑处理，
服务Service：主要负责独立的网络收发请求等的一些功能。
消息/信号：通过消息/信号去解耦Model、View、Controller、Service这四种模块，他们之间通过消息/信号进行交互。
绑定器Binder：负责绑定消息处理、接口与实例对象、View与Mediator的对应关系。
MVCS Context：可以理解为MVC各个模块存在的上下文，负责MVC绑定和实例的创建工作。

腾讯桌球客户端项目框架

代码目录的组织：一般客户端用得比较多的MVC框架，怎么划分目录？
先按业务功能划分，再按照?MVC?来划分。蛋糕心语就是使用的这种方式。
先按MVC划分，再按照业务功能划分。D9、宝宝斗场、魔法花园、腾讯桌球、欢乐麻将使用的这种方式。

　　根据使用习惯，可以自行选择。个人推荐先按业务功能划分，再按照 MVC 来划分，使得模块更聚焦（高内聚），第二种方式用多了发现随着项目的运营模块增多，没有第一种那么好维护。

　　Unity项目目录的组织：结合Unity规定的一些特殊的用途的文件夹，我们建议Unity项目文件夹组织方式如下。

　　其中，Plugins支持Plugins/{Platform}这样的命名规范：

Plugins/x86
Plugins/x86_64
Plugins/Android
Plugins/iOS

　　如果存在Plugins/{Platform}，则加载Plugins/{Platform}目录下的文件，否则加载Plugins目录下的，也就是说，如果存在{Platform}目录，Plugins根目录下的DLL是不会加载的。

　　另外，资源组织采用分文件夹存储成品资源及原料资源的方式处理：防止无关资源参与打包，RawResource即原始资源，Resource即成品资源。当然并不限于RawResource这种形式，其他Unity规定的特殊文件夹都可以这样，例如Raw Standard Assets。

　　公司组件

msdk（sns、支付midas、推送灯塔、监控Bugly）
apollo
apollo voice
xlua

　　目前我们的腾讯桌球、四棋都接入了apollo，但是如果服务器不采用apollo框架，不建议客户端接apollo，而是直接接msdk减少二次封装信息的丢失和带来的错误，方便以后升级维护，并且减少导入无用的代码。

　　第三方插件选型

NGUI
DoTween
GIF
GAF
VectrosityScripts
PoolManager
Mad Level Manger

　　2、原生插件/平台交互

　　虽然大多时候使用Unity3D进行游戏开发时，只需要使用C#进行逻辑编写。但有时候不可避免的需要使用和编写原生插件，例如一些第三方插件只提供C/C++原生插件、复用已有的C/C++模块等。有一些功能是Unity3D实现不了，必须要调用Android/iOS原生接口，比如获取手机的硬件信息（UnityEngine.SystemInfo没有提供的部分）、调用系统的原生弹窗、手机震动等等

　　2.1C/C++插件

　　编写和使用原生插件的几个关键点：

　　创建C/C++原生插件

导出接口必须是C ABI-compatible函数
函数调用约定

　　在C#中标识C/C++的函数并调用

标识 DLL 中的函数。至少指定函数的名称和包含该函数的 DLL 的名称。
创建用于容纳 DLL 函数的类。可以使用现有类，为每一非托管函数创建单独的类，或者创建包含一组相关的非托管函数的一个类。
在托管代码中创建原型。使用?DllImportAttribute?标识 DLL 和函数。?用?static?和?extern?修饰符标记方法。
调用 DLL 函数。像处理其他任何托管方法一样调用托管类上的方法。

　　在C#中创建回调函数，C/C++调用C#回调函数

创建托管回调函数。
创建一个委托，并将其作为参数传递给?C/C++函数。平台调用会自动将委托转换为常见的回调格式。
确保在回调函数完成其工作之前，垃圾回收器不会回收委托。

　　那么C#与原生插件之间是如何实现互相调用的呢？在弄清楚这个问题之前，我们先看下C#代码（.NET上的程序）的执行的过程：（更详细一点的介绍可以参见我之前写的博客：http://www.cnblogs.com/skynet/archive/2010/05/17/1737028.html）

　　1.将源码编译为托管模块；

　　2.将托管模块组合为程序集；

　　3.加载公共语言运行时CLR；

　　4.执行程序集代码。

　　注：CLR(公共语言运行时，Common Language Runtime)和Java虚拟机一样也是一个运行时环境，它负责资源管理（内存分配和垃圾收集），并保证应用和底层操作系统之间必要的分离。

　　为了提高平台的可靠性，以及为了达到面向事务的电子商务应用所要求的稳定性级别，CLR还要负责其他一些任务，比如监视程序的运行。按照.NET的说法，在CLR监视之下运行的程序属于托管(managed)代码，而不在CLR之下、直接在裸机上运行的应用或者组件属于非托管(unmanaged)的代码。

　　这几个过程我总结为下图：

图 .NET上的程序运行
　　回调函数是托管代码C#中的定义的函数，对回调函数的调用，实现从非托管C/C++代码中调用托管C#代码。那么C/C++是如何调用C#的呢？大致分为2步，可以用下图表示：

　　将回调函数指针注册到非托管C/C++代码中（C#中回调函数指委托delegate）

　　调用注册过的托管C#函数指针

　　相比较托管调用非托管，回调函数方式稍微复杂一些。回调函数非常适合重复执行的任务、异步调用等情况下使用。

　　由上面的介绍可以知道CLR提供了C#程序运行的环境，与非托管代码的C/C++交互调用也由它来完成。CLR提供两种用于与非托管C/C++代码进行交互的机制：

平台调用（Platform Invoke，简称PInvoke或者P/Invoke），它使托管代码能够调用从非托管DLL中导出的函数。
COM 互操作，它使托管代码能够通过接口与组件对象模型 (COM) 对象交互。考虑跨平台性，Unity3D不使用这种方式。

　　平台调用依赖于元数据在运行时查找导出的函数并封送（Marshal）其参数。下图显示了这一过程。

　　注意：1.除涉及回调函数时以外，平台调用方法调用从托管代码流向非托管代码，而绝不会以相反方向流动。虽然平台调用的调用只能从托管代码流向非托管代码，但是数据仍然可以作为输入参数或输出参数在两个方向流动。2.图中DLL表示动态库，Windows平台指.dll文件、Linux/Android指.so文件、Mac OS X指.dylib/framework文件、iOS中只能使用.a。后文都使用DLL代指，并且DLL使用C/C++编写。

　　当平台调用调用非托管函数时，它将依次执行以下操作：

查找包含该函数的DLL。
将该DLL加载到内存中。
查找函数在内存中的地址并将其参数推到堆栈上，以封送所需的数据（参数）。
将控制权转移给非托管函数。

　　注意:只在第一次调用函数时，才会查找和加载 DLL 并查找函数在内存中的地址。iOS中使用的是.a已经静态打包到最终执行文件中。

　　2.2Android插件

　　Java同样提供了这样一个扩展机制JNI（Java Native Interface），能够与C/C++互相通信。

　　注：

JNI wiki这里不深入介绍JNI，有兴趣的可以自行去研究。如果你还不知道JNI也不用怕，就像Unity3D使用C/C++库一样，用起来还是比较简单的，只需要知道这个东西即可。并且Unity3D对C/C++桥接器这块做了封装，提供AndroidJNI/AndroidJNIHelper/AndroidJavaObject/AndroidJavaClass/AndroidJavaProxy方便使用等，具体使用后面在介绍。JNI提供了若干的API实现了Java和其他语言的通信（主要是CC++）。从Java1.1开始，JNI标准成为java平台的一部分，它允许Java代码和其他语言写的代码进行交互，保证本地代码能工作在任何Java?虚拟机环境下。
作为知识扩展，提一下Android Java虚拟机。Android的Java虚拟机有2个，最开始是Dalvik，后面Google在Android 4.4系统新增一种应用运行模式ART。ART与Dalvik 之间的主要区别是其具有提前 (AOT) 编译模式。根据 AOT 概念，设备安装应用时，DEX 字节代码转换仅进行一次。相比于 Dalvik，这样可实现真正的优势，因为 Dalvik 的即时 (JIT) 编译方法需要在每次运行应用时都进行代码转换。下文中用Java虚拟机代指Dalvik/ART。

　　C#/Java都可以和C/C++通信，那么通过编写一个C/C++模块作为桥接，就使得C#与Java通信成为了可能，如下图所示：

　　注：C/C++桥接器本身跟Unity3D没有直接关系，不属于Android和Unity3D，图中放在Unity3D中是为了代指libunity.so中实现的桥接器以表示真实的情况。

　　通过JNI既可以用于Java代码调用C/C++代码，也可用于C/C++代码与Java（Dalvik/ART虚拟机）的交互。JNI定义了2个关键概念/结构：JavaVM、JNIENV。JavaVM提供虚拟机创建、销毁等操作，Java中一个进程可以创建多个虚拟机，但是Android一个进程只能有一个虚拟机。JNIENV是线程相关的，对应的是JavaVM中的当前线程的JNI环境，只有附加（attach）到JavaVM的线程才有JNIENV指针，通过JNIEVN指针可以获取JNI功能，否则不能够调用JNI函数。

　　C/C++要访问的Java代码，必须要能访问到Java虚拟机，获取虚拟机有2中方法：

在加载动态链接库的时候，JVM会调用JNI_OnLoad(JavaVM* jvm, void* reserved)，第一个参数会传入JavaVM指针。
在C/C++中调用JNI_CreateJavaVM(jvm, (void**)env, vm_args)创建JavaVM指针

　　所以，我们只需要在编写C/C++桥接器so的时候定义JNI_OnLoad(JavaVM* jvm, void* reserved)方法即可，然后把JavaVM指针保存起来作为上下文使用。

　　获取到JavaVM之后，还不能直接拿到JNI函数去获取Java代码，必须通过线程关联的JNIENV指针去获取。所以，作为一个好的开发习惯在每次获取一个线程的JNI相关功能时，先调用AttachCurrentThread()；又或者每次通过JavaVM指针获取当前的JNIENV：java_vm->GetEnv((void**)jni_env,?version)，一定是已经附加到JavaVM的线程。通过JNIENV可以获取到Java的代码，例如你想在本地代码中访问一个对象的字段（field），你可以像下面这样做：

　　1.对于类，使用jni_env->FindClass获得类对象的引用

　　2.对于字段，使用jni_env->GetFieldId获得字段ID

　　3.使用对应的方法（例如jni_env->GetIntField）获取字段的值

　　类似地，要调用一个方法，你step1.得获得一个类对象的引用obj，step2.是方法methodID。这些ID通常是指向运行时内部数据结构。查找到它们需要些字符串比较，但一旦你实际去执行它们获得字段或者做方法调用是非常快的。step3.调用jni_env->CallVoidMethodV(obj,methodID,args)。

　　从上面的示例代码，我们可以看出使用原始的JNI方式去与Android（Java）插件交互是多的繁琐，要自己做太多的事情，并且为了性能需要自己考虑缓存查询到的方法ID，字段ID等等。幸运的是，Unity3D已经为我们封装好了这些，并且考虑了性能优化。Unity3D主要提供了一下2个级别的封装来帮助高效编写代码：

　　注：Unity3D中对应的C/C++桥接器包含在libunity.so中。

Level 1：AndroidJNI、AndroidJNIHelper，原始的封装相当于我们上面自己编写的C# Wrapper。AndroidJNIHelper和AndroidJNI自动完成了很多任务（指找到类定义，构造方法等），并且使用缓存使调用java速度更快。AndroidJavaObject和AndroidJavaClass基于AndroidJNIHelper和AndroidJNI创建，但在处理自动完成部分也有很多自己的逻辑，这些类也有静态的版本，用来访问java类的静态成员。
Level 2：AndroidJavaObject、AndroidJavaClass、AndroidJavaProxy，这个3个类是基于Level1的封装提供了更高层级的封装使用起来更简单，这个在第三部分详细介绍。

　　2.3iOS插件

　　iOS编写插件比Android要简单很多，因为Objective-C也是 C-compatible的，完全兼容标准C语言。这些就可以非常简单的包一层 extern c{}，用C语言封装调用iOS功能，暴露给Unity3D调用。并且可以跟原生C/C++库一样编成.a插件。C#与iOS（Objective-C）通信的原理跟C/C++完全一样：

　　除此之外，Unity iOS支持插件自动集成方式。所有位于Asset/Plugings/iOS文件夹中后缀名为.m , .mm , .c , .cpp的文件都将自动并入到已生成的Xcode项目中。然而，最终编进执行文件中。后缀为.h的文件不能被包含在Xcode的项目树中，但他们将出现在目标文件系统中，从而使.m/.mm/.c/.cpp文件编译。这样编写iOS插件，除了需要对iOS Objective-C有一定了解之外，与C/C++插件没有差异，反而更简单。

　　3、版本与补丁

　　任何游戏（端游、手游）都应该提供游戏内更新的途径。一般游戏分为全量更新/整包更新、增量更新、资源更新。

　　全量

　　android游戏内完整安装包下载（ios跳转到AppStore下载）

　　增量：主要指android省流量更新

可以使用bsdiff生成patch包
应用宝也提供增量更新sdk可供接入

　　资源

　　Unity3D通过使用AssetBundle即可实现动态更新资源的功能。

　　手游在实现这块时需要注意的几点：

　　1.游戏发布出一定要提供游戏内更新的途径。即使是删掉测试，保不准这期间需要进行资源或者BUG修复更新。很多玩家并不知道如何更新，而且Android手机应用分发平台多样，分发平台本身也不会跟官方同步更新（特别是小的分发平台）。

　　2.更新功能要提供强制更新、非强制更新配置化选项，并指定哪些版本可以不强更，哪些版本必须强更。

　　3.当游戏提供非强制更新功能之后，现网一定会存在多个版本。如果需要针对不同版本做不同的更新，例如配置文件A针对1.0.0.1修改了一项，针对1.0.0.2修改了另一项，2个版本需要分别更新对应的修改，需要自己实现更新策略IIPS不提供这个功能。当需要复杂的更新策略，推荐自己编写更新服务器和客户端逻辑，不使用iips组件（其实自己实现也很简单）。

　　没有运营经验的人会选择二进制，认为二进制安全、更小，这对端游/手游外网只存在一个版本的游戏适合，对一般不强升版本的手游并不适合，反而会对更新和维护带来很大的麻烦。

　　4.配置使用XML或者JSON等文本格式，更利于多版本的兼容和更新。最开始腾讯桌球客户端使用的二进制格式（由excel转换而来），但是随着运营配置格式需要增加字段，这样老版本程序就解析不了新的二进制数据，给兼容和更新带来了很大的麻烦。这样就要求上面提到的针对不同步做不同更新，又或者配置一开始就预留好足够的扩展项，其实不管怎么预留扩展也很难跟上需求的变化，而且一开始会把配置表复杂化但是其实只有一张或者几张才会变更结构。

　　5.iOS版本的送审版本需要连接特定的包含新内容的服务器，现网服务器还不包含新内容。送审通过之后，上架游戏现网服务器会进行更新，iOS版本需要连接现网服务器而非送审服务器，但是这期间又不能修改客户度，这个切换需要通过服务器下发开关进行控制。例如通过指定送审的iOS游戏版本号，客户端判断本地版本号是否为送审版本，如果是连接送审服务器，否则连接现网服务器。

　　4、用脚本，还是不用？这是一个问题

　　方便更新，减少Crash（特别是使用C++的cocos引擎）

　　通过上面一节【版本与补丁】知道要实现代码更新是非常困难的，正式这个原因客户端开发的压力是比较大的，如果出现了比较严重的BUG必须发强制更新版本，使用脚本可以解决这个问题。

　　由于Unity3D手游更新成本比较大，而且目前腾讯桌球要求不能强制更新，这导致新版本的活动覆盖率提升比较慢、出现问题之后难以修复。针对这个情况，考虑引入lua进行活动开发，后续发布活动及修复bug只需要发布lua资源，进行资源更新即可，大大降低了发布和修复问题的成本。

　　可选方案还有使用Html5进行活动开发，目前游戏中已经预埋了Html5活动入口，并且已经用来发过玩家调查、腾讯棋牌宣传等。但是与lua对比，不能做到与Unity3D的深度融合，体验不如使用lua，例如不能操作游戏中的ui、不能完成复杂界面的制作、不能复用已有的功能、玩家付费充值跟已有的也会有差异

　　游戏脚本之王——Lua

　　在公司内部魔方比较喜欢用lua，火隐忍者（手游）unity+ulua，全民水浒cocos2d-x+lua等等都有使用lua进行开发。我们可以使用公司内部的xlua组件，也可以使用ulua、UniLua等等。

　　5、资源管理

　　5.1资源管理器

业务不要直接使用引擎或者系统原生接口，而是封装一个资源管理器负责：资源加载、卸载
兼容Resource.Load与AssetBundle资源互相变更需求，开发期间使用Resource.Load方式而不必打AB包效率更高
加载资源时，不管是同步加载还是异步加载，最好是使用异步编码方式（回调函数或者消息通知机制）。如果哪一天资源由本地加载改为从服务器按需加载，而游戏中的逻辑都是同步方式编码的，改起来将非常痛苦。其实异步编码方式很简单，不比同步方式复杂。

　　5.2资源类型

　　图片/纹理（对性能、包体影响最大因素）

　　音频

背景音乐，腾讯桌球使用.ogg/.mp3
音效，腾讯桌球使用.wav

　　数据

文本
二进制

　　动画/特效

　　5.3图片-文件格式与纹理格式

　　常用的图像文件格式有BMP，TGA，JPG，GIF，PNG等；

　　常用的纹理格式有R5G6B5，A4R4G4B4，A1R5G5B5，R8G8B8, A8R8G8B8等。

　　文件格式是图像为了存储信息而使用的对信息的特殊编码方式，它存储在磁盘中，或者内存中，但是并不能被GPU所识别，因为以向量计算见长的GPU对于这些复杂的计算无能为力。这些文件格式当被游戏读入后，还是需要经过CPU解压成R5G6B5，A4R4G4B4，A1R5G5B5，R8G8B8, A8R8G8B8等像素格式，再传送到GPU端进行使用。

　　纹理格式是能被GPU所识别的像素格式，能被快速寻址并采样。举个例子，DDS文件是游戏开发中常用的文件格式，它内部可以包含A4R4G4B4的纹理格式，也可以包含A8R8G8B8的纹理格式，甚至可以包含DXT1的纹理格式。在这里DDS文件有点容器的意味。OpenGL ES 2.0支持以上提到的R5G6B5，A4R4G4B4，A1R5G5B5，R8G8B8，A8R8G8B8等纹理格式，其中 R5G6B5，A4R4G4B4，A1R5G5B5每个像素占用2个字节(BYTE)，R8G8B8每个像素占用3个字节，A8R8G8B8每个像素占用 4个字节。

　　基于OpenGL ES的压缩纹理有常见的如下几种实现：

　　1）ETC1（Ericsson texture compression)，ETC1格式是OpenGL ES图形标准的一部分，并且被所有的Android设备所支持。

　　2）PVRTC (PowerVR texture compression)，支持的GPU为Imagination Technologies的PowerVR SGX系列。

　　3）ATITC (ATI texture compression)，支持的GPU为Qualcomm的Adreno系列。

　　4）S3TC (S3 texture compression)，也被称为DXTC，在PC上广泛被使用，但是在移动设备上还是属于新鲜事物。支持的GPU为NVIDIA Tegra系列。

　　5.4资源工具

　　有了规范就可以做工具检查，从源头到打包

资源导入检查
资源打包检查

　　6、性能优化

　　掉帧主要针对GPU和CPU做分析；内存占用大主要针对美术资源，音效，配置表，缓存等分析；卡顿也需要对GPU和CPU峰值分析，另外IO或者GC也易导致。

　　6.1工欲善其事，必先利其器

Unity Profiler
XCode?instruments
Qualcomm?Adreno Profiler
NVIDIA PerfHUD ES Tegra

　　6.2CPU：最佳原则减少计算

　　复用，UIScrollView Item复用，避免频繁创建销毁对象

　　缓存，例如Transform

　　运算裁剪，例如碰撞检测裁剪

粗略碰撞检测（划分空间——二分/四叉树/八叉树/网格等，降低碰撞检测的数量）
精确碰撞检测（检查候选碰撞结果，进而确定对象是否真实发生碰撞）
休眠机制：避免模拟静止的球
逻辑帧与渲染帧分离
分帧处理
异步/多线程处理

　　6.3GPU：最佳原则减少渲染

纹理压缩
批处理减少DrawCall（unity-Static Batching和Dynamic Batching，cocos SpriteBatchNode）
减少无效/不必要绘制：屏幕外的裁剪，Flash脏矩阵算法，
LOD/特效分档
NGUI动静分离（UIPanel.LateUpdate的消耗）
控制角色骨骼数、模型面数/顶点数
降帧，并非所有场景都需要60帧（腾讯桌球游戏场景60帧，其他场景30帧；天天酷跑，在开始游戏前，FPS被限制为30，游戏开始之后FPS才为60。天天飞车的FPS为30，但是当用户一段时间不点击界面后，FPS自动降）

　　6.4内存：最佳原则减少内存分配/碎片、及时释放

纹理压缩-Android ETC1、iOS PVRTC 4bpp、windows DXT5
对象池-PoolManager
合并空闲图集
UI九宫格
删除不用的脚本（也会占用内存）

　　6.5IO：最佳原则减少/异步io

资源异步/多线程加载
预加载
文件压缩
合理规划资源合并打包，并非texturepacker打包成大图集一定好，会增加文件io时间

　　6.6网络：其实也是IO的一种

　　使用单线程——共用UI线程，通过事件/UI循环驱动；还是多线程——单独的网络线程？

　　单线程：由游戏循环（事件）驱动，单线程模式比使用多线程模式开发、维护简单很多，但是性能比多线程要差一些，所以在网络IO的时候，需要注意别阻塞到游戏循环。说明，如果网络IO不复杂的情况下，推荐使用该模式。

在UI线程中，别调用可能阻塞的网络函数，优先考虑非阻塞IO
这是网络开发者经常犯的错误之一。比如：做一个简单如 gethostbyname() 的调用，这个操作在小范围中不会存在任何问题，但是在有些情况中现实世界的玩家却会因此阻塞数分钟之久！如果你在 GUI 线程中调用这样一个函数，对于用户来说，在函数阻塞时，GUI 一直都处于 frozen 或者 hanged 状态，这从用户体验的角度是绝对不允许的。

　　多线程：单独的网络线程，使用独立的网络线程有一个非常明显的好处，主线程可以将脏活、累活交给网络线程做使得UI更流畅，例如消息的编解码、加解密工作，这些都是非常耗时的。但是使用多线程，给开发和维护带来一定成本，并且如果没有一定的经验写出来的网络库不那么稳定，容易出错，甚至导致游戏崩溃。下面是几点注意事项：

　　千万千万别在网络线程中，回调主线程（UI线程）的回调函数。而是网络线程将数据准备好，让主线程主动去取，亦或者说网络线程将网络数据作为一个事件驱动主线程去取。当年我在用Cocos2d-x + Lua做魔法花园的手机demo时，就采用的多线程模式，最初在网络线程直接调用主线程回调函数，经常会导致莫名其妙的Crash。因为网络线程中没有渲染所必须的opengl上下文，会导致渲染出问题而Crash。

　　6.7包大小

使用压缩格式的纹理/音频
尽量不要使用System.Xml而使用较小的Mono.Xml
启用Stripping来减小库的大小
Unity strip level（strip by byte code）
Unity3D输出APK，取消X86架构
iOS?Xcode?strip开启

　　6.8耗电

　　下面影响耗电的几个因素和影响度摘自公司内部的一篇文章。

　　7、异常与Crash

　　7.1防御式编程

　　非法的输入中保护你的程序

检查每一输入参数
检查来自外部的数据/资源

　　断言

错误处理
隔栏

　　防不胜防，不管如何防御总有失手的时候，这就需要异常捕获和上报。

　　7.2异常捕获

　　异常捕获已经有很多第三组件可供接入，这里不介绍组件的而接入，而是简单谈一下异常捕获的原理。

　　由于很多错误并不是发生在开发工作者调试阶段，而是在用户或测试工作者使用阶段；这就需要相关代码维护工作者对于程序异常捕获收集现场信息。异常与Crash的监控和上报，这里不介绍Bugly的使用，按照apollo或者msdk的文档接入即可，没有太多可以说的。这里主要透过Bugly介绍手游的几类异常的捕获和分析：

　　Unity3D C#层异常捕获：比较简单使用Application.RegisterLogCallback/Application.RegisterLogCallbackThreaded（在一个新的线程中调用委托）注册回调函数。特别注意：保证项目中只有一个Application.RegisterLogCallback注册回调，否则后面注册的会覆盖前面注册的回调！回调函数中stackTrace参数包异常调用栈。

public void HandleLog(string logString, string stackTrace, LogType type)
{
if (logString == null logString.StartsWith(cLogPrefix))
{
return;
}
ELogLevel level = ELogLevel.Verbose;
switch (type)
{
case LogType.Exception:
level = ELogLevel.Error;
break;
default:
return;
}
if (stackTrace != null)
{
Print(level, ELogTag.UnityLog, logString + \n + stackTrace);
}

　　上线前的checklist

项目

要点

说明

指标

标签：魔兽开发经验爬坑游戏开发者开发技术游戏开发论坛

你还没有登录，请先登录或注册！

还没有人评论，欢迎说说您的想法！