??大家好，我是阿趙。
??最近很流行把之前制作在安卓或者iOS端的游戲轉成微信小程序上架，我所在的項目也有這樣的操作。微信小程序是用WebGL來運行的，實際上它的性能很差，只有不到app端的三分之一的性能可用，內存方面也有非常大的限制，所以導致了在微信小程序端的應用比較容易閃退，而且幀率比app端要低很多。
??我的項目同樣也遇到了類似的問題，閃退、掉幀等問題很影響游戲的體驗。大家都在努力的去嘗試解決這個問題。領導也非常的著急，總感覺團隊沒有這方面的經驗，想在外面找些朋友來幫忙解決，包括網上問一些其他公司的人，甚至帶著某些同事直接去別的公司去取經。
??在取經完成的第二三天，我們的游戲小程序端的閃退率從原來的百分之10幾，掉到了只有百分之三左右了。得到了這個結果，大家都很高興，領導估計就更高興了，因為他可以確定團隊本身的確沒經驗沒能力解決這個閃退問題，然后得益于他找關系帶我們去取經，最終解決了這個問題。
??從不懂技術的人的眼中，解決一個問題，應該是只要大方向改一下，就OK的。比如說，引擎里面有一個什么設置，你只要勾選一下，就可以。或者發布的時候，有個什么選項漏了勾選，然后選一下，就解決問題了。這些問題有可能只是自己沒有經驗忽略了，所以稍微問一下人，應該就解決了。但實際上是不是真的這么簡單了？
??實際情況是，為了解決這個問題，其實我重寫了對象池，重寫了消耗大的Shader，重寫了之前消耗占比比較大的角色移動邏輯，然后再在場景上面做了lua的內存檢測和定時回收機制。其實這些問題在領導出去取經之前，就已經做好了，只是一直沒有更新出去。然后取經回來的結果，唯一的收獲只有一個提高設置可用內存，讓低端機直接不能啟動，從而欺騙性的降低閃退率(低端機直接啟動不了，當然就沒有閃退率了)，當然，這種手段也是可以用上去的，畢竟低端機沒有人權，不需要玩游戲。
??然后就一起更新了，所以得到的結果是，問題在取經后順利解決了。不過其實我也無所謂，因為雖然整個項目的底層都是我寫的，但由于工作室同時開多個項目，我寫完了所有的底層之后，就已經去做別的項目組，并不直接參與該項目的管理了，只是由于我是整個底層的作者，有難題還是需要我去解決而已。所以不論怎樣，解決了問題就好了。
??領導不懂技術，是很正常的情況。實際上如果領導一定要搞技術，反而沒有精力去搞管理工作。不過很多時候，領導自己認為的事情，實際情況并不是那樣。如果真的能隨隨便便問問朋友，找找關系，就能把一個項目做好，把技術問題都解決，那么辦公司就太簡單了。就算朋友之間的關系有多好，涉及到工作利益上的東西，如果不是有足夠利益的誘惑，就算關系再好，有別的公司過來請教，我也不可能把真正的核心問題告訴別人。而能告訴別人的東西，一般網上都能查得到。
??然后是，每個項目的底層框架和設計理念會存在差異，并不是說一個項目的經驗就能直接套用在另外一個項目上的。都是需要具體問題具體分析。所以近年來才這么多專門幫別人分析項目性能的服務出現，比如UWA，我也用過。如果是買服務深入項目去做詳細分析，我覺得是非常有用的，他們可以幫助項目很具體的找出問題所在，并提供建議針對實際情況去修改。但如果只是提供一下工具，讓我們看一下性能，或者只是簡單的問問一些籠統的問題，其實對項目的幫助是不會很大的。
??最后再分享一下阿趙我自己解決性能問題的思路。我自己解決問題的思路很簡單，先分析消耗的來源，是cpu、gpu還是內存。有了大方向之后，再配合著性能分析工具，逐個值得懷疑的函數去檢查，找出真正產生問題的點。當找到了懷疑問題所在的地方，直接對比調用和不調用時候的性能情況。如果確定了產生問題的根源，那么就開始分析函數存在的問題，然后再針對性的進行優化了。
??這些步驟都很細碎，很繁瑣，所以是比較耗時間的。查性能問題本身就不是一個很簡單的事情，所以有可能大家都很心急，但實際上心態要好。因為真的不存在說聽誰誰說改一個設置，問題就能解決這么簡單的。問題的出現，往往是由于某一行代碼欠缺考慮，或者某個資源做的時候不夠規范，諸如此類。如果沒有良好的心態，真的是做不到逐個函數去檢查，然后找出根源去解決問題的。