一、序

Hi，大家好，我是承香墨影！

HTTP 协议在网络知识中占据了重要的地位，HTTP 协议最基础的就是请求和响应的报文，而报文又是由报文头（Header）和实体组成。大多数 HTTP
协议的使用方式，都是依赖设置不同的 HTTP 请求/响应 的 Header 来实现的。

本系列《实用 HTTP》就抛开常规的 Header 讲解式的表述方式，从实际问题出发，来分析这些 HTTP
协议的使用方式，到底是为了解决什么问题？同时讲解它是如何设计的和它实现原理。

HTTP
协议是一种无状态的“松散协议”，它不会记录不同请求的状态，并且因为它本身包含了两端（客户端和服务端），根据请求和响应来区分，它大部分的内容都只是一个建议，其实双边是可以不遵守此建议的。

“这里写了建议零售价 2 元…”

“哦，不接受建议！”

文本是本系列的第五篇，前四篇传送门：

• HTTP 的缓存机制

• HTTP 内容实体编码压缩机制

• HTTP 传输编码压缩机制

• HTTP 的 Cookie 细节

今天再来介绍一下 HTTP 的范围请求。范围请求主要是针对较大的文件的请求或者上传，可以仅操作它的某一段。

一个比较常见的场景，就是断点续传/下载，在网络情况不好的时候，可以在断开连接以后，仅继续获取部分内容。例如在网上下载软件，已经下载了 95%
了，此时网络断了，如果不支持范围请求，那就只有被迫重头开始下载。但是如果有范围请求的加持，就只需要下载最后 5% 的资源，避免重新下载。

另一个场景就是多线程下载，对大型文件，开启多个线程，每个线程下载其中的某一段，最后下载完成之后，在本地拼接成一个完整的文件，可以更有效的利用资源。

这算是两个比较常见的场景，接下来我们来看看范围请求的 HTTP 协议支持的技术细节。

二、HTTP 的范围请求

2.1 是否支持范围请求

HTTP 本身是一种无状态的“松散”协议，而在经历了很多版本的迭代之后，只在 HTTP/1.1（RFC2616）
之上，才支持范围请求。所以如果客户端或者服务端两端的某一端低于 HTTP/1.1，我们就不应该使用范围请求的功能。

而在 HTTP/1.1 中，很明确的声明了一个响应头部 Access-Ranges 来标记是否支持范围请求，它只有一个可选参数 bytes。

例如这里给了一个 MP4 的响应头，可以看到它是有 Accept-Ranges:bytes 来标记的，有此标记标识当前资源支持范围请求。

2.2 使用范围请求

如果已经确定双端都支持范围请求，我们就可以在请求资源的时候使用它。

所有的文件最终都是存储在磁盘或者内存中的字节，对于待操作的文件可以将其以字节为单位分割。这样只需要 HTTP 支持请求该文件从 n 到 n+x
这个范围内的资源，就可以实现范围请求了。

HTTP/1.1 中定义了一个 Ranges 的请求头，来指定请求实体的范围。它的范围取值是在 0 - Content-Length 之间，使用 -
分割。。

例如已经下载了 1000 bytes 的资源内容，想接着继续下载之后的资源内容，只要在 HTTP 请求头部，增加 Ranges:bytes=1000-
就可以了。

Range 还有几种不同的方式来限定范围，可以根据需要灵活定制：

1. 500-1000：指定开始和结束的范围，一般用于多线程下载。

2. 500- ：指定开始区间，一直传递到结束。这个就比较适用于断点续传、或者在线播放等等。

3. -500：无开始区间，只意思是需要最后 500 bytes 的内容实体。

4. 100-300,1000-3000：指定多个范围，这种方式使用的场景很少，了解一下就好了。

HTTP 协议是一种双边协商的协议，既然请求头部已经确定是使用 Ranges 了，还有响应头部中，也需要使用 Content-Ragne
这个响应头来标记响应的实体内容范围。

Content-Range 的格式也很清晰，首先标记它的单位是 bytes 然后标记当前传递的内容实体范围和总长度。

