IOS URL加载系统 UIWebView URL拦截

转自：http://prolove10.blog.163.com/blog/static/138411843201443111235812/

转自：http://www.cocoachina.com/ios/20150626/12161.html

iOS根本离不开网络——不论是从服务端读写数据、向系统分发计算任务，还是从云端加载图片、音频、视频等。


当应用程序面临处理问题的抉择时，通常会选择最高级别的框架来解决这个问题。所以如果给定的任务是通过http://，              
https:// 或 ftp://进行通讯，那么与NSURLConnection 相关的方法就是最好的选择了。
苹果关于网络的类涵盖甚广，包括从URL加载、还存管理到认证与存储cookie等多个领域，完全可以满足现代Objective-C应用开发的需要：


URL加载
NSURLConnection
NSURLRequest NSMutableURLRequest
NSURLResponse NSHTTPURLResponse
缓存管理
NSURLCache
NSCacheURLRequest
NSCachedURLResponse
认证 & 证书
NSURLCredential
NSURLCredentialStorage
NSURLAuthenticationChallenge
NSURLProtectionSpace
Cookie存储
NSHTTPCookie
NSHTTPCookieStorage
协议支持
NSURLProtocol




虽然URL加载系统包含的内容众多，但代码的设计上却非常良好，没有把复杂的操作暴露出来，开发者只需要在用到的时候进行设置。
任何通过NSURLConnection 进行的请求都会被系统的其他部分所拦截，这也使得当可用时显式地从硬盘加载缓存成为了可能。
说到这里，我们就说说：NSURLProtocol。
NSURLProtocol
NSURLProtocol或许是URL加载系统中最功能强大但同时也是最晦涩的部分了。它是一个抽象类，
你可以通过子类化来定义新的或已经存在的URL加载行为。
听了我说了这些乱七八糟的如果你还没有抓狂，这里有一些关于_希望加载请求时不用改变其他部分代码_的例子，供你参考：
拦截图片加载请求，转为从本地文件加载
为了测试对HTTP返回内容进行mock和stub
对发出请求的header进行格式化
对发出的媒体请求进行签名
创建本地代理服务，用于数据变化时对URL请求的更改
故意制造畸形或非法返回数据来测试程序的鲁棒性
过滤请求和返回中的敏感信息
在既有协议基础上完成对 NSURLConnection的实现且与原逻辑不产生矛盾
再次强调 NSURLProtocol
核心思想最重要的一点：用了它，你不必改动应用在网络调用上的其他部分，就可以改变URL加载行为的全部细节。
或者这么说吧： NSURLProtocol 就是一个苹果允许的中间人攻击。
子类化NSURLProtocol
之前提到过 NSURLProtocol是一个抽象类，所以不能够直接使用必须被子类化之后才能使用。
让子类识别并控制请求
子类化 NSURLProtocol 的第一个任务就是告诉它要控制什么类型的网络请求。比如说如果你想要当本地有资源的时候请求直接使用本地资源文件，
那么相关的请求应该对应已有资源的文件名。
这部分逻辑定义在 +canInitWithRequest: 中，如果返回   YES，该请求就会被其控制。返回 NO 则直接跳入下一Protocol。
提供请求规范
如果你想要用特定的某个方式来修改一个请求，应该使用   +canonicalRequestForRequest: 方法。每一个subclass都应该依据某一个规范，
也就是说，一个protocol应该保证只有唯一的规范格式（虽然很多不同的请求可能是同一种规范格式）。
获取和设置请求的属性
NSURLProtocol提供方法允许你来添加、获取、删除一个request对象的任意metadata，而且不需要私有扩展或者方法欺骗(swizzle)：
+propertyForKey:inRequest:
+setProperty:forKey:inRequest:
+removePropertyForKey:inRequest:
在操作protocol时对尚未赋予特定信息的 NSURLRequest
进行操作时，上述方法都是特别重要的。这些对于和其他方法之间的状态传递也非常有用。
加载请求
你的子类中最重要的方法就是 -startLoading 和  -stopLoading。不同的自定义子类在调用这两个方法是会传入不同的内容，
但共同点都是要围绕protocol客户端进行操作。
每个 NSURLProtocol 的子类实例都有一个  client 属性，该属性对URL加载系统进行相关操作。它不是NSURLConnection，
但看起来和一个实现了NSURLConnectionDelegate 协议的对象非常相似。
<NSURLProtocolClient>
-URLProtocol:cachedResponseIsValid:
-URLProtocol:didCancelAuthenticationChallenge:
-URLProtocol:didFailWithError:
-URLProtocol:didLoadData:
-URLProtocol:didReceiveAuthenticationChallenge:
-URLProtocol:didReceiveResponse:cacheStoragePolicy:
-URLProtocol:wasRedirectedToRequest:redirectResponse:
-URLProtocolDidFinishLoading:
在对-startLoading 和-stopLoading的实现中，你需要在恰当的时候让client调用每一个delegate方法。
简单来说就是连续调用那些方法，不过这是至关重要的。
向URL加载系统注册子类
最后，为了使用 NSURLProtocol 子类，需要向URL加载系统进行注册。
当请求被加载时，系统会向每一个注册过的protocol询问：“Hey你能控制这个请求吗？”第一个通过
+canInitWithRequest: 回答为  YES 的protocol就会控制该请求。URLprotocol会被以注册顺序的反序访问，所以当在  
-application:didFinishLoadingWithOptions:方法中调用 [NSURLProtocol registerClass:[MyURLProtocol class]]; 时，
你自己写的protocol比其他内建的protocol拥有更高的优先级。
就像控制请求的URL加载系统一样， NSURLProtocol也一样的无比强大，可以通过各种灵活的方式使用。它作为一个相对晦涩难解的类，
我们挖掘出了它的潜力来让我们的代码更清爽健壮。




