前言
筆者過去被指派多次改善 CPU 效能的項目，累積了一些心得可以分享。因此本系列將以 UE4 為範例，預計提供一些觀念，標準流程，技巧給大家參考。讓大家都可以更快的入門，避免走一些曾經走過的冤枉路。
本篇不會提到太多 UE4 相關的技巧，會以效能分析與改善的觀念為主。
確認自己清楚為何而戰
在改善效能的過程中，一定要隨時知道自己在改善什麼，做了這個項目在最佳情況可以改善多少。不要一股腦兒的投入某個細項，結果其實改善微乎其微。
CPU bound? GPU bound?
在進行效能改善前，請務必先了解自己的遊戲到底是 CPU bound 還是 GPU bound，也就是遊戲的瓶頸到底是 CPU 還是 GPU，這絕對是首先最重要的事情。
本系列要提的是 CPU 效能的改進，不會提及 GPU 改進的相關部份。
如何知道遊戲是不是 CPU bound?
在 UE4 要知道這件事很容易，將你的遊戲放到目標平台上，使用 console command stat unit 並觀察 CPU 與 GPU 佔用的時間。CPU 過高就是 CPU bound，GPU 過高就是 GPU bound，如果都很高的話，就挑嚴重的先處理。
謹記 80/20 原則
80/20 原則是個概念，可以套用在很多的事情上（可以無限上綱的意思）。在這邊提的意思則是：大多數程式執行的總時間只在執行少部分的程式碼。所以我們在做效能改善的時候，只處理少部分的程式碼就可以改善最多的效能。
不要用猜的來改善效能
改善效能的流程請務必從量測效能開始，偷懶跳過這個步驟，用直覺來改善效能的話，下場就是很容易成為 80/20 原則的反向教材，花了 80% 的時間卻只改善了效能的 20%。
這是經驗談，就算是有經驗的老手也會中招。畢竟一個遊戲系統很大，每個人都會知道自己經手的系統哪裡效能不佳。如果直接分配一段時間（例如一週），讓每個人改善自己的系統效能，這樣的做法是浪費且沒有效率的，因為效率瓶頸可能根本就不在某人上。
又例如說某個系統有一段寫法很暴力或是用了很多層迴圈，花了大把時間去改善，結果這段程式碼只執行一次，也不會影響畫面卡頓。那麼這個時間應該要省下來去作別的項目。
藉由量測效能估算極限
先從量測效能開始的另一個好處是可以很快知道極限在哪裏。拿到效能數據，有經驗的話很快就可以預測出要讓 FPS 達標，總共需要改善多少系統。就算沒有經驗也可以推估一個大概的方向。
舉例來說，根據量測的結果，現在距離目標的 FPS 還有 3ms 要改進。佔用前幾名的 A 系統佔用 3ms，B 系統佔用 1.5ms，C 系統佔用 0.5ms。尋找各系統的開發者，詢問他們系統改進方案，是屬於可移除/可改善？改進難度，是屬於極難/中等/極簡單？
假設評估結果 A 是極難/可改善，B 系統是中等/可改善，C 系統是可移除/極簡單。那麼就可以稍微訂出目標為改善 B 與 C。估算 ABC 三個系統大概可以改進多少，若可改進 0.5+0.5ms，即代表還有 2ms 需要找其他系統改進，或是要花時間投資在 A 項目上。
時間寶貴，更要斤斤計較
很多時候我們沒有太多的時間可以做效能改善，遊戲說不定快要推出了才說現在要調效能。
注意量測的目標平台
特別注意你現在的目標是哪個平台，請針對平台處理。完全不建議在編輯器量測平台，除非你明確知道編輯器與打包後的差異。
如果是 Server/Client 架構的話通常效能瓶頸也會差很多，例如 UE4 的架構 AI 幾乎只能在 Server 執行，Client不會有 AI。如果現在在意的是 Client 端的 FPS，那就直接忘了 AI 很貴的存在吧。
至於有沒有要每次都在目標平台做分析，這個我反而持保留的態度。因為很多平台的出版本很耗費時間，不利於頻繁地來回測試與驗證。這時候我會建議一開始用同一個版本出各個目標平台。例如 PC、 iOS、 Android，然後以相似的測試條件錄製效能報告。比對不同平台的測試報告，確認系統的瓶頸是不是大同小異。
假如說各系統所佔的 CPU 比例在所有平台都差不多，只是絕對值的差別（如 PC 佔約 0.1ms，iOS 佔約 1ms 之類的）。如果差不多，那可以先專注在 PC改善就好。如果有平台特別異常的項目，就要紀錄下來，納入改善的考量。
標準作業流程
首先大家要清楚知道在調整效能的時候是大家都需要幫忙的，但是瓶頸分析可以一個人做就好。其他人依照分析的方向作改進會比較有效率。
所以這邊分享一下之前試過一次，覺得不錯的一個作業流程（經過幾次的調整就可以有效率的達到目標）：
1. 錄製多平台，每平台多個效能檔
2. 使用分析工具確認效能瓶頸沒有受到不同測試環境而有極大的差異
3. 列出應該調整的瓶頸項目
4. 詢問項目開發人員改進方案與難易度
5. 制訂改進目標
6. 分發工作項目
7. 著手進行改善
8. 回到步驟 1 驗收
項目 1 與 2 的目的是避免只錄一次會有偏差，我曾經遇過只對某一次測試結果分析，結果某個很貴的角色在該次測試沒出現，最後多花了時間處理這個角色。
項目 3 就比較偏向如何使用工具來找瓶頸，比較偏一些心得與技巧，會在之後的文章介紹。
項目 4、5、6、7 就是前面提到的項目，重點就是挑風險低，改善多的項目先下手。
結論
以上講了一些過去的心得與自己的觀念，之後預計會介紹如何在 UE4 Profile CPU，如何使用 Unreal Frontend。Blueprint(BP) 轉 C++ 的衡量，以及一些曾經遇過常常是瓶頸的項目。
