1，點擊UI上的登錄按鈕，從腳本發(fā)出ioo.netmanager.SendConnet->進(jìn)入CS->soketclient.sendconnet...
->netmanager調(diào)用 callfunc("onsoket")又將網(wǎng)絡(luò)通信回調(diào)到腳本，腳本通訊一切都是從OnSocket開始的。
解包時如果前后兩端的協(xié)議配置文件MD5不一致則重新下發(fā)，如果一致直接取本地
2,RPC調(diào)用流程：分為后端調(diào)用和前端調(diào)用。
后端調(diào)用：rpc_client_xxxx，這是后端向前端發(fā)起的調(diào)用。過程是：
建立連接后，前端OutStream o = TCPClient.BeginRead(...)讀取得到后端的數(shù)據(jù)。讀完后將獲得的字節(jié)數(shù)據(jù)通過
netmanager回調(diào)到腳本 onsocket中，onsocket調(diào)用protocolmanager.onsocket -> rpc.onpacket對服務(wù)端的字節(jié)包進(jìn)行解包，包的第一個short是functionId,就是rpc_lua_table中的function_cfg的key，根據(jù)它取得函數(shù)名。
然后再解包出后面的字節(jié)（函數(shù)的調(diào)用參數(shù)），然后調(diào)用該函數(shù)，如果我們按照該函數(shù)的名字在cprotocol中實現(xiàn)了該函數(shù)（參數(shù)也要對應(yīng)），那么該函數(shù)就會被調(diào)用。
這就實現(xiàn)了一個遠(yuǎn)程調(diào)用，RPC，實際是封裝了網(wǎng)絡(luò)底層的通信細(xì)節(jié)，讓前端調(diào)用后端及后端調(diào)用前端都像本地調(diào)用。
前端調(diào)用：rpc_server_xxxx，這是前端向后端發(fā)送相關(guān)信息。
過程是：前端使用protocolmaager.rpc_server_xxx()的函數(shù)形式發(fā)起調(diào)用。這些rpc_server_xxx其實都是同一個LUA函數(shù)proxy_func，可在GenServerProxy中看到。proxy_func中執(zhí)行封包，將基本類型及結(jié)構(gòu)類型全以字節(jié)數(shù)據(jù)封到一個BUF中，然后通過ioo.networkManager:SendMessage(buff)發(fā)到CS中，進(jìn)而調(diào)入socketcliet中通過tcpclient返回的Outstream向服務(wù)端發(fā)送數(shù)據(jù) Outstreeam.BeginWrite，完成發(fā)送
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的引用，因此可以像這樣創(chuàng)建一個Gameobject，然后添加一個組件，然后返回該組件，而不須返回創(chuàng)建的GameObject
??? }

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

總結(jié)

以上是生活随笔為你收集整理的U3D杂记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。