我們在iOS11.3上踩了一個大坑！這個坑表現在線上的版本只要使用者升級到iOS11.3且退出登入，或者登入態過期，都會閃退。因為iOS11.3支援了兩個超級一線城市的公交卡，引發了使用者短時間集中更新。為了解決這個問題，整個團隊發一個小版本來降級這個問題的影響。

問題的表現：

前面說過，只要退出登入，App就會閃退。這是因為我們在退出登入時清除WKWebView的cookie時引發了崩潰。

問題的原因：

蘋果應該在iOS11.3上修改了nonPersistentDataStore建立的DataStore的實現。

問題覆盤：

我們先回歸一下WKWebView下cookie的前世今生。cookie本質上是h5用來儲存登入、使用者名稱、以及一些特定時間內有效的資訊的機制。這個東西有幾個顯而易見的好處：

1、本地化的儲存一些資訊，可以減少h5請求的次數。提升h5的效能，降低服務端壓力；

2、cookie作為h5請求request的一部分，會把一些客戶端的固定資訊直接傳給服務端，避免h5因為某些資訊又需要傳送網路請求；

3、cookie是域名隔離的，有一定的安全性；

正因為有這麼多的好處，所以，很多時候h5大量的依賴了cookie機制。甚至用它儲存了一些敏感資訊。這些資訊的洩露會對使用者的安全造成重大威脅。所以蘋果在iOS8引入WKWebView時，沒有給原生暴露任何操控cookie的API（事實上，不僅cookie，其他任何和快取、持久化相關的介面都沒有）。我的理解是：蘋果有意識將cookie對開發者進行了遮蔽，就是不希望原生開發者對cookie進行干預。而cookie的安全性完全由h5來保證。講道理這麼做無可厚非。但是有個東西很可怕----那就是使用者習慣。在原來老的UIWebView下，以及其他的瀏覽器中熟悉了各種cookie操作的開發者肯定不會就此罷休。各種攜帶cookie的“黑”操作層出不窮。所以，從iOS9開始，蘋果暴露了WKWebView資料儲存的類----

+ (NSSet<NSString *> *)allWebsiteDataTypes;

可以獲取dataStore中所有的資料型別。這裡有：

    WKWebsiteDataTypeDiskCache,//硬碟快取
    WKWebsiteDataTypeOfflineWebApplicationCache,//離線應用快取
    WKWebsiteDataTypeMemoryCache,//記憶體快取
    WKWebsiteDataTypeLocalStorage,//localStorage,cookie的一個兄弟
    WKWebsiteDataTypeCookies,//cookie
    WKWebsiteDataTypeSessionStorage,//session
    WKWebsiteDataTypeIndexedDBDatabases,//索引資料庫
    WKWebsiteDataTypeWebSQLDatabases//資料庫
 

這裡可以看出，與h5相關的快取都暴露給了原生。

-(void)fetchDataRecordsOfTypes:(NSSet<NSString*>*)dataTypes completionHandler:(void(^)(NSArray<WKWebsiteDataRecord *> *))completionHandler;

獲取某些指定的資料型別。最後資料例項用一個統一的抽象的WKWebsiteDataRecord來表示。

-(void)removeDataOfTypes:(NSSet<NSString*>*)dataTypes forDataRecords:(NSArray<WKWebsiteDataRecord *> *)dataRecords completionHandler:(void (^)(void))completionHandler;

移除某些特定的資料型別。

- (void)removeDataOfTypes:(NSSet<NSString*> *)websiteDataTypes modifiedSince:(NSDate *)date completionHandler:(void (^)(void))completionHandler;

移除指定時期的特定的資料型別。

從以上可以看出，蘋果暴露了各種快取的獲取方法和移除方法。但是沒有給設定方法。而且cookie並不突出。和其他兄弟一樣。所以蘋果的本意還是不希望原生直接干預cookie的設定。

但是從iOS11開始，一切都變了。蘋果徹底放開了cookie的操作許可權。它在WKWebsiteDataStore中暴露了一個

WKHTTPCookieStore型別的屬性。專門用來管理cookie。cookie搖身一變，從嬪妃變成了皇后。位置特殊了。通過這個屬性，原生可以自由的移除cookie和設定cookie了（是不是和以前的NSHttpCookieStorage一樣了？）。

