Unity3d 拖拽賦值組件與通過Find賦值組件的優點與缺點？

01-11

Unity3d 拖拽賦值組件與通過Find賦值組件的優點與缺點的評估，來請教下各位大神，大神可以說下自己的觀點，你們用的話是一般是怎麼樣的賦值方式比較多？

之前的回答沒有寫詳細- -，好吧我背鍋。

拖拽的問題：

1.數據儲存是放在meta文件中，如果修改了資源和地址你的數據就丟失了，得重新拖拽。腳本拖拽的東西越多丟失後找回來越麻煩

2.沒法做自動化處理，任何賦值操作必須人為拖拽

推拽的好處：

1.參數因為是序列化保存的，這樣UI可以非常流暢的初始化打開。

2.保存的物體信息和具體路徑無關，和他的數據信息有關（比如meta文件裡面存儲的guid）,這樣美術人員拖動修改了物體的名字或者位置不會丟棄引用。

Find賦值好處：

所以賦值必須有代碼書寫，但是可以自己做自動化工具去寫代碼。而且不易丟失引用資源，所以安全性大大提高。

壞處：

Find()需要耗時，而且很多時候不容易操作。加上因為和路徑相關，修改了名字或者路徑就會失效。因此需要能方便重新刷新路徑的工具腳本支持。

總結：

其實國內如果不是為了熱更新，很多時候都是怎麼方便怎麼來，但是一旦要搞熱更新了麻煩就接踵而至。

還是那句話，為了安全性、擴展性、可讀性考慮，所以代碼的查詢組件賦值最好都是通過代碼Find去找。為了方便、流暢、和敏捷可以直接拖拽。

最後的最後，優點缺點還不是根據項目框架來定的，有的遊戲框架全是Find，也有的遊戲框架全是拖拽，利用特性趨利避害而已。

各有好處吧，拖拽方便，並且耗時會少，find的話不容易造成資源丟失，但是耗時多。

反對上面說用Find代替拖曳賦值的，這麼說的估計都是沒做過UI載入優化的。可以自己發布一個真機版測試效率看看，用同樣的一個較為複雜的UI做兩份分別打包成AssetBundle，用Find方法列印一下載入以及UI Awake的時候Find出所有組件的時間，另一個用序列化方法列印一下載入UI所需時間對比一下就知道了。

Find自動化也自動不到哪去，路徑還不是要手動填寫？再自動化能避免這一步？除非是Find出所有的根節點。

唯一需要考慮的是序列化後的UI打包成AssetBundle後如果發生改動，會不利於熱更新，可能造成代碼與資源對應不上。這個要額外寫個組件來解決。

find優點是可以跨場景尋找gameobject缺點是find比較消耗性能拖拽的缺點是只能引用本場景的物體

首先UI結構布局上就是一棵樹結構，推薦用廣度優先演算法FIND，如果UI面板結構比較複雜，推薦FIND到父節點，在以父節點為基礎FIND查找目標組件。深度優先演算法FIND不要用。

有代碼潔癖find ，沒有就手拖…

個人比較建議用find ，而且抵制拖腳本的行為…

拖拽挺好的呀，如果對於一開始就存在於場景中的物體，拖拽是個省時省力的方法。find寫到代碼里也要把路徑寫出來，寫錯路徑還要回頭改，不如拖拽來的實在

根據我的經驗，能不用find就不用find，不要聽他們的，

遞歸Find也還好命名不衝突（我們的做法是大UI綁定lua腳本 ui下面的子頁簽綁定lua腳本，子頁簽下面還可以繼續拆，相同類型的item也綁定lua腳本，這樣拆就把一個大UI拆成了很多小的，這些腳本對應ui下面需要find的節點不重名就好了）

用Find可以方便代碼重用，並且可以避免出現拖拽的引用丟失的問題。

但要注意的是：

1、要注意給物體合理命名，並避免出現同一路徑下相同名字的物體。

2、避免在Update()裡面用Find，這麼做會很消耗性能。正確的做法是先定義引用，在Start()里賦值。

Find一定是會比拖拽的方法慢的，因此遇到需要大量循環賦值的情況也要另闢蹊徑

當然用find，因為ui都在lua裡面寫