NSURLCache 
NSURLCache 为您的应用的 URL 请求提供了内存中以及磁盘上的综合缓存机制。 作为基础类库 URL 加载系统 的一部分，
任何通过 NSURLConnection加载的请求都将被 NSURLCache 处理。
网络缓存减少了需要向服务器发送请求的次数，同时也提升了离线或在低速网络中使用应用的体验。
当一个请求完成下载来自服务器的回应，一个缓存的回应将在本地保存。下一次同一个请求再发起时，本地保存的回应就会马上返回，
不需要连接服务器。NSURLCache会 自动 且 透明 地返回回应。
初始化并设置一个共享的 URL 缓存
为了好好利用 NSURLCache，你需要初始化并设置一个共享的 URL 缓存。在 iOS 中这项工作需要在
-application:didFinishLaunchingWithOptions: 完成，而 Mac OS X 中是在
–applicationDidFinishLaunching:：
例如：
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  NSURLCache *URLCache = [[NSURLCache alloc] initWithMemoryCapacity:4 * 1024 * 1024
                                                       diskCapacity:20 * 1024 * 1024
                                                           diskPath:nil];
  [NSURLCache setSharedURLCache:URLCache];
}
缓存策略由请求（客户端）和回应（服务端）分别指定。理解这些策略以及它们如何相互影响，是为您的应用程序找到最佳行为的关键。
NSURLRequestCachePolicy NSURLRequest 有个 cachePolicy属性，它根据以下常量指定了请求的缓存行为：
NSURLRequestUseProtocolCachePolicy：对特定的 URL 请求使用网络协议中实现的缓存逻辑。这是默认的策略。
NSURLRequestReloadIgnoringLocalCacheData：数据需要从原始地址加载。不使用现有缓存。
NSURLRequestReloadIgnoringLocalAndRemoteCacheData：不仅忽略本地缓存，同时也忽略代理服务器或其他中间介质目前已有的、协议允许的缓存。
NSURLRequestReturnCacheDataElseLoad：无论缓存是否过期，先使用本地缓存数据。如果缓存中没有请求所对应的数据，那么从原始地址加载数据。
NSURLRequestReturnCacheDataDontLoad：无论缓存是否过期，先使用本地缓存数据。如果缓存中没有请求所对应的数据，那么放弃从原始地址加载数据，
请求视为失败（即：“离线”模式）。
NSURLRequestReloadRevalidatingCacheData：从原始地址确认缓存数据的合法性后，缓存数据就可以使用，否则从原始地址加载。
你并不会惊奇于这些值不被透彻理解且经常搞混淆。
NSURLRequestReloadIgnoringLocalAndRemoteCacheData  和NSURLRequestReloadRevalidatingCacheData
              
根本没有实现（Link to Radar）更加加深了混乱程度！
关于NSURLRequestCachePolicy，以下才是你实际 需要了解的东西：
UseProtocolCachePolicy     默认行为
ReloadIgnoringLocalCacheData     不使用缓存
ReloadIgnoringLocalAndRemoteCacheData     我是认真地，不使用任何缓存
ReturnCacheDataElseLoad     使用缓存（不管它是否过期），如果缓存中没有，那从网络加载吧
ReturnCacheDataDontLoad     离线模式：使用缓存（不管它是否过期），但是不从网络加载
ReloadRevalidatingCacheData     在使用前去服务器验证


HTTP 缓存语义
因为 NSURLConnection 被设计成支持多种协议——包括 FTP、HTTP、HTTPS——所以
URL加载系统用一种协议无关的方式指定缓存。为了本文的目的，缓存用术语 HTTP 语义来解释。
HTTP 请求和回应用
headers 来交换元数据，如字符编码、MIME 类型和缓存指令等。
Request Cache Headers
在默认情况下，NSURLRequest会用当前时间决定是否返回缓存的数据。为了更精确地控制，允许使用以下请求头：
    If-Modified-Since - 这个请求头与 Last-Modified回应头相对应。把这个值设为同一终端最后一次请求时返回的 Last-Modified 字段的值。
