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

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

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

• 微信小游戲的內存結構

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

• 為什么 iOS 會在 1.3GB 左右閃退

• 如何通過資源管理減少閃退風險

1

微信小游戲的內存結構

在微信官方文檔中，有一張小游戲內存結構圖。

但很多開發(fā)者第一次看到這張圖時都會有一個感覺：看不太懂。因為小游戲的內存結構，與 Unity App 的內存結構差異很大。

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

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

• Native Memory

• Unity Reserved Memory

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

• AssetBundle

• Texture

• Mesh

通過這些測試，我們逐漸還原了小游戲內存的真實行為。

2

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

當我們用Xcode 調試微信小游戲時，會看到兩個核心進程：WeChat 進程以及WebKit.WebContent 進程，為了方便理解，我們把它們稱為：

• WeChat 進程

• Web 進程

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

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

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

• 單張大小：21.3MB

• 分辨率：2048 × 2048

• 未壓縮

• 開啟 Read / Write

然后將這些圖片打包成AssetBundle并逐個加載。結果如下：

WeChat 進程：增長約 2.1GB

Web 進程：增長較少

這說明一個關鍵問題：紋理資源的內存大部分進入了 WeChat 進程。

因此：僅僅加載紋理資源，通常不會導致小游戲閃退。小游戲閃退真正的原因是：Web 進程內存超過限制。

3

AssetBundle 對內存的影響

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

測試數(shù)據：

• AssetBundle 數(shù)量：21 個

• 總體積：約 200MB

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

加載后的內存變化：

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

• Web 進程同步增長，WeChat 進程幾乎沒有變化。

這說明：AssetBundle 主要影響 Web 進程內存。而 Web 進程正是iOS 閃退的關鍵限制。

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

原因包括：

• 支持及時卸載

• 自帶緩存管理

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

4

一個常被忽略的問題：AB 利用率

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

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

• AB 中資源數(shù)量

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

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

• 主動加載資源

• 被動引用資源

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

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

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