SDWebImage代码赏析

过NSOperationQueue来控制

为了保护变量，使用大量了sychronized

读的时候使用了dispatch_sync

                                                             dispatch_sync(sself.barrierQueue, ^{
                                                                 callbacksForURL = [sself.URLCallbacks[url] copy];
                                                             });

写的时候使用

                                                            dispatch_barrier_sync(sself.barrierQueue, ^{
                                                                callbacksForURL = [sself.URLCallbacks[url] copy];
                                                                if (finished) {
                                                                    [sself.URLCallbacks removeObjectForKey:url];
                                                                }
                                                            });

同时根据Apple Developer Document的要求，在并发编程里面，继承NSOperation必须实现函数start(), 与属性isFinished, isExecuting, isAychourousd

https://developer.apple.com/documentation/foundation/operation

start()也要注意处理cancel情况下的调用，还有KVO通知isFinished，isExecuting的属性。

SDWebImageDownloaderOperation的使用了CFRunLoopRun（）--- 文档解释：Runs the current thread’s CFRunLoop object in its default mode indefinitely.

 对应的使用这个函数退出 CFRunLoopStop（CFRunloopGetCurrent()）(C

 在取消的cancel函数里面，使用了这种函数performSelector:onThread:withObject:waitUntilDone: ，这种也要依靠runloop， waitUntilDone设置为NO，就是把消息放到runloop里面然后异步立刻返回。有一个限制就是这个一旦执行就不能取消，依赖与runloop是否运行。

 

缓存的问题：SDWebImage忽略了http head缓存控制，强制缓存。如果能改变URL，就可以刷新，如果不能改变URL，就要使用参数来刷新。

SDWebImage does very aggressive caching by default. It ignores all kind of caching control header returned by the HTTP server and cache the returned images with no time restriction. It implies your images URLs are static URLs pointing to images that never change. If the pointed image happen to change, some parts of the URL should change accordingly.

If you don't control the image server you're using, you may not be able to change the URL when its content is updated. This is the case for Facebook avatar URLs for instance. In such case, you may use the SDWebImageRefreshCached flag. This will slightly degrade the performance but will respect the HTTP caching control headers:

 

 

HTTP流水线

request.HTTPShouldUsePipelining = YES;

iOS设备上，不可以减少一个HTTP请求的延迟时间，但是可以减少发布多个HTTP请求的延迟时间。减少请求延迟时间可以：在单个TCP连接上集中处理HTTP请求，流水线操作HTTP请求以优化使用全双工TCP连接。但是

POST和PUT会修改服务器上的实体，所以不建议流水线操作发送POST和PUT请求。原因：

Idempotence

Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

——HTTP/1.1规范中幂等性的定义

HTTP的幂等性

本文主要以HTTP GET、DELETE、PUT、POST四种方法为主进行语义和幂等性的介绍。

HTTP GET方法用于获取资源，不应有副作用，所以是幂等的。比如：GET http://www.bank.com/account/123456，不会改变资源的状态，不论调用一次还是N次都没有副作用。请注意，这里强调的是一次和N次具有相同的副作用，而不是每次GET的结果相同。GET http://www.news.com/latest-news这个HTTP请求可能会每次得到不同的结果，但它本身并没有产生任何副作用，因而是满足幂等性的。

HTTP DELETE方法用于删除资源，有副作用，但它应该满足幂等性。比如：DELETE http://www.forum.com/article/4231，调用一次和N次对系统产生的副作用是相同的，即删掉id为4231的帖子；因此，调用者可以多次调用或刷新页面而不必担心引起错误。

HTTP POST方法用于创建资源，所对应的URI并非创建的资源本身，而是去执行创建动作的操作者，有副作用，不满足幂等性。比如：POST http://www.forum.com/articles的语义是在http://www.forum.com/articles下创建一篇帖子，HTTP响应中应包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI；所以，POST方法不具备幂等性。

HTTP PUT方法用于创建或更新操作，所对应的URI是要创建或更新的资源本身，有副作用，它应该满足幂等性。比如：PUT http://www.forum/articles/4231的语义是创建或更新ID为4231的帖子。对同一URI进行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有幂等性。

如何防范 POST 重复提交

HTTP POST 操作既不是安全的，也不是幂等的（至少在HTTP规范里没有保证）。当我们因为反复刷新浏览器导致多次提交表单，多次发出同样的POST请求，导致远端服务器重复创建出了资源。

所以，对于电商应用来说，第一对应的后端 WebService 一定要做到幂等性，第二服务器端收到 POST 请求，在操作成功后必须302跳转到另外一个页面，这样即使用户刷新页面，也不会重复提交表单。

把分布式事务分解为具有幂等性的异步消息处理 -- BASE（即Basically Available、Soft state、和Eventually consistent），而不是 ACID（Atomicity、Consistency、Isolation和 Durability））

 

UML图 无非是这几种关系

泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

 

FRunLoopGetCurrent())