q1：如下圖，我們發現waitingforjob這個函式消耗過高導致了卡頓，請問該卡頓是否由於渲染壓力過大導致？
從圖中看，該執行緒最後是在等待 canvas.sortjob，而這是 ui 排序造成的開銷（自unity5.2版本開始，ugui的部分計算已經移出了主線程）。
詳情參考：
因此理論上，這是 ui 的 canvas.sortjob 在指定的時間上沒有完成，從而使得渲染執行緒等待，且最終導致主線程進行等待而造成的開銷。
q2：我們在檢視《六龍爭霸測評精講》時，看到下圖中的gc的呼叫，請問該數值的是取決於明式呼叫system.gc.collect()這個方法嗎，還是指系統自動gc的頻率？
手動觸發system.gc.collect和系統觸發gc都屬於gc的呼叫。除ios平台外，unity專案的gc呼叫是由mono來控制的。其主要有兩種方式，一種是系統每隔一段時間呼叫一次，一種則是當堆記憶體分配過大過快時被觸發。q3：在報告中我們看到函式uwa-***是我們加的自定義**段取樣， 我們發現它們觸發了很多gc， 是什麼情況呢？每次gc呼叫均會造成一定程度上的卡頓，從而降低專案執行的流暢度。因此uwa測評中專設了gc呼叫詳細檢測，歡迎開發者上傳專案測試！
說明這些函式中會經常分配大量的堆記憶體 。gc是mono來控制的，當mono認為累積堆記憶體較高時，它就會呼叫gc。同時，哪個函式在分配堆記憶體時觸發了mono的gc，該gc呼叫就會被算作是哪個函式呼叫的。所以如果經常被特定函式來觸發gc，那麼從概率上來說這個函式或這個**段分配的堆記憶體相當高。q4：專案中勾選static batching和不勾選對效率有多大影響？我們在使用中發現勾選了以後包大小會增大一倍。如果不勾選，和自己在**中呼叫staticbatchingutility.combine的效率有多大區別？ q5：如何在移動裝置上，對bloom和全屏抗鋸齒進行優化？unity標準資源裡面自帶的效率比較低（已經嘗試過bloom(optimized)）。
建議使用asset store上適合移動端的bloom shader外掛程式，比如fxpro: bloom&dof和bloompro等。q6：我現在發現兩個因素直接影響overhead，乙個是shader的複雜度，乙個是空update方法及其同類空方法，不知道是否還有其他因素？對於aa，目前在移動裝置上並沒有特別優化的方法，僅能建議在低端裝置上關閉aa功能，而在高階裝置上可嘗試開啟較低倍數（2x）的msaa。
overhead的計算方法是：profiler當前幀統計的總耗時時間減去所有已知選項的累加時間，即引擎當前還無法識別模組的耗時時間。overhead數值理論上是趨向於0的，但是由於目前市面上的硬體裝置、系統框架過於豐富，所以引擎可能無法識別所有模組的cpu開銷。就我們目前遇到的大部分案例而言，overhead數值較高一般是由硬體裝置的垂直同步演算法無法識別而引起的。所以，一般情況下，overhead的數值其實並不需要開發者特別關注。
在uwa的效能分析中，我們並沒有將overhead計算在內，一方面是其本身資料的統計意義對目前大多數專案的效能優化幫助不大，另一方面是即便知道了它的cpu數值，也無法知道到底是哪些地方引起的，上層很難有針對性地進行優化。
當然，我們會持續對overhead進行實驗和研究，分析其cpu耗時規律、與已知選項的關聯性等。後續有任何相關發現，我們都會總結成文，及時分享給大家。
Q A 效能優化（三）
q1 請問怎麼優化下圖這兩者的gc alloc？每次addcomponent 都會有這麼多的開銷。圖中的兩項gc alloc是在進行addcomponent時不可避免的，因此只能通過儘量減少addcomponent的呼叫次數來進行優化。q2 請問，反覆對乙個gameobject呼叫setactive...
效能診斷與優化工具（Q A）
q1 texture占用記憶體總是雙倍，這個是我們自己的問題，還是unity引擎的機制？出現這種情況的原因有兩種 一種是你在真機執行時開啟了read write。另一種可能是unity的bug，目前的unity 5.2.3 release note如下 735644 opengl fixed tex...
Q A 記憶體管理（一）
q1 如圖，在editor中檢視profiler裡的記憶體詳細資訊，發現used total中有個 unity 請問是什麼意思？為什麼會特別大？在editor中執行時，unity 大是正常的，因為在editor中執行專案時，引擎包含了所有的資源占用的記憶體 除了部分紋理和mesh是在gfx中 同時自...