SafariServices，以及WebKit在iOS 9上的新變化

標籤：

SFSafariViewController

App可以選擇UIWebView和WKWebView，展現Web內容。但是某些情況下，App既想使用類似於Safari的瀏覽器架構來開啟網頁，又不想自己重寫地址欄工具列，那麼SFSafariViewController就是一個最好的選擇，效果

 

SFSafariViewController是一個特殊的UIViewController，可在當前App使用Safari的UI架構展現Web內容，同時還能享受到Safari的一些便利特性，包括但不限於：

• 相似的使用者體驗
• 和Safari共用Cookie
• 密碼、認證自動填滿
• Safari閱讀器

缺點也是很明顯的：SFSafariViewController的可定製性極差，甚至連地址欄都是不可編輯的，只能在init的時候，傳入一個URL來指定網頁的地址。另外一個定製功能在於SFSafariViewControllerDelegate裡面的一個方法：

- (NSArray<UIActivity *> *)safariViewController:(SFSafariViewController *)controller activityItemsForURL:(NSURL *)URL title:(nullable NSString *)title;

可以傳入UIActivity的數組，為UIActivityViewController（點擊底部工具列中間的按鈕觸發）添加各類外掛程式式的服務。

題外話：

蘋果為了鞏固MobileSafari在iOS中Web的地位可謂是不遺餘力：只允許使用iOS WebKit架構和WebKit Javascript瀏覽web內容，卻只開放一個極低效率、極不靈活的UIWebView，以及一個開放度較高但bug成噸的WKWebView。不過一直以來，蘋果還是以「限制」為主；從iOS 9開始，蘋果開始重視App – 使用者 – Web這條關係鏈，並為此開放了大量的新介面給開發人員使用，SFSafariViewController就是其中之一。

App – 使用者 – Web這條關係鏈中，最重要的是什嗎？使用者資料。蘋果通過SFSafariViewController，讓App得以使用到使用者最私密的Cookie和iCloud Web表單資料，App和Web的關係通過使用者資料被拉近了，而Web的官方承載體依然是Safari —— 這是蘋果想要強調的。

使用者會關心什麼呢？使用者才不理那些深層次的玩意呢。完善的功能，便捷的體驗才是使用者關心的。SFSafariViewController就是一個內建於App的小型Safari，強行提高了Safari的曝光度，甚至可以藉此俘獲敵營使用者。另一方面，SFSafariViewController去掉App跳轉Safari的沉重感，減少App和Safari的割裂。

總的來說，這是一個多贏的結局。受損的可能只有第三方的瀏覽器——讓第三方瀏覽器幫忙帶Safari的量，開玩笑呢；另外假設一些由SFSafariViewController接觸到Safari的使用者，可能會從第三方瀏覽器陣營，轉投Safari的懷抱。Safari的體驗真不是吹的，特別是當你手上幾乎都是蘋果裝置的時候。反正我早已從Chrome轉投Safari，不用燒紙。

 

SFContentBlockerManager

目前的api文檔中只有一個介面：

+ (void)reloadContentBlockerWithIdentifier:(NSString *)identifier completionHandler:(void (^__nullable)(NSError *__nullable error))completionHandler;

Content Blocker，據說是一個Browser Extension之類的玩意，和廣告過濾的作用類似，目前功能不明，更多資訊可以看這裡。

 

WebKit

目前WKWebView在iOS 9有點問題，無法用來測試新的API，只能通過API名稱來猜測其用途。

 

WKWebView

@property (nullable, nonatomic, copy) NSString *customUserAgent NS_AVAILABLE(10_11, 9_0);

自訂WKWebView的UA。

- (nullable WKNavigation *)loadData:(NSData *)data MIMEType:(NSString *)MIMEType characterEncodingName:(NSString *)characterEncodingName baseURL:(NSURL *)baseURL NS_AVAILABLE(10_11, 9_0);- (nullable WKNavigation *)loadFileURL:(NSURL *)URL allowingReadAccessToURL:(NSURL *)readAccessURL NS_AVAILABLE(10_11, 9_0);

loadData和loadFileURL，這兩個網頁載入資料的介面終於回來了T^T。

 

WKWebsiteDataRecord, WKWebsiteDataStore

可以操作WKWebView的資料記錄

和UIWebView只能操作Cookies和URLCache不同，從API提供的資料類型可以看出，可以操作的記錄包括了：

• Disk Cache
• Memory Cache
• WebApp Cache
• Cookies
• Session Storage
• Local Storage
• WebSQL
• Indexed DB

覆蓋了所有網頁的資料記錄，解決了iOS 8上WKWebView操作NSHTTPCookie和NSURLCache無效的bug，同時比UIWebView更加先進：要知道UIWebView無法清除Local Storage有多令人惱火。

由於目前還沒能實測WKWebView，尚不知道iOS 9上是否解決了WKWebView的其他bug，如WKWebView的請求不經過NSURLProtocol之類的問題。這些致命bug不解決的話，WKWebView很難實裝到第三方瀏覽器中，具體更詳細的原因可以看這裡。

SafariServices，以及WebKit在iOS 9上的新變化