Content-Range: bytes 100-999/1000

在这个例子中，会传递 100 ~ 999 范围的内容实体，而该资源文件的总大小是 1000 bytes。并且此时的 HTTP 响应状态码为 206
Partial Content 。

HTTP 206 Partial Content 成功状态响应代码表示请求已成功，并且主体包含所请求的数据区间，该数据区间是在请求的 Range
首部指定的。

有关 206 状态码的解释可以参考：https://developer.mozilla.org/zh-
CN/docs/Web/HTTP/Status/206

所以一个正常的流程应该如下图所示：

注意这里的每个 HTTP 事务中的响应头里，都是会包含 Content-Length
的，只是它包含的是当前范围请求响应的内容实体长度，而非此资源完整的长度。

到这里基本上算是讲清楚 HTTP 范围请求的正确流程了，接下来看看一些特殊的情况。

2.3 资源变化

当我们在一些下载工具中，下载大尺寸资源的时候，偶尔中间暂停过再重新下载，可能会遇见它又重头开始下载的情况。

这看似是 HTTP 的范围请求失效了，但是实际上并不一定如此，很可能是因为请求的资源，在请求的这个过程中，发生了改变。

假如你下载的过程中，下载的源资源文件发生了变化，但是 URL
没有改变，此时文件长度可能已经变化了（这是非常容易发现的），极端情况下就算没有长度没有变化，你再继续下载，很可能最终下载完成之后，无法将下载的内容拼接成我们需要的文件。

如果我们需要从服务器上下载某个资源，一定要预防此资源可能发生的变动。在之前讲 HTTP
缓存的时候讲到，在
HTTP 协议中，可以通过 ETag 或者 Last-Modified 来标识当前资源是否变化。

• ETag：当前文件的一个验证令牌指纹，用于标识文件的唯一性。

• Last-Modified：标记当前文件最后被修改的时间。

在 HTTP 的范围请求中，也可以使用这两个字段来区分分段请求的资源，是否有修改过，只需要在请求头中，将它放在 If-Range 这个请求报文头中即可
。If-Range 使用 ETag 或者 Last-Modified 两个参数任意一个，原样填入即可。

此时，如果两次操作的都是同一个资源文件，就会继续返回 206 状态码，开始后续的操作，反之则会返回 200 状态码，表示文件发生改变，要从头下载。

需要注意的是 If-Range 需要和 Range 配合起来使用，否则会被服务端忽略。

再额外提一点，如果客户端请求报文头中，对 Range 填入的范围错误，会返回 416 状态码。

HTTP 416 Range Not Satisfiable
错误状态码意味着服务器无法处理所请求的数据区间。最常见的情况是所请求的数据区间不在文件范围之内，也就是说，Range
首部的值，虽然从语法上来说是没问题的，但是从语义上来说却没有意义。

有关 416 状态码，可以参考：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/416

三、范围请求的例子

3.1 用 Chrome 播放一个适配

前面介绍的概念，很多技术点其实描述的都是某一个请求片段，接下来我们以一个实际的例子来说明范围请求的具体细节。

在这个例子中，我找了一个视频的播放地址，直接在 Chrome 中进行播放。正常播放之后，再随手拖动视频进度，之后无操作让其自动播放一段时间，来看看 HTTP
的事务报文。

简单描述一下情况，自然播放的时候，会首先想资源的 URL 发送请求，返回 200 的响应码，可以判断出当前资源支持 Accept-
Ranges，接下来会去使用 Range 发送范围请求，得到的响应码就是
206，并返回对应范围的实体内容。而在每次拖动进度的时候，都会去重新发送一个范围请求，依照拖动的进度来计算请求范围。此处不存在资源被修改的情况，所以不会出现重新请求下载的情况。

就不一个一个对 HTTP 事务截图了，大概抽象了一下流程，如下图所示：

可以看到，一次资源下载其实包含了很多次的请求过程，我们需要站在全局的角度来看到它。