這種設計帶來了一個問題？現在在iOS8、9、10、11都存在的情況下，我們如何清除cookie。iOS8沒有暴露介面，使用者量也不大了，我們不做考慮。iOS9，10只有一種方式。iOS11有兩種（注意蘋果暴露了WKHTTPCookieStore的屬性來操作cookie，但是老的API並沒有廢棄，哪怕是和cookie相關的那部分也沒有廢棄）。我想看到這個問題，腦子比較正常的人都會想：

iOS11採用新的API就行了啊。

但總有腦子不正常的人，比如我。我原本是想這麼幹的。但是後來一想，老的API沒有廢棄，那就肯定可以用，那我繼續用它唄。但是有個問題，iOS11既然暴露了新的介面，這是不是意味著老的API可能清除cookie會失敗呢？或者後續哪個版本萬一失敗呢？所以，我用了一種比較“保險”的方案。那就是先用老的API去清除，然後用新的API去校驗。虛擬碼可以這麼來看：

old api fetch cookie:
finish{
   old api remove cookie:
   finish{
        new api get cookie:
        finish{
           if cookie still exist
              new api clear cookie
        }
   }
}

邏輯上沒有毛病！！！我到目前為止仍然認為邏輯上沒有毛病。

下面開始清除。在清除的時候我們發現WKWebsiteDataStore有兩個類方法：

/* @abstract Returns the default data store. */
+ (WKWebsiteDataStore *)defaultDataStore;

/** @abstract Returns a new non-persistent data store.
 @discussion If a WKWebView is associated with a non-persistent data store, no data will
 be written to the file system. This is useful for implementing "private browsing" in a web view.
*/
+ (WKWebsiteDataStore *)nonPersistentDataStore;

字面意思很清楚，第二個是非持久的dataStore, 那第一個就是持久的。我的做法是分別去清除這兩類dataStore中的cookie。需求做完沒有毛病，一直很健康，退出登入時cookie被清除的寸草不生。我暗自欣慰。

但是iOS11.3推出後，登陸的同事反饋，閃退。瞎了我的鈦合金狗眼。為啥，再經歷了mac系統升級、xcode升級、手機作業系統升級等一系列變態操作後，真相來了：

我們上述方法在清除nonPersistentDataStore時當執行到用iOS11的API去校驗時就掛了。崩潰的棧顯示WKWebsiteDataStore正在析構。WTF！！！！

問題的原因大概就清晰了：

defaultDataStore不掛，原因是它類似於單例，程式碼執行過程中不會析構！

nonPersistentDataStore 以前不掛，現在開始掛，說明以前蘋果對它的實現也是單例，而現在它應該不是單例了。我們建立它的例項是在函式內部，當出了方法作用域後它就會析構了。執行iOS11 API檢驗時它正在析構，向一個正在析構的物件發訊息它是會掛的。

現在我們回頭來看nonPersistentDataStore的說明：

 @abstract Returns a new non-persistent data store.
 @discussion If a WKWebView is associated with a non-persistent data store, no data will
 be written to the file system. This is useful for implementing "private browsing" in a web view.

和前面持久化的dataStore不同的是，nonPersistentDataStore用於實現私密的瀏覽器，即該瀏覽器的資料與其他WebView不共享。蘋果本質的意願應該是一個WKWebView和一個nonPersistentDataStore的繫結。以前的策略應該是多個WKWebView可以和一個non-persistent的datastore繫結。只要它和普通的datastore隔離即可。（當然，以上都是通過現象的推測。如果有人有確定說明，歡迎指正）

至此，這個坑介紹完畢！我們來總結一下這裡我們的失誤：

第一、對nonPersistentDataStore缺少比較全面的理解，如果理解了它的用途，其實可以判定當前我們的App是沒有使用場景的；

第二、iOS11和iOS9、10的API最好不要巢狀使用。其實我們當時做的時候就發現老的API的效果是ok的。只不過不放心，用一種莫須有的心態增加了一個邏輯。其實這個邏輯即使有必要，也要經過驗證，證明老的API確實無法完成再去完善，畢竟cookie即使清除不了，也不是天塌下來的事。後續完善即可。這種前期畫蛇添足的思維方式還是要多改變！！！

完！