程序写累了，就来玩玩酷跑小游戏吧，嘿嘿。
雨松MOMO送你一首歌曲，嘿嘿。
UGUI研究院之Text字体花屏（二十二）
UGUI研究院之Text字体花屏（二十二）
围观14331次
编辑日期： 字体：
今天我同事说在老项目用的是unity4.7.2打包发布韩文和泰文，偶尔会出现字体花屏的问题，但是中文是好的。（我也不知道怎么解释，只能靠猜吧）我们用的TTF动态字体,Text每次赋值的时候Unity会生成贴图，以及保存每个字的UV信息，那么显示字体的时候根据UV信息去生成的贴图里取最终渲染在屏幕上。那么出现花屏很可能就是贴图更新了，而还在用老的UV取图，所以就取不到了。这个时候需要重新刷新一下Text理论上就正确。
下面的代码挂在任意对象上。意思就是Font.textureRebuilt监听字体的贴图是否发生rebuild的事件。然后调用text.FontTextureChanged();重新刷新一下字体
<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7<div class="crayon-num crayon-striped-num" data-line="crayon-59b8b7<div class="crayon-num" data-line="crayon-59b8b7
using UnityEngine;using System.Collections;using UnityEngine.UI;&public class UIFontDirty : MonoBehaviour{&&&&bool isDirty = false;&&&&Font dirtyFont = null;&&&&&void Awake()&&&&{&&&&&&&&Font.textureRebuilt += delegate(Font font1)&&&&&&&&{&&&&&&&&&&&&isDirty = true;&&&&&&&&&&&&dirtyFont = font1;&&&&&&&&};&&&&}&&&&&void LateUpdate()&&&&{&&&&&&&&if (isDirty)&&&&&&&&{&&&&&&&&&&&&isDirty = false;&&&&&&&&&&&&foreach (Text text in GameObject.FindObjectsOfType&Text&())&&&&&&&&&&&&{&&&&&&&&&&&&&&&&if (text.font == dirtyFont)&&&&&&&&&&&&&&&&{&&&&&&&&&&&&&&&&&&&&text.FontTextureChanged();&&&&&&&&&&&&&&&&}&&&&&&&&&&&&}&&&&&&&&&&&&print("雨松MOMO textureRebuilt " + dirtyFont.name);&&&&&&&&&&&&dirtyFont = null;&&&&&&&&}&&&&}}
我也不确定在别的unity版本，或者别的文字里还会出现这个问题。欢迎大家测试，也欢迎大家在下面给我留言。
本文固定链接:
转载请注明:
雨松MOMO提醒您：亲，如果您觉得本文不错，快快将这篇文章分享出去吧 。另外请点击网站顶部彩色广告或者捐赠支持本站发展，谢谢！
作者：雨松MOMO
专注移动互联网，Unity3D游戏开发
如果您愿意花10块钱请我喝一杯咖啡的话，请用手机扫描二维码即可通过支付宝直接向我捐款哦。
您可能还会对这些文章感兴趣！{"debug":false,"apiRoot":"","paySDK":"/api/js","wechatConfigAPI":"/api/wechat/jssdkconfig","name":"production","instance":"column","tokens":{"X-XSRF-TOKEN":null,"X-UDID":null,"Authorization":"oauth c3cef7c66aa9e6a1e3160e20"}}
{"database":{"Post":{"":{"contributes":[{"sourceColumn":{"lastUpdated":,"description":"","permission":"COLUMN_PUBLIC","memberId":,"contributePermission":"COLUMN_PUBLIC","translatedCommentPermission":"all","canManage":true,"intro":"","urlToken":"uwa4d","id":18298,"imagePath":"4fecf539d0fcfce34c4b.jpeg","slug":"uwa4d","applyReason":"0","name":"UWA：简单优化、优化简单","title":"UWA：简单优化、优化简单","url":"/uwa4d","commentPermission":"COLUMN_ALL_CAN_COMMENT","canPost":true,"created":,"state":"COLUMN_NORMAL","followers":2355,"avatar":{"id":"4fecf539d0fcfce34c4b","template":"/{id}_{size}.jpeg"},"activateAuthorRequested":false,"following":false,"imageUrl":"/4fecf539d0fcfce34c4b_l.jpeg","articlesCount":105},"state":"accepted","targetPost":{"titleImage":"/v2-35bd6dede3f0_r.png","lastUpdated":,"imagePath":"v2-35bd6dede3f0.png","permission":"ARTICLE_PUBLIC","topics":[,18432],"summary":"原文链接：UI制作一向是项目开发中的瓶颈所在。如何在实现绚丽效果的同时还能保持优秀的性能以此带来流畅的操作体验？也许看似UI图集、UI按钮等背后都隐藏着错综复杂的逻辑设定，每个UI元素的属性细节都需要开发者细细揣摩。UI优化，知…","copyPermission":"ARTICLE_COPYABLE","translatedCommentPermission":"all","likes":0,"origAuthorId":0,"publishedTime":"T16:36:03+08:00","sourceUrl":"","urlToken":,"id":1850683,"withContent":false,"slug":,"bigTitleImage":false,"title":"关于Unity中的UGUI优化，你可能遇到这些问题","url":"/p/","commentPermission":"ARTICLE_ALL_CAN_COMMENT","snapshotUrl":"","created":,"comments":0,"columnId":18298,"content":"","parentId":0,"state":"ARTICLE_PUBLISHED","imageUrl":"/v2-35bd6dede3f0_r.png","author":{"bio":"招网站前端、后端、引擎功能开发实习生。有意者私信我：）","isFollowing":false,"hash":"7fdb9e2544cdf169ab0bf0b1bd9e04ba","uid":498100,"isOrg":false,"slug":"zhang-xin-81-92-50","isFollowed":false,"description":"用实力让情怀落地。","name":"张鑫","profileUrl":"/people/zhang-xin-81-92-50","avatar":{"id":"v2-4e579678fdf30dc1f03b1fd9fdd412a8","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"memberId":,"excerptTitle":"","voteType":"ARTICLE_VOTE_CLEAR"},"id":487078}],"title":"关于Unity中的UGUI优化，你可能遇到这些问题","author":"zhang-xin-81-92-50","content":"原文链接：UI制作一向是项目开发中的瓶颈所在。如何在实现绚丽效果的同时还能保持优秀的性能以此带来流畅的操作体验？也许看似UI图集、UI按钮等背后都隐藏着错综复杂的逻辑设定，每个UI元素的属性细节都需要开发者细细揣摩。UI优化，知易行难。下面均是开发者在实战中遇到过的拦路虎，我们均提供了解决思路，值得Mark！关键字界面制作网格重建界面切换加载相关字体一、界面制作Q1：UGUI里的这个选项 ，应该是ETC2拆分Alpha通道的意思，但是在使用中并没起作用？请问有没有什么拆分的标准和特别要求呢？据我们所知，alpha split 的功能最初只对 Unity 2D 的 Sprite（SpriteRenderer）有完整的支持，而UI的支持是在Unity 5.4版本之后的。建议大家在Unity 5.4版本以后的UGUI中尝试该功能。Q2：在UI界面中，用Canvas还是用RectTransform做根节点更好？哪种方法效率更高？Canvas划分是个很大的话题。简单来说，因为一个Canvas下的所有UI元素都是合在一个Mesh中的，过大的Mesh在更新时开销很大，所以一般建议每个较复杂的UI界面，都自成一个Canvas(可以是子Canvas)，在UI界面很复杂时，甚至要划分更多的子Canvas。同时还要注意动态元素和静态元素的分离，因为动态元素会导致Canvas的mesh的更新。最后，Canvas又不能细分的太多，因为会导致Draw Call的上升。我们后续将对UI模块做具体的讲解，尽请期待。Q3：UWA性能检测报告中的Shared UI Mesh表示什么呢？Shared UI Mesh是在Unity 5.2 版本后UGUI系统维护的UI Mesh。在以前的版本中，UGUI会为每一个Canvas维护一个Mesh（名为BatchedMesh，其中再按材质分为不同的SubMesh）。而在Unity 5.2版本后，UGUI底层引入了多线程机制，而其Mesh的维护也发生了改变，目前Shared UI Mesh作为静态全局变量，由底层直接维护，其大小与当前场景中所有激活的UI元素所生成的网格数相关。一般来说当界面上UI元素较多，或者文字较多时该值都会较高，在使用UI/Effect/shadow和UI/Effect/Outline时需要注意该值，因为这两个Effect会明显增加文字所带来的网格数。Q4：在使用NGUI时，我们通常会将很多小图打成一个大的图集，以优化内存和Draw Call。而在UGUI时代，UI所使用的Image必须是Sprite；Unity提供了SpritePacker。 它的工作流程和UGUI Atlas Paker有较大的差别。在Unity Asset中，我们压根看不到图集的存在。 问题是：1. SpritePacker大概的工作机制是什么样的？2. 如果Sprite没有打包成AssetBundle，直接在GameObject上引用，那么在Build时Unity会将分散的Sprite拼接在一起么？如果没有拼接，那SpritePacker是不是只会优化Draw Call，内存占用上和不用SpritePacker的分离图效果一样？3. 如果将Sprite打成AssetBundle，AssetBundle中的资源是分散的Sprite吗？如果不是，不同的AssetBundle中引用了两张Sprite，这两张Sprite恰好用SpritePacker拼在了一起，是不是就会存在两份拼接的Sprite集？4. 如果想使用NGUI Atlas Packer的工作流程，该如何去实现？简单来说，UGUI和 NGUI 类似，但是更加自动化。只需要通过设定 Packing Tag 即可指定哪些 Sprite 放在同一个 Atlas 下。可以通过 Edit -& Project Settings -& Editor -& Sprite Packer 的 Mode 来设置是否起效，何时起效（一种是进入 Play Mode 就生效，一种是 Build 时才生效）。所以只要不选 Disabled，Build 时就会把分散的 Sprite 拼起来。可以认为 Sprite 就是一个壳子，实际上本身不包含纹理资源，所以打包的时候会把Atlas 打进去。如果不用依赖打包，那么分开打两个 Sprite 就意味各自的AssetBundle 里都会有一个 Atlas。可以通过第三方工具（如 Texture Packer）制作 Atlas，导出 Sprite 信息（如，第 N 个 Sprite 的 Offset 和 Width，Height 等），然后在 Unity 中通过脚本将该 Atlas 转成一个 Multiple Mode 的 Sprite 纹理（即一张纹理上包含了多个 Sprite），同时禁用 Unity 的 Sprite Packer 即可。两种做法各有利弊，建议分析一下两种做法对于自身项目的合适程度来进行选择。Q5：在Unity 5.x版本下，我们在用UGUI的过程中发现它把图集都打进了包里，这样就不能自动更新了，请问图集怎么做自动更新呢？在Unity 5.x中UGUI使用的Atlas确实是不可见的，因此无法直接将其独立打包。但我们建议，可以把Packing Tag相同的源纹理文件，打到同一个AssetBundle中（设置一样的AssetBundle Name），从而避免Atlas的冗余。同时这样打包可以让依赖它的Canvas的打包更加自由，即不需要把依赖它的Canvas都打在一个AssetBundle中，在更新时直接更新Atlas所在的AssetBundle即可。Q6：ScrollRect在滚动的时候，会产生Canvas.SendwillRenderCanvases，有办法消除吗？ScrollRect在滚动时，会产生OnTransformChanged的开销，这是UI元素在移动时触发的，但通常这不会触发Canvas.SendWillRenderCanvases。如果观察到Canvas.SendWillRenderCanvases耗时较高，可以检查下ScrollRect所在的Canvas是否开启了Pixel Perfect的选项，该选项的开启会导致UI元素在发生位移时，其长宽会被进行微调（为了对其像素），而ScrollRect中通常有较多的UI元素，从而产生较高的Canvas.SendWillRenderCanvases开销。因此可以尝试关闭Pixel Perfect看效果是否可以接受，或者尝试在滚动过程中暂时关闭Pixel Perfect等方式来消除其开销。二、网格重建Q1：我在UGUI里更改了Image的Color属性，那么Canvas是否会重建？我只想借用它的Color做Animation里的变化量。如果修改的是Image组件上的Color属性，其原理是修改顶点色，因此是会引起网格的Rebuild的（即Canvas.BuildBatch操作，同时也会有Canvas.SendWillRenderCanvases的开销）。而通过修改顶点色来实现UI元素变色的好处在于，修改顶点色可以保证其材质不变，因此不会产生额外的Draw Call。Q2：Unity自带的UI Shader处理颜色时，改_Color属性不会触发顶点重建吗?在UI的默认Shader中存在一个Tint Color的变量，正常情况下，该值为常数(1,1,1)，且并不会被修改。如果是用脚本访问Image的Material，并修改其上的Tint Color属性时，对UI元素产生的网格信息并没有影响，因此就不会引起网格的Rebuild。但这样做因为修改了材质，所以会增加一个Draw Call。Q3：能否就UGUI Batch提出一些建议呢？是否有一些Batch的规则？在 UGUI 中，Batch是以Canvas为单位的，即在同一个Canvas下的UI元素最终都会被Batch到同一个Mesh中。而在Batch前，UGUI会根据这些UI元素的材质（通常就是Atlas）以及渲染顺序进行重排，在不改变渲染结果的前提下，尽可能将相同材质的UI元素合并在同一个SubMesh中，从而把DrawCall降到最低。而Batch的操作只会在UI元素发生变化时才进行，且合成的Mesh越大，操作的耗时也就越大。因此，我们建议尽可能把频繁变化（位置，颜色，长宽等）的UI元素从复杂的Canvas中分离出来，从而避免复杂的Canvas频繁重建。Q4：我用的是UGUI Canvas，Unity 5.3.4版本，请问如何查看每次Rebuild Batch影响的顶点数， Memory Profiler是个办法但是不好定位。由于Unity引擎在5.2后开始使用Shared UI Mesh来存储UI Mesh，所以确实很难查看每次Rebuild的UI顶点数。但是，研发团队可以尝试通过Frame Debugger工具对UI界面进行进一步的查看。Q5：动静分离或者多Canvas带来性能提升的理论基础是什么呢？如果静态部分不变动，整个Canvas就不刷新了？在UGUI中，网格的更新或重建（为了尽可能合并UI部分的DrawCall）是以Canvas为单位的，且只在其中的UI元素发生变动（位置、颜色等）时才会进行。因此，将动态UI元素与静态UI元素分离后，可以将动态UI元素的变化所引起的网格更新或重建所涉及到的范围变小，从而降低一定的开销。而静态UI元素所在的Canvas则不会出现网格更新和重建的开销。Q6：UWA建议“尽可能将静态UI元素和频繁变化的动态UI元素分开，存放于不同的Panel下。同时，对于不同频率的动态元素也建议存放于不同的Panel中。”那么请问，如果把特效放在Panel里面，需要把特效拆到动态的里面吗？通常特效是指粒子系统，而粒子系统的渲染和UI是独立的，仅能通过Render Order来改变两者的渲染顺序，而粒子系统的变化并不会引起UI部分的重建，因此特效的放置并没有特殊的要求。Q7：多人同屏的时候，人物移动会使得头顶上的名字Mesh重组，从而导致较为严重的卡顿，请问一下是否有优化的办法？如果是用UGUI开发的，当头顶文字数量较多时，确实很容易引起性能问题，可以考虑从以下几点入手进行优化：尽可能避免使用UI/Effect，特别是Outline，会使得文本的Mesh增加4倍，导致UI重建开销明显增大；拆分Canvas，将屏幕中所有的头顶文字进行分组，放在不同的Canvas下，一方面可以降低更新的频率（如果分组中没有文字移动，该组就不会重建），另一方面可以减小重建时涉及到的Mesh大小（重建是以Canvas为单位进行的）；降低移动中的文字的更新频率，可以考虑在文字移动的距离超过一个阈值时才真正进行位移，从而可以从概率上降低Canvas更新的频率。三、界面切换Q1：游戏中出现UI界面重叠，该怎么处理较好？比如当前有一个全屏显示的UI界面，点其中一个按钮会再起一个全屏界面，并把第一个UI界面盖住。我现在的做法是把被覆盖的界面 SetActive(False)，但发现后续 SetActive(True) 的时候会有 GC.Alloc 产生。这种情况下，希望既降低 Batches 又降低 GC Alloc 的话，有什么推荐的方案吗？可以尝试通过添加一个 Layer 如 OutUI， 且在 Camera 的 Culling Mask 中将其取消勾选（即不渲染该 Layer）。从而在 UI 界面切换时，直接通过修改 Canvas 的 Layer 来实现“隐藏”。但需要注意事件的屏蔽，禁用动态的 UI 元素等等。这种做法的优点在于切换时基本没有开销，也不会产生多余的 Draw Call，但缺点在于“隐藏时”依然还会有一定的持续开销（通常不太大），而其对应的 Mesh 也会始终存在于内存中（通常也不太大）。以上的方式可供参考，而性能影响依旧是需要视具体情况而定。Q2：通过移动位置来隐藏UI界面，会使得被隐藏的UIPanel继续执行更新（LateUpdate有持续开销），那么如果打开的界面比较多，CPU的持续开销是否就会超过一次SetActive所带来的开销？这确实是需要注意的，通过移动的方式“隐藏”的UI界面只适用于几个切换频率最高的界面，另外，如果“隐藏”的界面持续开销较高，可以考虑只把一部分Disable，这个可能就需要具体看界面的复杂度了。一般来说在没有UI元素变化的情况下，持续的 Update 开销是不太明显的。Q3：如图，我们在UI打开或者移动到某处的时候经常会观测到CPU上的冲激，经过进一步观察发现是因为Instantiate产生了大量的GC。想请问下Instantiate是否应该产生GC呢？我们能否通过资源制作上的调整来避免这样的GC呢？如下图，因为一次性产生若干MB的GC在直观感受上还是很可观的。准确的说这些 GC Alloc 并不是由Instantiate 直接引起的，而是因为被实例化出来的组件会进行 OnEnable 操作，而在 OnEnable 操作中产生了 GC，比如以上图中的函数为例：上图中的 Text.OnEnable 是在实例化一个 UI 界面时，UI 中的文本（即 Text 组件）进行了 OnEnable 操作，其中主要是初始化文本网格的信息（每个文字所在的网格顶点，UV，顶点色等等属性），而这些信息都是储存在数组中（即堆内存中），所以文本越多，堆内存开销越大。但这是不可避免的，只能尽量减少出现次数。因此，我们不建议通过 Instantiate/Destroy 来处理切换频繁的 UI 界面，而是通过 SetActive(true/false)，甚至是直接移动 UI 的方式，以避免反复地造成堆内存开销。四、加载相关Q1：UGUI的图集操作中我们有这么一个问题，加载完一张图集后，使用这个方式获取其中一张图的信息：assetBundle.Load (subFile, typeof (Sprite)) as S 这样会复制出一个新贴图（图集中的子图），不知道有什么办法可以不用复制新的子图，而是直接使用图集资源 。经过测试，这确实是 Unity 在 4.x 版本中的一个缺陷，理论上这张“新贴图（图集中的子图）”是不需要的，并不应该加载。 因此，我们建议通过以下方法来绕过该问题：在 assetBundle.Load (subFile, typeof (Sprite)) as S 之后，调用Texture2D t = assetBundle.Load (subFile, typeof (Texture2D)) as Texture2D;Resources.UnloadAsset(t);从而卸载这部分多余的内存。Q2：加载UI预制的时候，如果把特效放到预制里，会导致加载非常耗时。怎么优化这个加载时间呢？UI和特效（粒子系统）的加载开销在多数项目中都占据较高的CPU耗时。UI界面的实例化和加载耗时主要由以下几个方面构成：纹理资源加载耗时UI界面加载的主要耗时开销，因为在其资源加载过程中，时常伴有大量较大分辨率的Atlas纹理加载，我们在之前的有详细讲解。对此，我们建议研发团队在美术质量允许的情况下，尽可能对UI纹理进行简化，从而加快UI界面的加载效率。UI网格重建耗时UI界面在实例化或Active时，往往会造成Canvas（UGUI）或Panel（NGUI）中UIDrawCall的变化，进而触发网格重建操作。当Canvas或Panel中网格量较大时，其重建开销也会随之较大。UI相关构造函数和初始化操作开销这部分是指UI底层类在实例化时的ctor开销，以及OnEnable和OnDisable的自身开销。上述2和3主要为引擎或插件的自身逻辑开销，因此，我们应该尽可能避免或降低这两个操作的发生频率。我们的建议如下：在内存允许的情况下，对于UI界面进行缓存。尽可能减少UI界面相关资源的重复加载以及相关类的重复初始化；根据UI界面的使用频率，使用更为合适的切换方式。比如移进移出或使用Culling Layer来实现UI界面的切换效果等，从而降低UI界面的加载耗时，提升切换的流畅度。对于特效（特别是粒子特效）来说，我们暂时并没有发现将UI界面和特效耦合在一起，其加载耗时会大于二者分别加载的耗时总和。因此，我们仅从优化粒子系统加载效率的角度来回答这个问题。粒子系统的加载开销，就目前来看，主要和其本身组件的反序列化耗时和加载数量相关。对于反序列化耗时而言，这是Unity引擎负责粒子系统的自身加载开销，开发者可以控制的空间并不大。对于加载数量，则是开发者需要密切关注的，因为在我们目前看到的项目中，不少都存在大量的粒子系统加载，有些项目的数量甚至超过1000个，如下图所示。因此，建议研发团队密切关注自身项目中粒子系统的数量使用情况。一般来说，建议我们建议粒子系统使用数量的峰值控制在400以下。Q3：我有一个UI预设，它使用了一个图集， 我在打包的时候把图集和UI一起打成了AssetBundle。我在加载生成了GameObject后立刻卸载了AssetBundle对象， 但是当我后面再销毁GameObject的时候发现图集依然存在，这是什么情况呢？这是很可能出现的。unload(false)卸载AssetBundle并不会销毁其加载的资源 ，是必须调用 Resources.UnloadUnusedAssets才行。关于AssetBundle加载的详细解释可以参考我们之前的文章：五、字体相关Q1：我在用Profiler真机查看iPhone App时，发现第一次打开某些UI时，Font.CacheFontForText占用时间超过2s，这块主要是由什么影响的?若iPhone5在这个接口消耗2s多，是不是问题很大？这个消耗和已经生成的RenderTexture的大小有关吗？Font.CacheFontForText主要是指生成动态字体Font Texture的开销, 一次性打开UI界面中的文字越多，其开销越大。如果该项占用时间超过2s，那么确实是挺大的，这个消耗也与已经生成的Font Texture有关系。简单来说，它主要是看目前Font Texture中是否有地方可以容下接下来的文字，如果容不下才会进行一步扩大Font Texture，从而造成了性能开销。","updated":"T08:36:03.000Z","canComment":false,"commentPermission":"anyone","commentCount":1,"collapsedCount":0,"likeCount":22,"state":"published","isLiked":false,"slug":"","lastestTipjarors":[{"isFollowed":false,"name":"赵成顺","headline":"","avatarUrl":"/da8e974dc_s.jpg","isFollowing":false,"type":"people","slug":"zhao-cheng-shun","bio":"辣鸡Unity程序员","hash":"82f2da61ecfea180cb257","uid":932900,"isOrg":false,"description":"","profileUrl":"/people/zhao-cheng-shun","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false}],"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-35bd6dede3f0_r.png","links":{"comments":"/api/posts//comments"},"reviewers":[],"topics":[{"url":"/topic/","id":"","name":"Unity（游戏引擎）"},{"url":"/topic/","id":"","name":"性能优化"},{"url":"/topic/","id":"","name":"手机游戏开发"}],"adminClosedComment":false,"titleImageSize":{"width":799,"height":499},"href":"/api/posts/","excerptTitle":"","column":{"slug":"uwa4d","name":"UWA：简单优化、优化简单"},"tipjarState":"activated","tipjarTagLine":"真诚赞赏，手留余香","sourceUrl":"","pageCommentsCount":1,"tipjarorCount":1,"annotationAction":[],"hasPublishingDraft":false,"snapshotUrl":"","publishedTime":"T16:36:03+08:00","url":"/p/","lastestLikers":[{"bio":"软件工程师","isFollowing":false,"hash":"17c9abdacfbbd0e4b424ae2","uid":40,"isOrg":false,"slug":"zeng-zhi-an","isFollowed":false,"description":"","name":"godzza","profileUrl":"/people/zeng-zhi-an","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"flash，as3 发烧友，游戏研发码农。这就是我混迹新浪微博最实在的标签，也是我一直能坚持潜水的原动力。","isFollowing":false,"hash":"ecae720ac5dca","uid":48,"isOrg":false,"slug":"xinzhe-sun","isFollowed":false,"description":"","name":"xinzhe sun","profileUrl":"/people/xinzhe-sun","avatar":{"id":"efff4a43d","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"程序员","isFollowing":false,"hash":"7cf3249e602","uid":48,"isOrg":false,"slug":"m-hello","isFollowed":false,"description":"","name":"M Hello","profileUrl":"/people/m-hello","avatar":{"id":"babe6acc648b4d65b8b97b","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"程序员","isFollowing":false,"hash":"290e4d9e0ca313ee9d0abef","uid":641200,"isOrg":false,"slug":"huang-zhi-min-93-23","isFollowed":false,"description":"","name":"iscune","profileUrl":"/people/huang-zhi-min-93-23","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":null,"isFollowing":false,"hash":"062d533cb609adc49f2bd1c5","uid":16,"isOrg":false,"slug":"ismyhouse","isFollowed":false,"description":"知乎，与世界分享你刚编的故事","name":"为何执着","profileUrl":"/people/ismyhouse","avatar":{"id":"5ca9ccf29","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false}],"summary":"原文链接：UI制作一向是项目开发中的瓶颈所在。如何在实现绚丽效果的同时还能保持优秀的性能以此带来流畅的操作体验？也许看似UI图集、UI按钮等背后都隐藏着错综复杂的逻辑设定，每个UI元素的属性细节都需要开发者细细揣摩。UI优化，知…","reviewingCommentsCount":0,"meta":{"previous":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-233b83efbe6e5ed7db642_r.png","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"Unity（游戏引擎）"},{"url":"/topic/","id":"","name":"性能优化"},{"url":"/topic/","id":"","name":"手机游戏开发"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"招网站前端、后端、引擎功能开发实习生。有意者私信我：）","isFollowing":false,"hash":"7fdb9e2544cdf169ab0bf0b1bd9e04ba","uid":498100,"isOrg":false,"slug":"zhang-xin-81-92-50","isFollowed":false,"description":"用实力让情怀落地。","name":"张鑫","profileUrl":"/people/zhang-xin-81-92-50","avatar":{"id":"v2-4e579678fdf30dc1f03b1fd9fdd412a8","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"column":{"slug":"uwa4d","name":"UWA：简单优化、优化简单"},"content":"UWA优化日—深圳站将于12月10日在深圳举行。作为UWA技术活动的第十站，我们将为大家带来最受欢迎的两大技术议题：游戏和VR应用性能诊断与分析和UI 开发和优化技巧，针对实际开发中遇到的疑难杂症，和大家分享一些优秀手游的性能数据和优化方法。同时，我们也邀请了来自深圳游戏科学的客户端主程招文勇，他将为我们带来实战分享—在Unity上如何高效使用Lua。干货云集，实力撩你！活动议程13:30-15:00 游戏和VR应用性能诊断与分析15:00-15:15 答疑15:15-15:45 实战分享—在Unity上如何高效使用Lua15:45-16:00 答疑16:00-17:00 UI开发和性能优化技巧活动信息主办方： 侑虎科技合作媒体：GameRes 游资网时间： 12月10日（周六） 下午1:30地点： 深圳市南山区科苑路9号讯美科技广场3号楼16楼阶梯教室（最近地铁站：1号线 高新园站）报名： 请关注下图本微信号，回复“11月26日技术开放日+姓名+联络方式”，审核通过后您将收到我们的活动邀请确认。 (二维码自动识别)由于场地有限，报名请从速。同时，我们仍将陆续开展系列技术讲座，未能赶上本次活动的开发者，敬请关注本公众号活动信息。讲师介绍张鑫：毕业于浙江大学CAD&CG国家重点实验室，理学博士学位，主要研究方向为计算机图形学、数字几何处理等。2012年10月加入Unity大中华区，担任技术支持经理，主要从事与Unity相关的技术研发、支持和培训等工作，有着丰富全面的Unity开发、使用经验。2015年8月，创办侑虎科技（上海）有限公司，着力为游戏及虚拟现实开发者提供深入的技术咨询平台。张强： 毕业于华东师范大学，软件学院工学硕士，研究方向为计算机图形学、基于物理的流体模拟。2012年就职于腾讯（上海）公司，担任客户端开发工程师，参与一款客户端3D网络游戏的开发。2013年10月加入Unity大中华区，担任技术支持工程师，主要从事与Unity引擎相关的技术研发、支持和培训等工作，具有丰富的理论与实战经验。2015年9月加入侑虎科技（上海）有限公司，成为技术核心人员之一。招文勇：深圳游戏科学客户端主程，负责网易代理手游《百将行》的客户端开发，曾在腾讯公司任职，参与《斗战神》以及腾讯自研引擎AGE的开发。对图像渲染、引擎性能优化、人工智能等方面有浓厚兴趣。","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T15:11:55+08:00","url":"/p/","title":"报名| UWA 优化日深圳站即将起航！","summary":"UWA优化日—深圳站将于12月10日在深圳举行。作为UWA技术活动的第十站，我们将为大家带来最受欢迎的两大技术议题：游戏和VR应用性能诊断与分析和UI 开发和优化技巧，针对实际开发中遇到的疑难杂症，和大家分享一些优秀手游的性能数据和优化方法。同时，我们…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":2,"likesCount":2},"next":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-a0e84aa99e3ae89ad8328df09bab9ef2_r.png","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"Unity（游戏引擎）"},{"url":"/topic/","id":"","name":"性能优化"},{"url":"/topic/","id":"","name":"手机游戏开发"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"招网站前端、后端、引擎功能开发实习生。有意者私信我：）","isFollowing":false,"hash":"7fdb9e2544cdf169ab0bf0b1bd9e04ba","uid":498100,"isOrg":false,"slug":"zhang-xin-81-92-50","isFollowed":false,"description":"用实力让情怀落地。","name":"张鑫","profileUrl":"/people/zhang-xin-81-92-50","avatar":{"id":"v2-4e579678fdf30dc1f03b1fd9fdd412a8","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},"column":{"slug":"uwa4d","name":"UWA：简单优化、优化简单"},"content":"原文链接：上期我们聊到了UGUI的性能优化思路，本期我们来探秘NGUI。可能不少开发朋友会有疑惑，到底是NGUI还是UGUI的性能更好？小编在此想先表达下我的个人观点：从理论上来说，没有什么依据可以证明UGUI的性能一定比NGUI更优异。在UWA的测评报告中，对于NGUI来说，主要统计UIPanel.LateUpdate\\UICamera.Update\\UIRect.Update和UIRect.Start；对于UGUI来说，主要统计Canvas.BuildBatch和Canvas.SendwillRenderCanvases。相对于NGUI来看，UGUI确实在以下方面存在提升性能的可能：首先，5.2版本之后，Unity逐渐将一部分UGUI的计算放到子线程去做，以此来缓解主线程的压力；其次，UGUI的UIMesh生成是通过底层C++代码实现的，而NGUI只能通过在上层不断创建vertex list来进行，这样在堆内存的管理上，UGUI确实要好很多，带来的隐性收益就是GC触发次数会少很多。但不能表示NGUI做出来的UI性能就一定比UGUI差，这个说法是不存在的。而且，在我们深度优化的过程中发现，NGUI同样可以达到很高的性能水准。所以，NGUI和UGUI都是很好的工具，只要把它们的特性掌握好，都可以做成性能很棒的UI界面。关键字界面制作界面切换网格重建UICamera.UpdateDraw Call加载字体一、界面制作Q1：我用的是NGUI，本来已经打包图集了，输出时候是不是就不用理会那些原始2D Sprite图 ？粒子贴图需要Packing Tag吗？在NGUI中使用Atlas后，原纹理是不需要进行打包或进行其他特殊处理的，因为理论上这些资源在运行时已不再需要。粒子系统所使用的纹理并不是Sprite类型的，因此不需要设置Packing Tag。Q2：NGUI变形，如下图走样了，请问是不是图片压缩导致的？当UI纹理在设备上的显示分辨率低于原始分辨率时，会因为出现aliasing现象，导致UI局部变形。通常对于粗线条、块状的UI图素，变形通常是不明显的，但对于细线条的UI图素，则可能非常明显。通常该问题可以考虑三种方式来改善：在NGUI中将UIRoot的Scaling Style设置为Flexible，这种方式的好处在于UI纹理不会因为设备分辨率的限制而降低，而缺点在于相同的UI纹理在高分辨率设备上显得比较小，而在低分辨率设备上显得比较大，从而提高了UI布局的复杂度；将UI纹理的显示分辨率（Sprite的size属性）设定为高于原始分辨率，其缺点在于高分辨率设备上可能会产生模糊，但大多数情况下“模糊”相比于“走样”更不易察觉；开启UI纹理的Mipmap，从而在低分辨率设备上自动切换到低Level，以“模糊”替换“走样”，但缺点在于增加了纹理的大小，因此只适用于出现了明显变形的少量UI。Q3：能否在NGUI多分辨率适应方面提供一些解决方案或者思路？多分辨率适应涉及到以下几个方面：布局。通常可以通过 NGUI 中的 Anchor 组件来实现，能够保证 UI 到屏幕上指定锚点的距离；UI 背景图比例。通常我们建议将背景图的长宽比放大，以适配不同长宽比的屏幕，但要注意两边需要留空，或者保留可被裁掉的元素；UI 的整体缩放。可以通过 UIRoot 组件的 Scaling Style 来统一配置。需要提醒的是，不同类型的游戏对布局的需求通常也不同，因此还是需要结合实际开发情况来做调整。Q4：我发现ScrollRect里有大量元素，在拖动的时候触发了很多onTransformChanged，能否提供一些优化思路？OnTransformChanged是UI元素在移动时触发的，所以该回调的开销是不可避免的，但一般来说该回调本身耗时并不会太高。因此，当OnTransformChanged耗时很高时，有三种方式进行优化：可以先查看是否有哪个或者哪些子函数占比较高，比如，当OnTransformChanged触发了OnDimensionChanged时，耗时会明显升高，而OnDimensionChanged则是在开启了Canvas的Pixel Perfect时才会出现的。那么就可以考虑是否在拖动时暂时关闭Pixel Perfect。如果主要是其自身开销造成，那么很可能就是因为移动的UI元素数量太大引起的。那么就可以从策略上减少UI元素数量，比如，做成拖动翻页的界面，一次性只需移动两页的UI元素等。如果使用的是Mask组件，那么可以尝试改为Rect Mask 2D组件，同样会有性能上的提升。Q5：我看到UICamera.Update()的GC调用特别高，只要我一移动就会产生2.8K的GC，看起来是NGUITools.FindInParents这个方法导致的，有没有什么可以优化的方法呢？在 Editor 下，当调用GetComponent() 且 T组件并不在当前的GameObject 上时，确实会出现GC Alloc，但这在发布后是不会出现的，因此建议在真机上做一个验证。这是因为在Editor下，Unity的MissingComponentException实现所致，在出现以上情况时，Unity 并不是直接返回一个 NULL，而是返回一个代理 Object用来储存一些相关信息，在后续被访问时可以给出更详细的报错信息。二、网格重建Q1：我用NGUI开发，因为角色名字导致重建，使得UIPanel.LateUpdate的CPU占用很高。如果将它们分离到多个UIPanel里，是否这个开销会相对小一些？将较多的动态UI元素分组放在不同的UIPanel中确实是UWA比较推荐的方式，一方面可以降低重建的概率，某些分组中可能没有UI元素发生变化，从而不会进行重建；另一方面可以降低重建的开销。通过分组，可以将每个UIPanel所产生的Mesh控制在较小的范围内，从而控制其重建的开销（通常重建的开销会因Mesh的增大而明显升高，且不是线性的关系）。虽然这种做法会产生额外的DrawCall，但DrawCall的开销与网格重建相比通常都非常小。Q2：我的UWA报告中看到几乎每次切换场景都会有UIPanel.LateUpdate()这个函数的堆内存开销，请问说明了什么问题，我是否还能优化？UIPanel.LateUpdate持续分配较大量的堆内存，说明UI界面在制作上存在以下问题：Panel中Widgets数量过多，且存在频繁的变动，导致UIPanel需要进行大量的网格重建；动静态UI元素没有分离；建议研发团队对UI界面的制作进行进一步检测，尽可能将静态UI元素和动态UI元素分开，存放于不同的Panel下。同时，对于不同频率的动态元素也建议存放于不同的Panel中。Q3：UWA建议“尽可能将静态UI元素和频繁变化的动态UI元素分开，存放于不同的Panel下。同时，对于不同频率的动态元素也建议存放于不同的Panel中。”那么请问，如果把特效放在Panel里面，需要把特效拆到动态的里面吗？通常特效是指粒子系统，而粒子系统的渲染和UI是独立的，仅能通过Render Order来改变两者的渲染顺序，而粒子系统的变化并不会引起UI部分的重建，因此特效的放置并没有特殊的要求。三、界面切换Q1：请问这个GameObject.Active的开销怎么这么高？Activate会产生堆内存分配吗？这个是PC上的鼠标交互事件造成的，是UI界面的Active操作，所以触发了各种相关的OnEnable调用，研发团队可以在Profiler中进行进一步定位，查看根源。一般来说，GameObject的Activate操作本身是不会产生堆内存分配，但它引发的各种底层类的OnEnable会产生堆内存的分配。开发团队可以参考这里加深理解：Q2：我在Profiler中看到GameObject.Deactivate耗时较大，请问该如何优化？实际上GameObject.Activate/Deactivate本身通常不会产生很高的开销，主要都是由其上或其子节点上的组件的OnEnable/OnDisable操作引起，比如UI相关的组件在OnEnable和OnDisable中都会有较多的操作，所以较复杂的UI界面的GameObject.Activate/Deactivate会有很高的开销。因此，针对这一问题，如果是由自定义的脚本造成，那么就需要考虑优化OnEnable/OnDisable的逻辑；如果是UI，那么可以对频繁切换激活状态的UI采用平移出屏幕、修改Culling Layer等方式来替换。Q3：游戏中出现UI界面重叠，该怎么处理较好？比如当前有一个全屏显示的UI界面，点其中一个按钮会再起一个全屏界面，并把第一个UI界面盖住。我现在的做法是把被覆盖的界面 SetActive(False)，但发现后续 SetActive(True) 的时候会有 GC.Alloc 产生。这种情况下，希望既降低 Batches 又降低 GC Alloc 的话，有什么推荐的方案吗？可以尝试通过添加一个 Layer 如 OutUI， 且在 Camera 的 Culling Mask 中将其取消勾选（即不渲染该 Layer）。从而在 UI 界面切换时，直接通过修改 Canvas 的 Layer 来实现“隐藏”。但需要注意事件的屏蔽，禁用动态的 UI 元素等等。这种做法的优点在于切换时基本没有开销，也不会产生多余的 Draw Call，但缺点在于“隐藏时”依然还会有一定的持续开销（通常不太大），而其对应的 Mesh 也会始终存在于内存中（通常也不太大）。以上的方式可供参考，而性能影响依旧是需要视具体情况而定。Q4：通过移动位置来隐藏UI界面，会使得被隐藏的UIPanel继续执行更新（LateUpdate有持续开销），那么如果打开的界面比较多，CPU的持续开销是否就会超过一次SetActive所带来的开销？这确实是需要注意的，通过移动的方式“隐藏”的UI界面只适用于几个切换频率最高的界面，另外，如果“隐藏”的界面持续开销较高，可以考虑只把一部分Disable，这个可能就需要具体看界面的复杂度了。一般来说在没有UI元素变化的情况下，持续的 Update 开销是不太明显的。Q5：如图，我们在UI打开或者移动到某处的时候经常会观测到CPU上的冲激，经过进一步观察发现是因为Instantiate产生了大量的GC。想请问下Instantiate是否应该产生GC呢？我们能否通过资源制作上的调整来避免这样的GC呢？如下图，因为一次性产生若干MB的GC在直观感受上还是很可观的。准确的说这些 GC Alloc 并不是由Instantiate 直接引起的，而是因为被实例化出来的组件会进行 OnEnable 操作，而在 OnEnable 操作中产生了 GC，比如以上图中的函数为例：上图中的 Text.OnEnable 是在实例化一个 UI 界面时，UI 中的文本（即 Text 组件）进行了 OnEnable 操作，其中主要是初始化文本网格的信息（每个文字所在的网格顶点，UV，顶点色等等属性），而这些信息都是储存在数组中（即堆内存中），所以文本越多，堆内存开销越大。但这是不可避免的，只能尽量减少出现次数。因此，我们不建议通过 Instantiate/Destroy 来处理切换频繁的 UI 界面，而是通过 SetActive(true/false)，甚至是直接移动 UI 的方式，以避免反复地造成堆内存开销。四、字体Q1：对NGUI字体错乱有什么好的解决方案吗？有这么几种可能：一次展开文字太多了。这种情况在部分高通机型和Unity早期版本上都经常出现，现在也偶尔有，究其原理是FontTexture的扩容操作做得不够快或者收到了硬件驱动的限制。一般来说有两种方法可以解决：（1）减少面板中的字体内容；（2）一开始就用超大量的字体去扩容，将动态字体的FontTexture扩大到足够大；文字渲染与开发团队编写的多线程渲染发生了冲突。这种情况也常有发生，特别是通过GL.IssuePluginEvent方式来开启多线程渲染的项目，就会容易出现问题。就我们的优化经验来看，第一种情况发生的可能性比较大。Q2：我在用Profiler真机查看iPhone App时，发现第一次打开某些UI时，Font.CacheFontForText占用时间超过2s，这块主要是由什么影响的?若iPhone5在这个接口消耗2s多，是不是问题很大？这个消耗和已经生成的RenderTexture的大小有关吗？Font.CacheFontForText主要是指生成动态字体Font Texture的开销, 一次性打开UI界面中的文字越多，其开销越大。如果该项占用时间超过2s，那么确实是挺大的，这个消耗也与已经生成的Font Texture有关系。简单来说，它主要是看目前Font Texture中是否有地方可以容下接下来的文字，如果容不下才会进行一步扩大Font Texture，从而造成了性能开销。五、加载相关Q1：加载UI预制的时候，如果把特效放到预制里，会导致加载非常耗时。怎么优化这个加载时间呢？UI和特效（粒子系统）的加载开销在多数项目中都占据较高的CPU耗时。UI界面的实例化和加载耗时主要由以下几个方面构成：1. 纹理资源加载耗时UI界面加载的主要耗时开销，因为在其资源加载过程中，时常伴有大量较大分辨率的Atlas纹理加载，我们在之前的有详细讲解。对此，我们建议研发团队在美术质量允许的情况下，尽可能对UI纹理进行简化，从而加快UI界面的加载效率。2. UI网格重建耗时UI界面在实例化或Active时，往往会造成Canvas（UGUI）或Panel（NGUI）中UIDrawCall的变化，进而触发网格重建操作。当Canvas或Panel中网格量较大时，其重建开销也会随之较大。3. UI相关构造函数和初始化操作开销这部分是指UI底层类在实例化时的ctor开销，以及OnEnable和OnDisable的自身开销。上述2和3主要为引擎或插件的自身逻辑开销，因此，我们应该尽可能避免或降低这两个操作的发生频率。我们的建议如下：在内存允许的情况下，对于UI界面进行缓存。尽可能减少UI界面相关资源的重复加载以及相关类的重复初始化；根据UI界面的使用频率，使用更为合适的切换方式。比如移进移出或使用Culling Layer来实现UI界面的切换效果等，从而降低UI界面的加载耗时，提升切换的流畅度。对于特效（特别是粒子特效）来说，我们暂时并没有发现将UI界面和特效耦合在一起，其加载耗时会大于二者分别加载的耗时总和。因此，我们仅从优化粒子系统加载效率的角度来回答这个问题。粒子系统的加载开销，就目前来看，主要和其本身组件的反序列化耗时和加载数量相关。对于反序列化耗时而言，这是Unity引擎负责粒子系统的自身加载开销，开发者可以控制的空间并不大。对于加载数量，则是开发者需要密切关注的，因为在我们目前看到的项目中，不少都存在大量的粒子系统加载，有些项目的数量甚至超过1000个，如下图所示。因此，建议研发团队密切关注自身项目中粒子系统的数量使用情况。一般来说，建议我们建议粒子系统使用数量的峰值控制在400以下。Q2：我有一个UI预设，它使用了一个图集， 我在打包的时候把图集和UI一起打成了AssetBundle。我在加载生成了GameObject后立刻卸载了AssetBundle对象， 但是当我后面再销毁GameObject的时候发现图集依然存在，这是什么情况呢？这是很可能出现的。unload(false)卸载AssetBundle并不会销毁其加载的资源 ，是必须调用 Resources.UnloadUnusedAssets才行。关于AssetBundle加载的详细解释可以参考我们之前的文章：","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T10:56:08+08:00","url":"/p/","title":"关于Unity中的NGUI优化，你可能遇到这些问题","summary":"原文链接：上期我们聊到了UGUI的性能优化思路，本期我们来探秘NGUI。可能不少开发朋友会有疑惑，到底是NGUI还是UGUI的性能更好？小编在此想先表达下我的个人观点：从理论上来说，没有什么依据可以证明UGUI…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":2,"likesCount":19}},"annotationDetail":null,"commentsCount":1,"likesCount":22,"FULLINFO":true}},"User":{"zhang-xin-81-92-50":{"isFollowed":false,"name":"张鑫","headline":"用实力让情怀落地。","avatarUrl":"/v2-4e579678fdf30dc1f03b1fd9fdd412a8_s.jpg","isFollowing":false,"type":"people","slug":"zhang-xin-81-92-50","bio":"招网站前端、后端、引擎功能开发实习生。有意者私信我：）","hash":"7fdb9e2544cdf169ab0bf0b1bd9e04ba","uid":498100,"isOrg":false,"description":"用实力让情怀落地。","profileUrl":"/people/zhang-xin-81-92-50","avatar":{"id":"v2-4e579678fdf30dc1f03b1fd9fdd412a8","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false,"badge":{"identity":null,"bestAnswerer":null}}},"Comment":{},"favlists":{}},"me":{},"global":{},"columns":{"next":{},"uwa4d":{"following":false,"canManage":false,"href":"/api/columns/uwa4d","name":"UWA：简单优化、优化简单","creator":{"slug":"zhang-xin-81-92-50"},"url":"/uwa4d","slug":"uwa4d","avatar":{"id":"4fecf539d0fcfce34c4b","template":"/{id}_{size}.jpeg"}}},"columnPosts":{},"columnSettings":{"colomnAuthor":[],"uploadAvatarDetails":"","contributeRequests":[],"contributeRequestsTotalCount":0,"inviteAuthor":""},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldAddVideo":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"drafts":{"draftsList":[],"next":{}},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false},"sys":{}}