四、范围请求小结

到这里我们就已经把 HTTP 范围请求的整个流程都说明清楚了。

再重新整理一下关键点：

1. HTTP 范围请求，需要 HTTP/1.1 及之上支持，如果双端某一段低于此版本，则认为不支持。

2. 通过响应头中的 Accept-Ranges 来确定是否支持范围请求。

3. 通过在请求头中添加 Range 这个请求头，来指定请求的内容实体的字节范围。

4. 在响应头中，通过 Content-Range 来标识当前返回的内容实体范围，并使用 Content-Length 来标识当前返回的内容实体范围长度。

5. 在请求过程中，可以通过 If-Range 来区分资源文件是否变动，它的值来自 ETag 或者 Last-Modifled。如果资源文件有改动，会重新走下载流程。

再配一张流程图，就更清晰了。

到此 HTTP 范围请求的所有关键技术点，就已经讲解清楚。范围请求被用在诸如：断点续传、多线程下载等场景下，大部分 CDN
上的资源都是支持范围请求的，具体你能在什么场景下应用，就看你的想象力了。

Hi，大家好，我是承香墨影！

HTTP 协议在网络知识中占据了重要的地位，HTTP 协议最基础的就是请求和响应的报文，而报文又是由报文头（Header）和实体组成。大多数 HTTP
协议的使用方式，都是依赖设置不同的 HTTP 请求/响应 的 Header 来实现的。

本系列《实用 HTTP》就抛开常规的 Header 讲解式的表述方式，从实际问题出发，来分析这些 HTTP
协议的使用方式，到底是为了解决什么问题？同时讲解它是如何设计的和它实现原理。

HTTP
协议是一种无状态的“松散协议”，它不会记录不同请求的状态，并且因为它本身包含了两端（客户端和服务端），根据请求和响应来区分，它大部分的内容都只是一个建议，其实双边是可以不遵守此建议的。

“这里写了建议零售价 2 元…”

“哦，不接受建议！”

前两篇文章中，我们分别聊了 HTTP
的缓存机制
和 HTTP
内容实体编码压缩机制
，在说到实体编码压缩的时候，还提到了一个传输编码，让我们优化传输的方式。实体编码和传输编码二者是相辅相成的，一般我们会配合使用。

本文就来聊聊 HTTP 的传输编码机制。

二、HTTP 的传输编码

2.1 什么是传输编码?

传输编码在 HTTP 的报文头中，使用 Transfer-Encoding 首部进行标记，它就是指明当前使用的传输编码。

Transfer-Encoding
会改变报文的格式和传输的方式，使用它不但不会减少内容传输的大小，甚至还有可能会使传输变大，看似是一个不环保的做法，但是其实是为了解决一些特殊问题。

简单来说，传输编码必须配合持久连接去使用，为了在一个持久连接中，将数据分块传输，并标记传输结束而设计的，后面会详细讲解。

在早年间的设计里，和内容编码使用 Accept-Encoding 来标记客户端接收的压缩编码类型一样，传输编码还需要配合 TE
这个请求报文头来使用，用于指定支持的传输编码。但是在最新的 HTTP/1.1
协议规范中，只定义了一种传输编码：分块编码（chunked），所以并不需要再依赖 TE 这个头部。

这些细节，后面都会讲到。既然传输编码和持久连接是息息相关的，那我们就先来了解一下什么是持久连接。

2.2 持久连接（Persistent Connection）

持久连接通俗来讲，就是长连接，英文叫 Persistent Connection，其实按字面意思理解就好了。

在早期的 HTTP
协议中，传输数据的顺序大致分为发起请求、建立连接、传输数据、关闭连接等步骤，而持久连接，就是去掉关闭连接这个步骤，让客户端和服务端可以继续通过此次连接传输内容。

这其实也是为了提高传输效率，我们知道 HTTP 协议是建立在 TCP 协议之上的，自然有 TCP
一样的三次握手、慢启动等特性，这样每一次连接其实都是一次宝贵的资源。为了尽可能的提高 HTTP 的性能，使用持久连接就显得很重要了。为此在 HTTP
协议中，就引入了相关的机制。

