《騰訊撞球：客戶端總結》 本次分享總結，起源於騰訊撞球項目，但是不僅僅限於項目本身。雖然基於Unity3D，很多東西同樣適用於Cocos。本文從以下10大點進行闡述： 1.架構設計 好的架構利用大規模項目的多人團隊開發和代碼管理，也利用查找錯誤和後期維護。 框架的選擇：需要根據團隊、項目來進行選擇， ...
《騰訊撞球：客戶端總結》
本次分享總結，起源於騰訊撞球項目，但是不僅僅限於項目本身。雖然基於Unity3D，很多東西同樣適用於Cocos。本文從以下10大點進行闡述：
- 架構設計
- 原生插件/平臺交互
- 版本與補丁
- 用腳本，還是不用？這是一個問題
- 資源管理
- 性能優化
- 異常與Crash
- 適配與相容
- 調試及開發工具
- 項目運營
1.架構設計
好的架構利用大規模項目的多人團隊開發和代碼管理，也利用查找錯誤和後期維護。
- 框架的選擇：需要根據團隊、項目來進行選擇，沒有最好的框架，只有最合適的框架。
- 框架的使用：統一的框架能規範大家的行為，互相之間可以比較平滑切換，可維護性大大提升。除此之外，還能代碼解耦。例如StrangeIOC是一個超輕量級和高度可擴展的控制反轉(IoC)框架，專門為C#和Unity編寫。已知公司內部使用StrangeIOC框架的游戲有：騰訊撞球、歡樂麻將、植物大戰僵屍Online。<https://github.com/strangeioc/strangeioc>
依賴註入（Dependency Injection，簡稱DI），是一個重要的面向對象編程的法則來削減電腦程式的耦合問題。依賴註入還有一個名字叫做控制反轉（Inversion of Control，英文縮寫為IoC）。依賴註入是這樣一個過程：由於某客戶類只依賴於服務類的一個介面，而不依賴於具體服務類，所以客戶類只定義一個註入點。在程式運行過程中，客戶類不直接實例化具體服務類實例，而是客戶類的運行上下文環境或專門組件負責實例化服務類，然後將其註入到客戶類中，保證客戶類的正常運行。即對象在被創建的時候，由一個運行上下文環境或專門組件將其所依賴的服務類對象的引用傳遞給它。也可以說，依賴被註入到對象中。所以，控制反轉是，關於一個對象如何獲取他所依賴的對象的引用，這個責任的反轉。
StrangeIOC採用MVCS（數據模型 Model，展示視圖 View，邏輯控制 Controller，服務Service）結構，通過消息/信號進行交互和通信。整個MVCS框架跟flash的robotlegs基本一致，（忽略語言不一樣）詳細的參考<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）
- 將源碼編譯為托管模塊；
- 將托管模塊組合為程式集；
- 載入公共語言運行時CLR；
- 執行程式集代碼。
註：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-https://en.wikipedia.org/wiki/Java_Native_Interface，這裡不深入介紹JNI，有興趣的可以自行去研究。如果你還不知道JNI也不用怕，就像Unity3D使用C/C++庫一樣，用起來還是比較簡單的，只需要知道這個東西即可。並且Unity3D對C/C++橋接器這塊做了封裝，提供AndroidJNI/AndroidJNIHelper/AndroidJavaObject/AndroidJavaClass/AndroidJavaProxy方便使用等，具體使用後面在介紹。JNI提供了若幹的API實現了Java和其他語言的通信（主要是C&C++）。從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），你可以像下麵這樣做：
- 對於類，使用jni_env->FindClass獲得類對象的引用
- 對於欄位，使用jni_env->GetFieldId獲得欄位ID
- 使用對應的方法（例如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類的靜態成員。更詳細介面參考幫助文檔：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的，完全相容標準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即可實現動態更新資源的功能。
手游在實現這塊時需要註意的幾點：
- 游戲發佈出一定要提供游戲內更新的途徑。即使是刪掉測試，保不准這期間需要進行資源或者BUG修複更新。很多玩家並不知道如何更新，而且Android手機應用分發平臺多樣，分發平臺本身也不會跟官方同步更新（特別是小的分發平臺）。
- 更新功能要提供強制更新、非強制更新配置化選項，並指定哪些版本可以不強更，哪些版本必須強更。
-
當游戲提供非強制更新功能之後，現網一定會存在多個版本。如果需要針對不同版本做不同的更新，例如配置文件A針對1.0.0.1修改了一項，針對1.0.0.2修改了另一項，2個版本需要分別更新對應的修改，需要自己實現更新策略IIPS不提供這個功能。當需要複雜的更新策略，推薦自己編寫更新伺服器和客戶端邏輯，不使用iips組件（其實自己實現也很簡單）。
沒有運營經驗的人會選擇二進位，認為二進位安全、更小，這對端游/手游外網只存在一個版本的游戲適合，對一般不強升版本的手游並不適合，反而會對更新和維護帶來很大的麻煩。
-
配置使用XML或者JSON等文本格式，更利於多版本的相容和更新。最開始騰訊撞球客戶端使用的二進位格式（由excel轉換而來），但是隨著運營配置格式需要增加欄位，這樣老版本程式就解析不了新的二進位數據，給相容和更新帶來了很大的麻煩。這樣就要求上面提到的針對不同步做不同更新，又或者配置一開始就預留好足夠的擴展項，其實不管怎麼預留擴展也很難跟上需求的變化，而且一開始會把配置表複雜化但是其實只有一張或者幾張才會變更結構。
- 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<http://ulua.org/>、UniLua<https://github.com/xebecnan/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.6包大小
- 使用壓縮格式的紋理/音頻
- 儘量不要使用System.Xml而使用較小的Mono.Xml
- 啟用Stripping來減小庫的大小
- Unity strip level（strip by byte code）
- Unity3D輸出APK，取消X86架構
- iOS Xcode strip開啟
6.7耗電
下麵影響耗電的幾個因素和影響度摘自公司內部的一篇文章。
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"
|
