Q1：我最近用Deep Profiler發現項目裡有一個直接調用Color != Color的接口耗時很高，而且百分比也很高（不管是Self還是Total）。但是如果用Profiler.BeginSample顯示時，其耗時又很低，百分比也很低幾乎等于0。這樣的情況下是Deep Profiler出問題了嗎？
針對上圖具體例子來看，Deep Profiler中RoleRender_ChangeColor.get_running的CPU開銷雖然較高，但其參考意義不大。因為不開Deep Profiler模式，此處開銷是不會這麼高的。這是因為，圖中的開銷實際上是操作了200次循環且擷取時間戳的開銷，也就是說，當循環或者操作大量次數時，Deep Profiler模式中本身統計耗時操作的時間占比很大，是以此處回報的時間其實并不是研發團隊想看到的真正代碼耗時。這也是為何很多團隊回報Deep Profiler統計不算準确的原因。
Q2：Unity中修改了Material的一個屬性後，該Object就會單獨執行個體化出一個Material，是以它就不能被動态Batching了，是這樣嗎？
是的，是以我們在Material使用詳情中對記憶體中駐留的Material進行了詳細的檢測和分析，如下圖所示。圖中字尾為（Instance）的材質均為修改材質屬性而生成的臨時材質，對于這種情況，我們建議研發團隊應嚴格将Instance材質數量控制在盡可能小（<10）的範圍内，而對于過高數量的Instance材質，建議研發團隊考慮是否可以通過動态更換Material的方式來代替修改材質屬性的方式，進而來減少不必要的Instance材質，進而提升物體動态合批的幾率。
技術分享連載（五十一）
Q3：對于UGUI文字花屏問題，有什麼推薦的解決方法嗎？
對于UGUI字型花屏的現象， 很有可能是字型的UV不準确導緻。對此，我們推薦兩篇博文，大家可以通過其中的具體做法來進行解決。 關于UGUI字型花屏和亂碼：http://www.cnblogs.com/yaukey/p/unity_ugui_font_texture_uv_wrong.html UGUI研究院之Text字型花屏（二十二）：http://www.xuanyusong.com/archives/4259
Q4：SkinnedMeshRenderer的Mesh是不是不能動态修改？屬性裡隻開放了SharedMesh。
如果需要動态修改 SkinnedMeshRender 對應的 Mesh，則可以通過讀寫 SharedMesh 來實作，類似于 MeshFilter.sharedMesh 的用法，參見： https://docs.unity3d.com/ScriptReference/MeshFilter-sharedMesh.html 但文檔中的例子會修改原 Mesh，如果不想改動原 Mesh，那麼則可以先通過 new Mesh 或者 Instantiate 來拷貝一份後，再修改并給 SharedMesh 指派。在 UWA 的 Blog 中有一篇介紹動态合并多個 SkinnedMeshRender 的文章，其中則是通過 new Mesh 來做合并，最終賦給SharedMesh，可作參考：http://blog.uwa4d.com/archives/avartar.html
Q5：粒子系統裡面使用到的模型，是不是讀寫開關必須要打開，否則會崩潰？
在Unity 5.3早期的版本中，我們确實收到過類似的回報，在某些特效上使用了沒有設定 Readable 的 Mesh 時就會觸發崩潰，且在崩潰日志中會出現ParticleSystemRenderer::UpdateCachedMesh的堆棧。但目前我們在較新的版本上（例如4.7.2，5.3.5 等版本）進行了各種情況的測試後，尚未複現出這一現象。是以，我們建議研發團隊可以嘗試關閉 Readable選項。
原文出處：侑虎科技
本文作者：admin
轉載請與作者聯系，同時請務必标明文章原始出處和原文連結及本聲明。