共计 2689 个字符，预计需要花费 7 分钟才能阅读完成。
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 计划时，很多时候内存中会用到一张 4096×4096 分辨率的 Alpha 格局的动静图集纹理，内存占用高达 32MB。优化形式就是将罕用字符构建为 4096×4096 的一张动态图集，并通过代码替换纹理、设置压缩格局（如 ASTC8x8），则内存降至仅 4MB。此时再应用一张 512×512 的动静图集作为它的 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