在早期的 HTTP/1.0 协议中并没有持久连接，持久连接的概念是在后期才引入的，当时是通过 Connection:Keep-Alive
这个头部来标记实现，用于通知客户端或服务端相对的另一端，在发送完数据之后，不要断开 TCP 连接，之后还需要再次使用。

而在 HTTP/1.1 协议中，发现持久连接的重要性了，它规定所有的连接必须都是持久的，除非显式的在报文头里，通过 Connection:close
这个首部，指定在传输结束之后会关闭此连接。

实际上在 HTTP/1.1 中Connect 这个头部已经没有 Keep-Alive 这个取值了，由于历史原因，很多客户端和服务端，依然保留了这个报文头。

长连接带来了另外一个问题，如何判定当前数据发送完成。

2.3 判断传输完成

在早期不支持持久连接的时候，其实是可以依靠连接断开来判定当前传输已经结束，大部分浏览器也是这么干的，但这并不是规范的操作。应该使用 Content-
Length 这个头部，来指定当前传输的实体内容长度。

下面举个例子，在保持持久连接的情况下，依赖 Content-Length 来确定数据发送完毕。

Content-Length 在这里起到了一个响应实体已经发送结束的判断依据。这样的情况下，我们就要求 Content-Length
必须和内容实体的长度一致，如果不一致，就会出现各种问题。

如上图所示，如果 Content-Length 小于内容实体的长度，则会截断，反之则无法判定当前响应已经结束，会将请求持续挂起造成 Padding 状态。

理想情况下，我们在响应一个请求的时候，就需要知道它的内容实体的大小。但是在实际应用中，有些时候内容实体的长度并没有那么容易获得。例如内容实体来自网络文件、或者是动态生成的。这个时候如果依然想要提前获取到内容实体的长度，只能开一个足够大的
Buffer，等内容全部缓存好了再计算。

但这并不是一个好的方案，全部缓存到 Buffer 里，第一会消耗更多的内存，第二也会更耗时，让客户端等待过久。

此时就需要一个新的机制，不依赖 Content-Length 的值，来判定当前内容实体是否传输完成，此时就需要 Transfer-Encoding
这个头部来判定。

2.4 Transfer-Encoding:chunked

前面也提到，Transfer-Encoding 在最新的 HTTP/1.1 协议里，就只有 chunked 这个参数，标识当前为分块编码传输。

分块编码传输既然只有一个可选的参数，我们就只需要指定它为 Transfer-Encoding:chunked
，后续我们就可以将内容实体包装一个个块进行传输。

分块传输的规则：

1. 每个分块包含一个 16 进制的数据长度值和真实数据。

2. 数据长度值独占一行，和真实数据通过 CRLF(\r\n) 分割。

3. 数据长度值，不计算真实数据末尾的 CRLF，只计算当前传输块的数据长度。

4. 最后通过一个数据长度值为 0 的分块，来标记当前内容实体传输结束。

在这个例子中，首先在响应头部里标记了 Transfer-Encoding: chunked，后续先传递了第一个分块 “0123456780”，长度为
b（11 的十六进制），之后分别传输了 “Hello CxmyDev” 和 “123”，最后以一个长度为 0 的分块标记当前响应结束。

2.5 chunked 的拖挂

当我们使用 chunked 进行分块编码传输的时候，传输结束之后，还有机会在分块报文的末尾，再追加一段数据，此数据称为拖挂（Trailer）。

拖挂的数据，可以是服务端在末尾需要传递的数据，客户端其实是可以忽略并丢弃拖挂的内容的，这就需要双方协商好传输的内容了。

在拖挂中可以包含附带的首部字段，除了 Transfer-Encoding、Trailer 以及 Content-Length 首部之外，其他 HTTP
首部都可以作为拖挂发送。

