Re: [討論] 詭異的………閃退。

[tkdmaf (皮皮快跑)]

※ 引述《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有
關連………)

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.158.168.152 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/MacDev/M.1651151835.A.9A5.html
推 lemontea0328: ParentData 改成 class 就不會閃退
→ lemontea0328: 真是奇妙...
→ lemontea0328: https://imgur.com/BlGYMt6
→ lemontea0328: 改這樣的話用struct似乎不會壞
我也不明白為什麼改這樣就不會壞。
但是改成這樣就變成同步運行而不是非同步運行了。
一個wait處理完才接下去處理後面的。
(解決callback hell的話，這招反倒是挺好用就是了。但我原本的需求是
 同時並發，並等待，雖然有傳統的NSOperation，但覺得作法比較「囉唆」。)
推 tomhawkreal: 樓上 這表示struct經不起並行存取
→ tomhawkreal: 不知古典模式是否也如此
→ lemontea0328: swift-evolution
→ lemontea0328: 0304-structured-concurrency.md
→ lemontea0328: 這種寫法尚未支援
→ lemontea0328: https://imgur.com/i0wARyL
※ 編輯: tkdmaf (49.158.168.152 臺灣), 04/29/2022 22:52:17
推 appleway: 如果是不同threads 讀取資料出問題，你
→ appleway: 是是看把var 都改成let
→ appleway: 試試看
→ tkdmaf: 樓上，我提供的範例是var，但原本是let，
→ tkdmaf: 情況沒變
推 ethanhuang13: 我跟 Pofat 試過。覺得是編譯器的
→ ethanhuang13: bug。換回 Xcode 13.2.x 就沒問題
如果是編譯器的問題的話，基本上……仍然算是蘋果爸爸的鍋。
※ 編輯: tkdmaf (49.158.168.152 臺灣), 05/08/2022 22:44:11
→ ethanhuang13: 那當然。13.3 以上小問題不少，我
→ ethanhuang13: 繼續用 13.2.1