1）對於字體裁剪生僻字的做法
2）協程中yield return CoFunction()和yield return StartCoroutine(CoFunction())的區別
3）Unity切換場景時對技能特效首次釋放卡頓
4）《SLG手遊的製作與優化》中Shadowmap優化的疑問
這是第324篇UWA技術知識分享的推送，精選了UWA社區的熱門話題，涵蓋了UWA問答、社區帖子等技術知識點，助力大家更全面地掌握和學習。
UWA社區主頁：answer.uwa4d.com
UWA QQ羣：465082844
Font
Q：我們項目中使用的中文字體TTF文件大於10MB，於是採用了通用的裁剪生僻字的做法，把字體中低頻使用的字形數據刪掉了，但是項目又有取名相關的需求，並且在玩家取名完成後無論是大廳主界面還是戰鬥界面都有顯示玩家名字的需求，那麼在這種情況下有什麼方法既能兼容玩家取名一些被裁剪掉的生僻字，又能夠有效降低字體TTF Asset內存的做法呢？
我的意思並不是指降低字體圖集的大小，而是降低原字體TTF文件的大小。
A：我有個思路題主可以考慮試一下：
首先是一個前提，就是TMP圖集的內存優化做法：是我參考了UWA DAY 2022中的議題《Unity移動遊戲性能優化案例分析》結尾左右的一個分享。簡單來説，就是在遊戲項目中使用TMP方案時，很多時候內存中會用到一張4096x4096分辨率的Alpha格式的動態圖集紋理，內存佔用高達32MB。優化方式就是將常用字符構建為4096x4096的一張靜態圖集，並通過代碼替換紋理、設置壓縮格式（如ASTC8x8），則內存降至僅4MB。此時再使用一張512x512的動態圖集作為它的Fallback，就能處理生僻字需求了。
基於上述的做法，我們還知道TMP中打靜態圖集後是可以解除對TTF文件的引用的，沒有引用，也就不用打進包體、加載進內存；但問題在於，那張小的、用來處理生僻字的動態圖集還是要引用TTF才能在運行時生成。那麼，我們就可以考慮反向裁剪，也就是隻把TTF裏的已經打進靜態圖集裏的常用字裁剪掉而保留生僻字，再把這個處理過的TTF資源作為那張動態圖集的引用對象。
通過上面這一系列操作，字體圖集紋理和TTF文件的內存佔用應該都降低了，同時理論上能達成題主的功能需求。
感謝Faust@UWA問答社區提供了回答
Script
Q：請問協程中yield return CoFunction()和yield return StartCoroutine(CoFunction())有什麼區別？
針對以上問題，有經驗的朋友歡迎轉至社區交流分享
Performance
Q：在切換場景時對技能特效用緩存池提前做了緩存，進入場景後首次釋放依然卡頓，這是為什麼呢？
A1：首次特效釋放的卡頓往往與Shader編譯有關係，可以嘗試收集Shader變種並提前Warmup一下。
感謝該用户匿名@UWA問答社區提供了回答
A2：比較全面的預加載應該模擬真實環境下的播放流程，因此可以在切場景Loading期間，創建一個臨時Camera，隨後將需要預加載的資源全部在Camera前面播放一下，並調用Camera.Render：
- 對於特效Prefab，在對象池裏實例化，並在Camera視野裏實例化並播放一幀，同時調用Camera.Render強制渲染，再回收到對象池。
- 對於Animator和Animation，Animator.Update(1.0)調用Animation.Sample模擬播放一遍，如果有動畫事件，確保動畫事件關聯的特效和聲音也在預加載列表裏。
- 對於AudioClip，調用PlayOneShot並靜音。
- 其他資源按需處理。
按以上步驟處理後，下次在真實場景播放時，不會再有任何耗時的邏輯步驟，一般不會再出現卡頓了。
感謝流浪貓咪2@UWA問答社區提供了回答
Shadow
Q：對於UWA DAY 2022系列課程中《SLG手遊的製作與優化》的疑問：
Shadowmap改進裏説可以在生成和接受時把WorldToLightMatrix的計算去掉，這個是怎麼做到的？就算不轉到光空間也得轉到其他空間，怎麼都得有矩陣運算得出shadowCoord，而且矩陣乘法是幾個MAD，即使頂點很多，vs裏跟其他方式比會有很大差異？
A：首先，頂點的投影點是在水平面上的，頂點和投影點的相對關係是比較穩定的，在WorldSpace是這樣，在CameraSpace中也是如此。
其次，改進算法中的投影點的偏移計算是發生在CameraSpace中的，所以：
- 頂點本身MVP計算，是會計算到ViewSpace也就是CameraSpace下的viewPos；
- 光線方向V，在CameraSpace下，是可以提前算一遍的，CPU一幀算一次就好；
- 頂點到投影點的距離是很容易通過相似三角形算出來的，而且這個比值是固定的，其實就是光線和地平面夾角A的，1/sinA；而A也是可以提前就知道的，CPU一幀計算一次就好；
- 知道偏移長度和方向V，是很容易算出偏移的，那麼也就很容易算出在ViewSpace下的投影點的位置；
- 到這裏，看起來很多步驟（主要是思考過程），其實就是一個MAD的事情；
- 我只想知道投影點的UV（即Shadowmap的ShadowCoord），所以Projection的過程其實就是一個MAD的事情；
- 根據相似三角形的成像原理，Shadowmap中寫入的是頂點在地平面上的Y值；
- 到現在為止VS過程中，一共只用了兩個MAD，而一個矩陣運算是四個MAD（不同寫法指令不一樣）。
再次，生成和接收都需要經過這樣的計算。
最後，從PPT中最後的性能對比來看，性能的提升是有的，相差也不算很大，低端機上表現更為明顯一點，有1.5ms左右的差距，高端機上差距並不算顯著。
它帶來對Shadowmap利用率的提高，而導致使用更低Shadowmap Size達到相同的效果，對於高配機器來説，收益可能更大一點。
感謝Jessica@UWA問答社區提供了回答
封面圖來源於《SLG手遊的製作與優化》課程
今天的分享就到這裏。當然，生有涯而知無涯。在漫漫的開發週期中，您看到的這些問題也許都只是冰山一角，我們早已在UWA問答網站上準備了更多的技術話題等你一起來探索和分享。歡迎熱愛進步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之“石”，也能攻你之“玉”。
官網：www.uwa4d.com
官方技術博客：blog.uwa4d.com
官方問答社區：answer.uwa4d.com
UWA學堂：edu.uwa4d.com
官方技術QQ羣：465082844