一般我们会使用拖挂来传递一些在响应报文开始的时候，无法确定的某些值，例如：Content-MD5
首部就是一个常见的在拖挂中追加发送的首部。和长度一样，对于需要分块编码传输的内容实体，在开始响应的时候，我们也很难算出它的 MD5 值。

注意这里在头部增加了 Trailder，用以指定末尾还会传递一个 Content-MD5 的拖挂首部，如果有多个拖挂的数据，可以使用逗号进行分割。

三、内容编码和传输编码结合

内容编码和传输编码一般都是配合使用的。我们会先使用内容编码，将内容实体进行压缩，然后再通过传输编码分块发送出去。客户端接收到分块的数据，再将数据进行重新整合，还原成最初的数据。

四、传输编码小结

我们对传输编码应该有一定的了解了。这里简单总结一下：

1. 传输编码使用 Transfer-Encoding 首部进行标记，在最新的 HTTP/1.1 协议里，它只有 chunked 这一个取值，表示分块编码。

2. 传输编码主要是为了解决持久连接里将数据分块传输之后，判定内容实体传输结束。

3. 分块的格式：数据长度（16进制）+ 分块数据。

4. 如果还有额外的数据，可以在结束之后，使用 Trailer 进行拖挂传输额外的数据。

5. 传输编码通常会配合内容编码一起使用。

此外，传输编码应该是所有 HTTP/1.1 的标准实现，应该都有支持，如果收到无法理解的经过传输编码的报文，应该直接返回 501 Unimplemented
这个状态码来回复即可。

参考连接：

• HTTP 协议中的 Transfer-Encoding：https://imququ.com/post/transfer-encoding-header-in-http.html

• REC 7230, 3.3.1 Transfer-Encoding：https://tools.ietf.org/html/rfc7230#page-28

• RFC 7230, section 4.4: Trailer：https://tools.ietf.org/html/rfc7230#section-4.4

• RFC 7230, section 4.1.2: Chunked trailer part：https://tools.ietf.org/html/rfc7230#section-4.1.2

一、界面制作

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 Sprite; 这样会复制出一个新贴图（图集中的子图），不知道有什么办法可以不用复制新的子图，而是直接使用图集资源
。

经过测试，这确实是 Unity 在 4.x 版本中的一个缺陷，理论上这张“新贴图（图集中的子图）”是不需要的，并不应该加载。
因此，我们建议通过以下方法来绕过该问题：

在 assetBundle.Load (subFile, typeof (Sprite)) as Sprite; 之后，调用

Texture2D t = assetBundle.Load (subFile, typeof (Texture2D)) as Texture2D;

Resources.UnloadAsset(t);

从而卸载这部分多余的内存。

Q2：加载UI预制的时候，如果把特效放到预制里，会导致加载非常耗时。怎么优化这个加载时间呢？

UI和特效（粒子系统）的加载开销在多数项目中都占据较高的CPU耗时。UI界面的实例化和加载耗时主要由以下几个方面构成：

纹理资源加载耗时

UI界面加载的主要耗时开销，因为在其资源加载过程中，时常伴有大量较大分辨率的Atlas纹理加载，我们在之前的Unity加载模块深度分析之纹理篇有详细讲解。对此，我们建议研发团队在美术质量允许的情况下，尽可能对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加载的详细解释可以参考我们之前的文章：你应该知道的AssetBundle管理机制。

五、字体相关

Q1：我在用Profiler真机查看iPhone
App时，发现第一次打开某些UI时，Font.CacheFontForText占用时间超过2s，这块主要是由什么影响的?若iPhone5在这个接口消耗2s多，是不是问题很大？这个消耗和已经生成的RenderTexture的大小有关吗？

Font.CacheFontForText主要是指生成动态字体Font Texture的开销,
一次性打开UI界面中的文字越多，其开销越大。如果该项占用时间超过2s，那么确实是挺大的，这个消耗也与已经生成的Font
Texture有关系。简单来说，它主要是看目前Font Texture中是否有地方可以容下接下来的文字，如果容不下才会进行一步扩大Font
Texture，从而造成了性能开销。