If-None-Match - 这个请求头与与Etag 回应头相对应。使用同一终端最后一次请求的Etag 值。
Response Cache Headers
NSHTTPURLResponse 包含多个 HTTP 头，当然也包括以下指令来说明回应应当如何缓存：
Cache-Control - 这个头必须由服务器端指定以开启客户端的HTTP 缓存功能。这个头的值可能包含 max-age（缓存多久），
是公共 public 还是私有 private，或者不缓存  no-cache 等信息。详情请参阅 Cache-Control section of RFC 2616。
除了 Cache-Control 以外，服务器也可能发送一些附加的头用于根据需要有条件地请求（如上一节所提到的）：
Last-Modified -
这个头的值表明所请求的资源上次修改的时间。例如，一个客户端请求最近照片的时间线，/photos/timeline，
Last-Modified的值可以是最近一张照片的拍摄时间。
Etag - 这是 “entity tag”的缩写，它是一个表示所请求资源的内容的标识符。在实践中，Etag
的值可以是类似于资源的 MD5 之类的东西。这对于那些动态生成的、可能没有明显的 Last-Modified
值的资源非常有用。
NSURLConnectionDelegate
一旦收到了服务器的回应，NSURLConnection 的代理就有机会在  -connection:willCacheResponse: 中指定缓存数据。
NSCachedURLResponse 是个包含NSURLResponse 以及它对应的缓存中的 NSData 的类。
在 -connection:willCacheResponse:中，cachedResponse 对象会根据 URL连接返回的结果自动创建。因为 NSCachedURLResponse没有可变部分，
为了改变 cachedResponse 中的值必须构造一个新的对象，把改变过的值传入
–initWithResponse:data:userInfo:storagePolicy:
例如：
- (NSCachedURLResponse *)connection:(NSURLConnection *)connection
                  willCacheResponse:(NSCachedURLResponse *)cachedResponse
{
    NSMutableDictionary *mutableUserInfo = [[cachedResponse userInfo] mutableCopy];
    NSMutableData *mutableData = [[cachedResponse data] mutableCopy];
    NSURLCacheStoragePolicy storagePolicy = NSURLCacheStorageAllowedInMemoryOnly;
   // ...
    return [[NSCachedURLResponse alloc] initWithResponse:[cachedResponse response]
                                                              data:mutableData
                                                     userInfo:mutableUserInfo
                                              storagePolicy:storagePolicy];
}
如果 -connection:willCacheResponse: 返回  nil，回应将不会缓存。
- (NSCachedURLResponse *)connection:(NSURLConnection *)connection
                  willCacheResponse:(NSCachedURLResponse *)cachedResponse
{
    return nil;
}
如果不实现此方法，NSURLConnection 就简单地使用本来要传入 -connection:willCacheResponse:的那个缓存对象，
所以除非你需要改变一些值或者阻止缓存，否则这个代理方法不必实现。
注意事项
正如它那个毫无关系但是名字相近的小伙伴 NSCache 一样，NSURLCache 也是有一些特别的。在 iOS 5，磁盘缓存开始支持，
但仅支持 HTTP，非 HTTPS（iOS 6中增加了此支持）。Peter Steinberger关于这个主题写了一篇优秀的文章
(http://petersteinberger.com/blog/2012/nsurlcache-uses-a-disk-cache-as-of-ios5/)，
在深入研究内部细节后实现他自己的 NSURLCache 子类(https://github.com/steipete/SDURLCache)。
Daniel Pasco 在 Black Pixel 上的另一篇文章 
http://blackpixel.com/blog/2012/05/caching-and-nsurlconnection.html      
描述了一些与服务器通信时不设置缓存头的意外的默认行为。
NSURLCache 提醒着我们熟悉我们正在操作的系统是多么地重要。开发 iOS 或 Mac OS X 程序时，
这些系统中的重中之重，非   URL Loading System莫属。
无数开发者尝试自己做一个简陋而脆弱的系统来实现网络缓存的功能，殊不知NSURLCache只要两行代码就能搞定且好上100倍。
甚至更多开发者根本不知道网络缓存的好处，也从未尝试过，导致他们的应用向服务器作了无数不必要的网络请求。
所以如果你想看到世界的变化，你想确保你有程序总以正确的方式开启，在
-application:didFinishLaunchingWithOptions:设置一个共享的 NSURLCache 吧。

本文译者：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并重载其方法：

1

- (NSCachedURLResponse*)cachedResponseForRequest:(NSURLRequest*)request

UIWebView请求所有资源时都会调用这个方法。因为我们只需要在这个方法里判断请求的URL是否是我们想拦截的。如果是则创建一个没有内容的假response，否则只需调用super方法即可。

如下是实现细节：

1.继承NSURLCache:

FilteredWebCache.h:

1

2

3

4

@interface FilteredWebCache : NSURLCache

{ 

} 

@end

子类的主要代码

FilteredWebCache.m:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

#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启动的时候：

1

2

3

4

5

6

7

8

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提供了删除方法，所以这不是问题。如果过滤规则不会改变，则无需关心