一、AFNetworking框架分析
- AFURLSessionManager、AFHTTPSessionManager
AFHTTPSessionManager又是继承于AFURLSessionManager，进行了封装。主要负责网络请求通讯。
- AFURLRequestSerialization
主要用于网络请求之前的操作配置，负责配置网络请求的请求头部、序列化请求参数。
- AFURLResponseSerialization
主要用于网络请求之后的数据处理，针对不同的数据进行处理，比如JSON、XML、plist、图片格式等数据。
- AFSecurityPolicy
主要用于HTTPS环境下的认证安全请求通讯。如果是通过CA认证过的HTTPS访问地址，使用AFN时只需要拼接上https://即可，AFN的网络请求配置中默认使用CA认证访问HTTPS地址；若是自签的证书时，则需要当前类用于进行认证。
- AFNetworkReachabilityManager
用于网络状态的监听，判断是否有网络，以及判断网络连接类型，比如蜂窝网络或WiFi环境。但当前类无法判断当前环境能否访问服务器服务。其原理是利用主机的数据包发送。
二、SDWebImage分析
- 图片缓存在那个目录下？
缓存的方法在SDImageCache.m里面，图片默认缓存路径~/Library/Caches/default/com.hackemist.SDWebImageCache.default
- 图片下载最大并发数和超时时间？
#import "SDWebImageDownloader.h"
//下载最大并发数
_downloadQueue.maxConcurrentOperationCount = 6;
//下载超时时间
_downloadTimeout = 15.0;
- 图片是怎样命名的？
#import "SDImageCache.h"
//写入缓存用url做key
NSUInteger cost = SDCacheCostForImage(image);
[self.memCache setObject:image forKey:key cost:cost];
//写入磁盘需要将url进行md5作为图片的key,防止文件名称过长
- (nullable NSString *)cachedFileNameForKey:(nullable NSString *)key {
const char *str = key.UTF8String;
if (str == NULL) {
str = "";
}
unsigned char r[CC_MD5_DIGEST_LENGTH];
CC_MD5(str, (CC_LONG)strlen(str), r);
NSURL *keyURL = [NSURL URLWithString:key];
NSString *ext = keyURL ? keyURL.pathExtension : key.pathExtension;
NSString *filename = [NSString stringWithFormat:@"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%@",
r[0], r[1], r[2], r[3], r[4], r[5], r[6], r[7], r[8], r[9], r[10],
r[11], r[12], r[13], r[14], r[15], ext.length == 0 ? @"" : [NSString stringWithFormat:@".%@", ext]];
return filename;
}
- 如何识别图片类型？
#import "NSData+ImageContentType.h"
//通过NSData的第一个字符判断图片类型
+ (SDImageFormat)sd_imageFormatForImageData:(nullable NSData *)data;
- 查找到的图片可以知道图片来源吗？
typedef NS_ENUM(NSInteger, SDImageCacheType) { /**
* 从网上下载
*/ SDImageCacheTypeNone, /**
* 从磁盘获得
*/ SDImageCacheTypeDisk, /**
* 从内存获得
*/ SDImageCacheTypeMemory
};
- 所有下载的图片都将被写入缓存？磁盘呢？何时缓存的？
其一是下载成功后、自动保存。或者开发者通过代理处理图片并返回后缓存
其二是当缓存中没有、但是从硬盘中查询到了图片,在缓存上进行缓存。
//磁盘不是强制写入。从枚举SDWebImageOptions可见
typedef NS_OPTIONS(NSUInteger, SDWebImageOptions) { /**
* 禁用磁盘缓存
*/ SDWebImageCacheMemoryOnly = 1 << 2,
}
- 磁盘缓存的时长？清理操作的时间点？
默认一周清理一次；首先、通过时间进行清理。（最后修改时间>一周）；然后、根据占据内存大小进行清理。（如果占据内存大于上限、则按时间排序、删除到上限的1/2。）
- 下载图片的URL必须是NSURL么？
不是，有容错处理。
- 读取缓存以及读取磁盘的时候如何保证线程安全？
读取缓存：
读取缓存的时候是在主线程进行。由于使用NSCache进行存储、所以不需要担心单个value对象的线程安全。
读取磁盘：
磁盘的读取虽然创建了一个NSOperation对象，但据我所见这个对象只是用来标记该操作是否被取消、以及取消之后不再读取磁盘文件的作用。
真正的磁盘缓存是在另一个IO专属线程中的一个串行队列下进行的。
如果你搜索self.ioQueue还能发现、不只是读取磁盘内容。
包括删除、写入等所有磁盘内容都是在这个IO线程进行、以保证线程安全。
但计算大小、获取文件总数等操作。则是在主线程进行。
AsyncDisplayKit理解
其主要目的就只解决App使用卡顿问题。
- 分析原因部分：
尽管从iPhone4S(A5)开始CPU已经采用多核，然而对于大多数app来说，多线程协作并没有被充分利用。换句话说，在app卡顿（主线程所占用的核心满负荷）时，往往CPU的其他核心几乎无事可做。一般情况下，由于主线程承担了绝大部分的工作，如果能把主线程的任务转移一部给其他线程进行异步处理，就可以马上享受到并发带来的性能提升。这应该也是AsyncDisplayKit得名的原因之一。
UIKit的单线程设计也有一定的历史原因。早在十年前iOS SDK刚问世的时候，mobileSDK还是一个非常新的概念，更没有移动多核CPU的存在，因此当时的重点是简单可靠，大多数API都没有支持相对复杂的异步操作。时至今日，如果要完全重构UIKit使之支持异步绘制和布局，对于兼容已有海量的app，难度可想而知。在iOS10中虽然对UICollectionView/UITableView做了一定的预加载优化（WWDC2016Session219），然而并没有从根本上解决主线程布局和渲染的问题。
主要处理的问题：
UILayout：文本计算、视图布局计算
Rendering：文本渲染、图片解码、图形绘制
UIKit Objects：对象的创建、调整、销毁基本原理：
针对ASNode的修改和提交，会对其进行封装并提交到一个全局容器中
ASDK也在RunLoop中注册了一个Observer
当RunLoop进入休眠前，ASDK执行该Loop内提交的所有任务
三、ReactiveCocoa理解
ReactiveCocoa是一个基于函数响应式编程思想（Function Reactive Programming，简称FRP）的框架。由几个重要的部分组成，如下：
1、信号：例如RACSignal，可以被订阅，订阅后进行逻辑处理或者数据传递。
2、订阅者：例如RACSubscriber，表示订阅者的意思。用于订阅和发送数据。它是一个协议，由具体的类实现。
3、清理者：例如RACDisposable，用于取消或者清理订阅者的资源。
4、RACSubject：可以当成一个信号，也可以充当信号发送者。
