※ 引述《tkdmaf (皮皮快跑)》之銘言：
: https://gist.github.com/tkdmaf/19790d5bb9f0f3c5070b0d3f364d7071
: 各位如果有空，可以測試這裡面的code嗎？
: 有個很奇怪的不確定是不是蘋果爸爸的Bug.....
: 這當中，只要sub層的Codable中的property假設型態都是String時。
: 只要總合加起來是「14」個，在某些版本或裝置上就會閃退……
: (或是我測過String有13個，Int有2個，這種情形也會閃退)
: 有測試的，麻煩請告知：
: CPU：Intel或是M1
: XCode版本、iOS裝置及版本(請至少測三種，而且一定要測 15.4)
: 如果最終認定是apple的Issue，可能有必要回報給apple了。
: (我在執行公司的專案中……意外的發現了這個狀況。)
: 在幾個line群組，有測試的回應有的人會閃退，有的人不會……
: 有點神奇……
本來想說修改文章好還是回自己的文章好。
想了想還是回文吧。
首先，這個問題比較神奇的是同樣的Code有人會閃退有人不會閃退。
就算同樣是iOS 15.4也是有人閃有人不閃。(也不確定跟手機型號有沒關係)
然後就在昨天深夜某位朋友傳訊息給我並改了我寫的東西加了一點讓我自己看。
因為昨晚累的半死我沒什麼思考能力，早上才又問他。
大致得到的結論是：
因為struct是call by value。
在跨thread回傳資料時可能因為某個條件符合導致回傳(組語顯示的是mov)
可能從這個記憶體搬到另一個位置時出些了不可預期的問題。
但如果改用class來宣告Codable的資料結構的話。
因為class是call by reference，不會有記憶體搬遷(mov的行為)。
而是跨thread後仍然是參考原本的記憶體位置，所以就沒有帶出那個不可預期的問題。
當然這都只是猜測。雖然測試上來說，確實改成class來宣告Codable時就不會產生
這樣的問題。而且通常都是用於網路資料請求，所以也不太可能發生記憶體參考洩漏的
狀況。
總之……就是一個我專案突然閃退讓我花了很長的時間一個一個去測才測出這奇怪
閃退的規則(我暫時稱之為14個String的結構bug，當然不只有14個String的狀況會
發生，不同的型態，有可能會造成這個數字的增減……估計可能跟該屬性佔用的byte有
關連………)