? ? ? ? 現(xiàn)在iOS的求職中苹粟，有時候會遇到關(guān)于多線程的問題--“你在項目中飞盆，什么時候用到過多線程”恐锦，然后就能聽到無數(shù)多的AFN請求數(shù)據(jù)滑燃，各種異步請求網(wǎng)絡數(shù)據(jù)的答案役听，但是這個答案講道理，比較粗糙表窘，AFN確實有使用異步請求典予，但是我們在使用的時候，直接發(fā)送Post/Get請求就行了乐严，異步開啟子線程并不是我們操作的瘤袖，而是AFN自己底層進行操作的！ -->所以昂验，如果答到AFN捂敌，恐怕不是最理想的答案。
如圖既琴，只是簡單的Post請求操作占婉，然后我們打開progress，這是AFN在發(fā)送請求的--> ? ? ? ? Block{ ?xxx}呛梆，我們未添加任何dispatch_asyn 或者 NSOperation 的情況下锐涯，通過打印 獲取當前線程。
如圖填物，我們發(fā)現(xiàn)我們未使用異步發(fā)送請求的Post請求的前提下纹腌，AFN請求執(zhí)行的線程并不是在主線程霎终！ --> 而是自己開了一個子線程，所以如果面試的時候回答 AFN升薯，肯定就暴露了自己莱褒，因為AFN的異步請求并不是我們調(diào)用的！我們只是一句簡單的Post請求代碼涎劈。
華麗分割線 ---->那如何回答這個問題广凸！
首先我想說的是，其實在實際開發(fā)中蛛枚，用到多線程的最常見的就是發(fā)送網(wǎng)絡請求獲取數(shù)據(jù)的時候谅海，因為這確實是一項耗時操作，但是因為有AFN在蹦浦，所以我們處理網(wǎng)絡請求其實很簡單扭吁，異步處理是AFN底層做的，并不是我們做的事盲镶！這點定要切記＝耐唷！
那我們有地方用到異步處理嗎溉贿？ 答案是有的枫吧！
處理圖片的壓縮的時候！
當有一定工作經(jīng)驗的移動應用開發(fā)工程師宇色，在與產(chǎn)品經(jīng)理夜以繼日的撕逼生活中九杂，潛意識的會對產(chǎn)品的用戶體驗比較上心，為了與產(chǎn)品經(jīng)理之間友好相處（捷徑-->少溝通Ｐ洹Ｄ崮稹），在開發(fā)中植影，對于性能優(yōu)化只能說-->銘記于心。
壓縮時間計算-->時間差：
NSDate* StartTime = [NSDate date];
//圖片壓縮代碼
double deltaTime = [[NSDate date] timeIntervalSinceDate:StartTime];
NSLog(@"cost time = %f", deltaTime);
上面2圖所示涎永，異步壓縮的耗時思币，差不多是同步壓縮效率的1000倍
同時，如果壓縮超大圖（比如20M的圖片）-->壓縮到500K羡微，如果不開啟子線程異步壓縮谷饿，通過工具檢測-->內(nèi)存占用可能達到1G，這里由于我們常用的圖妈倔，應該都是<2~3M博投，所有內(nèi)存占用相對沒耗時的差距這么明顯，就不貼出來了盯蝴。
-->1000倍的效率差距毅哗，異步壓縮的作用性就出來了
進階篇-->實際開發(fā)中的GCD使用听怕！
主隊列的異步執(zhí)行
具體用法：實現(xiàn)圖片輪播功能時，設置viewWillAppear 與 數(shù)據(jù)源方法的執(zhí)行順序問題虑绵！
-->用放大數(shù)倍數(shù)據(jù)源的方式（比如50倍）尿瞭，使用collectionView 的良好復用性，實現(xiàn)廣告圖片的無限輪播翅睛。
正常的執(zhí)行順序-->viewWillAppear（or viewDidLoad） --> tableView Delegate
使用主隊列的異步-->實現(xiàn)數(shù)據(jù)源先執(zhí)行声搁，在執(zhí)行viewWillAppear方法
如圖，我們會發(fā)現(xiàn)捕发，tableView Delegate的方法疏旨，竟然走在了viewWillAppear 方法的前面！用這種方法扎酷，我們可以先設置tableView cell的count檐涝，再在viewWillAppear中實現(xiàn)滾動，可以完美實現(xiàn) --> 廣告圖片無限輪播效果~
如圖有小白想知道霞玄，如何用collectionView實現(xiàn)圖片無限滾動的骤铃，我到時候簡單講解一下實現(xiàn)的原理，開源下簡單功能的代碼坷剧。
