本文譯者:candeladiao,原文:URL filtering for UIWebView on the iPhone
說明:譯者在做app開發時,因為頁面的javascript文件比較大導致加載速度很慢,所以想把javascript文件打包在app裡,當UIWebView需要加載該腳本時就從app本地讀取,但UIWebView並不支持加載本地資源。最後從下文中找到了解決方法,第一次翻譯,難免有誤,大家多多指教。
iCab Mobile(一款iOS平台的網頁浏覽器)要實現一個攔截管理器來過濾頁面上的廣告及其他東西。它有一個簡單的基於URL過濾規則的列表(通常由用戶維護),當頁面包含的資源(圖片、js以及css等),文件的URL存在於規則列表中時,資源就不會被加載。
但看一下UIWebView類的API,會發現我們沒有辦法知道UIWebView正在加載什麼資源,更糟的是,當你希望過濾掉某些資源文件的時候,沒有方法可以強制UIWebView不去加載這些文件,
攔截器看起來貌似沒有可能實現。
當然還是有解決方案的,否則這篇文件就沒什麼卵用。
正如上面所說,實現攔截器不能靠UIWebView,因為UIWebView沒有提供任何有用的API。
對UIWebView的所有請求,要找到一個能中斷所有HTTP 請求的切入點,我們需要先了解一下Cocoa的URL Loading System,因為UIWebView是使用URL Loading System從web端取數據的。我們需要的切入點NSURLCache類就是URL Loading System的一部分。雖然目前iOS系統不會在磁盤上緩存任何數據(後面的iOS系統版本或許會有不同),因此在UIWebView開始加載前,NSURLCache管理的緩存數據通常為空,但UIWebView仍然會檢測所請求資源文件是否存在於緩存。所以我們需要做的只是繼承NSURLCache並重載其方法:
- (NSCachedURLResponse*)cachedResponseForRequest:(NSURLRequest*)request
UIWebView請求所有資源時都會調用這個方法。因為我們只需要在這個方法裡判斷請求的URL是否是我們想攔截的。如果是則創建一個沒有內容的假response,否則只需調用super方法即可。
如下是實現細節:
1.繼承NSURLCache:
FilteredWebCache.h:
@interface FilteredWebCache : NSURLCache { } @end
子類的主要代碼
FilteredWebCache.m:
#import "FilteredWebCache.h" #import "FilterManager.h" @implementation FilteredWebCache - (NSCachedURLResponse*)cachedResponseForRequest:(NSURLRequest*)request { NSURL *url = [request URL]; BOOL blockURL = [[FilterMgr sharedFilterMgr] shouldBlockURL:url]; if (blockURL) { NSURLResponse *response = [[NSURLResponse alloc] initWithURL:url MIMEType:@"text/plain" expectedContentLength:1 textEncodingName:nil]; NSCachedURLResponse *cachedResponse = [[NSCachedURLResponse alloc] initWithResponse:response data:[NSData dataWithBytes:" " length:1]]; [super storeCachedResponse:cachedResponse forRequest:request]; [cachedResponse release]; [response release]; } return [super cachedResponseForRequest:request]; } @end
首先判斷URL是否需攔截(判斷通過FilterManager類實現,類實現在此不列出)。如果需要,創建一個無內容的響應對象並把它存在cache中。有人可能會認為只需要返回假的響應對象就夠了,沒必要緩存它。但這樣會因響應對象被系統釋放而導致app crash。不知道為何為會這樣,可能是iOS的bug(Mac OS X 10.5.x也存在同樣問題,而10.4.x及更早的系統上沒有問題),也可能是URL Loading System內部類之間的依賴所致。所以我們先緩存響應對象。確保所有響應都是真實存在於緩存中,這也iOS希望的,最重要的是不會crash.
更新:因為假的響應是以大於0的大小來初始化的,看起來結緩存它也是必要的。
2.創建新的緩存:
接下來需要創建一個新的緩存並告訴iOS系統使用新的緩存代替默認的,這樣當URL Loading System檢測資源緩存時才會調用上面的代碼。這要在任意UIWebView開始加載頁面前做,顯然應該放在app啟動的時候:
NSString *path = ...// the path to the cache file NSUInteger discCapacity = 10*1024*1024; NSUInteger memoryCapacity = 512*1024; FilteredWebCache *cache = [[FilteredWebCache alloc] initWithMemoryCapacity: memoryCapacity diskCapacity: discCapacity diskPath:path]; [NSURLCache setSharedURLCache:cache]; [cache release];
這裡需要提供一個緩存存儲路徑。緩存文件由NSURLCache對象自動生成,我們無需事先創建文件,但要定義緩存文件所存位置(必須是應用程序“沙盒”內,如“tmp”目錄或是“Document”目錄)
這就是實現UIWebView基於URL進行請求過濾的所有內容,看起來其實並不復雜
注:如果過濾規則在app運行過程中會改變,你需要從緩存中刪除假的響應。NSURLCache提供了刪除方法,所以這不是問題。如果過濾規則不會改變,則無需關心