Sqlite + 80K行+ LIKE =键盘滞后

我有这个问题,我一直推迟解决,但现在是时候了.

我有一个基本的字典程序.它有一个UISearchBar和一个UITableView.它的工作方式除了在设备上运行时它会导致键盘滞后.(模拟器很好,当然)我有两种类型的搜索.按你型和回程.我发现两者都需要大约相同的时间来返回结果,但是As-you-type会使键盘滞后.

我有UISearchBar textDidChange,它接受searchText并将其发送到执行所有sqlite提升的搜索方法,将结果放入Array中.重新加载表格.

- (void)searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)searchText{
    if((searchType == SEARCH_AS_YOU_TYPE) && ([searchText length] >= 2)){
        NSString *myKeyword = [NSString stringWithFormat:@"%@", searchText];
        [self search:myKeyword];
        [myTableView reloadData];
    }
}

我将结果限制为50.我的SQL查询使用了LIKE和OR,还没有办法解决.

SELECT WORD_ID, DEFIN, PINYIN, SIMP, TRAD from WORDS where DEFIN LIKE "%to dog %" OR DEFIN LIKE "%dog" OR DEFIN LIKE "%dog%"  ORDER BY DEFIN LIMIT 50

我也尝试将[myTableView reloadData]移动到搜索方法中,希望键盘至少不会滞后.没有喜悦.遗憾的是,我知道sqlite基本上是检查每一行,当它使用like运算符时.但是对于80人来说3-4秒似乎有点慢.

任何想法,想法,意见或建议将不胜感激!

听起来你正在搜索并在同一个线程中准备好键盘.这样,您将搜索与字符一样多的次数,并且打字速度仅限于搜索速度.

一个合适的解决方案是将其分为两个线程,一个用于读取和显示键盘,第二个用于搜索和显示搜索结果.这样,如果您输入的速度比搜索速度快,那么只有搜索会滞后,而不是输入.例如,Firefox地址栏以这种方式工作.

由于两个线程以及两者之间的通信/协调,您的代码将更加复杂,但我认为这是唯一的好解决方案.