现在iOS的求职中，有时候会遇到关于多线程的问题--“你在项目中，什么时候用到过多线程”，然后就能听到无数多的AFN请求数据，各种异步请求网络数据的答案，但是这个答案讲道理，比较粗糙，AFN确实有使用异步请求，但是我们在使用的时候，直接发送Post/Get请求就行了，异步开启子线程并不是我们操作的，而是AFN自己底层进行操作的！ -->所以，如果答到AFN，恐怕不是最理想的答案。

模拟-发送AFN请求

如图，只是简单的Post请求操作，然后我们打开progress，这是AFN在发送请求的-->         Block{  xxx}，我们未添加任何dispatch_asyn 或者 NSOperation 的情况下，通过打印 获取当前线程。

AFN执行过程的线程

如图，我们发现我们未使用异步发送请求的Post请求的前提下，AFN请求执行的线程并不是在主线程！ --> 而是自己开了一个子线程，所以如果面试的时候回答 AFN，肯定就暴露了自己，因为AFN的异步请求并不是我们调用的！我们只是一句简单的Post请求代码。

华丽分割线 ---->那如何回答这个问题！

首先我想说的是，其实在实际开发中，用到多线程的最常见的就是发送网络请求获取数据的时候，因为这确实是一项耗时操作，但是因为有AFN在，所以我们处理网络请求其实很简单，异步处理是AFN底层做的，并不是我们做的事！这点定要切记！！

那我们有地方用到异步处理吗？ 答案是有的！

处理图片的压缩的时候！

图片压缩处理

当有一定工作经验的移动应用开发工程师，在与产品经理夜以继日的撕逼生活中，潜意识的会对产品的用户体验比较上心，为了与产品经理之间友好相处（捷径-->少沟通！！），在开发中，对于性能优化只能说-->铭记于心。

压缩时间计算-->时间差：

NSDate* StartTime = [NSDate date];

//图片压缩代码

double deltaTime = [[NSDate date] timeIntervalSinceDate:StartTime];

NSLog(@"cost time = %f", deltaTime);

未开启异步压缩图片-耗时

开启异步压缩图片

上面2图所示，异步压缩的耗时，差不多是同步压缩效率的1000倍

同时，如果压缩超大图（比如20M的图片）-->压缩到500K，如果不开启子线程异步压缩，通过工具检测-->内存占用可能达到1G，这里由于我们常用的图，应该都是<2~3M，所有内存占用相对没耗时的差距这么明显，就不贴出来了。

-->1000倍的效率差距，异步压缩的作用性就出来了

进阶篇-->实际开发中的GCD使用！

主队列的异步执行

具体用法：实现图片轮播功能时，设置viewWillAppear 与 数据源方法的执行顺序问题！

-->用放大数倍数据源的方式（比如50倍），使用collectionView 的良好复用性，实现广告图片的无限轮播。

正常执行顺序

正常的执行顺序-->viewWillAppear（or viewDidLoad） --> tableView Delegate

使用主队列的异步-->实现数据源先执行，在执行viewWillAppear方法

主队列异步执行--执行顺序的改变

如图，我们会发现，tableView Delegate的方法，竟然走在了viewWillAppear 方法的前面！用这种方法，我们可以先设置tableView cell的count，再在viewWillAppear中实现滚动，可以完美实现 --> 广告图片无限轮播效果~

如图有小白想知道，如何用collectionView实现图片无限滚动的，我到时候简单讲解一下实现的原理，开源下简单功能的代码。