在2016年2月過年期間，我們的快行app收集的線上crash突然飆升，其中一個數組越界的問題，我們很百思不得其解，起初我并不看好隊友寫iOS的一些習慣，但是后來覺得可能對方的編程思想導致他會有的代碼風格，面對出現的很多問題，其實我看了代碼也百思不得其解，只能說如果是我做，我不會那么去設計這樣的iOS結構，也就不會出現這樣的問題，但是作為一名百度的程序猿這樣的想法是遠遠不夠，不能理清深處的原理，錯誤。不能讓對方信服就不太合格，自己也沒有提升技術，于是我掰開他的代碼，開始協(xié)作同伴一起探索真理。

線上crash崩潰地址指示在tableview 的代理內

按照原理，我們請求回來的數據是不會出現數組越界的，但是是為什么呢，就算此處做了防護，還是不知道為什么會crash，而且無法復現，跑幾萬次的代碼，偶爾出現的2到3次的crash，后來搬出了大神深度解析；

大灰灰的博客 http://www.itdecent.cn/p/db19b17a88f6

查閱代碼確實有很多處的dataSource直接被替換，直接被改變的地方，因為我們的程序員把城際專線，汽車票和拼車三處訂單列表均實現在同一個viewController，并且tableView的代理都賦給了dataSource，通過數據源來控制，在數據源內實現代理和cell的布局，反正我重來沒有這樣實現過。

當刷新控件在轉菊花的同時cell會往下滑動，有一個cell會滾出屏幕，菊花還在轉的同時 dataSource此時已經改變，菊花停止時cell往上滾動會重新繪制，此時tableVIew還沒有來得及relodate刷新，菊花停止轉動，cell向上移動，cell去向之前的dataSource去拿數據卻已經拿不到了，因為此時的dataSource已經改變，恰好數據源比之前的數據源上兩個數據，代理去讀去讀不到，tableView就炸掉了 。因此此種跑了上萬次的才會出現幾次crash的問題得到了解決

再看看寫的錯誤代碼

修改方法：把reloadData 位置放置到endRefreshing上面

徹底解決問題的辦法：先讓tableview刷新reloadData，然后再延時0.1秒endRefresh

// 主線程延遲執(zhí)行：

double delayInSeconds = 0.1f;

dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * NSEC_PER_SEC);

dispatch_after(popTime, dispatch_get_main_queue(), ^(void){

//? ? 延時endRefresh

});