记一次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一次。这相当于是一个原则性的约定,不遵守该约定就容易造成很多问题。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容