在將Unity App 游戲移植到微信小游戲的過程中，很多團(tuán)隊(duì)都會(huì)遇到一個(gè)非常典型的問題：Android 運(yùn)行穩(wěn)定，但 iOS 經(jīng)常閃退。

經(jīng)過大量項(xiàng)目經(jīng)驗(yàn)和測試數(shù)據(jù)分析，我們發(fā)現(xiàn)：大多數(shù)閃退問題，其實(shí)都與小游戲的內(nèi)存結(jié)構(gòu)有關(guān)。而微信小游戲的內(nèi)存機(jī)制，與傳統(tǒng) Unity App差異非常大。

本文將通過大量實(shí)測數(shù)據(jù)，系統(tǒng)拆解：

• 微信小游戲的內(nèi)存結(jié)構(gòu)

• 不同資源類型的內(nèi)存表現(xiàn)

• 為什么 iOS 會(huì)在 1.3GB 左右閃退

• 如何通過資源管理減少閃退風(fēng)險(xiǎn)

1

微信小游戲的內(nèi)存結(jié)構(gòu)

在微信官方文檔中，有一張小游戲內(nèi)存結(jié)構(gòu)圖。

但很多開發(fā)者第一次看到這張圖時(shí)都會(huì)有一個(gè)感覺：看不太懂。因?yàn)樾∮螒虻膬?nèi)存結(jié)構(gòu)，與 Unity App 的內(nèi)存結(jié)構(gòu)差異很大。

官方文檔中有一句非常關(guān)鍵的說明：Mono Heap + Native Reserved + 原生插件內(nèi)存 = Dynamic Memory

其中最容易產(chǎn)生誤解的是：Native Reserved，很多開發(fā)者會(huì)把它理解為 Unity App 中的：

• Native Memory

• Unity Reserved Memory

但實(shí)際上，兩者并不完全一致。為了搞清楚真實(shí)情況，我們做了大量測試，分別分析了不同資源類型：

• AssetBundle

• Texture

• Mesh

通過這些測試，我們逐漸還原了小游戲內(nèi)存的真實(shí)行為。

2

iOS 為什么在 1.3GB 左右閃退？

當(dāng)我們用Xcode 調(diào)試微信小游戲時(shí)，會(huì)看到兩個(gè)核心進(jìn)程：WeChat 進(jìn)程以及WebKit.WebContent 進(jìn)程，為了方便理解，我們把它們稱為：

• WeChat 進(jìn)程

• Web 進(jìn)程

經(jīng)過測試發(fā)現(xiàn)：小游戲的閃退幾乎全部發(fā)生在 Web 進(jìn)程。當(dāng) Web 進(jìn)程的內(nèi)存超過約1.3GB，系統(tǒng)就會(huì)觸發(fā)崩潰。

我們做了一個(gè)壓力測試，測試數(shù)據(jù)：

• 圖片數(shù)量：100 張

• 單張大小：21.3MB

• 分辨率：2048 × 2048

• 未壓縮

• 開啟 Read / Write

然后將這些圖片打包成AssetBundle并逐個(gè)加載。結(jié)果如下：

WeChat 進(jìn)程：增長約 2.1GB

Web 進(jìn)程：增長較少

這說明一個(gè)關(guān)鍵問題：紋理資源的內(nèi)存大部分進(jìn)入了 WeChat 進(jìn)程。

因此：僅僅加載紋理資源，通常不會(huì)導(dǎo)致小游戲閃退。小游戲閃退真正的原因是：Web 進(jìn)程內(nèi)存超過限制。

3

AssetBundle 對(duì)內(nèi)存的影響

接下來我們測試AssetBundle 的加載行為。

測試數(shù)據(jù)：

• AssetBundle 數(shù)量：21 個(gè)

• 總體積：約 200MB

首先使用Unity 原生接口加載。

加載后的內(nèi)存變化：

• Native Reserved 增加約200MB，Dynamic Memory增加約200MB；

• Web 進(jìn)程同步增長，WeChat 進(jìn)程幾乎沒有變化。

這說明：AssetBundle 主要影響 Web 進(jìn)程內(nèi)存。而 Web 進(jìn)程正是iOS 閃退的關(guān)鍵限制。

因此我們建議：盡量使用微信官方提供的 AB 加載接口。

原因包括：

• 支持及時(shí)卸載

• 自帶緩存管理

• 更適合小游戲環(huán)境

4

一個(gè)常被忽略的問題：AB 利用率

在分析項(xiàng)目資源時(shí)，我們發(fā)現(xiàn)一個(gè)非常常見的問題：很多 AssetBundle 的利用率非常低。

有些 AB 的資源利用率甚至低于 10%。換句話說：90% 的資源被加載，但從未使用。為了解決這個(gè)問題，我們開發(fā)了一個(gè)工具，用來統(tǒng)計(jì)：

• AB 中資源數(shù)量

• 實(shí)際被使用的資源數(shù)量

統(tǒng)計(jì)方式是通過分析：RefCount（引用計(jì)數(shù)），從而區(qū)分：

• 主動(dòng)加載資源

• 被動(dòng)引用資源

最終計(jì)算：資源利用率 = 實(shí)際使用資源 / AB 內(nèi)資源，對(duì)于利用率極低的 AB，我們會(huì)進(jìn)一步分析：哪些資源體積最大？為什么被加載卻沒有使用？優(yōu)先處理“體積大但利用率低”的資源。

本文內(nèi)容節(jié)選自我們的課程《從App到多平臺(tái)小游戲 - 高效遷移的全鏈路優(yōu)化策略》，更多關(guān)于各類資源（紋理 / Mesh / 動(dòng)畫 / 音頻）的內(nèi)存行為，“同步轉(zhuǎn)異步”的問題，iOS的異常處理以及我們在一些在項(xiàng)目中實(shí)際做過的性能優(yōu)化點(diǎn)分享，可復(fù)制 鏈接瀏覽器打開/點(diǎn)擊文末【閱讀原文】了解課程詳情：

https://edu.uwa4d.com/course-intro/0/629