<h1>1、SDWebImage的原理实现机制，如何解决TableView卡的问题?
SDWebImage内部实现过程（建议画图记住）</h1>
1> 入口 setImageWithURL:placeholderImage:options: 会先把 placeholderImage 显示，
然后 SDWebImageManager 根据 URL 开始处理图片。
2> 进入 SDWebImageManager-downloadWithURL:delegate:options:userInfo:，
交给 SDImageCache 从缓存查找图片是否已经下载 queryDiskCacheForKey:delegate:userInfo:.
3> 先从内存图片缓存查找是否有图片，如果内存中已经有图片缓存，SDImageCacheDelegate 回调
imageCache:didFindImage:forKey:userInfo: 到 SDWebImageManager。
4> SDWebImageManagerDelegate 回调 webImageManager:didFinishWithImage:
到 UIImageView+WebCache 等前端展示图片。
5> 如果内存缓存中没有，生成 NSInvocationOperation 添加到队列开始从硬盘查找图片是否已经缓存。
6> 根据 URLKey 在硬盘缓存目录下尝试读取图片文件。
这一步是在 NSOperation 进行的操作，所以回主线程进行结果回调 notifyDelegate:。
7> 如果上一操作从硬盘读取到了图片，将图片添加到内存缓存中（如果空闲内存过小，会先清空内存缓存）。
8> SDImageCacheDelegate 回调 imageCache:didFindImage:forKey:userInfo:。进而回调展示图片。
9> 如果从硬盘缓存目录读取不到图片，说明所有缓存都不存在该图片，需要下载图片, 回调 imageCache:didNotFindImageForKey:userInfo:。
10> 共享或重新生成一个下载器 SDWebImageDownloader 开始下载图片。
11> 图片下载由 NSURLConnection 来做，实现相关 delegate 来判断图片下载中、下载完成和下载失败。
12> connection:didReceiveData: 中利用 ImageIO 做了按图片下载进度加载效果。
13> connectionDidFinishLoading: 数据下载完成后交给 SDWebImageDecoder 做图片解码处理。
14> 图片解码处理在一个 NSOperationQueue 完成，不会拖慢主线程 UI。如果有需要对下载的图片进行二次处理，最好也在这里完成，效率会好很多。
15> 在主线程 notifyDelegateOnMainThreadWithInfo: 宣告解码完成，
imageDecoder:didFinishDecodingImage:userInfo: 回调给 SDWebImageDownloader。
imageDownloader:didFinishWithImage: 回调给 SDWebImageManager 告知图片下载完成。
16> 通知所有的 downloadDelegates 下载完成，回调给需要的地方展示图片。
17> 将图片保存到 SDImageCache 中，内存缓存和硬盘缓存同时保存。
写文件到硬盘也在以单独 NSInvocationOperation 完成，避免拖慢主线程。
18> SDImageCache 在初始化的时候会注册一些消息通知，在内存警告或退到后台的时候清理内存图片缓存，应 用结束的时候清理过期图片。
19> SDWI 也提供了 UIButton+WebCache 和 MKAnnotationView+WebCache，方便使用。
20> SDWebImagePrefetcher 可以预先下载图片，方便后续使用。
21> 如何解决tableView卡顿问题，前面也提了很多方案。
通过设置最大并发数, 设置当前页的cell, 而不是把所有cell一次性设置完,
以及数据图片的三级缓存, 直接保存在内存中和沙盒缓存中进行读取. 降低网络请求的次数,
不仅节约用户流量. 也会保证tableView滑动的流畅性
<h1>2、SDWebImage怎样实现图片的缓存机制的？</h1>
图片的缓存, 内存缓存, 沙盒缓存, 操作缓存, 以tableViewController为例:
1> 每次cell需要显示,都需要重新调用
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { }方法
2> 每次调用tableView显示行的数据源方法时, 如果需要从网络加载图片, 就需要将加载图片这样的耗时操作放在子线程上执行,
从网络上下载的图片可以以键值对的形式保存在定义的可变字典中,将每张图片的唯一的路径作为键,将从网络下载下来的图片作为值,
保存在内存缓存中, 这样每次滑动tableView cell重用时就直接判断内存缓存中有没有需要的图片,
如果有就不需要再次下载,在没有出现内存警告或者程序员手动清理内存缓存时, 就直接从内存缓存中获取图片.
3> 为了每次退出程序,再次进入程序时,不浪费用户的流量, 需要将第一次进入程序时加载的图片保存在本地沙盒缓存文件中,
在沙盒中保存的图片数据没有被改变之前,下次开启程序就直接从沙盒的缓存文件中读取需要显示的图片,
并将沙盒缓存文件夹(Cache)中保存的图片保存到内存缓存中, 这样用户每次
滑动tableView cell重用时直接从内存缓存中读取而不是从沙盒中读取, 节约时间.
<h1>3、使用 AFNetworking做过断点续传吗？</h1>
断点续传的主要思路:
1> 检查服务器文件信息
2> 检查本地文件
3> 如果比服务器文件小, 断点续传, 利用 HTTP 请求头的 Range 实现断点续传
4> 如果比服务器文件大，重新下载
5> 如果和服务器文件一样，下载完成
<h1>4、使用第三方框架的时候有没有仔细研读过它们的源码(AFNetworking)？AFN底层原理分析。</h1>
AFNetworking主要是对NSURLSession和NSURLCollection（iOS9.0废弃）的封装,其中主要有以下类:
AFHTTPRequestOperationManager :内部封装的是 NSUrlConnection,负责发送网络请求,使用最多的一个类.（3.0废弃）
AFHTTPSessionManager :内部封装是 NSUrlSession ,负责发送网络请求,使用最多的一个类.
AFHTTPRequestOperationManager 和 AFHTTPSessionManager :定义的 API(方法名称)是一模一样,没有任何区别.
AFNetworkReachabilityManager :实时监测网络状态的工具类.当前的网络环境发生改变之后,这个工具类就可以检测到.
AFSecurityPolicy :网络安全的工具类, 主要是针对 HTTPS 服务.
AFURLRequestSerialization :序列化工具类,基类.上传的数据转换成JSON格式(AFJSONRequestSerializer).使用不多.
AFURLResponseSerialization :反序列化工具类;基类.使用比较多:
AFJSONResponseSerializer; JSON解析器,默认的解析器.
AFHTTPResponseSerializer; 万能解析器; JSON和XML之外的数据类型,直接返回二进制数据.对服务器返回的数据不做任何处理.
AFXMLParserResponseSerializer; XML解析器;
<h1>5、实现过框架或者库以供他人使用么？如果有，请谈一谈构建框架或者库时候的经验；如果没有，请设想和设计框架的public的API，并指出大概需要如何做、需要注意哪些问题，以使人人更容易地使用你的框架。</h1>
从以下角度出发来思考和设计公共框架：
• 确保外部调用简单，且保证有详细的头文件注释说明。
• 确保API编码规范，保证风格统一。
• 确保API易扩展，可以考虑预留参数
• 确保没有外部依赖或者依赖要尽可能的少，以保证公共库的纯洁（原则上不能有外部依赖）
• 确保易维护，不存在冗余API
<h1>6、简述下苹果的开发框架？</h1>
Foundation
提供OC的基础类（像NSObject）、基本数据类型等
UIKit
创建和管理应用程序的用户界面
QuartzCore
提供动画特效以及通过硬件进行渲染的能力
CoreGraphics
提供2D绘制的基于C的API
SystemConfiguration
检测当前网络是否可用和硬件设备状态
AVFoundation
提供音频录制和回放的底层API，同时也负责管理音频硬件
CFNetwork
访问和配置网络，像HTTP、FTP和Bonjour Services
CoreFoundation
提供抽象的常用数据类型，如Unicode strings、XML、URL等
CoreLocation
使用GPS和WIFI获取位置信息
