一、unity vsync
參考文章：本文僅做記錄，具體思路可以參考原作者描述）
安卓系統中有 2 種 vsync 訊號：螢幕產生的硬體 vsync 和由 su***ceflinger 將其轉成的軟體 vsync 訊號。後者經由 binder 傳遞給 choreographer。
關閉vsync ，採用單快取工作流程，如圖:
如上圖，cpu/gpu 向 buffer 中生成影象，螢幕從 buffer 中取影象、重新整理後顯示。這是乙個典型的生產者——消費者模型。
理想的情況是幀率和重新整理頻率相等，每繪製一幀，螢幕顯示一幀。而實際情況是，二者之間沒有必然的大小關係，如果沒有鎖來控制同步，很容易出現問題。例如，當幀率大於重新整理頻率，當螢幕還沒有重新整理第 n-1 幀的時候，gpu 已經在生成第 n 幀了，從上往下開始覆蓋第 n-1 幀的資料，當螢幕開始重新整理第 n-1 幀的時候，buffer 中的資料上半部分是第 n 幀資料，而下半部分是第 n-1 幀的資料，顯示出來的影象就會出現上半部分和下半部分明顯偏差的現象，我們稱之為 「tearing」，如下圖：
開啟vsync：採用雙重快取（double buffer）
注意，此處的「雙緩衝」和計算機組成原理中的「二級快取」是兩回事。三重快取也是如此。
為了解決單快取的「tearing」問題，雙重快取和 vsync 應運而生。雙重快取模型如下圖：
兩個快取區分別為 back buffer 和 frame buffer。gpu 向 back buffer 中寫資料，螢幕從 frame buffer 中讀資料。vsync 訊號負責排程從 back buffer 到 frame buffer 的複製操作，可認為該複製操作在瞬間完成。其實，該複製操作是等價後的效果，實際上雙緩衝的實現方式是交換 back buffer 和 frame buffer 的名字，更具體的說是交換記憶體位址（有沒有聯想到那道經典的筆試題目：「有兩個整型數，如何用最優的方法交換二者的值？」），通過二位運算「與」即可完成，所以可認為是瞬間完成。
雙緩衝的模型下，工作流程這樣的：
在某個時間點，乙個螢幕重新整理周期完成，進入短暫的重新整理空白期。此時，vsync 訊號產生，先完成複製操作，然後通知 cpu/gpu 繪製下一幀影象。複製操作完成後螢幕開始下乙個重新整理周期，即將剛複製到 frame buffer 的資料顯示到螢幕上。
在這種模型下，只有當 vsync 訊號產生時，cpu/gpu 才會開始繪製。這樣，當幀率大於重新整理頻率時，幀率就會被迫跟重新整理頻率保持同步，從而避免「tearing」現象。
注意：當 vsync 訊號發出時，如果 gpu/cpu 正在生產幀資料，此時不會發生複製操作。螢幕進入下乙個重新整理周期時，從 frame buffer 中取出的是「老」資料，而非正在產生的幀資料，即兩個重新整理周期顯示的是同一幀資料。這是我們稱發生了「掉幀」（dropped frame，skipped frame，jank）現象。
總結：帶下劃線的位置，就是博主遇到的開啟垂直同步，會引起幀率輕微波動的原因。
方案，關閉垂直同步，同時控制幀率。
二、camera 個數（盡可能的少，或者在不用時，禁用掉）
每個camera 都會走camera.render ,即使沒有渲染任何東西，也會culling（錐形範圍視口剔除操作）
其次，減少場景內的物體數量，能有效降低sceneculling的消耗。
unity 優化總結
一 記憶體 資源優化 紋理 read write 對於ui和一些不需要遠近處理的紋理關閉mipmap 紋理的分辨力率盡量小，夠用就好的原則 盡量採用硬體支援格式，安卓 etc1 etc2 ios pvrtc ios 平台使用pvrt壓縮紋理。adroid平台使用etc1格式壓縮。均可以減至1 4的記...
Unity效能優化之記憶體篇
效能優化，進無止境 記憶體篇 上 效能優化，進無止境 記憶體篇 下 本篇主旨是總結兩篇內容的重點，細節還請在作者文章檢視。1.資源記憶體占用 2.引擎模組自身記憶體占用 3.託管堆記憶體占用。4.記憶體洩露。5.無效的mono堆記憶體開銷。6.資源冗餘。資源的記憶體占用往往佔據了總體記憶體的70 以...
Unity移動端優化總結
模型面數和頂點數的控制 unity這邊沒辦法控制.就需要和做三維的同事交流好 指令碼新建的指令碼缺省會建立出update函式.在不需要用到的情況下可以刪掉 盡量不要在update函式中做複雜運算,盡量不要在update函式中使用find,getcomponent這類的呼叫 只在乙個指令碼中使用ong...