[[439486]]

在 iOS 15 公開推出后， 我們開始從用戶端收到反饋報告：在打開我們的應用程序(Cookpad) 時他們被莫名其妙的反復退出到登錄頁。非常令人驚訝的是，這并不是我們在測試 iOS 15 beta 版的時候發現的問題。

如果你是來找修復方法的，那就直接向下滾動到結論，但如果你想了解更多關于我們如何調試這個特定問題，那就開始吧。

復現反饋的問題

用戶報告中的具體信息有限，我們唯一知道的是：從 iOS 15 開始，用戶打開程序后會發現自己已經退出登錄。

我們沒有視頻，也沒有具體的步驟來重現這個問題，所以我努力嘗試以各種方式啟動應用程序，希望能親眼看到它。我試著重新安裝應用程序，我試著在有網絡連接和沒有網絡連接的情況下啟動，我試著強制退出，經過30分鐘的努力，我放棄了，我開始回復用戶說我沒找到具體問題。

直到我再次解鎖手機，沒有做任何操作，就啟動了 Cookpad，我發現APP就像我們的用戶所反饋的那樣，直接退出到了登錄界面!

在那之后，我無法準確的復現該問題，但似乎與暫停使用手機一段時間后再次使用它有關。

縮小問題范圍

我擔心從 Xcode 重新安裝應用程序可能會影響問題的復現，所以在這樣做之前，是時候查看代碼并試圖縮小問題的范圍。根據我們的實現，我想出了三個潛在的原因。

1、UserDefaults 中的數據被清除。

2、一個意外的API調用返回HTTP 401并觸發退出登錄。

3、Keychain 拋出了一個錯誤。

我能夠排除前兩個潛在的原因，這要歸功于我在自己重現該問題后觀察到的一些微妙行為。

• 登錄界面沒有要求我選擇地區——這表明UserDefaults中的數據沒有問題，因為我們的 "已顯示地區選擇 "偏好設置仍然生效。
• 主用戶界面沒有顯示，即使是短暫的也沒有——這表明沒有嘗試進行網絡請求，所以 API 是問題原因可能還為時過早。

這就把Keychain留給了我們，指引我進入下一個問題。是什么發生了改變以及為什么它如此難以復現?

是什么發生了改變以及為什么它如此難以復現?

我粗略地看了一下發布說明，在谷歌上快速搜索了一下，我找不到任何東西，所以我不得不繼續挖掘以更好地了解這個問題。

對Keychain數據的訪問是通過 Security[1] 框架提供的，這是一個眾所周知的棘手的問題。雖然有很多第三方庫來包裝這個框架以使事情變得更容易，但我們還是基于一些蘋果的示例代碼來維護我們自己的簡單封裝。

看一下這段代碼，我們調用 SecItemCopyMatching[2] 方法來加載我們的訪問令牌，它返回數據以及描述結果的 OSStatus 代碼。然而，不幸的是，雖然我們的封裝器會將不成功的結果與狀態代碼一起拋出，用于調試，但我們在下一層中卻拋棄了這些信息，只是將錯誤視為 nil。

我們實行了每周一次的發布計劃，多虧了大量的自動化。此時，我們即將發布的下一個截止點(封版)是在第二天。因為我們還沒有完全了解這個問題有多普遍，而且我們也不確定是否能夠在代碼凍結前發布一個修復程序，所以我利用這個機會通過使用Crashlytics(崩潰日志記錄工具) 增加一些額外的非致命性日志來解決缺乏可觀察性的問題。

雖然我們無法改變加載會話的行為，但我們能夠開始記錄錯誤并更好地記錄我們實現的當前行為。

這個結果給了我們一些很好的觀察點，然后我們可以在接下來的幾周內觀察。

在10.58.0和10.59.0版本中，受影響的用戶數量慢慢減少，這是由于我們在努力確定根本原因時引入了一項緩解措施，該措施在10.60.0中得到了修復。

此時，我能夠捕捉到返回的確切錯誤代碼。罪魁禍首是errSecInteractionNotAllowed[3]：

不允許與 Security Server 交互。

這個錯誤告訴我們，我們正試圖在數據不可用的時間點上從Keychain中讀取數據。這通常會發生在你試圖讀取已存儲的數據，并將其可訪問性設置為kSecAttrAccessibleWhenUnlocked[4]，而設備仍處于鎖定狀態。

現在這完全說得通了，但唯一的問題是，在 Cookpad 中，我們只在應用啟動時從Keychain中讀取信息，而我的假設是，用戶一定是點擊了應用圖標來啟動應用，因此設備在這時應該總是解鎖的，對嗎?

那么，究竟發生了什么變化呢?即使我能夠重現這個問題，我也100%確定我的手機在我點擊應用圖標的時候是解鎖的，所以我不明白為什么會出現這個Keychain錯誤。

我決心找到原因，用一個調試工具替換了我們的應用程序的實現，該工具將嘗試并記錄其生命周期中不同節點的Keychain讀取。

