Unity3D手游开发实践
本次分享總結(jié)，起源于騰訊桌球項目，但是不僅僅限于項目本身。雖然基于Unity3D，很多東西同樣適用于Cocos。本文從以下10大點進行闡述：架構(gòu)設(shè)計、原生插件/平臺交互、版本與補丁、用腳本，還是不用？這是一個問題、資源管理、性能優(yōu)化、異常與Crash、適配與兼容、調(diào)試及開發(fā)工具、項目運營。
1.架構(gòu)設(shè)計
好的架構(gòu)利用大規(guī)模項目的多人團隊開發(fā)和代碼管理，也利用查找錯誤和后期維護。
- 框架的選擇：需要根據(jù)團隊、項目來進行選擇，沒有最好的框架，只有最合適的框架。
- 框架的使用：統(tǒng)一的框架能規(guī)范大家的行為，互相之間可以比較平滑切換，可維護性大大提升。除此之外，還能代碼解耦。例如StrangeIOC是一個超輕量級和高度可擴展的控制反轉(zhuǎn)(IoC)框架，專門為C#和Unity編寫。已知公司內(nèi)部使用StrangeIOC框架的游戲有：騰訊桌球、歡樂麻將、植物大戰(zhàn)僵尸Online。[https://github.com/strangeioc/strangeioc](https://github.com/strangeioc/strangeioc)
依賴注入（Dependency Injection，簡稱DI），是一個重要的面向?qū)ο缶幊痰姆▌t來削減計算機程序的耦合問題。依賴注入還有一個名字叫做控制反轉(zhuǎn)（Inversion of Control，英文縮寫為IoC）。依賴注入是這樣一個過程：由于某客戶類只依賴于服務(wù)類的一個接口，而不依賴于具體服務(wù)類，所以客戶類只定義一個注入點。在程序運行過程中，客戶類不直接實例化具體服務(wù)類實例，而是客戶類的運行上下文環(huán)境或專門組件負責(zé)實例化服務(wù)類，然后將其注入到客戶類中，保證客戶類的正常運行。即對象在被創(chuàng)建的時候，由一個運行上下文環(huán)境或?qū)ｉT組件將其所依賴的服務(wù)類對象的引用傳遞給它。也可以說，依賴被注入到對象中。所以，控制反轉(zhuǎn)是，關(guān)于一個對象如何獲取他所依賴的對象的引用，這個責(zé)任的反轉(zhuǎn)。
StrangeIOC采用MVCS（數(shù)據(jù)模型 Model，展示視圖 View，邏輯控制 Controller，服務(wù)Service）結(jié)構(gòu)，通過消息/信號進行交互和通信。整個MVCS框架跟flash的robotlegs基本一致，（忽略語言不一樣）詳細的參考[http://www.cnblogs.com/skynet/archive/2012/03/21/2410042.html](http://www.cnblogs.com/skynet/archive/2012/03/21/2410042.html)。
- 數(shù)據(jù)模型 Model：主要負責(zé)數(shù)據(jù)的存儲和基本數(shù)據(jù)處理
- 展示視圖 View：主要負責(zé)UI界面展示和動畫表現(xiàn)的處理
- 邏輯控制 Controller：主要負責(zé)業(yè)務(wù)邏輯處理，
- 服務(wù)Service：主要負責(zé)獨立的網(wǎng)絡(luò)收發(fā)請求等的一些功能。
- 消息/信號：通過消息/信號去解耦Model、View、Controller、Service這四種模塊，他們之間通過消息/信號進行交互。
- 綁定器Binder：負責(zé)綁定消息處理、接口與實例對象、View與Mediator的對應(yīng)關(guān)系。
- MVCS Context：可以理解為MVC各個模塊存在的上下文，負責(zé)MVC綁定和實例的創(chuàng)建工作。
騰訊桌球客戶端項目框架
1.2代碼目錄的組織：一般客戶端用得比較多的MVC框架，怎么劃分目錄？
先按業(yè)務(wù)功能劃分，再按照MVC來劃分。"蛋糕心語"就是使用的這種方式。
先按MVC劃分，再按照業(yè)務(wù)功能劃分。"D9"、"寶寶斗場"、"魔法花園"、"騰訊桌球"、"歡樂麻將"使用的這種方式。
根據(jù)使用習(xí)慣，可以自行選擇。個人推薦"先按業(yè)務(wù)功能劃分，再按照 MVC 來劃分"，使得模塊更聚焦（高內(nèi)聚），第二種方式用多了發(fā)現(xiàn)隨著項目的運營模塊增多，沒有第一種那么好維護。
Unity項目目錄的組織：結(jié)合Unity規(guī)定的一些特殊的用途的文件夾，我們建議Unity項目文件夾組織方式如下。
其中，Plugins支持Plugins/{Platform}這樣的命名規(guī)范：
- Plugins/x86
- Plugins/x86_64
- Plugins/Android
- Plugins/iOS
如果存在Plugins/{Platform}，則加載Plugins/{Platform}目錄下的文件，否則加載Plugins目錄下的，也就是說，如果存在{Platform}目錄，Plugins根目錄下的DLL是不會加載的。
另外，資源組織采用分文件夾存儲"成品資源"及"原料資源"的方式處理：防止無關(guān)資源參與打包，RawResource即原始資源，Resource即成品資源。當(dāng)然并不限于RawResource這種形式，其他Unity規(guī)定的特殊文件夾都可以這樣，例如Raw Standard Assets。
1.2公司組件
- msdk（sns、支付midas、推送燈塔、監(jiān)控Bugly）
- apollo
- apollo voice
- xlua
目前我們的騰訊桌球、四國軍棋都接入了apollo，但是如果服務(wù)器不采用apollo框架，不建議客戶端接apollo，而是直接接msdk減少二次封裝信息的丟失和帶來的錯誤，方便以后升級維護，并且減少導(dǎo)入無用的代碼。
1.3第三方插件選型
- NGUI
- DoTween
- GIF
- GAF
- VectrosityScripts
- PoolManager
- Mad Level Manger
2.原生插件/平臺交互
雖然大多時候使用Unity3D進行游戲開發(fā)時，只需要使用C#進行邏輯編寫。但有時候不可避免的需要使用和編寫原生插件，例如一些第三方插件只提供C/C++原生插件、復(fù)用已有的C/C++模塊等。有一些功能是Unity3D實現(xiàn)不了，必須要調(diào)用Android/iOS原生接口，比如獲取手機的硬件信息（UnityEngine.SystemInfo沒有提供的部分）、調(diào)用系統(tǒng)的原生彈窗、手機震動等等
2.1C/C++插件
編寫和使用原生插件的幾個關(guān)鍵點：
- 創(chuàng)建C/C++原生插件
- 導(dǎo)出接口必須是C ABI-compatible函數(shù)
- 函數(shù)調(diào)用約定
- 在C#中標(biāo)識C/C++的函數(shù)并調(diào)用
- 標(biāo)識 DLL 中的函數(shù)。至少指定函數(shù)的名稱和包含該函數(shù)的 DLL 的名稱。
- 創(chuàng)建用于容納 DLL 函數(shù)的類。可以使用現(xiàn)有類，為每一非托管函數(shù)創(chuàng)建單獨的類，或者創(chuàng)建包含一組相關(guān)的非托管函數(shù)的一個類。
- 在托管代碼中創(chuàng)建原型。使用DllImportAttribute標(biāo)識 DLL 和函數(shù)。 用static和extern修飾符標(biāo)記方法。
- 調(diào)用 DLL 函數(shù)。像處理其他任何托管方法一樣調(diào)用托管類上的方法。
- 在C#中創(chuàng)建回調(diào)函數(shù)，C/C++調(diào)用C#回調(diào)函數(shù)
- 創(chuàng)建托管回調(diào)函數(shù)。
- 創(chuàng)建一個委托，并將其作為參數(shù)傳遞給 C/C++函數(shù)。平臺調(diào)用會自動將委托轉(zhuǎn)換為常見的回調(diào)格式。
- 確保在回調(diào)函數(shù)完成其工作之前，垃圾回收器不會回收委托。
那么C#與原生插件之間是如何實現(xiàn)互相調(diào)用的呢？在弄清楚這個問題之前，我們先看下C#代碼（.NET上的程序）的執(zhí)行的過程：（更詳細一點的介紹可以參見我之前寫的博客：http://www.cnblogs.com/skynet/archive/2010/05/17/1737028.html）
- 將源碼編譯為托管模塊；
- 將托管模塊組合為程序集；
- 加載公共語言運行時CLR；
- 執(zhí)行程序集代碼。
注：CLR(公共語言運行時，Common Language Runtime)和Java虛擬機一樣也是一個運行時環(huán)境，它負責(zé)資源管理（內(nèi)存分配和垃圾收集），并保證應(yīng)用和底層操作系統(tǒng)之間必要的分離。
為了提高平臺的可靠性，以及為了達到面向事務(wù)的電子商務(wù)應(yīng)用所要求的穩(wěn)定性級別，CLR還要負責(zé)其他一些任務(wù)，比如監(jiān)視程序的運行。按照.NET的說法，在CLR監(jiān)視之下運行的程序?qū)儆?span style="font-weight:700;">"托管"(managed)代碼，而不在CLR之下、直接在裸機上運行的應(yīng)用或者組件屬于"非托管"(unmanaged)的代碼。
這幾個過程我總結(jié)為下圖：
圖 .NET上的程序運行
回調(diào)函數(shù)是托管代碼C#中的定義的函數(shù)，對回調(diào)函數(shù)的調(diào)用，實現(xiàn)從非托管C/C++代碼中調(diào)用托管C#代碼。那么C/C++是如何調(diào)用C#的呢？大致分為2步，可以用下圖表示：
- 將回調(diào)函數(shù)指針注冊到非托管C/C++代碼中（C#中回調(diào)函數(shù)指委托delegate）
- 調(diào)用注冊過的托管C#函數(shù)指針
相比較托管調(diào)用非托管，回調(diào)函數(shù)方式稍微復(fù)雜一些。回調(diào)函數(shù)非常適合重復(fù)執(zhí)行的任務(wù)、異步調(diào)用等情況下使用。
由上面的介紹可以知道CLR提供了C#程序運行的環(huán)境，與非托管代碼的C/C++交互調(diào)用也由它來完成。CLR提供兩種用于與非托管C/C++代碼進行交互的機制：
- 平臺調(diào)用（Platform Invoke，簡稱PInvoke或者P/Invoke），它使托管代碼能夠調(diào)用從非托管DLL中導(dǎo)出的函數(shù)。
- COM 互操作，它使托管代碼能夠通過接口與組件對象模型 (COM) 對象交互。考慮跨平臺性，Unity3D不使用這種方式。
平臺調(diào)用依賴于元數(shù)據(jù)在運行時查找導(dǎo)出的函數(shù)并封送（Marshal）其參數(shù)。 下圖顯示了這一過程。
注意：
當(dāng)"平臺調(diào)用"調(diào)用非托管函數(shù)時，它將依次執(zhí)行以下操作：
- 查找包含該函數(shù)的DLL。
- 將該DLL加載到內(nèi)存中。
查找函數(shù)在內(nèi)存中的地址并將其參數(shù)推到堆棧上，以封送所需的數(shù)據(jù)（參數(shù)）。注意
只在第一次調(diào)用函數(shù)時，才會查找和加載 DLL 并查找函數(shù)在內(nèi)存中的地址。iOS中使用的是.a已經(jīng)靜態(tài)打包到最終執(zhí)行文件中。 - 將控制權(quán)轉(zhuǎn)移給非托管函數(shù)。
2.2Android插件
Java同樣提供了這樣一個擴展機制JNI（Java Native Interface），能夠與C/C++互相通信。
注：
- JNI wiki-https://en.wikipedia.org/wiki/Java_Native_Interface，這里不深入介紹JNI，有興趣的可以自行去研究。如果你還不知道JNI也不用怕，就像Unity3D使用C/C++庫一樣，用起來還是比較簡單的，只需要知道這個東西即可。并且Unity3D對C/C++橋接器這塊做了封裝，提供AndroidJNI/AndroidJNIHelper/AndroidJavaObject/AndroidJavaClass/AndroidJavaProxy方便使用等，具體使用后面在介紹。JNI提供了若干的API實現(xiàn)了Java和其他語言的通信（主要是C&C++）。從Java1.1開始，JNI標(biāo)準(zhǔn)成為java平臺的一部分，它允許Java代碼和其他語言寫的代碼進行交互，保證本地代碼能工作在任何Java 虛擬機環(huán)境下。"
- 作為知識擴展，提一下Android Java虛擬機。Android的Java虛擬機有2個，最開始是Dalvik，后面Google在Android 4.4系統(tǒng)新增一種應(yīng)用運行模式ART。ART與Dalvik 之間的主要區(qū)別是其具有提前 (AOT) 編譯模式。 根據(jù) AOT 概念，設(shè)備安裝應(yīng)用時，DEX 字節(jié)代碼轉(zhuǎn)換僅進行一次。 相比于 Dalvik，這樣可實現(xiàn)真正的優(yōu)勢 ，因為 Dalvik 的即時 (JIT) 編譯方法需要在每次運行應(yīng)用時都進行代碼轉(zhuǎn)換。下文中用Java虛擬機代指Dalvik/ART。
C#/Java都可以和C/C++通信，那么通過編寫一個C/C++模塊作為橋接，就使得C#與Java通信成為了可能，如下圖所示：
注：C/C++橋接器本身跟Unity3D沒有直接關(guān)系，不屬于Android和Unity3D，圖中放在Unity3D中是為了代指libunity.so中實現(xiàn)的橋接器以表示真實的情況。
通過JNI既可以用于Java代碼調(diào)用C/C++代碼，也可用于C/C++代碼與Java（Dalvik/ART虛擬機）的交互。JNI定義了2個關(guān)鍵概念/結(jié)構(gòu)：JavaVM、JNIENV。JavaVM提供虛擬機創(chuàng)建、銷毀等操作，Java中一個進程可以創(chuàng)建多個虛擬機，但是Android一個進程只能有一個虛擬機。JNIENV是線程相關(guān)的，對應(yīng)的是JavaVM中的當(dāng)前線程的JNI環(huán)境，只有附加（attach）到JavaVM的線程才有JNIENV指針，通過JNIEVN指針可以獲取JNI功能，否則不能夠調(diào)用JNI函數(shù)。
C/C++要訪問的Java代碼，必須要能訪問到Java虛擬機，獲取虛擬機有2中方法：
- 在加載動態(tài)鏈接庫的時候，JVM會調(diào)用JNI_OnLoad(JavaVM?jvm, void?reserved)，第一個參數(shù)會傳入JavaVM指針。
- 在C/C++中調(diào)用JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args)創(chuàng)建JavaVM指針。
所以，我們只需要在編寫C/C++橋接器so的時候定義**JNI_OnLoad(JavaVM?jvm, voidreserved)方法即可，然后把JavaVM指針保存起來作為上下文使用。
獲取到JavaVM之后，還不能直接拿到JNI函數(shù)去獲取Java代碼，必須通過線程關(guān)聯(lián)的JNIENV指針去獲取。所以，作為一個好的開發(fā)習(xí)慣在每次獲取一個線程的JNI相關(guān)功能時，先調(diào)用AttachCurrentThread()；又或者每次通過JavaVM指針獲取當(dāng)前的JNIENV：java_vm->GetEnv((void)&jni_env, version)，一定是已經(jīng)附加到JavaVM的線程。通過JNIENV可以獲取到Java的代碼，例如你想在本地代碼中訪問一個對象的字段（field），你可以像下面這樣做：
- 對于類，使用jni_env->FindClass獲得類對象的引用
- 對于字段，使用jni_env->GetFieldId獲得字段ID
- 使用對應(yīng)的方法（例如jni_env->GetIntField）獲取字段的值
類似地，要調(diào)用一個方法，你step1.得獲得一個類對象的引用obj，step2.是方法methodID。這些ID通常是指向運行時內(nèi)部數(shù)據(jù)結(jié)構(gòu)。查找到它們需要些字符串比較，但一旦你實際去執(zhí)行它們獲得字段或者做方法調(diào)用是非常快的。step3.調(diào)用jni_env->CallVoidMethodV(obj, methodID, args)。
從上面的示例代碼，我們可以看出使用原始的JNI方式去與Android（Java）插件交互是多的繁瑣，要自己做太多的事情，并且為了性能需要自己考慮緩存查詢到的方法ID，字段ID等等。幸運的是，Unity3D已經(jīng)為我們封裝好了這些，并且考慮了性能優(yōu)化。Unity3D主要提供了一下2個級別的封裝來幫助高效編寫代碼：
注：Unity3D中對應(yīng)的C/C++橋接器包含在libunity.so中。
- Level 1：AndroidJNI、AndroidJNIHelper，原始的封裝相當(dāng)于我們上面自己編寫的C# Wrapper。AndroidJNIHelper 和AndroidJNI自動完成了很多任務(wù)（指找到類定義，構(gòu)造方法等），并且使用緩存使調(diào)用java速度更快。AndroidJavaObject和AndroidJavaClass基于AndroidJNIHelper 和AndroidJNI創(chuàng)建，但在處理自動完成部分也有很多自己的邏輯，這些類也有靜態(tài)的版本，用來訪問java類的靜態(tài)成員。更詳細接口參考幫助文檔：http://docs.unity3d.com/ScriptReference/AndroidJNI.html，http://docs.unity3d.com/ScriptReference/AndroidJNIHelper.html
- Level 2：AndroidJavaObject、AndroidJavaClass、AndroidJavaProxy，這個3個類是基于Level1的封裝提供了更高層級的封裝使用起來更簡單，這個在第三部分詳細介紹。
2.3iOS插件
iOS編寫插件比Android要簡單很多，因為Objective-C也是 C-compatible的，完全兼容標(biāo)準(zhǔn)C語言。這些就可以非常簡單的包一層 extern "c"{}，用C語言封裝調(diào)用iOS功能，暴露給Unity3D調(diào)用。并且可以跟原生C/C++庫一樣編成.a插件。C#與iOS（Objective-C）通信的原理跟C/C++完全一樣：
除此之外，Unity iOS支持插件自動集成方式。所有位于Asset/Plugings/iOS文件夾中后綴名為.m , .mm , .c , .cpp的文件都將自動并入到已生成的Xcode項目中。然而，最終編進執(zhí)行文件中。后綴為.h的文件不能被包含在Xcode的項目樹中，但他們將出現(xiàn)在目標(biāo)文件系統(tǒng)中，從而使.m/.mm/.c/.cpp文件編譯。這樣編寫iOS插件，除了需要對iOS Objective-C有一定了解之外，與C/C++插件沒有差異，反而更簡單。
3.版本與補丁
任何游戲（端游、手游）都應(yīng)該提供游戲內(nèi)更新的途徑。一般游戲分為全量更新/整包更新、增量更新、資源更新。
- 全量
android游戲內(nèi)完整安裝包下載（ios跳轉(zhuǎn)到AppStore下載） - 增量：主要指android省流量更新
- 可以使用bsdiff生成patch包
- 應(yīng)用寶也提供增量更新sdk可供接入
- 資源
Unity3D通過使用AssetBundle即可實現(xiàn)動態(tài)更新資源的功能。
手游在實現(xiàn)這塊時需要注意的幾點：
- 游戲發(fā)布出一定要提供游戲內(nèi)更新的途徑。即使是刪掉測試，保不準(zhǔn)這期間需要進行資源或者BUG修復(fù)更新。很多玩家并不知道如何更新，而且Android手機應(yīng)用分發(fā)平臺多樣，分發(fā)平臺本身也不會跟官方同步更新（特別是小的分發(fā)平臺）。
- 更新功能要提供強制更新、非強制更新配置化選項，并指定哪些版本可以不強更，哪些版本必須強更。
- 當(dāng)游戲提供非強制更新功能之后，現(xiàn)網(wǎng)一定會存在多個版本。如果需要針對不同版本做不同的更新，例如配置文件A針對1.0.0.1修改了一項，針對1.0.0.2修改了另一項，2個版本需要分別更新對應(yīng)的修改，需要自己實現(xiàn)更新策略IIPS不提供這個功能。當(dāng)需要復(fù)雜的更新策略，推薦自己編寫更新服務(wù)器和客戶端邏輯，不使用iips組件（其實自己實現(xiàn)也很簡單）。
沒有運營經(jīng)驗的人會選擇二進制，認為二進制安全、更小，這對端游/手游外網(wǎng)只存在一個版本的游戲適合，對一般不強升版本的手游并不適合，反而會對更新和維護帶來很大的麻煩。
- 配置使用XML或者JSON等文本格式，更利于多版本的兼容和更新。最開始騰訊桌球客戶端使用的二進制格式（由excel轉(zhuǎn)換而來），但是隨著運營配置格式需要增加字段，這樣老版本程序就解析不了新的二進制數(shù)據(jù)，給兼容和更新帶來了很大的麻煩。這樣就要求上面提到的針對不同步做不同更新，又或者配置一開始就預(yù)留好足夠的擴展項，其實不管怎么預(yù)留擴展也很難跟上需求的變化，而且一開始會把配置表復(fù)雜化但是其實只有一張或者幾張才會變更結(jié)構(gòu)。
- iOS版本的送審版本需要連接特定的包含新內(nèi)容的服務(wù)器，現(xiàn)網(wǎng)服務(wù)器還不包含新內(nèi)容。送審?fù)ㄟ^之后，上架游戲現(xiàn)網(wǎng)服務(wù)器會進行更新，iOS版本需要連接現(xiàn)網(wǎng)服務(wù)器而非送審服務(wù)器，但是這期間又不能修改客戶度，這個切換需要通過服務(wù)器下發(fā)開關(guān)進行控制。例如通過指定送審的iOS游戲版本號，客戶端判斷本地版本號是否為送審版本，如果是連接送審服務(wù)器，否則連接現(xiàn)網(wǎng)服務(wù)器。
4.用腳本，還是不用？這是一個問題
方便更新，減少Crash（特別是使用C++的cocos引擎）
通過上面一節(jié)【版本與補丁】知道要實現(xiàn)代碼更新是非常困難的，正式這個原因客戶端開發(fā)的壓力是比較大的，如果出現(xiàn)了比較嚴重的BUG必須發(fā)強制更新版本，使用腳本可以解決這個問題。
由于Unity3D手游更新成本比較大，而且目前騰訊桌球要求不能強制更新，這導(dǎo)致新版本的活動覆蓋率提升比較慢、出現(xiàn)問題之后難以修復(fù)。針對這個情況，考慮引入lua進行活動開發(fā)，后續(xù)發(fā)布活動及修復(fù)bug只需要發(fā)布lua資源，進行資源更新即可，大大降低了發(fā)布和修復(fù)問題的成本。
可選方案還有使用Html5進行活動開發(fā)，目前游戲中已經(jīng)預(yù)埋了Html5活動入口，并且已經(jīng)用來發(fā)過"玩家調(diào)查"、"騰訊棋牌宣傳"等。但是與lua對比，不能做到與Unity3D的深度融合，體驗不如使用lua，例如不能操作游戲中的ui、不能完成復(fù)雜界面的制作、不能復(fù)用已有的功能、玩家付費充值跟已有的也會有差異
游戲腳本之王——Lua
在公司內(nèi)部魔方比較喜歡用lua，火隱忍者（手游）unity+ulua，全民水滸cocos2d-x+lua等等都有使用lua進行開發(fā)。我們可以使用公司內(nèi)部的xlua組件，也可以使用ulua[http://ulua.org/]、UniLua[https://github.com/xebecnan/UniLua]等等。
5.資源管理
5.1資源管理器
- 業(yè)務(wù)不要直接使用引擎或者系統(tǒng)原生接口，而是封裝一個資源管理器負責(zé)：資源加載、卸載
- 兼容Resource.Load與AssetBundle資源互相變更需求，開發(fā)期間使用Resource.Load方式而不必打AB包效率更高
- 加載資源時，不管是同步加載還是異步加載，最好是使用異步編碼方式（回調(diào)函數(shù)或者消息通知機制）。如果哪一天資源由本地加載改為從服務(wù)器按需加載，而游戲中的邏輯都是同步方式編碼的，改起來將非常痛苦。其實異步編碼方式很簡單，不比同步方式復(fù)雜。
5.2資源類型
- 圖片/紋理（對性能、包體影響最大因素）
- 音頻
- 背景音樂，騰訊桌球使用.ogg/.mp3
- 音效，騰訊桌球使用.wav
- 數(shù)據(jù)
- 文本
- 二進制
- 動畫/特效
5.3圖片-文件格式與紋理格式
- 常用的圖像文件格式有BMP，TGA，JPG，GIF，PNG等；
- 常用的紋理格式有R5G6B5，A4R4G4B4，A1R5G5B5，R8G8B8, A8R8G8B8等。
文件格式是圖像為了存儲信息而使用的對信息的特殊編碼方式，它存儲在磁盤中，或者內(nèi)存中，但是并不能被GPU所識別，因為以向量計算見長的GPU對于這些復(fù)雜的計算無能為力。這些文件格式當(dāng)被游戲讀入后，還是需要經(jīng)過CPU解壓成R5G6B5，A4R4G4B4，A1R5G5B5，R8G8B8, A8R8G8B8等像素格式，再傳送到GPU端進行使用。
紋理格式是能被GPU所識別的像素格式，能被快速尋址并采樣。舉個例子，DDS文件是游戲開發(fā)中常用的文件格式，它內(nèi)部可以包含A4R4G4B4的紋理格式，也可以包含A8R8G8B8的紋理格式，甚至可以包含DXT1的紋理格式。在這里DDS文件有點容器的意味。OpenGL ES 2.0支持以上提到的R5G6B5，A4R4G4B4，A1R5G5B5，R8G8B8，A8R8G8B8等紋理格式，其中 R5G6B5，A4R4G4B4，A1R5G5B5每個像素占用2個字節(jié)(BYTE)，R8G8B8每個像素占用3個字節(jié)，A8R8G8B8每個像素占用 4個字節(jié)。
基于OpenGL ES的壓縮紋理有常見的如下幾種實現(xiàn)：
5.4資源工具
有了規(guī)范就可以做工具檢查，從源頭到打包
- 資源導(dǎo)入檢查
- 資源打包檢查
6.性能優(yōu)化
掉幀主要針對GPU和CPU做分析；內(nèi)存占用大主要針對美術(shù)資源，音效，配置表，緩存等分析；卡頓也需要對GPU和CPU峰值分析，另外IO或者GC也易導(dǎo)致。
6.1工欲善其事，必先利其器
- Unity Profiler
- XCode instruments
- Qualcomm Adreno Profiler
- NVIDIA PerfHUD ES Tegra
6.2CPU：最佳原則減少計算
- 復(fù)用，UIScrollView Item復(fù)用，避免頻繁創(chuàng)建銷毀對象
- 緩存，例如Transform
- 運算裁剪，例如碰撞檢測裁剪
- 粗略碰撞檢測（劃分空間——二分/四叉樹/八叉樹/網(wǎng)格等，降低碰撞檢測的數(shù)量）
- 精確碰撞檢測（檢查候選碰撞結(jié)果，進而確定對象是否真實發(fā)生碰撞）
- 休眠機制：避免模擬靜止的球
- 邏輯幀與渲染幀分離
- 分幀處理
- 異步/多線程處理
6.3GPU：最佳原則減少渲染
- 紋理壓縮
- 批處理減少DrawCall（unity-Static Batching和Dynamic Batching，cocos SpriteBatchNode）
- 減少無效/不必要繪制：屏幕外的裁剪，Flash臟矩陣算法，
- LOD/特效分檔
- NGUI動靜分離（UIPanel.LateUpdate的消耗）
- 控制角色骨骼數(shù)、模型面數(shù)/頂點數(shù)
- 降幀，并非所有場景都需要60幀（騰訊桌球游戲場景60幀，其他場景30幀；天天酷跑，在開始游戲前，FPS被限制為30，游戲開始之后FPS才為60。天天飛車的FPS為30，但是當(dāng)用戶一段時間不點擊界面后，FPS自動降）
6.4內(nèi)存：最佳原則減少內(nèi)存分配/碎片、及時釋放
- 紋理壓縮-Android ETC1、iOS PVRTC 4bpp、windows DXT5
- 對象池-PoolManager
- 合并空閑圖集
- UI九宮格
- 刪除不用的腳本（也會占用內(nèi)存）
6.5IO：最佳原則減少/異步io
- 資源異步/多線程加載
- 預(yù)加載
- 文件壓縮
- 合理規(guī)劃資源合并打包，并非texturepacker打包成大圖集一定好，會增加文件io時間
6.6網(wǎng)絡(luò)：其實也是IO的一種
使用單線程——共用UI線程，通過事件/UI循環(huán)驅(qū)動；還是多線程——單獨的網(wǎng)絡(luò)線程？
- 單線程：由游戲循環(huán)（事件）驅(qū)動，單線程模式比使用多線程模式開發(fā)、維護簡單很多，但是性能比多線程要差一些，所以在網(wǎng)絡(luò)IO的時候，需要注意別阻塞到游戲循環(huán)。說明，如果網(wǎng)絡(luò)IO不復(fù)雜的情況下，推薦使用該模式。
- 在UI線程中，別調(diào)用可能阻塞的網(wǎng)絡(luò)函數(shù)，優(yōu)先考慮非阻塞IO
- 這是網(wǎng)絡(luò)開發(fā)者經(jīng)常犯的錯誤之一。比如：做一個簡單如 gethostbyname() 的調(diào)用，這個操作在小范圍中不會存在任何問題，但是在有些情況中現(xiàn)實世界的玩家卻會因此阻塞數(shù)分鐘之久！如果你在 GUI 線程中調(diào)用這樣一個函數(shù)，對于用戶來說，在函數(shù)阻塞時，GUI 一直都處于 frozen 或者 hanged 狀態(tài)，這從用戶體驗的角度是絕對不允許的。
- 多線程：單獨的網(wǎng)絡(luò)線程，使用獨立的網(wǎng)絡(luò)線程有一個非常明顯的好處，主線程可以將臟活、累活交給網(wǎng)絡(luò)線程做使得UI更流暢，例如消息的編解碼、加解密工作，這些都是非常耗時的。但是使用多線程，給開發(fā)和維護帶來一定成本，并且如果沒有一定的經(jīng)驗寫出來的網(wǎng)絡(luò)庫不那么穩(wěn)定，容易出錯，甚至導(dǎo)致游戲崩潰。下面是幾點注意事項：
- 千萬千萬別在網(wǎng)絡(luò)線程中，回調(diào)主線程（UI線程）的回調(diào)函數(shù)。而是網(wǎng)絡(luò)線程將數(shù)據(jù)準(zhǔn)備好，讓主線程主動去取，亦或者說網(wǎng)絡(luò)線程將網(wǎng)絡(luò)數(shù)據(jù)作為一個事件驅(qū)動主線程去取。當(dāng)年我在用Cocos2d-x + Lua做魔法花園的手機demo時，就采用的多線程模式，最初在網(wǎng)絡(luò)線程直接調(diào)用主線程回調(diào)函數(shù)，經(jīng)常會導(dǎo)致莫名其妙的Crash。因為網(wǎng)絡(luò)線程中沒有渲染所必須的opengl上下文，會導(dǎo)致渲染出問題而Crash。
6.6包大小
- 使用壓縮格式的紋理/音頻
- 盡量不要使用System.Xml而使用較小的Mono.Xml
- 啟用Stripping來減小庫的大小
- Unity strip level（strip by byte code）
- Unity3D輸出APK，取消X86架構(gòu)
- iOS Xcode strip開啟
6.7耗電
下面影響耗電的幾個因素和影響度摘自公司內(nèi)部的一篇文章。
7.異常與Crash
7.1防御式編程
- 非法的輸入中保護你的程序
- 檢查每一輸入?yún)?shù)
- 檢查來自外部的數(shù)據(jù)/資源
- 斷言
- 錯誤處理
- 隔欄
防不勝防，不管如何防御總有失手的時候，這就需要異常捕獲和上報。
7.2異常捕獲
由于很多錯誤并不是發(fā)生在開發(fā)工作者調(diào)試階段，而是在用戶或測試工作者使用階段；這就需要相關(guān)代碼維護工作者對于程序異常捕獲收集現(xiàn)場信息。異常與Crash的監(jiān)控和上報，這里不介紹Bugly的使用，按照apollo或者msdk的文檔接入即可，沒有太多可以說的。這里主要透過Bugly介紹手游的幾類異常的捕獲和分析。
Unity3D C#層異常捕獲
相比比較簡單使用：
code>Application.RegisterLogCallback/Application.RegisterLogCallbackThreaded注冊回調(diào)函數(shù)/在一個新的線程中調(diào)用委托。特別注意：保證項目中只有一個Application.RegisterLogCallback注冊回調(diào)，否則后面注冊的會覆蓋前面注冊的回調(diào)！回調(diào)函數(shù)中stackTrace參數(shù)包異常調(diào)用棧。publicvoidHandleLog(stringlogString, stringstackTrace, LogType type){if(logString == null|| logString.StartsWith(cLogPrefix)){return;}ELogLevel level = ELogLevel.Verbose;switch(type){caseLogType.Exception:level = ELogLevel.Error;break;default:return;}if(stackTrace != null){Print(level, ELogTag.UnityLog, logString + "\n"+ stackTrace);}else{Print(level, ELogTag.UnityLog, logString);}}
Android Java層異常捕獲
try…catch顯式的捕獲異常一般是不引起游戲Crash的，它又稱為編譯時異常，即在編譯階段被處理的異常。編譯器會強制程序處理所有的Checked異常，因為Java認為這類異常都是可以被處理（修復(fù)）的。如果沒有try…catch這個異常，則編譯出錯，錯誤提示類似于"Unhandled exception type xxxxx"。
UnChecked異常又稱為運行時異常，由于沒有相應(yīng)的try…catch處理該異常對象，所以Java運行環(huán)境將會終止，程序?qū)⑼顺?#xff0c;也就是我們所說的Crash。那為什么不會加在try…catch呢？
- 無法將所有的代碼都加上try…catch
- UnChecked異常通常都是較為嚴重的異常，或者說已經(jīng)破壞了運行環(huán)境的。比如內(nèi)存地址，即使我們try…catch住了，也不能明確知道如何處理該異常，才能保證程序接下來的運行是正確的。
Uncaught異常會導(dǎo)致應(yīng)用程序崩潰。那么當(dāng)崩潰了，我們是否可以做些什么呢，就像Application.RegisterLogCallback注冊回調(diào)打印日志、上報服務(wù)器、彈窗提示用戶？Java提供了一個接口給我們，可以完成這些，這就是UncaughtExceptionHandler，該接口含有一個純虛函數(shù)：
Uncaught異常發(fā)生時會終止線程，此時，系統(tǒng)便會通知UncaughtExceptionHandler，告訴它被終止的線程以及對應(yīng)的異常，然后便會調(diào)用uncaughtException函數(shù)。如果該handler沒有被顯式設(shè)置，則會調(diào)用對應(yīng)線程組的默認handler。如果我們要捕獲該異常，必須實現(xiàn)我們自己的handler，并通過以下函數(shù)進行設(shè)置：
public static void setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler handler)
特別注意：多次調(diào)用setDefaultUncaughtExceptionHandler設(shè)置handler，后面注冊的會覆蓋前面注冊的，以最后一次為準(zhǔn)。實現(xiàn)自定義的handler，只需要繼承UncaughtExceptionHandler該接口，并實現(xiàn)uncaughtException方法即可。
static class MyCrashHandler implements UncaughtExceptionHandler{ public void uncaughtException(Thread thread, finalThrowable throwable) { // Deal this exception }
}
在任何線程中，都可以通過setDefaultUncaughtExceptionHandler來設(shè)置handler，但在Android應(yīng)用程序中，全局的Application和Activity、Service都同屬于UI主線程，線程名稱默認為"main"。所以，在Application中應(yīng)該為UI主線程添加UncaughtExceptionHandler，這樣整個程序中的Activity、Service中出現(xiàn)的UncaughtException事件都可以被處理。
捕獲Exception之后，我們還需要知道崩潰堆棧的信息，這樣有助于我們分析崩潰的原因，查找代碼的Bug。異常對象的printStackTrace方法用于打印異常的堆棧信息，根據(jù)printStackTrace方法的輸出結(jié)果，我們可以找到異常的源頭，并跟蹤到異常一路觸發(fā)的過程。
Android Native Crash
前面我們知道可以編寫和使用C/C++原生插件，除非C++使用try...catch捕獲異常，否則一般會直接crash，通過捕獲信號進行處理。
iOS 異常捕獲
跟Android、Unity類似，iOS也提供NSSetUncaughtExceptionHandler 來做異常處理。
@implementation CatchCrash voiduncaughtExceptionHandler(NSException *exception) { // 異常的堆棧信息 NSArray *stackArray = [exception callStackSymbols]; // 出現(xiàn)異常的原因 NSString *reason = [exception reason]; // 異常名稱 NSString *name = [exception name]; NSString *exceptionInfo = [NSString stringWithFormat:@"Exception reason：%@\nException name：%@\nException stack：%@",name, reason, stackArray]; NSLog(@"%@", exceptionInfo); NSMutableArray *tmpArr = [NSMutableArray arrayWithArray:stackArray]; [tmpArr insertObject:reason atIndex:0]; [exceptionInfo writeToFile:[NSString stringWithFormat:@"%@/Documents/error.log",NSHomeDirectory()] atomically:YES encoding:NSUTF8StringEncoding error:nil]; } @end但是內(nèi)存訪問錯誤、重復(fù)釋放等錯誤引起崩潰就無能為力了，因為這種錯誤它拋出的是信號，所以還必須要專門做信號處理。
windows crash
同樣windows提供SetUnhandledExceptionFilter函數(shù)，設(shè)置最高一級的異常處理函數(shù)，當(dāng)程序出現(xiàn)任何未處理的異常，都會觸發(fā)你設(shè)置的函數(shù)里，然后在異常處理函數(shù)中獲取程序異常時的調(diào)用堆棧、內(nèi)存信息、線程信息等。
8.適配與兼容
8.1UI適配
- 錨點（UIAnchor、UIWidgetAnchor屬性）
- NGUI UIRoot統(tǒng)一設(shè)置縮放比例
- UIStretch
8.2兼容
- shader兼容：例如if語句有的機型支持不好，Google nexus 6在shader中使用了if就會crash
- 字體兼容：android復(fù)雜的環(huán)境，有的手機廠商和rom會對字體進行優(yōu)化，去掉android默認字體，如果不打包字體會不現(xiàn)實中文字
9.調(diào)試及開發(fā)工具
9.1日志及跟蹤
事實證明，打印日志（printf調(diào)試法）是非常有效的方法。一個好用的日志調(diào)試，必備以下幾個功能：
- 日志面板/控制臺，格式化輸出
- 冗長級別（verbosity level）：ERROR、WARN、INFO、DEBUG
- 頻道（channel）：按功能等進行模塊劃分，如網(wǎng)絡(luò)頻道只接收/顯示網(wǎng)絡(luò)模塊的消息，頻道建議使用枚舉進行命名。
- 日志同時會輸出到日志文件
- 日志上報（iOS屏蔽文檔目錄，出了問題也拿不到日志）
9.2調(diào)試用繪圖工具
調(diào)試繪圖用工具指開發(fā)及調(diào)試期間為了可視化的繪圖用工具，如騰訊桌球開發(fā)調(diào)試時會使用VectrosityScripts可視化球桌的物理模型（實際碰撞線）幫助調(diào)試。這類工具可以節(jié)省大量時間及快速定位問題。通常調(diào)試用繪圖工具包含：
- 支持繪制基本圖形，如直線、球體、點、坐標(biāo)軸、包圍盒等
- 支持自定義配置，如顏色、粒度（線的粗細/球體半徑/點的大小）等
9.3游戲內(nèi)置菜單/作弊工具
在開發(fā)調(diào)試期間提供游戲進行中的一些配置選項及作弊工具，以方便調(diào)試和提高效率。例如騰訊桌球游戲中提供：
- 游戲內(nèi)物理引擎參數(shù)調(diào)整菜單；
- 修改簽到獎勵領(lǐng)取天數(shù)等作弊工具
注意游戲內(nèi)的所有開發(fā)調(diào)試用的工具，都需要通過編譯宏開關(guān)，保證發(fā)布版本不會把工具代碼包含進去。
9.4Unity擴展
Untiy引擎提供了非常強大的編輯器擴展功能，基于Unity Editor可以實現(xiàn)非常多的功能。公司內(nèi)部、外部都有非常的開源擴展可用
公司外部，如GitHub上的：
UnityEditor-MiniExtension
Unity-Resource-Checker
UnityEditorHelper
MissingReferencesUnity
Unity3D-ExtendedEditor
…
公司內(nèi)部：
TUT、BeautyUnity、UnityDependencyBy
10.項目運營
自動構(gòu)建
- 版本號——主版本號.特性版本號.修正版本號.構(gòu)建版本號
- [構(gòu)建版本號]應(yīng)用分發(fā)平臺升級判斷基準(zhǔn)
- 自動構(gòu)建
- Android
- iOS — XUPorter
公司內(nèi)部接入SODA即可，建議搭建自己的構(gòu)建機，開發(fā)期間每日N Build排隊會死人的，另外也可以搭建自己的搭建構(gòu)建平臺
統(tǒng)計上報
- Tlog上報
- 玩家轉(zhuǎn)化關(guān)鍵步驟統(tǒng)計（重要）
- Ping統(tǒng)計上報
- 游戲業(yè)務(wù)的統(tǒng)計上報（例如桌球球局相關(guān)的統(tǒng)計上報）
- 燈塔自定義上報
運營模板
- 配置化
- 服務(wù)器動態(tài)下發(fā)
- CDN拉取圖片并緩存
上線前的checklist
| 燈塔上報 | 1. 燈塔自帶統(tǒng)計信息 2. 自定義信息上報 | 燈塔里面包含很多統(tǒng)計數(shù)據(jù)，需要檢查是否ok | 1. 版本/渠道分布 2. 使用頻率統(tǒng)計 3. 留存統(tǒng)計（1天留存、3天留存、7天留存、14天留存） 4. 用戶結(jié)構(gòu)統(tǒng)計（有效用戶、沉默用戶、流失用戶、回流用戶、升級用戶、新增用戶） 5. 硬件統(tǒng)計（機型+版本、分辨率、操作系統(tǒng)、內(nèi)存、cpu、gpu） 6. Crash統(tǒng)計（Crash版本、Crash硬件、Crash次數(shù)等）等等 | |
| 信鴿推送 | 能夠針對單個玩家，所有玩家推送消息 | ? | ? | |
| 米大師支付 | 正常支付 | ? | ? | |
| 安全組件 | 1. TSS組件接入 2. 隱藏內(nèi)部符號表：C++開發(fā)的代碼使用strip編繹選項，抹除程序的符號 3. 關(guān)鍵數(shù)據(jù)加密，如影子變量+異或加密算法項 | 根據(jù)安全中心提供的文檔完成所有 | 接入安全組件，并通過安全中心的驗收 | |
| 穩(wěn)定性 | crash率 | 用戶crash率：發(fā)生CRASH的用戶數(shù)/使用用戶數(shù)；啟動crash率：啟動5S內(nèi)發(fā)生crash用戶數(shù)/使用用戶數(shù) | 低于3% | |
| 弱網(wǎng)絡(luò) | ? | 斷線重連考慮，緩存消息，重發(fā)機制等等 | 客戶端的核心場景必須有斷線重連機制，并在有網(wǎng)絡(luò)抖動、延時、丟包的網(wǎng)絡(luò)場景下，客戶端需達到以下要求：一. 不能出現(xiàn)以下現(xiàn)象：1、游戲中不能出現(xiàn)收支不等、客戶端卡死/崩潰等異常情況；2、游戲核心功能（如登錄、單局、支付等）不能有導(dǎo)致游戲無法正常進行的UI、交互問題；3、不能有損害玩家利益或可被玩家額外獲利的問題；4、需要有合理的重連機制，避免每次重連都返回到登錄界面。二. 需要對延時的情況有相應(yīng)的提示 | |
| 兼容性 | ? | ? | 通過適配測試 | |
| 游戲更新 | 1. 整包更新；2. 增量更新 | ? | 特別說明：iOS送審版本支持連特定環(huán)境，與正式環(huán)境區(qū)別開，需要通過服務(wù)器開關(guān)控制 | |
| 性能 | 內(nèi)存、CPU、幀率、流量、安裝包大小 | ? | 【內(nèi)存占用要求】Android平臺：在對應(yīng)檔次客戶端最低配置以上，均需滿足以下內(nèi)存消耗指標(biāo)（PSS）： 1. 檔機型指標(biāo)：最高PSS<=300MB （PSS高于這個標(biāo)準(zhǔn)會影響28%用戶的體驗，約1800萬） 2. 檔機型指標(biāo)：最高PSS<=200MB（PSS高于這個標(biāo)準(zhǔn)會影響45%用戶的體驗，約3000萬） 3. 檔機型指標(biāo)：最高PSS<=150MB（PSS高于這個標(biāo)準(zhǔn)會影響27%用戶的體驗，約1800萬） iOS平臺：在對應(yīng)檔次客戶端最低配置以上，均需滿足以下內(nèi)存消耗指標(biāo)（PSS）： 1. 檔機型指標(biāo)：消耗內(nèi)存（real mem）不大于250MB（高于這個標(biāo)準(zhǔn)會影響53%用戶的體驗，約1900萬） 2. 檔機型指標(biāo)：消耗內(nèi)存（real mem）不大于200MB（高于這個標(biāo)準(zhǔn)會影響47%用戶的體驗，約1700萬） 【CPU占用要求】Android平臺：CPU占用(90%)小于60% iOS平臺：CPU占用(90%)小于80% 【幀率要求】 1. 檔機型（CPU為四核1.4GHZ，RAM為2G）或以上機型：游戲核心玩法中，最小FPS應(yīng)不小于25幀/秒? 2. 檔機型（CPU為兩核1.1GH，RAM為768M）或以上機型：游戲核心玩法中，最小FPS應(yīng)不小于25幀/秒? 3. 檔機型（CPU為1GHZ，RAM為768M）或以上機型：游戲核心玩法中，最小FPS應(yīng)不小于18幀/秒 【流量消耗要求】游戲核心玩法流量消耗情況（非一次性消耗）應(yīng)滿足以下條件： 1. 對于分局的游戲場景，單局消耗流量不超過200KB? 2. 對于不分局游戲場景或流量與局時有關(guān)的場景，10分鐘消耗流量不超過500KB | ? |
總結(jié)
以上是生活随笔為你收集整理的Unity3D手游开发实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 浙大160位学者入选2020“中国高被引
- 下一篇： P4084 [USACO17DEC]Ba