1、頂點效能
一般來說，如果您想在
iphone 3gs
或更新的裝置上每幀渲染不超過
40,000
可見點，那麼對於一些配備
mbx gpu
的舊裝置（比如，原始的
iphone
，如iphone 3g
和ipod touch第1
和第2代）來說，你應該保證每幀的渲染頂點在
10000以下。
2、光照效能
畫素的動態光照將對每個受影響的畫素增加顯著的計算開銷，並可能導致物體會被渲染多次。為了避免這種情況的發生，您應該避免對於任何單個物體都使用多個畫素光照，並盡可能地使用方向光。需要注意的是畫素光源是乙個渲染模式（render mode）設定為重要（important
）的光源。畫素的動態光照將對頂點變換增加顯著的開銷。所以，應該盡量避免任何給定的物體被多個光源同時照亮的情況。對於靜態物體，採用烘焙光照方法則是更為有效的方法。
3、角色
每個角色盡量使用乙個skinned mesh renderer,這是因為當角色僅有乙個 skinned mesh renderer 時， unity 會 使用可見性裁剪和包圍體更新的方法來優化角色的運動，而這種優化只有在角色僅含有乙個
skinned mesh renderer 時才會啟動。角色的面數一般不要超過1500，骨骼數量少於30就好，角色material數量一般1~2個為最佳。
4、靜態物體
對於靜態物體定點數要求少於500，uv的取值範圍不要超過（0,1）區間，這對於紋理的拼合優化很有幫助。不要在靜態物體上附加animation元件，雖然加了對結果沒什麼影響，但是會增加cpu開銷。
5、攝像機
將遠平面設定成合適的距離，遠平面過大會將一些不必要的物體加入渲染，降低效率。另外我們可以根據不同的物體來設定攝像機的遠裁剪平面。unity 提供了可以根據不同的 layer 來設定不同的 view distance ，所以我們可以實現將物體進行分層，大物體層設定的可視距離大些，而小物體層可以設定地小些，另外，一些開銷比較大的實體（如粒子系統）可以設定得更小些等等。
6、drawcall
盡可能地減少 drawcall 的數量。 ios 裝置上建議不超過 100 。減少的方法主要有如下幾種： frustum culling ， occlusion culling ， texture packing 。 frustum culling 是 unity 內建的，我們需要做的就是尋求乙個合適的遠裁剪平面； occlusion culling ，遮擋剔除， unity 內嵌了 umbra ，乙個非常好 oc 庫。但 occlusion culling 也並不是放之四海而皆準的，有時候進行 oc 反而比不進行還要慢，建議在 oc 之前先確定自己的場景是否適合利用 oc 來優化； texture packing ，或者叫 texture atlasing ，是將同種 shader 的紋理進行拼合，根據 unity 的 static batching 的特性來減少 draw call 。建議使用，但也有弊端，那就是一定要將場景中距離相近的實體紋理進行拼合，否則，拼合後很可能會增加每幀渲染所需的紋理大小，加大記憶體頻寬的負擔。這也就是為什麼會出現「 drawcall 降了，渲染速度也變慢了」的原因。
Unity遊戲開發效能優化（Sprite優化）
通過減少setpass calls draw calls 數來減少效能消耗 直接進入正題 我隨便在網上找到幾張，將其拖到hierachry面板 此時執行遊戲，觀察game試圖下的stats視窗，此時setpass calls數為4 包括場景的setpass calls 選中需要打包的幾張，選擇為sp...
Android開發效能優化
1 盡量不適用靜態引用，以避免記憶體溢位 2 對進行壓縮 3 listview的優化 4 自定義view中減少measure layout draw 中的耗時操作即它們執行次數 5 不在ui執行緒總做耗時操作，網路請求 資料庫操作 複雜計算等放在子執行緒 6 webview退出時手動銷毀 方法未知 ...
web開發效能優化
1 查詢出的資料量過大 可以採用多次查詢，其他的方法降低資料量 盡量採取分頁查詢資料 2 鎖或者死鎖 這也是查詢慢最常見的問題，是程式設計的缺陷 3 返回了不必要的行和列 用or的字句可以分解成多個查詢，並且通過union鏈結多個查詢。它們的速度只與是否使用索引有關，如果查詢需要用到聯合索引，用un...