在能夠復現問題的場景中，我觀察到以下結果：

• main.swift — 失敗 (errSecInteractionNotAllowed)
• AppDelegate.init() — 失敗 (errSecInteractionNotAllowed)
• AppDelegate.applicationProtectedDataDidBecomeAvailable(_:)— 成功
• AppDelegate.application(_:didFinishLaunchingWithOptions:) — 成功
• ViewController.viewDidAppear(_:) — 成功

所以這(一半)解釋了它。為了避免在我們的AppDelegate上持有一些隱式解包的可選屬性，我們在init()方法中進行了一些設置，其中一部分涉及從Keychain中讀取訪問令牌。這就是為什么讀取會失敗，以及最終為什么一些用戶會發現自己被登出了。

我在這里學到了重要的一課，即我不應該假設受保護的數據在AppDelegate初始化時是可用的，但說實話，我還是不高興，因為我不明白為什么它不可用。畢竟，我們已經很多年沒有改變過這部分代碼了，而且它在iOS 12、13和14系統中一直運行良好，那么是什么原因呢?

尋找根本原因

我的調試界面很有用，但它缺少了一些有助于回答所有問題的重要信息：時間。

我知道在AppDelegate.application(_:didFinishLaunchingWithOptions:)之前，“受保護的數據” 是不可用的，但它仍然沒有意義，因為為了重現這個問題，我正在執行以下操作：

1、啟動應用程序 2、簡單使用 3、強制退出應用 4、鎖定我的設備并將其放置約 30 分鐘 5、解鎖設備 6、再次啟動應用

每當我在第 6 步中再次啟動應用程序時，我 100% 確定設備已解鎖，因此我堅信我應該能夠從 AppDelegate.init()中的Keychain讀取數據。

直到我看了所有這些步驟的時間，事情才開始變得有點意義。

再次仔細查看時間戳：

• main.swift — 11:38:47
• AppDelegate.init() — 11:38:47
• AppDelegate.application(_:didFinishLaunchingWithOptions:) — 12:03:04
• ViewController.viewDidAppear(_:) — 12:03:04

在我真正解鎖手機并點擊應用圖標之前的25分鐘，應用程序本身就已經啟動了!

現在，我實際上從未想過有這么大的延遲，實際上是@_saagarjha建議我檢查時間戳，之后，他指給我看這條推特。

Twitter：Apple開發人員文檔的首頁

推特翻譯：有趣的iOS 15優化。Duet 現在試圖先發制人地 "預熱" 第三方應用程序，在你點擊一個應用程序圖標前幾分鐘，通過dyld和預主靜態初始化器運行它們。然后，該應用程序被暫停，隨后的 "啟動"似乎更快。

現在一切都說得通了。我們最初沒有測試到它，因為我們很可能沒有給 iOS 15 beta 版足夠的時間來 "學習" 我們的使用習慣，所以這個問題只在現實世界的場景中再現，即設備認為我很快就要啟動應用程序。我仍然不知道這種預測是如何形成的，但我只想把它歸結為 "Siri智能"，然后就到此為止了。

結論

從iOS 15開始，系統可能決定在用戶實際嘗試打開你的應用程序之前對其進行 "預熱"，這可能會增加受保護的數據在你認為應該無法使用的時候的被訪問概率。

通過等待application(_:didFinishLaunchingWithOptions:)委托回調來保護自己，如果可能的話，留意UIApplication.isProtectedDataAvailable(或對應委托的回調/通知)并相應處理。

我們仍然發現了非常少的非致命問題，在application(_:didFinishLaunchingWithOptions:)中報告isProtectedDataAvailable為false，在我們可以推遲從鑰匙串閱讀的訪問令牌之外，這將是一個大規模的任務，現在它不值得進行進一步調查。

這是一個相當難調試的bug，而且行為的變化似乎完全沒有記錄，這對我來說真的沒有幫助。如果你也被這個問題所困擾，請考慮復制FB9780579[5]。

我從中學到了很多東西，我希望你也一樣!

更新： 自從發表這篇文章以來，實際上很多人都向我指出了蘋果公司關于預熱行為的相對完善的文檔[6]。然而，其他人也告訴我，他們仍然觀察到與某些場景中記錄的行為不同的行為，因此請謹慎行事。

參考資料

[1]Security:

https://developer.apple.com/documentation/security

[2]SecItemCopyMatching: https:

//developer.apple.com/documentation/security/1398306-secitemcopymatching?language=objc

[3]errSecInteractionNotAllowed:

https://developer.apple.com/documentation/security/errsecinteractionnotallowed?changes=_3

[4]kSecAttrAccessibleWhenUnlocked:

https://developer.apple.com/documentation/security/ksecattraccessiblewhenunlocked

[5]FB9780579: https://openradar.appspot.com/FB9780579

[6]蘋果公司關于預熱行為的相對完善的文檔: https://developer.apple.com/documentation/uikit/app_and_environment/responding_to_the_launch_of_your_app/about_the_app_launch_sequence#3894431