效能診斷與優化工具（Q A）

q1：texture占用記憶體總是雙倍，這個是我們自己的問題，還是unity引擎的機制？

出現這種情況的原因有兩種：一種是你在真機執行時開啟了read&write。另一種可能是unity的bug，目前的unity 5.2.3 release note如下 ：

(735644) - opengl: fixed texture memory usage reporting in profiler, was twice the actual size for most textures.

開發者需要關注下自己的開發版本，5.2.3以前類似情況的專案可以參考一下。

overhead的計算方法是：profiler當前幀統計的總耗時時間減去所有已知選項的累加時間，即引擎當前還無法識別模組的耗時時間。overhead數值理論上是趨向於0的，但是由於目前市面上的硬體裝置、系統框架過於豐富，所以引擎可能無法識別所有模組的cpu開銷。

就我們目前遇到的大部分案例而言，overhead數值較高一般是由硬體裝置的垂直同步演算法無法識別而引起的。所以，一般情況下，overhead的數值其實並不需要開發者特別關注。

在uwa的效能分析中，我們並沒有將overhead計算在內，一方面是其本身資料的統計意義對目前大多數專案的效能優化幫助不大，另一方面是即便知道了它的cpu數值，也無法知道到底是哪些地方引起的，上層很難有針對性地進行優化。

當然，我們會持續對overhead進行實驗和研究，分析其cpu耗時規律、與已知選項的關聯性等。後續有任何相關發現，我們都會總結成文，及時分享給大家。

reserved total 和 used total為unity引擎在記憶體方面的總體分配量和總體使用量。 一般來說，引擎在分配記憶體時並不是向作業系統 「即拿即用」，而是首先獲取一定量的連續記憶體，然後供自己內部使用，待空餘記憶體不夠時，引擎才會向系統再次申請一定量的連續記憶體進行使用。所以，從圖表中可以看到，reserved total 的記憶體佔用量略大於 used total， 且兩者走勢基本一致。

q4：紋理atlas是建議合成一張2048（尺寸）的紋理還是四張1024的紋理？

在其他設定一致的情況下，這兩種方式無論在載入還是渲染方面其實並沒有實質上的差別。在我們接觸到的大多數案例中，紋理資源方面的問題除了尺寸外，紋理格式、mipmap設定和read&write功能同樣是需要研發團隊時刻關注的。

這個問題是unity的bug，5.4.0b3 release note 為：

particles: fixed particle system only playing once.（會在新版本5.4修復）

目前我們推薦通過另一種方法可以暫時繞過該 bug：

particlesystem.stop(); 

particlesystem.clear(); 
particlesystem.simulate(0.02f); 
particlesystem.play();

Android效能優化工具 bootchart

1.安裝bootchart sudo apt get install bootchart 2.編譯bootchart 由於5.1原始碼預設編譯時是不編譯bootchart的，需要開啟該編譯項 touch system core init init.c 由於該檔案對應的映象檔案為boot.img，需要...

SQL效能優化工具TKPROF

全名為trace kernel profile，用來格式化跟蹤檔案，是乙個命令列工具。主要的格式例如以下 tkprof tracefile outputfile tracefile 要分析的trace檔案 outputfile 格式化後的檔案 可選引數及說明例如以下 explain 為每乙個sql語...

Android效能優化學習（四）效能優化工具的使用

效能優化的幫助工具 mat,memory monitor 屬於androidmonitor中乙個模組 heaptool 檢視堆資訊 allocation tracking，leakcanary lint工具 1.alloction tracking 追蹤記憶體分配資訊。可以很直觀地看到某個操作的記憶...