公元前
運用的就是上面的這種三行代碼搞定一切的網頁加載的方法。
公元後
後來在項目中遇到了使用UIWebView控件時，理所當然的愚蠢的
用了裡面的方法完成了Boss的需求，但後期測試的時候，在腎4上
以及用Charles工具模拟慢網速的時候發現這樣做的使用者體驗不太
好，主要的問題就是當該網頁内容非常多的時候，在2G網絡和移
動3G網絡的時候，出現加載太慢，出現卡頓的現象。甚至在舊機
器上會出現崩潰的現象。
1.舊的手機CPU性能記憶體較差，一下占用率太高。（PS：後來
iOS8之後蘋果出了新的WebKit架構WKWebKit，性能提升了不
少，建議不需要适配iOS8以下的可以考慮嘗試）
2.頁面内容較多，資料量龐大，即使是新款手機也扛不住呀（最
典型的應該是天貓商城App的首頁啦，下拉了幾分鐘還沒有到達盡
頭，一下子加載全部資料，手機肯定扛不住呀）
3. 運用上面那種人人都會的沒技術含量的代碼是在主線程裡面進
行的，資料量大，網速不行，會一值在加載，影響使用者進行其他
操作
換手機？别逗了一個腎機依舊那麼貴，NO Pass
加載頁面的時候做上緩存，甚至分段的展示資料（先隻加載一部分資料，随着使用者下拉再逐漸加載）
既然擔心資料量多造成在主線程調用會卡死，那就想想辦法另外開辟線程加載資料。
上邊的代碼方法是萬萬行不通的最常用的還是想想辦法另辟蹊徑的開辟新航線：
這裡我們可以用到常用多線程四種方法中的一種：
NSOperationQueue 操作隊列中進行程式設計
1.建立一個隊列并初始化：
2.建立操作對象并封裝要執行的任務
将對象添加到隊列中
3.開辟一個新的線程，實作執行的任務,擷取從伺服器上加載的資料，并存儲在NSData中
4.判斷從伺服器中正确的獲得資料後，再傳回主線程中進行資料的加載（為啥要傳回主線程，因為蘋果規定資料加載到控件上必須在主線程上進行，防止多個線程修改控件引發崩潰和莫名其妙的問題）
其中第二參數需要調用一下下面方法，擷取指定URL的MIMEType類型
第四個參數是傳的URL的位址，當時我嘗試着指派nil後發現網頁裡面的圖檔就不能正确的顯示出來
1.首先我們運用了多線程加載資料，不影響使用者操作其他資料
我還故意調皮的在downLoadWeb中加上下面的代碼：
測試結果完全不影響使用者操作其他地方，要是按原始的三行代
碼搞定UIWebView就會出現一直卡的悲催體驗。
2.我們先在子線程中把資料加載到NSData中，再 通過loadData:函
數進行加載，相當于進行了本地資料的讀取操作，本地讀取的速
度是遠遠大于網絡擷取的。
3.對于網頁資料基本保持不變的，我們完全可以 用資料庫存儲
NSData裡面的資料，下次進入免去了下載下傳的過 程。這在三行代碼
的方法是完全行不通的。