[知识与探索] 在性能优化的过程中，UWA团队经常会遇到一些未知的问题。 在这里，我们将分享西澳大学研究这些问题的完整过程。 当然需要说明的是，好问题没有标准答案，欢迎大家在这里积极拍砖！
今天分享的内容来自我们对UWA问答社区“Ask for help with font dependencies”这个帖子的研究。
一、问题描述
两种不相关的字体在Unity中导入时会有依赖关系。
2.问题复现
研发团队做了一个测试demo，导入了“PKCommonFont.ttf”和“Normal.ttf”两种字体。 并且在测试前确认了这两个字体资源，无论是从字体本身还是Unity中的Font Name，都看不出有什么关联，但是可以通过AssetDatabase.GetDependencies(ttfPath)方法依赖找到两者的关系。 实际加载的时候，加载PKCommonFont的时候unity改变字体，Normal字体也会被加载。
三、问题分析
我们在研究这个问题的过程中，慢慢发现当字体是Dynamic类型时，会根据Font Names建立关联，其中Font Names并不是指字体文件的文件名，但是字体的内部名称 (TrueTypeFontImporter .fontTTFName)。 例子中的“Normal”和“PKCommonFont”都只是文件名游戏图片，它们的字体内部名称都是“Source Han Sans CN”； 并且当存在具有相同字体内部名称的字体文件时，编辑器将自动建立它们之间的关联（项目中较晚出现的字体将与较早出现的字体相关联）。 这就是示例中关联两种完全不同的字体的原因。 同时，为了验证这个问题，我们还尝试修改了两种字体的FontName，使其不再相同。 果然，两种字体之间的依赖关系消失了。
4.解决方案
1、更合理的解离方式：
重命名字体的内部名称，使获取的 TrueTypeFontImporter.fontTTFName 不同。
2.更方便的解除关联方式：
修改ttf对应的meta文件，将fallbackFontReferences:[]改为
以下是测试过程：
方法一：用FontCreator修改FontName
使用FontCreator(9.1)修改FontName，步骤如下：
1）用FontCreator打开PKCommonFont.ttf文件后unity改变字体，通过【字体】【属性】打开属性面板。
2) 切换到【Extended】选项卡，将【Font Family】修改为“PKCommonFont”。
3）导出：【文件】【导出字体为】选择TrueType字体，字体名称选择【版本重新生成】，导出PKCommonFont2.ttf。
下图是两种字体修改前后的meta文件对比，左边是修改前，右边是修改后。
下图是修改后的运行结果，可以看到PKCommonFont2.ttf不再依赖于Normal.ttf。
方法二：修改有依赖问题的ttf的meta文件
下图是元文件修改前后的对比游戏策划，左边是修改后，右边是修改前。
下图是修改后的运行结果，可以看到PKCommonFont.ttf不再依赖于Normal.ttf。
五、结语
当明确Unity使用字体资源的内部名称时，字体之间关联的原因就会揭晓。 这个问题的困惑源于字体资源文件名和字体内部名不一致，所以建议研发团队在给字体资源文件命名的时候尽量和字体内部名一一对应，所以以免在使用过程中被文件名打扰。
至此，这个问题已经解决了。 本问题来自问答社区：如果您对本问题还有疑问，可以到社区进一步交流。
同时也欢迎大家在UWA问答社区（）中积极提交研发过程中遇到的问题。 也许随着时间的推移和技术的进步，答案会变得廉价，但问题会变得更有价值，因为问题和研究会比答案更有力量。
近期亮点
