記一次UITableView優化

在專案中有一個機器人聊天頁面，把歷史聊天記錄寫入本地資料庫，下次進入頁面時會先從資料庫中查詢所有歷史聊天記錄並顯示。

為了提高頁面流暢性，採取了非同步獲取歷史資料的方式，但是結果發現總是點選進入聊天頁面的時候會卡頓一下，特別是聊天訊息比較多的情況下，使用者體驗較差。為了提高頁面流程性，於是開始檢查自己的程式碼，非同步獲取資料是沒錯，從資料庫中查詢資料也非常快。但是通過列印時間戳的方式，發現呼叫reloadData方法前後時間差比較大，經檢查發現自己把修改資料來源的程式碼寫到非同步程式碼中造成的。特記錄於此，希望以後寫程式碼的時候更加細心一點，注意細節，不要想當然地寫。

兩種修改資料來源和重新整理列表的方式如下：

//假如資料來源是dataSource
    //方式1
    dispatch_queue_t dispatchQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    dispatch_async(dispatchQueue, ^{
        NSLog(@"begin at %@",TimeStamp);
        //耗時的操作 拿到data 操作data
        [dataSource addObjectsFromArray:data];
        NSLog(@"fetch data finished at %@",TimeStamp);
        dispatch_sync(dispatch_get_main_queue(), ^{
            [tableView reloadData];
            NSLog(@"end at=%@",TimeStamp);
        });
    });

    //方式2
    dispatch_queue_t dispatchQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    dispatch_async(dispatchQueue, ^{
        NSLog(@"begin at %@",TimeStamp);
        //耗時的操作 拿到data  操作data
        NSLog(@"fetch data finished at %@",TimeStamp);
        dispatch_sync(dispatch_get_main_queue(), ^{
            [dataSource addObjectsFromArray:data];
            [tableView reloadData];
            NSLog(@"end at=%@",TimeStamp);
        });
    });

經過測試發現採用第二種方式，每次進入頁面非常快，基本上達到秒開，這裡測試時聊天資料將近200條。

測試結果如下：

方式1：
begin at 1488444419555.218018
fetch data finished at 1488444419575.990967  相差20.7729492188
end at=1488444421620.645996                  相差2044.6550293

begin at 1488444459916.071777
fetch data finished at 1488444459926.528809  相差10.45703125
end at=1488444461542.685059               相差1616.15625

begin at 1488444481942.781006
fetch data finished at 1488444481954.958008  相差12.1770019531
end at=1488444483555.129150               相差1600.17114258

begin at 1488444505205.805176   
fetch data finished at 1488444505216.610840  相差10.8056640625
end at=1488444506812.206055               相差1595.59521484


方式2：
begin at 1488444212553.555908
fetch data finished at 1488444212614.791992  相差61.2360839844
end at=1488444213317.329834               相差702.537841797

begin at 1488444275296.455811
fetch data finished at 1488444275307.606934  相差11.1511230469
end at=1488444275867.491943               相差559.885009766

begin at 1488444316944.398926
fetch data finished at 1488444316955.667969  相差11.2690429688
end at=1488444317508.981934               相差553.313964844

begin at 1488444352798.229980
fetch data finished at 1488444352812.494141  相差14.2641601563
end at=1488444353398.352051               相差585.857910156

由上可見方式2在操作完資料到重新整理UITableView之間的時間差比方式1的少很多。

其實總結一點：修改資料來源和重新整理UITableView的程式碼都必須在主執行緒中執行。跟容易造成UITableView訪問資料來源時越界的問題一樣，在修改UITableView的dataSource之後必須重新整理UITableView一次。這相當於是一個原則性的約定，不遵守該約定就容易造成很多問題。