afnetworking
AFNetWorking是基于NSURLsession,在生成配置的时候有三种配置选择
+ (NSURLSessionconfiguration *)defaultSessionConfiguration;
//默认会话模式(default):工作模式类似于原来的NSURLConnection,使用的是基于磁盘缓存的持久化策略,使用用户keychain中保存的证书进行认证授权。
+ (NSURLSessionConfiguration *)ephemeralSessionConfiguration;
//瞬时会话模式(ephemeral):该模式不使用磁盘保存任何数据。所有和会话相关的caches,证书,cookies等都被保存在RAM中,因此当程序使会话无效,这些缓存的数据就会被自动清空。
+ (NSURLSessionConfiguration *)backgroundSessionConfiguration:(NSString *)identifier;
//后台会话模式(background):该模式在后台完成上传和下载,在创建Configuration对象的时候需要提供一个NSString类型的ID用于标识完成工作的后台会话。
也就是说default同时实现了内存缓存和硬盘缓存,ephemeral实现了内存缓存,对于图片下载我们当然选择default。我们还可以对缓存的大小进行设置,只需要对NSURLCache进行初始化就可以了
也可以单独对NSURLSession的configuration进行设置,在AFNetWorking中对于图片网络请求设置了20M的内存缓存和150M的硬盘缓存:
+ (NSURLCache *)defaultURLCache {
return [[NSURLCache alloc] initwithMemoryCapacity:20 * 1024 * 1024
diskCapacity:150 * 1024 * 1024
diskPath:@"com.alamofire.imagedownloader"];
}
缓存策略是指对网络请求缓存如果处理,是使用缓存还是不使用
NSURLrequestUseProtocolCachePolicy: 对特定的 URL 请求使用网络协议中实现的缓存逻辑。这是默认的策略。
NSURLRequestreloadIgnoringlocalCacheData:数据需要从原始地址加载。不使用现有缓存。
NSURLRequestReloadIgnoringLocalAndRemoteCacheData:不仅忽略本地缓存,
同时也忽略代理服务器或其他中间介质目前已有的、协议允许的缓存。
NSURLRequestReturnCacheDataElseLoad:无论缓存是否过期,先使用本地缓存数据。
如果缓存中没有请求所对应的数据,那么从原始地址加载数据。
NSURLRequestReturnCacheDataDontLoad:无论缓存是否过期,先使用本地缓存数据。
如果缓存中没有请求所对应的数据,那么放弃从原始地址加载数据,
请求视为失败(即:“离线”模式)。
NSURLRequestReloadRevalidatingCacheData:从原始地址确认缓存数据的合法性后,
缓存数据就可以使用,否则从原始地址加载。
在AFNetWorking中同样对configuration进行设置
configuration.requestCachePolicy = NSURLRequestUseProtocolCachePolicy;
如果你继承AFImageDownloader重新实现了他的初始化,requestCachePolicy注意AFImageDownloader中只有三种才设置了缓存
case NSURLRequestUseProtocolCachePolicy:
case NSURLRequestReturnCacheDataElseLoad:
case NSURLRequestReturnCacheDataDontLoad:
AFNetworking由五个模块组成:
分别由NSURLSession,Security,Reachability,Serialization,UIKit五部分组成
NSURLSession:网络通信模块(核心模块) 对应 AFNetworking中的 AFURLSessionManager和对http协议进行特化处理的AFHTTPSessionManager,AFHTTPSessionManager是继承于AFURLSessionmanager的
以下三个是被AFURLSessionManager所引用;
Security:网络通讯安全策略模块 对应 AFSecurityPolicy
Reachability:网络状态监听模块 对应AFNetworkReachabilityManager
Serialization:网络通信信息序列化、反序列化模块 对应 AFURLresponseSerialization
UIKit:对于iOSUIKit的扩展库------这个UIKIt库中有网络下载图片的框架等;
网络请求的过程:
创建NSURLSessionConfig对象--用创建的config对象配置初始化NSURLSession--创建NSURLSessionTask对象并resume执行,用delegate或者block回调返回数据。
AFURLSessionManager封装了上述网络交互功能
AFURLSessionManager请求过程
1.初始化AFURLSessionManager。
2.获取AFURLSessionManager的Task对象
3.启动Task
AFURLSessionManager会为每一个Task创建一个AFURLSessionmanagerTaskDelegate对象,manager会让其处理各个Task的具体事务,从而实现了manager对多个Task的管理
初始化好manager后,获取一个网络请求的Task,生成一个Task对象,并创建了一个AFURLSessionmanagerTaskDelegate并将其关联,设置Task的上传和下载delegate,通过KVO监听download进度和upload进度
NSURLSessionDelegate的响应
因为AFURLSessionmanager所管理的AFURLSession的delegate指向其自身,因此所有的
NSURLSessiondelegate的回调地址都是AFURLSessionmanager,而AFURLSessionmanager又会根据是否需要具体处理会将AF delegate所响应的delegate,传递到对应的AF delegate去
=================
AFSecurity:(转载)
使用AFNetworking中的SSL功能。详细步骤如下:
1、获取到站点的证书:
我们可以使用以下openssl命令来获取到服务器的公开二进制证书(以Google为例):
1 |
|
冒号中的为命令主要部分。该条命令将会在当前路径下,形成google.com站点的公开二进制证书,命名为https.cer。您可以将www.google.com 替换成您自己的站点以此来获取您自己站点的https.cer。
2、将证书放进我们的XCode项目工程中:
如上图所示,将我们的https.cer拖到我们的工程Supporting Files中,把 Copy Items if needed 的勾选上。然后把您的add to targets 选上,点击确定。就完成了证书的导入工作。
3、在我们的代码中使用我们的cer
AFNetworking中的AFSecurityPolicy是主要的类,我们可以这样来使用它(AFNetworking 2.6.0之前):
1 2 3 4 5 6 7 8 9 10 11 12 |
|
解析:
1)新建一个manager, 地球人都知道
2)在mainBundle中寻找我们刚才拖进项目中的https.cer, 并且将相关的数据读取出来
3)新建一个AFSecurityPolicy,并进行相应的配置
4)将这个AFSecurityPolicy 实例赋值给manager
也可以这样来使用:
1 2 3 4 5 6 7 8 9 |
|
这种方式比前面那种方式要更加简便一些,主要原因在于AFNetworking会自动去搜索mainBundle下的所有cer结尾的文件并放进内存中;再一一对比。因此在代码中可以省略不写。
这样一个网络请求的https的安全策略就配置好了,接下来再说明一下几个AFSecurityPolicy相关的配置
(1)SSLPinningMode
SSLPinningMode 定义了https连接时,如何去校验服务器端给予的证书。
1 2 3 4 5 |
|
AFSSLPinningModeNone: 代表客户端无条件地信任服务器端返回的证书。
AFSSLPinningModePublicKey: 代表客户端会将服务器端返回的证书与本地保存的证书中,PublicKey的部分进行校验;如果正确,才继续进行。
AFSSLPinningModeCertificate: 代表客户端会将服务器端返回的证书和本地保存的证书中的所有内容,包括PublicKey和证书部分,全部进行校验;如果正确,才继续进行。
(2)allowInvalidCertificates
allowInvalidCertificates 定义了客户端是否信任非法证书。一般来说,每个版本的iOS设备中,都会包含一些既有的CA根证书。如果接收到的证书是iOS信任的CA根证书签名的,那么则为合法证书;否则则为“非法”证书。
allowInvalidCertificates 就是用来确认是否信任这样的证书的。当然,我们也可以给iOS加入新的信任的CA证书。
(3)pinnedCertificates
pinnedCertificates 就是用来校验服务器返回证书的证书。通常都保存在mainBundle 下。通常默认情况下,AFNetworking会自动寻找在mainBundle的根目录下所有的.cer文件并保存在pinnedCertificates数组里,以校验服务器返回的证书。
(4)validatesDomainName
validatesDomainName 是指是否校验在证书中的domain这一个字段。每个证书都会包含一个DomainName, 它可以是一个IP地址,一个域名或者一端带有通配符的域名。如*.google.com, www.google.com 都可以成为这个证书的DomainName。设置validatesDomainName=YES将严格地保证其安全性。
(5) validatesCertificateChain
validatesCertificateChain 指的是是否校验其证书链。
通常来讲,一个CA证书颁发机构有很多个子机构,用来签发不同用途的子证书,然后这些子证书又再用来签发相应的证书。只有证书链上的证书都正确,CertificateChain才算验证完成。以Google为例:
从上图可以看到,Google.com的证书的根CA证书是GeoTrust Global CA; 而CA并没有直接给google.com签证书,而是先签名了Google Internet Authority G2, 然后G2再签名了google.com。这时候就需要设备中保存有Google Internet Authority G2证书才能通过校验。
一般来讲,我推荐将validatesCertificateChain设置为NO,因为并不是太有必要做CertificateChain的校验。并且,在AFNetworking 2.6.0中,也正式将validatesCertificateChain拿掉了, 其原因也同样为:There was no documented security advantage to pinning against an entire certificate chain。
因此,在2.6.0之后,可以不管这个字段。而在此之前,从效率上来说,设定为NO会是个比较明智的选择。
做好以上工作后,您应该就可以正常访问您自己的https服务器了。如果还是有问题请检查:
HTTPS服务器的正确配置。一般来说,可以使用浏览器打开相同页面来查看浏览器上的小锁是否正常。
是否https.cer正确打包进了项目中。
Reachability:
SCNetworkReachabilityRef 这个很重要,这个类的就是基于它开发的。
+ (instancetype)managerFordomain:(NSString *)domain; 监听制定domain的网络状态。
+ (instancetype)managerForAddress:(const void *)address; 监听某个socket地址的网络状态
SCNetworkReachabilitycontext
点进去,会发现这是一个结构体,一般c语言的结构体是对要保存的数据的一种描述
1. 第一个参数接受一个signed long 的参数
2. 第二个参数接受一个void * 类型的值,相当于oc的id类型,void * 可以指向任何类型的参数
3. 第三个参数 是一个函数 目的是对info做retain操作,
4. 第四个参数是一个函数,目的是对info做release操作
5. 第五个参数是 一个函数,根据info获取Description字符串
设置网络监控分为下边几个步骤:
1.我们先新建上下文
1 SCNetworkReachabilityContext context = {0, (__bridge void *)callback, AFNetworkReachabilityRetainCallback, AFNetworkReachabilityReleaseCallback, NULL};
2.设置回调
1 SCNetworkReachabilitySetCallback(self.networkReachability, AFNetworkReachabilityCallback, &context);
其中这个AFNetworkReachabilityCallback 是这样被定义的一个函数
typedef void (*SCNetworkReachabilityCallBack) ( SCNetworkReachabilityRef target, SCNetworkReachabilityFlags flags, void * __nullable info );
在本类中
1 static void AFNetworkReachabilityCallback(SCNetworkReachabilityRef __unused target, SCNetworkReachabilityFlags flags, void *info) { 2 AFPostReachabilityStatusChange(flags, (__bridge AFNetworkReachabilityStatUSBlock)info); 3 }
3.加入RunLoop池
1 SCNetworkReachabilityScheduleWithRunLoop(self.networkReachability, CFRunLoopGetMain(), kCFRunLoopCommonModes);
其中CFRunLoopGetMain()代表主RunLoop
ok,差不多已经完成
在异步线程 发送一次当前的网络状态。
停止网络监控
这两个方法没什么好说的了,一个是getter 一个是setter
==============错误码==================All ERROR codes are on "CFNetwork Errors Codes references" on the documentation
A small extraction for CFURL and CFURLConnection Errors:
kCFURLErrorUnknown = -998,
kCFURLErrorCancelled = -999,
kCFURLErrorBadURL = -1000,
kCFURLErrorTimedOut = -1001,
kCFURLErrorUnsupportedURL = -1002,
kCFURLErrorcannotFindHost = -1003,
kCFURLErrorCannotConnectToHost = -1004,
kCFURLErrorNetworkConnectionLost = -1005,
kCFURLErrorDNSLookupfailed = -1006,
kCFURLErrorHTTPTooManyRedirects = -1007,
kCFURLErrorResourceUnavailable = -1008,
kCFURLErrorNotConnectedToInternet = -1009,
kCFURLErrorRedirectToNonExistentLocation = -1010,
kCFURLErrorBadServerResponse = -1011,
kCFURLErrorUserCancelledAuthentication = -1012,
kCFURLErrorUserAuthenticationrequired = -1013,
kCFURLErrorZeroByteResource = -1014,
kCFURLErrorCannotDecodeRawData = -1015,
kCFURLErrorCannotDecodeContentData = -1016,
kCFURLErrorCannotparseresponse = -1017,
kCFURLErrorInternationalRoamingOff = -1018,
kCFURLErrorCallIsActive = -1019,
kCFURLErrorDataNotAllowed = -1020,
kCFURLErrorRequestbodyStreamExhausted = -1021,
kCFURLErrorFiledoesnotexist = -1100,
kCFURLErrorFileIsDirectory = -1101,
kCFURLErrorNopermissionsToReadFile = -1102,
kCFURLErrorDataLengthExceedsMaximum = -1103,
文章最后发布于: 2017-03-23 22:54:26