iOS Widget 閃退除錯經驗

小工具

在開發 Widget 的時候，一開始遇到一個很奇怪的問題：UI 層的資料完全顯示不出來。

後來實際執行 Widget 時才發現，問題不是資料沒有進來，而是 Widget 一啟動就直接 crash。

我先透過 Codex 和 Claude 交叉確認，基本可以排除是資料處理邏輯的問題。 當時大家推測的方向都是記憶體使用量過高。

最一開始的排查方式，就是逐個檢查程式碼區塊，想找出到底是哪一段導致記憶體暴增。 Codex 和 Claude 給出的方向也很一致，都認為 Widget 的記憶體如果超過大約 30MB，就有可能發生 crash。

後來進一步確認，問題發生在同時請求兩隻 API 的時候。

但當我持續和 Codex、Claude 一起除錯，甚至嘗試修改程式寫法來壓低記憶體使用量時，我越想越覺得不合理。

因為我的 Widget 在啟動時，baseline 記憶體就已經接近 24MB。 而真正發送兩隻 API request 後，記憶體其實只上升到 28～29MB 左右。

這樣的增幅理論上不太像是 crash 的真正原因。

後來我抱著死馬當活馬醫的心態，改找 Cursor 協助排查，看看有沒有其他可能性。

結果 Cursor 提到一句很關鍵的話：

這個 Widget 的 target 結構底下沒有自己的 Asset catalog，因此它可能會直接引用主 App 的 Asset。

這句話讓我瞬間意識到問題點。

剛好我的 Widget 程式碼內確實有使用 Image，而且圖片來源就是主 App target 的 Asset catalog。

於是我嘗試在 Widget target 底下建立專屬的 Asset catalog，只放 Widget 需要使用的圖片資源。

結果修改完之後，Widget 就完全不再 crash 了。

最後得到的結論是：

這次 Widget 一開啟就 crash，真正原因其實不是記憶體超過 30MB。

而是 Widget 在載入 Image 時，會去讀取主 App target 的 Asset catalog。由於主 App 內的圖片資源很多，可能導致 Widget 在載入時額外加載過量資源，最後超出 Widget 能承受的範圍而 crash。

更有趣的是，在修正 Asset 結構之後，即使記憶體使用量上升到接近 40MB，Widget 依然可以正常運作，不會 crash。

這次經驗也讓我有一個很深的體會：

AI 工具不要只依賴單一種類。

因為長期使用同一套 AI，它的思考方向可能會逐漸同化。 透過不同 AI 工具交叉驗證與排查，往往更容易得到不同角度的思路與答案，也能讓問題排查更加全面。

While developing a Widget, I ran into a strange issue at the beginning: none of the UI data was showing up properly.

Later, when I actually tried running the Widget, I realized the problem wasn’t the data itself — the Widget was crashing immediately on launch.

I cross-checked the issue with both Codex and Claude, and we were able to mostly rule out data processing problems. The initial assumption from everyone was that the crash was caused by excessive memory usage.

My first debugging approach was to inspect each code block individually to identify which part was causing memory spikes. Both Codex and Claude gave very similar feedback: Widgets may crash if memory usage exceeds around 30MB.

Eventually, I narrowed the issue down to the point where two API requests were being executed simultaneously.

However, the more I debugged with Codex, Claude, and my own testing — including rewriting parts of the code to reduce memory usage — the more the situation felt unreasonable.

The reason was simple:

My Widget already had a baseline memory usage of around 24MB immediately after launch. After triggering the two API requests, memory usage only increased to around 28–29MB.

That level of increase didn’t really seem high enough to explain an immediate crash.

At that point, I decided to try Cursor as a last resort to see if it could identify another possible cause.

Then Cursor mentioned one very important detail:

This Widget target did not have its own Asset catalog, so it might automatically reference the Asset catalog from the main app.

That single sentence immediately made me realize the actual root cause.

As it turned out, my Widget code was indeed using an Image resource that came directly from the main app’s Asset catalog.

So I created a dedicated Asset catalog specifically inside the Widget target and only included the image resources required by the Widget itself.

After making that change, the Widget stopped crashing completely.

In the end, the real conclusion was this:

The crash was not actually caused by memory usage exceeding 30MB.

The real issue was that when the Widget loaded an Image, it was referencing the main app target’s Asset catalog. Since the main app contained a large number of image resources, the Widget may have been loading excessive assets during initialization, eventually causing it to exceed what the Widget environment could handle and resulting in a crash.

What’s even more interesting is that after fixing the Asset structure, the Widget could still run normally even when memory usage increased to nearly 40MB.

This experience also taught me an important lesson:

You should not rely on only one AI tool.

When you use the same AI tool for a long time, its reasoning patterns can gradually become homogenized. By cross-checking problems with multiple AI tools, you’re more likely to get completely different perspectives and debugging directions, which leads to more comprehensive troubleshooting overall.

[embed]《台灣即時電力通》App - App Store 在 App Store 下載Lin Sin Yi的《台灣即時電力通》。查看截圖、評分與評論、使用者提示以及更多與《台灣即時電力通》類似的遊戲。apps.apple.com