U3D雜記

1，點擊UI上的登陸按鈕，從腳本發出ioo.netmanager.SendConnet->進入CS->soketclient.sendconnet...
->netmanager調用 callfunc("onsoket")又將網絡通訊回調到腳本，腳本通信一切都是從OnSocket開始的。
解包時若是先後兩端的協議配置文件MD5不一致則從新下發，若是一致直接取本地
2,RPC調用流程：分爲後端調用和前端調用。
後端調用：rpc_client_xxxx，這是後端向前端發起的調用。過程是：
創建鏈接後，前端OutStream o = TCPClient.BeginRead(...)讀取獲得後端的數據。讀完後將得到的字節數據經過
netmanager回調到腳本 onsocket中，onsocket調用protocolmanager.onsocket -> rpc.onpacket對服務端的字節包進行解包，包的第一個short是functionId,就是rpc_lua_table中的function_cfg的key，根據它取得函數名。
而後再解包出後面的字節（函數的調用參數），而後調用該函數，若是咱們按照該函數的名字在cprotocol中實現了該函數（參數也要對應），那麼該函數就會被調用。
這就實現了一個遠程調用，RPC，實際是封裝了網絡底層的通訊細節，讓前端調用後端及後端調用前端都像本地調用。
前端調用：rpc_server_xxxx，這是前端向後端發送相關信息。
過程是：前端使用protocolmaager.rpc_server_xxx()的函數形式發起調用。這些rpc_server_xxx其實都是同一個LUA函數proxy_func，可在GenServerProxy中看到。proxy_func中執行封包，將基本類型及結構類型全以字節數據封到一個BUF中，而後經過ioo.networkManager:SendMessage(buff)發到CS中，進而調入socketcliet中經過tcpclient返回的Outstream向服務端發送數據 Outstreeam.BeginWrite，完成發送
3，
public class PlaySimulator : MonoBehaviour{
    public static PlaySimulator Create(){
        GameObject go = new GameObject("PlaySimulator");
        PlaySimulator ins = go.AddComponent<PlaySimulator>();
        return ins;//由於此時ins可使用 ins.gameobject，就是說ins有一個對go的引用，所以能夠像這樣建立一個Gameobject，而後添加一個組件，而後返回該組件，而不須返回建立的GameObject
    }

}
3，rootmotion一點新體會：
它是在美術動畫中作死的，好比一個跑步動畫，美術作跑步動畫時它自己是一邊跑一邊有位移的。
U3D自帶的演示角色跑步動畫有位移。WOW的角色跑步動畫都沒位移。
根動畫在導出成FBX時，存儲在動畫集中，如跑步動畫中。只要美術在3DMAX中作的時候角色不滑步，那麼在遊戲中也不會滑步。
這就是根動畫的好處。它是U3D自動處理的。
4，U3D中圖集打包很簡單，只須要爲sprite在屬性中指定 packing tag，而後打開sprite packer，點擊pack就會對全部指定了packing tag的圖片進行打包
，packing tag相同的sprite會打到同一個圖集中。使用時並無圖集的概念，仍是使用原始圖片。U3D會在遊戲運行時自動使用圖集。
對比NGUI的使用就麻煩些了，NGUI atlasmaker打包過程：在磁盤上選中要打包的小圖，打開atlasmaker，新建一個圖集。
點擊ADD會將選中的小圖添加進來。使用時：NGUI->create sprite ，點擊sprite屬性，選擇圖集，而後再選擇圖集中的圖片。
NGUI中有TWEEN功能，實現簡單的位置變換，旋轉，縮放，顏色或ALPAH漸變等。
使用NGUI添加一個sprite時，會在層級面板自動生成UI Root，下面有一個uicamera子結點和生成的sprite子結點。
UI ROOT也就至關於UGUI中的canvas, 不過UGUI把UI相機隱藏了，實際上仍是有一個默認的UI相機的。
5，忽然想到：由C++程序的編譯連接執行過程能夠知道NET程序（C#程序）在編譯時是不通過彙編的。
C++程序編譯執行過程：CPP源碼編譯爲彙編代碼，存儲在一個個的.obj文件中，而後執行連接，將這些OBJ文件，以及第三方DLL庫，
以及操做系統入口調用代碼彙編爲機器碼，而後在機器上執行。
NET程序的執行過程：將CS文件編譯爲程序集,即EXE，程序集中是IL和元數據，IL爲僞彙編代碼。運行EXE時，
加載CLR將程序集轉換爲本地機器碼
6，看了導航網格尋路的原理：第一步生成導航網格，算法沒看，就是利用凸包原理在3D場景上面生成一層覆蓋網格。
第二步，利用A星尋出一條網格路徑。第三步：在A星尋得的網格集上，拐點法尋找出真正的路線（一段拆線）
因而可知導航網格尋路要效率要比A星高得多，網上有人說要高1到2個數量級, 10到100倍？由於A星要把場景劃分爲密集的網格，
而導航網格的格子則有大有小，平坦的地方很是稀疏，且經過了A星篩選，這些都是預處理好的，在運行時只須要在A星篩選出的格
子中進行尋路，效率固然要比原始A星高上不知多少了。
並且導航網格比原始A星（路點A星尋路）多出許多優勢，總之是有過之而無不及。
7，  UnityEngine.Object[] soundObjs = Resources.LoadAll (path);
注意，path是相對於Resources文件夾的，Assets下能夠有許多Resources文件夾，不一樣位置的Resources文件夾內的文件和層級能夠徹底相同，loadAll將一視同仁的對待。
path傳「」時，會將全部Resources文件夾下的資源所有加載，無論重複與否。
8，像聲音這種資源，不須要實例化，只須要在某個GO上添加AudioSource組件，運行時獲取這個組件並調用play()便可。
有時候可能須要動態建立聲音，這個其實能夠繞開，沒必要本身加載本身管理聲音。
能夠在須要聲音的GO上依次添加多個音源組件（該組件只是個引用，不用怕），在使用時，根據音源順序與實際名字對應上。全部的GO均可以這樣作，這樣就避免了本身加載與管理音源，讓U3D幫我作。