前言
在游戲開發(fā)中，DrawCall 作為一個(gè)非常重要的性能指標(biāo)，直接影響游戲的整體性能表現(xiàn)员串。
無論是 Cocos Creator、Unity壕曼、Unreal 還是其他游戲引擎苏研，只要說到游戲性能優(yōu)化，DrawCall 都是絕對(duì)少不了的一項(xiàng)腮郊。
本文將會(huì)介紹什么是 DrawCall摹蘑，為什么要減少 DrawCall 以及在 Cocos Creator 項(xiàng)目中如何減少 DrawCall 來提升游戲性能。
正文
什么是 DrawCall轧飞？
DrawCall 中文譯為“繪制調(diào)用”或“繪圖指令”纹蝴。
DrawCall 是一種行為（指令），即 CPU 調(diào)用圖形 API踪少，命令 GPU 進(jìn)行圖形繪制塘安。
DrawCall 一般可以簡(jiǎn)稱為“DC”，當(dāng)然此“DC”非彼“DC”...
為什么要減少 DrawCall援奢？
發(fā)生了什么
當(dāng)我們?cè)谟懻摐p少 DrawCall 時(shí)我們?cè)谟懻撌裁矗?/p>
其實(shí)我們真正需要減少的并不是 DrawCall 這個(gè)行為本身兼犯，而是減少每個(gè) DrawCall 前置的一些消耗性能和時(shí)間的行為。
看不懂集漾？其實(shí)我也不知道我在說些什么切黔，還是接著看下面的內(nèi)容吧 : p
舉個(gè)栗子
問：嘗試在兩個(gè)硬盤之間傳輸文件，傳輸 1 個(gè) 1MB 的文件和傳輸 1024 個(gè) 1KB 的文件具篇，同樣是傳輸了共 1MB 的文件纬霞，哪個(gè)更快？
答：傳輸 1 個(gè) 1MB 的文件要比傳輸 1024 個(gè) 1KB 的文件要快得多得多驱显。因?yàn)樵诿恳粋€(gè)文件傳輸前诗芜，CPU 都需要做許多額外的工作來保證文件能夠正確地被傳輸，而這些額外工作造成了大量額外的性能和時(shí)間開銷埃疫，導(dǎo)致傳輸速度下降伏恐。
回到渲染
圖形渲染管線的大致流程如下：
上圖只是對(duì)渲染管線的部分概括，方便大家理解栓霜，實(shí)際的圖形渲染管線比較復(fù)雜翠桦，不在本文討論范圍內(nèi)。
從圖中可以看到在渲染管線中胳蛮，在每一次 DrawCall 前销凑，CPU 都需要做一系列準(zhǔn)備工作，才能讓 GPU 正確渲染出圖像仅炊。
而 CPU 的每一次內(nèi)存顯存讀寫斗幼、數(shù)據(jù)處理和渲染狀態(tài)切換都會(huì)帶來一定的性能和時(shí)間消耗。
到底是誰的鍋茂洒？
一般來說 GPU 渲染圖像的速度其實(shí)是非趁系海快的瓶竭，繪制 100 個(gè)三角形和繪制 1000 個(gè)三角形所消耗的時(shí)間沒差多少。
但是 CPU 的內(nèi)存顯存讀寫渠羞、數(shù)據(jù)處理和渲染狀態(tài)切換相對(duì)于 GPU 渲染來說是非常非常慢的斤贰。
實(shí)際的瓶頸在于 CPU 這邊，大量的 DrawCall 會(huì)讓 CPU 忙到焦頭爛額暈頭轉(zhuǎn)向不可開交次询，而 GPU 大部分時(shí)間都在摸魚荧恍，是導(dǎo)致游戲性能下降的主要原因。
所以 DrawCall 這玩意越少越好~
如何減少 DrawCall屯吊？
在游戲運(yùn)行時(shí)引擎是按照節(jié)點(diǎn)層級(jí)順序從上往下由淺到深進(jìn)行渲染的送巡，理論上每渲染一張圖像（文本最終也是圖像）都需要一次 DrawCall。
既然如此盒卸，只要我們想辦法將盡可能多的圖像在一次 DrawCall 中渲染出來（也就是“渲染合批”）骗爆，就可以盡量少去調(diào)用 CPU，從而減少 DrawCall蔽介。
簡(jiǎn)單點(diǎn)摘投，就是減少讓 CPU 工作的次數(shù)，但是每次都多給點(diǎn)活虹蓄，不就可以省去一些“CPU 準(zhǔn)備工具然后工作”和“工作結(jié)束叫 GPU 加工”的步驟了嘛犀呼，代價(jià)就是每次工作的時(shí)間會(huì)變長(zhǎng)~
明白了這個(gè)原理之后，下面讓我們看看在實(shí)際游戲開發(fā)中應(yīng)該如何操作吧薇组。
靜態(tài)合圖
靜態(tài)合圖就是在開發(fā)時(shí)將一系列碎圖整合成一張大圖外臂。
圖集對(duì)于 DrawCall 優(yōu)化來說非常重要，但是并不是說我們把所有圖片統(tǒng)統(tǒng)打成圖集就萬事大吉了律胀，這里面也有它的門道宋光，胡亂打圖集的話說不定還會(huì)變成負(fù)優(yōu)化。
最重要的是盡量將處于同一界面（UI）下的相鄰且渲染狀態(tài)相同的碎圖打包成圖集累铅，才能達(dá)到減少 DrawCall 的目的跃须。
還記得游戲渲染時(shí)是按順序渲染的嗎，所以“相鄰”很關(guān)鍵娃兽！要考，做筆記尽楔！
改變渲染狀態(tài)會(huì)打斷渲染合批投储，例如改變紋理狀態(tài)（預(yù)乘、循環(huán)模式和過濾模式）或改變 Material（材質(zhì)）阔馋、Blend（混合模式）等等玛荞，所以使用自定義 Shader 也會(huì)打斷合批。
舉個(gè)栗子呕寝，我這里有一個(gè)由 10 張碎圖和 1 個(gè)文本所組成的彈窗（假設(shè)都使用同樣的渲染方式）：
- 在不做任何優(yōu)化且未開啟動(dòng)態(tài)合圖的情況下勋眯，渲染這個(gè)彈窗需要 11 個(gè) DrawCall。
- 將所有碎圖打成一個(gè)圖集，文本節(jié)點(diǎn)夾在精靈節(jié)點(diǎn)之間的情況下需要 3 個(gè) DrawCall客蹋，在頂部最外層或者底部最外層的情況下需要 2 個(gè) DrawCall塞蹭。
- 文本使用 BMFont，將所有碎圖和 BMFont 打成一個(gè)圖集的話只需要 1 個(gè) DrawCall讶坯，如果碎圖不和 BMFont 打成一個(gè)圖集的情況則參考第 2 項(xiàng)番电。
- 碎圖不打包圖集，開啟動(dòng)態(tài)合圖辆琅，在理想情況下漱办，文本使用 BMFont 最少只需要 1 個(gè) DrawCall，不使用 BMFont 的情況同樣參考第 2 項(xiàng)婉烟。
如果上面的例子你不太能理解的話娩井，那請(qǐng)接著看下面的內(nèi)容，相信你閱讀完本篇文章的全部?jī)?nèi)容后再來看這個(gè)例子將會(huì)茅塞頓開哈哈哈~
動(dòng)態(tài)合圖和 BMFont 會(huì)在后面說到似袁。
當(dāng)然上面這個(gè)例子算是比較理想的情況撞牢，實(shí)際上的情況可能會(huì)比例子更為復(fù)雜，精靈和文本可能會(huì)更多叔营，也不一定能將所有圖像資源都打包進(jìn)一個(gè)圖集屋彪。所以我們只能是盡量合理地去優(yōu)化，避免出現(xiàn)“撿了芝麻绒尊，丟了西瓜”的情況畜挥。
不建議任何圖像資源的尺寸超過 2048 * 2048，否則在小游戲和原生平臺(tái)可能會(huì)出現(xiàn)問題婴谱；
而且圖像尺寸越大蟹但，加載的時(shí)間也越長(zhǎng)，而且是非線性的那種增長(zhǎng)谭羔，例如加載一張圖像比加載兩張圖像所消耗的時(shí)間還長(zhǎng)华糖，得不償失。
下面介紹兩種打包靜態(tài)圖集的方式：
自動(dòng)圖集資源（Auto Atlas）
利用 Cocos Creator 內(nèi)置的自動(dòng)圖集資源來將碎圖打包成圖集瘟裸。
在項(xiàng)目構(gòu)建時(shí)客叉，編輯器會(huì)將所有自動(dòng)圖集資源所在文件夾下的所有符合要求的圖像分別根據(jù)配置打包成一個(gè)或多個(gè)圖集。
自動(dòng)圖集資源使用起來很靈活话告，編輯器在打包圖集時(shí)會(huì)自動(dòng)遞歸子目錄兼搏，若子目錄下也有自動(dòng)圖集資源（即 .pac 文件）則會(huì)跳過該目錄，所以我們可以對(duì)同一目錄下的不同部分的碎圖配置不同的參數(shù)沙郭。
創(chuàng)建自動(dòng)圖集配置
在資源管理器中右鍵佛呻，點(diǎn)擊 [ 新建 -> 自動(dòng)圖集配置 ] 就會(huì)新建一個(gè)名為 AutoAtlas.pac 的資源。
配置屬性
在資源管理器中點(diǎn)擊自動(dòng)圖集資源文件就可以在屬性檢查器面板中看到自動(dòng)圖集資源可配置的屬性病线，點(diǎn)擊 Preview 按鈕即可預(yù)覽圖集吓著。
關(guān)于自動(dòng)圖集的幾點(diǎn)建議
- 合理控制圖集最大尺寸鲤嫡，避免單個(gè)圖像加載時(shí)間過長(zhǎng)。
- 尺寸太大的圖像沒有必要打進(jìn)圖集（如背景圖）绑莺。
- 善用九宮格（Sliced）可以節(jié)省很多空間（這一點(diǎn)需要美術(shù)大佬配合）暖眼。
- 間距保持默認(rèn)的 2 并保持勾選擴(kuò)邊選項(xiàng)，避免圖像裁剪錯(cuò)誤和出現(xiàn)黑邊的情況紊撕。
- 勾選不包含未被引用資源選項(xiàng)罢荡，自動(dòng)排除沒有用到的圖像以節(jié)省空間（該選項(xiàng)預(yù)覽時(shí)無效）。
- 開發(fā)時(shí)預(yù)覽圖集对扶，根據(jù)結(jié)果進(jìn)行調(diào)整区赵，以達(dá)到最好的優(yōu)化效果。
關(guān)于每個(gè)屬性具體的作用請(qǐng)參考官方文檔浪南。
自動(dòng)圖集資源官方文檔：http://docs.cocos.com/creator/manual/zh/asset-workflow/auto-atlas.html#配置自動(dòng)圖集資源
TexturePacker
我們也可以使用第三方軟件 TexturePacker 來預(yù)先將圖像打包成圖集再導(dǎo)入項(xiàng)目中笼才。
TexturePacker 是收費(fèi)軟件，但是一般情況下免費(fèi)功能就已經(jīng)夠用了络凿。
另外使用 TexturePacker 打包圖集時(shí)需要注意配置形狀填充（Shape Padding骡送，對(duì)應(yīng) Auto Atlas 中的間距），避免某張圖像出現(xiàn)相鄰圖像的像素的情況絮记。
TexturePacker 官網(wǎng)地址：https://www.codeandweb.com/texturepacker
Auto Atlas 和 TexturePacker 的對(duì)比
Auto Atlas
- Cocos Creator 內(nèi)置摔踱，方便到家了
- 功能不多但是該有的都有，免費(fèi)
- 項(xiàng)目構(gòu)建時(shí)才生成圖集怨愤，開發(fā)時(shí)任意修改無壓力
- 圖集尺寸在生成時(shí)自適應(yīng)派敷，節(jié)省空間
- 支持自動(dòng)紋理壓縮
TexturePacker
- 第三方軟件需自行安裝，不夠方便
- 收費(fèi)功能很多很專業(yè)但是用不著撰洗，免費(fèi)功能也夠用
- 先生成圖集再使用篮愉，更換圖像又要重新生成圖集
- 尺寸固定需要自己設(shè)置
- 自己壓縮去
總結(jié)：Auto Atlas 真香！
動(dòng)態(tài)合圖（Dynamic Atlas）
這里引用官方文檔中對(duì)于動(dòng)態(tài)合圖的介紹：
Cocos Creator 提供了在項(xiàng)目構(gòu)建時(shí)的靜態(tài)合圖方法 —— 自動(dòng)合圖（Auto Atlas）差导。但是當(dāng)項(xiàng)目日益壯大的時(shí)候貼圖會(huì)變得非常多试躏，很難將貼圖打包到一張大貼圖中，這時(shí)靜態(tài)合圖就比較難以滿足降低 DrawCall 的需求设褐。所以 Cocos Creator 在 v2.0 中加入了 動(dòng)態(tài)合圖（Dynamic Atlas）的功能颠蕴，它能在項(xiàng)目運(yùn)行時(shí)動(dòng)態(tài)的將貼圖合并到一張大貼圖中。當(dāng)渲染一張貼圖的時(shí)候络断，動(dòng)態(tài)合圖系統(tǒng)會(huì)自動(dòng)檢測(cè)這張貼圖是否已經(jīng)被合并到了圖集（圖片集合）中裁替，如果沒有，并且此貼圖又符合動(dòng)態(tài)合圖的條件貌笨，就會(huì)將此貼圖合并到圖集中。
動(dòng)態(tài)合圖官方文檔：https://docs.cocos.com/creator/manual/zh/advanced-topics/dynamic-atlas.html
簡(jiǎn)單來說襟沮，開啟動(dòng)態(tài)合圖之后锥惋，引擎會(huì)在運(yùn)行時(shí)幫我們對(duì)符合條件（即尺寸小于碎圖限制的最大尺寸）的精靈進(jìn)行合圖昌腰，達(dá)到和提前打包圖集一樣的效果。
引擎的動(dòng)態(tài)圖集尺寸最大是 2048 * 2048膀跌，可合并的碎圖限制的最大尺寸是 512遭商，用戶可以通過下面的 API 進(jìn)行修改：
cc.dynamicAtlasManager.maxFrameSize = 512;
啟用動(dòng)態(tài)合圖會(huì)占用額外的內(nèi)存，不同平臺(tái)占用的內(nèi)存大小不一樣捅伤。小游戲和原生平臺(tái)上默認(rèn)會(huì)禁用動(dòng)態(tài)合圖劫流，但如果你的項(xiàng)目?jī)?nèi)存空間仍有富余的話建議強(qiáng)制開啟：
cc.macro.CLEANUP_IMAGE_CACHE = false;
cc.dynamicAtlasManager.enabled = true;
另外還需要保證紋理的 Premulyiply Alpha（預(yù)乘）、Wrap Mode（循環(huán)模式） 和 Filter Mode（過濾模式） 等信息與動(dòng)態(tài)圖集一致才能夠動(dòng)態(tài)合批丛忆。
靜態(tài)圖集也可以參與動(dòng)態(tài)合圖
在動(dòng)態(tài)合圖的官方文檔中有提到：
當(dāng)渲染一張貼圖的時(shí)候祠汇，動(dòng)態(tài)合圖系統(tǒng)會(huì)自動(dòng)檢測(cè)這張貼圖是否已經(jīng)被合并到了圖集（圖片集合）中，如果沒有熄诡，并且此貼圖又符合動(dòng)態(tài)合圖的條件可很，就會(huì)將此貼圖合并到圖集中。
但其實(shí)只要靜態(tài)圖集滿足動(dòng)態(tài)合圖的要求（即尺寸小于碎圖限制的最大尺寸）凰浮，也是可以參與動(dòng)態(tài)合圖的我抠。
注意：自動(dòng)圖集資源（Auto Atlas）需要在其屬性檢查器面板中開啟 Texture 欄下的 Packable 選項(xiàng)，該選項(xiàng)默認(rèn)是禁用的袜茧。
額外補(bǔ)充
只有紋理開啟了 Packable 選項(xiàng)的精靈才能夠參與動(dòng)態(tài)合圖菜拓，該選項(xiàng)默認(rèn)開啟。
紋理參與動(dòng)態(tài)合圖后會(huì)修改原始貼圖的 UV 坐標(biāo)笛厦，所以在 Shader 中的無法正確計(jì)算 UV 坐標(biāo)纳鼎，導(dǎo)致 Shader 無效。
如果需要對(duì)精靈使用自定義 Shader递递，需要禁用其紋理的 Packable 選項(xiàng)喷橙。
也可以在代碼中禁用該選項(xiàng)：
let sprite = this.node.getComponent(cc.Sprite);
let texture = sprite.spriteFrame.getTexture();
texture.packable = false;
Packable 官方文檔：https://docs.cocos.com/creator/manual/zh/asset-workflow/sprite.html?h=packable
位圖字體（BMFont）
在場(chǎng)景中使用系統(tǒng)字體或 TTF 字體的 Label 會(huì)打斷渲染合批，特別是 Label 和 Sprite 層疊交錯(cuò)的情況登舞，每一個(gè) Label 都會(huì)打斷合批增加一個(gè) DrawCall贰逾，文本多的場(chǎng)景下輕輕松松 100+。
對(duì)于游戲中的文本菠秒，特別是數(shù)字疙剑、字母和符號(hào)，都建議使用 BMFont 來代替 TTF 或系統(tǒng)字體践叠，并且將 BMFont 與 UI 碎圖打包到同一圖集中（或開啟動(dòng)態(tài)合圖）言缤，可以免除大部分文本導(dǎo)致的 DrawCall。
舉個(gè)栗子
例如一個(gè)場(chǎng)景中有 80 張精靈和 80 個(gè)文本（系統(tǒng)字體）相互交錯(cuò)禁灼，節(jié)點(diǎn)層級(jí)如下圖：
運(yùn)行起來之后可以看到左下角的 Profile 顯示 DrawCall 已經(jīng)高達(dá) 161 個(gè)管挟，也就是說每一個(gè)精靈和文本都增加一個(gè) DrawCall，這種情況即使精靈打了圖集也一樣無濟(jì)于事弄捕。
不要問明明只有 80 張精靈和 80 個(gè)文本不應(yīng)該是 160 個(gè) DrawCall 嗎為什么是 161 個(gè)...
因?yàn)樽笙陆堑?Profile 也要占一個(gè) : (
對(duì)比栗子
還是上面的場(chǎng)景僻孝，嘗試將 Label 的系統(tǒng)字體換成 BMFont 并且與精靈打包到同一個(gè)圖集之后导帝，同樣是 80 個(gè)精靈和 80 個(gè)文本。
但是 DrawCall 只有 2 個(gè)穿铆，同時(shí)幀時(shí)間降低到了 1ms您单，幀率提升了 10 FPS，渲染耗時(shí)降低到了 0.6ms荞雏。
實(shí)際上場(chǎng)景只占了 1 個(gè) DrawCall虐秦，另一個(gè) DrawCall 是左下角的 Profile 占的...
另外，對(duì)于漢字可以嘗試使用 Label 組件的 Cache Mode 來優(yōu)化凤优。
文本緩存模式（Cache Mode）
Cocos Creator 2.0.9 版本在 Label 組件上增加了 Cache Mode 選項(xiàng)悦陋，來解決系統(tǒng)字體和 TTF 字體帶來的性能問題。
Cache Mode 官方文檔：https://docs.cocos.com/creator/manual/zh/components/label.html#文本緩存類型（cache-mode）
Cache Mode 有以下3 種選擇：
NONE（默認(rèn)）
每一個(gè) Label 都會(huì)生成為一張單獨(dú)的位圖别洪，且不會(huì)參與動(dòng)態(tài)合圖叨恨，所以每一個(gè) Label 都會(huì)打斷渲染合批。
BITMAP
當(dāng) Label 組件開啟 BITMAP 模式后挖垛，文本同樣會(huì)生成為一張位圖痒钝，但是只要符合動(dòng)態(tài)合圖要求就可以參與動(dòng)態(tài)合圖，和周圍的精靈合并 DrawCall痢毒。
一定要注意 BITMAP 模式只適用于不頻繁更改的文本送矩，否則內(nèi)存爆炸了后果自負(fù)！
舉個(gè)栗子
同樣是上文提到的精靈和文本相互交錯(cuò)的例子哪替，文本使用 BITMAP 模式栋荸，精靈不打包成圖集，開啟動(dòng)態(tài)合圖凭舶。
結(jié)果是所有精靈（包括背景）和文本都成功動(dòng)態(tài)合圖晌块，實(shí)際 DrawCall 降至 1 個(gè)。
如果精靈打包成了圖集則會(huì)變成 160 個(gè)帅霜，因?yàn)閳D集默認(rèn)不參與動(dòng)態(tài)合圖匆背。
所以當(dāng)前這種情況（少精靈多文本）不打圖集反而是比較好的選擇。
CHAR
當(dāng) Label 組件開啟 CHAR 模式后身冀，引擎會(huì)將該 Label 中出現(xiàn)的所有字符緩存到一張全局共享的位圖中钝尸，相當(dāng)于是生成了一個(gè) BMFont。
適用于文本頻繁更改的情況搂根，對(duì)性能和內(nèi)存最友好珍促。
注意：該模式只能用于字體樣式和字號(hào)固定，并且不會(huì)頻繁出現(xiàn)巨量未使用過的字符的 Label剩愧。因?yàn)楣蚕砦粓D的最大尺寸為 20482048猪叙，占滿了之后就沒辦法再渲染新的字符，需要切換場(chǎng)景才會(huì)清除共享位圖搓扯。*
開啟了 CHAR 模式的 Label 無法參與動(dòng)態(tài)合圖辣苏，但是可以和相鄰的同樣是 CHAR 模式的 Label 合并 DrawCall（相當(dāng)于是一張未打包進(jìn)圖集的 BMFont）。
舉個(gè)栗子
還是是上文提到的精靈和文本相互交錯(cuò)的例子，為了更好體現(xiàn) CHAR 模式的優(yōu)勢(shì)藏否，我更改了場(chǎng)景節(jié)點(diǎn)的結(jié)構(gòu)，將精靈和文本進(jìn)行分離（關(guān)于這點(diǎn)可以看下面的 UI層級(jí)調(diào)整）充包。
所有 Label 開啟 CHAR 模式副签，并在腳本中每過 0.2 秒就將文本更改成新的隨機(jī)數(shù)。
在這個(gè)例子中基矮，引擎會(huì)在運(yùn)行時(shí)生成一張包含數(shù)字 0 到 9 的 BMFont 存在內(nèi)存中淆储，另外由于我將所有 Label 都聚合在一起，所以所有 Label 的渲染合并成了 1 個(gè) DrawCall家浇，另外請(qǐng)?zhí)貏e關(guān)注左下角的幀時(shí)間本砰、幀率和渲染耗時(shí)。
光看上面的圖似乎看不出個(gè)所以然來钢悲，那我們?cè)黾右粋€(gè)對(duì)照組点额，將所有文本的 Cache Mode 選項(xiàng)設(shè)為默認(rèn)的 NONE 模式。
此時(shí)可以發(fā)現(xiàn)幀時(shí)間最高達(dá)到了 2 ms莺琳，平均幀率下降了大概 6 FPS还棱，渲染耗時(shí)更是翻了 4 倍最高達(dá)到了 1.8 ms。
總結(jié)
結(jié)論已經(jīng)很明顯了惭等，對(duì)于大量頻繁更改的文本珍手，使用 CHAR 模式帶來的性能提升是非常明顯的。
同時(shí) CHAR 模式的局限也很明顯辞做，一般用于場(chǎng)景中出現(xiàn)大量數(shù)字文本琳要，類似于經(jīng)驗(yàn)值增加、血量減少之類的特效的情況秤茅。
UI 層級(jí)調(diào)整
除了以上的優(yōu)化方案稚补，我們還可以在游戲場(chǎng)景中下功夫，將性能優(yōu)化做到極致嫂伞。
其實(shí)上文也有提到孔厉，我們可以通過優(yōu)化節(jié)點(diǎn)層級(jí)，分離圖像節(jié)點(diǎn)和文本節(jié)點(diǎn)帖努，文本使用 BMFont 或 Cache Mode 選項(xiàng)撰豺，盡量出現(xiàn)避免文本打斷渲染合批的情況。
特別是對(duì)于戰(zhàn)斗場(chǎng)景中大量的文本提示（傷害值拼余、血量值和法力值等等）或合成游戲中大量的經(jīng)驗(yàn)值文本污桦，因?yàn)檫@些文本基本都是數(shù)字，使用這種方式即使再多文本也只需要 1 個(gè) DrawCall 就可以全部渲染出來匙监。
舉個(gè)栗子
下面的場(chǎng)景中凡橱，文本開啟 CHAR 模式小作，使用腳本每秒生成 50 個(gè)左右的隨機(jī)數(shù)字，文本節(jié)點(diǎn)統(tǒng)一放在 labelLayer 節(jié)點(diǎn)下稼钩，讓所有文本可以共享 1 個(gè) DrawCall顾稀，另外背景和椰子頭占 1 個(gè)，左下角 Profile 占 1 個(gè)坝撑。
可以看到即使場(chǎng)景中瞬間出現(xiàn)這么多文本静秆，整體性能也還是比較可觀的。
在這個(gè)例子中巡李，引擎在運(yùn)行時(shí)為我們生成了一份包含數(shù)字 0 到 9 的全局共享位圖（BMFont）抚笔。
當(dāng)然如果可以在 Label 中直接使用 BMFont 的話那就更好了。
補(bǔ)充
再次提醒
改變渲染狀態(tài)會(huì)打斷渲染合批侨拦，例如改變紋理狀態(tài)（預(yù)乘殊橙、循環(huán)模式和過濾模式）或改變 Material（材質(zhì)）、Blend（混合模式）等等狱从，所以使用自定義 Shader 也會(huì)打斷合批膨蛮。
圖集默認(rèn)不參與動(dòng)態(tài)合圖，手動(dòng)開啟自動(dòng)圖集資源的 Packable 選項(xiàng)后如果最終圖集符合動(dòng)態(tài)合圖要求也可以參與動(dòng)態(tài)合圖矫夯。
紋理開啟 Packable 選項(xiàng)參與動(dòng)態(tài)合圖后無法使用自定義 Shader鸽疾，因?yàn)閯?dòng)態(tài)合圖會(huì)修改原始貼圖的 UV 坐標(biāo)。
使用 Cache Mode 的 BITMAP 模式需要注意內(nèi)存情況训貌，CHAR 模式需要注意文本內(nèi)容是否多且不重復(fù)制肮。
最后還需要注意
在 Cocos Creator 2.0.7 之前的版本中，改變節(jié)點(diǎn)的顏色或透明度递沪、Sprite 組件使用九宮格（Sliced）都會(huì)打斷渲染合批豺鼻。
蒜我球球你了快更新吧 : (
相關(guān)資料
Cocos Creator 用戶手冊(cè)
https://docs.cocos.com/creator/manual/zh/
傳送門
更多分享
公眾號(hào)
菜鳥小棧
我是陳皮皮款慨，這是我的個(gè)人公眾號(hào)儒飒，專注但不僅限于游戲開發(fā)、前端和后端技術(shù)記錄與分享檩奠。
每一篇原創(chuàng)都非常用心桩了，你的關(guān)注就是我原創(chuàng)的動(dòng)力！
Input and output.
