This article will not give a comprehensive analysis of AFNetworking, but will compare and analyze the differences between 2.x and 3.x.

  1. AFNetworkingDivided into the followingFive function modules:
  • Network Communication Module (AFURLSessionManager, AFHTTPSessionManger)
  • Network Status Monitoring module (Reachability)
  • Network Communication Security Policy Module (Security)
  • Network communication information serialization/deserialization module (Serialization)
  • foriOS UIKitLibrary extensions (UIKit)

  1. AFNetworking 2.x requires resident threads, while 3.x does not require resident threads. 2. X resident threads are used to concurrent requests and handle data callbacks, avoiding the thread overhead of multiple network requests. 3. X does not require resident threads because NSURLSession can specify callback delegateQueue, NSURLConnection cannot; One of the major pain points of NSURLConnection is the need to wait for a callback after a request is initiated. 3.x NSURLSession fixes this problem; NSURLSession requests no longer require callbacks on the current thread. You can specify the callback delegateQueue so that the thread is not held alive waiting for the proxy callback method

  2. 3. Need to set the maximum number of concurrent 1 x (self) operationQueue) maxConcurrentOperationCount = 1), (2) x why don’t you need the function is not the same: 3 x operationQueue is used for receiving NSURLSessionDelegate callback, in view of some multi-threaded data access security considerations, set up maxConcurrentOperationCount = 1 to concurrent requests for correction of serial effect. Note: The number of concurrent requests is not equal to the number of threads opened. The specific number of threads opened is up to the system

  3. 3. Why does X serial callback

- (AFURLSessionManagerTaskDelegate *)delegateForTask:(NSURLSessionTask *)task { NSParameterAssert(task); AFURLSessionManagerTaskDelegate *delegate = nil; [self.lock lock]; / / to the lock to access the resources, prevent data confusion delegate = self. MutableTaskDelegatesKeyedByTaskIdentifier [@ (task. TaskIdentifier)]; [self.lock unlock];return delegate;
}
Copy the code

Can be seen from the code, this place of the self. The access of mutableTaskDelegatesKeyedByTaskIdentifier lock, the purpose is to guarantee a multithreaded environment data security. Since added a lock, even maxConcurrentOperationCount not set to 1, when a request is a callback, the next request or have to wait until the last request for unlock after finish to resources, so this way, and send back, is of no significance. Conversely, multi-threaded concurrency caused by multi-task callbacks can also lead to wasted performance

Attached: my blog address