在 iOS 15 公開推出后， 我們開始從用戶端收到反饋報告：在打開我們的應(yīng)用程序(Cookpad) 時他們被莫名其妙的反復(fù)退出到登錄頁。非常令人驚訝的是，這并不是我們在測試 iOS 15 beta 版的時候發(fā)現(xiàn)的問題。
如果你是來找修復(fù)方法的，那就直接向下滾動到結(jié)論，但如果你想了解更多關(guān)于我們?nèi)绾握{(diào)試這個特定問題，那就開始吧。
復(fù)現(xiàn)反饋的問題
用戶報告中的具體信息有限，我們唯一知道的是：從 iOS 15 開始，用戶打開程序后會發(fā)現(xiàn)自己已經(jīng)退出登錄。
我們沒有視頻，也沒有具體的步驟來重現(xiàn)這個問題，所以我努力嘗試以各種方式啟動應(yīng)用程序，希望能親眼看到它。我試著重新安裝應(yīng)用程序，我試著在有網(wǎng)絡(luò)連接和沒有網(wǎng)絡(luò)連接的情況下啟動，我試著強(qiáng)制退出，經(jīng)過30分鐘的努力，我放棄了，我開始回復(fù)用戶說我沒找到具體問題。
直到我再次解鎖手機(jī)，沒有做任何操作，就啟動了 Cookpad，我發(fā)現(xiàn)APP就像我們的用戶所反饋的那樣，直接退出到了登錄界面!
在那之后，我無法準(zhǔn)確的復(fù)現(xiàn)該問題，但似乎與暫停使用手機(jī)一段時間后再次使用它有關(guān)。
縮小問題范圍
我擔(dān)心從 Xcode 重新安裝應(yīng)用程序可能會影響問題的復(fù)現(xiàn)，所以在這樣做之前，是時候查看代碼并試圖縮小問題的范圍。根據(jù)我們的實現(xiàn)，我想出了三個潛在的原因。
- 1、
UserDefaults中的數(shù)據(jù)被清除。 - 2、一個意外的API調(diào)用返回HTTP 401并觸發(fā)退出登錄。
- 3、
Keychain拋出了一個錯誤。
我能夠排除前兩個潛在的原因，這要歸功于我在自己重現(xiàn)該問題后觀察到的一些微妙行為。
- 登錄界面沒有要求我選擇地區(qū)——這表明
UserDefaults中的數(shù)據(jù)沒有問題，因為我們的 "已顯示地區(qū)選擇 "偏好設(shè)置仍然生效。 - 主用戶界面沒有顯示，即使是短暫的也沒有——這表明沒有嘗試進(jìn)行網(wǎng)絡(luò)請求，所以 API 是問題原因可能還為時過早。
這就把Keychain留給了我們，指引我進(jìn)入下一個問題。是什么發(fā)生了改變以及為什么它如此難以復(fù)現(xiàn)？
是什么發(fā)生了改變以及為什么它如此難以復(fù)現(xiàn)？
我粗略地看了一下發(fā)布說明，在谷歌上快速搜索了一下，我找不到任何東西，所以我不得不繼續(xù)挖掘以更好地了解這個問題。
對Keychain數(shù)據(jù)的訪問是通過 Security 框架提供的，這是一個眾所周知的棘手的問題。雖然有很多第三方庫來包裝這個框架以使事情變得更容易，但我們還是基于一些蘋果的示例代碼來維護(hù)我們自己的簡單封裝。
看一下這段代碼，我們調(diào)用 SecItemCopyMatching 方法來加載我們的訪問令牌，它返回數(shù)據(jù)以及描述結(jié)果的 OSStatus 代碼。然而，不幸的是，雖然我們的封裝器會將不成功的結(jié)果與狀態(tài)代碼一起拋出，用于調(diào)試，但我們在下一層中卻拋棄了這些信息，只是將錯誤視為 nil。
我們實行了每周一次的發(fā)布計劃，多虧了大量的自動化。此時，我們即將發(fā)布的下一個截止點（代碼凍結(jié)）是在第二天。因為我們還沒有完全了解這個問題有多普遍，而且我們也不確定是否能夠在代碼凍結(jié)前發(fā)布一個修復(fù)程序，所以我利用這個機(jī)會通過使用Crashlytics(崩潰日志記錄工具) 增加一些額外的非致命性日志來解決缺乏可觀察性的問題。
這個結(jié)果給了我們一些很好的觀察點，然后我們可以在接下來的幾周內(nèi)觀察。
此時，我能夠捕捉到返回的確切錯誤代碼。罪魁禍?zhǔn)资?a target="_blank">errSecInteractionNotAllowed：
不允許與 Security Server 交互。
這個錯誤告訴我們，我們正試圖在數(shù)據(jù)不可用的時間點上從Keychain中讀取數(shù)據(jù)。這通常會發(fā)生在你試圖讀取已存儲的數(shù)據(jù)，并將其可訪問性設(shè)置為kSecAttrAccessibleWhenUnlocked，而設(shè)備仍處于鎖定狀態(tài)。
現(xiàn)在這完全說得通了，但唯一的問題是，在 Cookpad 中，我們只在應(yīng)用啟動時從Keychain中讀取信息，而我的假設(shè)是，用戶一定是點擊了應(yīng)用圖標(biāo)來啟動應(yīng)用，因此設(shè)備在這時應(yīng)該總是解鎖的，對嗎？
那么，究竟發(fā)生了什么變化呢？即使我能夠重現(xiàn)這個問題，我也100%確定我的手機(jī)在我點擊應(yīng)用圖標(biāo)的時候是解鎖的，所以我不明白為什么會出現(xiàn)這個Keychain錯誤。
我決心找到原因，用一個調(diào)試工具替換了我們的應(yīng)用程序的實現(xiàn)，該工具將嘗試并記錄其生命周期中不同節(jié)點的Keychain讀取。
在能夠復(fù)現(xiàn)問題的場景中，我觀察到以下結(jié)果：
-
main.swift— 失敗 (errSecInteractionNotAllowed) -
AppDelegate.init()— 失敗 (errSecInteractionNotAllowed) -
AppDelegate.applicationProtectedDataDidBecomeAvailable(_:)
— 成功 -
AppDelegate.application(_:didFinishLaunchingWithOptions:)— 成功 -
ViewController.viewDidAppear(_:)— 成功
所以這（一半）解釋了它。為了避免在我們的AppDelegate上持有一些隱式解包的可選屬性，我們在init()方法中進(jìn)行了一些設(shè)置，其中一部分涉及從Keychain中讀取訪問令牌。這就是為什么讀取會失敗，以及最終為什么一些用戶會發(fā)現(xiàn)自己被登出了。
我在這里學(xué)到了重要的一課，即我不應(yīng)該假設(shè)受保護(hù)的數(shù)據(jù)在AppDelegate初始化時是可用的，但說實話，我還是不高興，因為我不明白為什么它不可用。畢竟，我們已經(jīng)很多年沒有改變過這部分代碼了，而且它在iOS 12、13和14系統(tǒng)中一直運行良好，那么是什么原因呢？
尋找根本原因
我的調(diào)試界面很有用，但它缺少了一些有助于回答所有問題的重要信息：時間。
我知道在AppDelegate.application(_:didFinishLaunchingWithOptions:)之前，“受保護(hù)的數(shù)據(jù)” 是不可用的，但它仍然沒有意義，因為為了重現(xiàn)這個問題，我正在執(zhí)行以下操作：
1、啟動應(yīng)用程序
2、簡單使用
3、強(qiáng)制退出應(yīng)用
4、鎖定我的設(shè)備并將其放置約 30 分鐘
5、解鎖設(shè)備
6、再次啟動應(yīng)用
每當(dāng)我在第 6 步中再次啟動應(yīng)用程序時，我 100% 確定設(shè)備已解鎖，因此我堅信我應(yīng)該能夠從 AppDelegate.init()中的Keychain讀取數(shù)據(jù)。
直到我看了所有這些步驟的時間，事情才開始變得有點意義。
再次仔細(xì)查看時間戳：
-
main.swift— 11:38:47 -
AppDelegate.init()— 11:38:47 -
AppDelegate.application(_:didFinishLaunchingWithOptions:)— 12:03:04 -
ViewController.viewDidAppear(_:)— 12:03:04
在我真正解鎖手機(jī)并點擊應(yīng)用圖標(biāo)之前的25分鐘，應(yīng)用程序本身就已經(jīng)啟動了!
現(xiàn)在，我實際上從未想過有這么大的延遲，實際上是@_saagarjha建議我檢查時間戳，之后，他指給我看這條推特。
推特翻譯：
有趣的iOS 15優(yōu)化。Duet 現(xiàn)在試圖先發(fā)制人地 "預(yù)熱" 第三方應(yīng)用程序，在你點擊一個應(yīng)用程序圖標(biāo)前幾分鐘，通過dyld和預(yù)主靜態(tài)初始化器運行它們。然后，該應(yīng)用程序被暫停，隨后的 "啟動"似乎更快。
現(xiàn)在一切都說得通了。我們最初沒有測試到它，因為我們很可能沒有給 iOS 15 beta 版足夠的時間來 "學(xué)習(xí)" 我們的使用習(xí)慣，所以這個問題只在現(xiàn)實世界的場景中再現(xiàn)，即設(shè)備認(rèn)為我很快就要啟動應(yīng)用程序。我仍然不知道這種預(yù)測是如何形成的，但我只想把它歸結(jié)為 "Siri智能"，然后就到此為止了。
結(jié)論
從iOS 15開始，系統(tǒng)可能決定在用戶實際嘗試打開你的應(yīng)用程序之前對其進(jìn)行 "預(yù)熱"，這可能會增加受保護(hù)的數(shù)據(jù)在你認(rèn)為應(yīng)該無法使用的時候的被訪問概率。
通過等待application(_:didFinishLaunchingWithOptions:)委托回調(diào)來保護(hù)自己，如果可能的話，留意UIApplication.isProtectedDataAvailable（或?qū)?yīng)委托的回調(diào)/通知）并相應(yīng)處理。
我們?nèi)匀话l(fā)現(xiàn)了非常少的非致命問題，在application(_:didFinishLaunchingWithOptions:)中報告isProtectedDataAvailable為false，在我們可以推遲從鑰匙串閱讀的訪問令牌之外，這將是一個大規(guī)模的任務(wù)，現(xiàn)在它不值得進(jìn)行進(jìn)一步調(diào)查。
這是一個相當(dāng)難調(diào)試的bug，而且行為的變化似乎完全沒有記錄，這對我來說真的沒有幫助。如果你也被這個問題所困擾，請考慮復(fù)制FB9780579。
我從中學(xué)到了很多東西，我希望你也一樣！
更新： 自從發(fā)表這篇文章以來，實際上很多人都向我指出了蘋果公司關(guān)于預(yù)熱行為的相對完善的文檔。然而，其他人也告訴我，他們?nèi)匀挥^察到與某些場景中記錄的行為不同的行為，因此請謹(jǐn)慎行事。
