unity unity專案開發過程經驗摘要（轉）
阿新 • • 發佈：2019-01-15
網路層：短連結+長連線
兩者的資料同步可以考慮通過資料庫層來處理，短連線處理業務邏輯，長連線處理資料同步以及一些後臺邏輯。當然只使用短連線的情況下，可以制定一種動態資料的攜帶機制，滿足隨時在任何協議中攜帶常用的各類資料，保證資料的一致，再者建議前端儘可能少的修改自己來源於伺服器的快取資料，寧願多定義一些中間變數，多做一些邏輯。
伺服器和客戶端統一資料結構：
通過策劃定義的excel表，一鍵匯出java c# proto檔案，通過在excel表中新增標註來確定哪些引數是公用資料(傳輸)，哪些是客戶端專用哪些是伺服器專用
另外：客戶端一定要儘量少的做比較重要邏輯的條件判斷，儘量少的使用公式計算，如果可能的話，直接由策劃提供對應公式計算後的數值，或者資料儘可能的由後端傳過來。 再者不同協議儘可能使用公用的結構體，這樣可以減少對快取資料操作的地方，也就可以減少出錯的地方。
還有一點，要多做異常錯誤碼的處理，可以在這裡進行一些前端與後端資料的同步工作。
儘量使用靜態表的方式來獲取各類資料，因為策劃會在線上服進行一定程度的數值調整，千萬不要寫死在程式裡面，當前我們進擊的魔王走的是靜態表，同時支援靜態表的動態更新，這樣可以滿足策劃對資料表的隨時修改，可以將靜態表都拆分成個體單獨處理，每個表都有自己的版本號，減少下載量。由一個總的資訊記錄檔案來控制(這個檔案每次必須從伺服器獲取最新)，記錄當前版本，下載地址等等，當然如果整體大小很小的話，那麼也可以合併成一個檔案，減少更新請求次數。
資源處理：打包成bundle是必須的，考慮是否將介面資源也打包，或者生成為場景資源，打包公用資源，打包單體介面資源，按照順序下載資源，處理資源 (這一條根據需求，如果邏輯合理的話可以減少資源量，不過會加重邏輯工作量)，同時如果使用Bundle的話一定得保證檔名的唯一性，因為WWW是使用檔名來進行區分下載的。合理拆分AssetBundle。 資源分類：場景、角色、介面、靜態表、動畫、特效、其他
//檔名, 版本號(修改時間), 檔案尺寸 md5(crc32) 下載地址(BaseURL+Platform+Resource)
使用WWW.LoadFromCacheOrDownload的方法，下載完的資料將在unity3d的本地快取目錄中進行儲存。Web瀏覽器通常允許快取大小達到50MB，PC和MAC的本地應用，IOS和Android應用都允許快取達到4GB大小
在Unity4.3.3中可以使用CRC32進行檔案正確性校驗，CRC32為32bit的簡單hash，MD5為128bit較複雜的hash演算法，根據網上的資料，雖然CRC32在某些情況不是一定比MD5快，但是有Unity3D內建的介面，同時如果我們使用MD5會增加自己的工作量，那麼還是建議使用CRC的校驗方式。
另外現在可以不用再考慮使用WWW.Dispose來清空程序，釋放資源了，一是這東西不保險，可能會造成崩潰(在下載完成之後呼叫沒問題，在下載中頻繁呼叫可能會出現異常)，二是Unity自己會在合適的時機清空載入程序。
保持良好的編碼：
專案開發中一定要保證委託使用的一致性(Observer pattern)，一定不要某些模組使用，另外的模組又不使用，造成程式碼比較散亂。 其次堅持統一的本地化語言開發機制，對於介面佈局的問題在程式碼中儘量不要使用寫死的數值來調整位置，不要因為前期偷懶造成後期修改成本的增加，畢竟在前期開發中對個人負責的功能更加清晰。
優化託管的堆記憶體：儘可能早的時間將不需要的引用去除掉，置為null，這樣回收機制才能正確地及時的把不需要的記憶體清理出來(理論上)
優化Unity記憶體：避免程式記憶體峰值，在載入兩個大場景時，中間最好穿插一個很小的場景，這樣在場景切換過程中不再使用的資源將會被適當釋放一部分，二是要注意指令碼中對一些資源Prefab、GameObject等引用，如果一些不會被刪除的指令碼包含了對大量資源的引用，那麼這部分資源將不會被釋放。
統一計時功能，根據需求分發到使用者，C#的話最好使用Ticks來計時，比較精確一點，不管使用Ticks或者second，一定要保證各處使用單位一致，同時保證使用Unity的Time. realtimeSinceStartup來記錄程式中與真實時間掛鉤的變數，而不是使用Time.deltaTime
協議碼的處理：建議使用C#的反射機制來處理，拋棄switch的編寫，利用C#的partial功能將檔案按模組或者功能分離程式碼檔案。
3D美術效果：比較合理的美術規範，適用於自身專案，適用於移動端的shader
介面佈局：堅持九宮格的佈局，介面統一動畫的處理，在九宮格的幾個節點掛上相應的動畫指令碼，在Enable和Disable的時候執行正反動畫，覺得我們專案對動畫部分的設計還是很不錯的，效果也比較統一，使用起來也比較簡單。
介面貼圖的製作：NGUI的圖集合並規則，按照美術風格，規定美術的圖素數量，將可能的圖素合併到1-2張通用大貼圖上，其次按照不同的模組進行單獨生成圖集，這樣可以方便做bundle，進行資源下載等其他功能.
自定義一些針對性的介面操作工具，圖集修改，深度統計、修改
效率：儘量減少Instantiate的使用，在合理的情況下使用Cache機制，但同時要控制記憶體的使用
ScrollList或者ScrollView一定要實現迴圈利用，使用盡可能少的模板進行資料迴圈顯示
做好介面管理功能，我們專案中沒有統一的介面管理，很容易造成介面該刪除的時候沒有刪除，再加上比較深層的委託使用，和單一事件分發，使得有的模組的邏輯看起來很複雜，很難快速定位邏輯問題。
任務系統
新手引導：建議以端遊的製作方式去處理，在開發過程中注意處理好事件遮蔽的邏輯，可以通過遮擋、tag標籤、collider等來進行事件遮蔽，總之一定要滿足不能因為引匯出現異常造成使用者無法繼續遊戲。
Shader：因為專案中使用的shader型別也不多，但是在三星的I9260上發現角色的效果不正確，經過檢視發現是shader指令碼中有變數沒有初始化造成，v2f o = (v2f)0; I9260使用的CPU是OMAP4470搭載了PowerVR
Unity自身的Shader Code不支援discard語法，我們是使用AlphaTest + Blend替換的，但是在open gles2.0上又是不支援AlphaTest的，而是通過shader的discard來實現，那麼應該是Unity進行了轉換，有些shader語法需要注意一下。
其他：注意與伺服器時鐘同步、注意監測網路，注意遊戲切入後臺再切回來的流逝時間處理，前後端的資料同步儘量使用直接賦值的方式，避免加減這種操作，減少邏輯出錯機率。
自動打包：資源自動打包，安裝包自動打包，減少人為操作，降低出錯機率。
工程設定：必須採用.Net2.0 Subset，儘量剝離系統庫，採用micro mscorlib，在這種模式下System.Xml System.Security.Cryptography等一些庫無法使用，採取較小的第三方替代
上線：開服前一定要做一遍checkList，梳理changelog以及需要那些資源，各功能的簡單測試結果單。
崩潰統計：
1. 友盟：http://www.umeng.com/analytics_errortype？ 2. Crittercism：https://www.crittercism.com/？ 3.
Crashlytics:http://blog.sina.com.cn/s/blog_8c87ba3b0101m1lf.html
兩者的資料同步可以考慮通過資料庫層來處理，短連線處理業務邏輯，長連線處理資料同步以及一些後臺邏輯。當然只使用短連線的情況下，可以制定一種動態資料的攜帶機制，滿足隨時在任何協議中攜帶常用的各類資料，保證資料的一致，再者建議前端儘可能少的修改自己來源於伺服器的快取資料，寧願多定義一些中間變數，多做一些邏輯。
伺服器和客戶端統一資料結構：
通過策劃定義的excel表，一鍵匯出java c# proto檔案，通過在excel表中新增標註來確定哪些引數是公用資料(傳輸)，哪些是客戶端專用哪些是伺服器專用
另外：客戶端一定要儘量少的做比較重要邏輯的條件判斷，儘量少的使用公式計算，如果可能的話，直接由策劃提供對應公式計算後的數值，或者資料儘可能的由後端傳過來。 再者不同協議儘可能使用公用的結構體，這樣可以減少對快取資料操作的地方，也就可以減少出錯的地方。
還有一點，要多做異常錯誤碼的處理，可以在這裡進行一些前端與後端資料的同步工作。
儘量使用靜態表的方式來獲取各類資料，因為策劃會在線上服進行一定程度的數值調整，千萬不要寫死在程式裡面，當前我們進擊的魔王走的是靜態表，同時支援靜態表的動態更新，這樣可以滿足策劃對資料表的隨時修改，可以將靜態表都拆分成個體單獨處理，每個表都有自己的版本號，減少下載量。由一個總的資訊記錄檔案來控制(這個檔案每次必須從伺服器獲取最新)，記錄當前版本，下載地址等等，當然如果整體大小很小的話，那麼也可以合併成一個檔案，減少更新請求次數。
資源處理：打包成bundle是必須的，考慮是否將介面資源也打包，或者生成為場景資源，打包公用資源，打包單體介面資源，按照順序下載資源，處理資源 (這一條根據需求，如果邏輯合理的話可以減少資源量，不過會加重邏輯工作量)，同時如果使用Bundle的話一定得保證檔名的唯一性，因為WWW是使用檔名來進行區分下載的。合理拆分AssetBundle。 資源分類：場景、角色、介面、靜態表、動畫、特效、其他
//檔名, 版本號(修改時間), 檔案尺寸 md5(crc32) 下載地址(BaseURL+Platform+Resource)
使用WWW.LoadFromCacheOrDownload的方法，下載完的資料將在unity3d的本地快取目錄中進行儲存。Web瀏覽器通常允許快取大小達到50MB，PC和MAC的本地應用，IOS和Android應用都允許快取達到4GB大小
在Unity4.3.3中可以使用CRC32進行檔案正確性校驗，CRC32為32bit的簡單hash，MD5為128bit較複雜的hash演算法，根據網上的資料，雖然CRC32在某些情況不是一定比MD5快，但是有Unity3D內建的介面，同時如果我們使用MD5會增加自己的工作量，那麼還是建議使用CRC的校驗方式。
另外現在可以不用再考慮使用WWW.Dispose來清空程序，釋放資源了，一是這東西不保險，可能會造成崩潰(在下載完成之後呼叫沒問題，在下載中頻繁呼叫可能會出現異常)，二是Unity自己會在合適的時機清空載入程序。
保持良好的編碼：
專案開發中一定要保證委託使用的一致性(Observer pattern)，一定不要某些模組使用，另外的模組又不使用，造成程式碼比較散亂。 其次堅持統一的本地化語言開發機制，對於介面佈局的問題在程式碼中儘量不要使用寫死的數值來調整位置，不要因為前期偷懶造成後期修改成本的增加，畢竟在前期開發中對個人負責的功能更加清晰。
優化託管的堆記憶體：儘可能早的時間將不需要的引用去除掉，置為null，這樣回收機制才能正確地及時的把不需要的記憶體清理出來(理論上)
優化Unity記憶體：避免程式記憶體峰值，在載入兩個大場景時，中間最好穿插一個很小的場景，這樣在場景切換過程中不再使用的資源將會被適當釋放一部分，二是要注意指令碼中對一些資源Prefab、GameObject等引用，如果一些不會被刪除的指令碼包含了對大量資源的引用，那麼這部分資源將不會被釋放。
統一計時功能，根據需求分發到使用者，C#的話最好使用Ticks來計時，比較精確一點，不管使用Ticks或者second，一定要保證各處使用單位一致，同時保證使用Unity的Time. realtimeSinceStartup來記錄程式中與真實時間掛鉤的變數，而不是使用Time.deltaTime
協議碼的處理：建議使用C#的反射機制來處理，拋棄switch的編寫，利用C#的partial功能將檔案按模組或者功能分離程式碼檔案。
3D美術效果：比較合理的美術規範，適用於自身專案，適用於移動端的shader
介面佈局：堅持九宮格的佈局，介面統一動畫的處理，在九宮格的幾個節點掛上相應的動畫指令碼，在Enable和Disable的時候執行正反動畫，覺得我們專案對動畫部分的設計還是很不錯的，效果也比較統一，使用起來也比較簡單。
介面貼圖的製作：NGUI的圖集合並規則，按照美術風格，規定美術的圖素數量，將可能的圖素合併到1-2張通用大貼圖上，其次按照不同的模組進行單獨生成圖集，這樣可以方便做bundle，進行資源下載等其他功能.
自定義一些針對性的介面操作工具，圖集修改，深度統計、修改
效率：儘量減少Instantiate的使用，在合理的情況下使用Cache機制，但同時要控制記憶體的使用
ScrollList或者ScrollView一定要實現迴圈利用，使用盡可能少的模板進行資料迴圈顯示
做好介面管理功能，我們專案中沒有統一的介面管理，很容易造成介面該刪除的時候沒有刪除，再加上比較深層的委託使用，和單一事件分發，使得有的模組的邏輯看起來很複雜，很難快速定位邏輯問題。
任務系統
新手引導：建議以端遊的製作方式去處理，在開發過程中注意處理好事件遮蔽的邏輯，可以通過遮擋、tag標籤、collider等來進行事件遮蔽，總之一定要滿足不能因為引匯出現異常造成使用者無法繼續遊戲。
Shader：因為專案中使用的shader型別也不多，但是在三星的I9260上發現角色的效果不正確，經過檢視發現是shader指令碼中有變數沒有初始化造成，v2f o = (v2f)0; I9260使用的CPU是OMAP4470搭載了PowerVR
Unity自身的Shader Code不支援discard語法，我們是使用AlphaTest + Blend替換的，但是在open gles2.0上又是不支援AlphaTest的，而是通過shader的discard來實現，那麼應該是Unity進行了轉換，有些shader語法需要注意一下。
其他：注意與伺服器時鐘同步、注意監測網路，注意遊戲切入後臺再切回來的流逝時間處理，前後端的資料同步儘量使用直接賦值的方式，避免加減這種操作，減少邏輯出錯機率。
自動打包：資源自動打包，安裝包自動打包，減少人為操作，降低出錯機率。
工程設定：必須採用.Net2.0 Subset，儘量剝離系統庫，採用micro mscorlib，在這種模式下System.Xml System.Security.Cryptography等一些庫無法使用，採取較小的第三方替代
上線：開服前一定要做一遍checkList，梳理changelog以及需要那些資源，各功能的簡單測試結果單。
崩潰統計：
1. 友盟：http://www.umeng.com/analytics_errortype？ 2. Crittercism：https://www.crittercism.com/？ 3.
Crashlytics:http://blog.sina.com.cn/s/blog_8c87ba3b0101m1lf.html