揹包卡頓的地方主要有這幾個地方，第乙個就是開啟揹包的時候，會明顯卡頓，然後就是切換揹包裡面的頁籤也會，還有乙個就是使用揹包裡面的道具，或者**道具的時候。
這個卡頓只有在開啟ilruntime熱更的時候，正常的還是很流暢的。但是我又不能去優化ilruntime，於是對於這幾個地方使用unity自帶的profiler檢視是什麼原因造成的。
調了全道具，然後開啟揹包的時候，發現耗時1900ms，哇，有點嚇人啊。看了下發現主要是揹包道具排序和fairygui建立元件這兩塊，fairygui這塊沒法處理，於是目標放在道具排序上。我們揹包的排序比較函式，這個函式被呼叫了2w多次，所以裡面比較小的時間消耗在這個基數上也會變得很大。我們排序比較方式是通過排序規則的優先順序來給不同的道具加上不同的值，最後比較值的大小來進行排序的。比如品質的優先順序大於型別，那麼品質高的+10000，然後型別中優先順序高的+5000這樣。在這一塊發現吃時間的居然是裡面的引用型別的屬性(之前一直沒有這方面的意識)，快取了一波發現效果不是很明顯，才減少了200ms，想了好一會才猛然發現，為啥我直接把道具比較時算的值快取起來呢，這樣下次碰到這個道具的時候就直接取出來就好了，不用在算一次了。於是我用字典將道具id和比較時算的值存起來。發現一下減少到了600ms，這樣感覺還能接受了。
接下來就是使用道具，這塊發現主要也是重新整理揹包的時候，而且還有個比較嚴重的問題是重新整理的時機，這塊重新整理是在伺服器通知揹包道具改變的時候重新整理的，使用道具的話，尤其是使用盒子之類的道具，在盒子被使用後，伺服器會回一條訊息告訴你盒子被使用掉了，然後馬上又有一條使用盒子獲得道具訊息回來，也就是會刷兩次揹包。這塊我使用了延遲一幀在重新整理處理的。
**道具，瞅了下也是因為對揹包排序導致的，但是**道具不需要重新對揹包排序，於是這塊我去掉了排序。
最後就是切換頁籤了，這個發現還是因為排序導致的，服了，每次切換不同型別的道具的時候，都會對這類道具進行一次排序重新整理。處理是做了快取，不用每次切換的時候排序重新整理，而是在伺服器道具改變訊息回來時，根據道具的型別，指定的排序重新整理這類道具的列表。這樣處理的話，就是拿空間去換時間了，不過效果還是很明顯的。
總結：這次讓我知道原來呼叫引用型別的屬性或者方法放回引用型別會有消耗的，只是消耗很小，如果次數大了後，就會出現問題，其次就是仔細考慮功能具體在哪些時候呼叫生效，不能籠統的呼叫，需要細化到具體的時機。
記一次SQL優化
問題發生在關聯主表a 4w資料量 和副表b 4w資料量 關聯欄位都是openid 當時用的是 left join 直接跑sql，卡死 伺服器也是差 優化1 改left join 為join，兩者區別就是left join查詢時已主表為依據，該是幾條就幾條 就算副表沒有關聯的資料 join如果副表沒有...
記一次oracle 優化過程
可能很多大牛都知道這個方法，但我是頭回遇到，因為專案原因，要寫很多查詢sql，對速度有要求，所以很注重sql語句的優化。像使用left join 速度會快一些等等一些算是比較常見的方法吧。近兩天做自測時發現了乙個問題，同樣一條語句，加了乙個條件竟然速度慢了那麼多，本身是乙個求彙總的sql語句，查全部...
記一次MySQL索引優化
兩張表是主 check drawings 從 check drawings img 關係。check drawings，主表資料 3591條。select count from check drawings 3591 check drawings img，從表資料107203條，資料量並不大，從表通...