Очень высокое время загрузки секционированного UITableView

Question

- (NSArray *)dataSourceForIndividuals:(NSArray *)individuals { 
    // Assumption: displayNames are sorted alphabetically 
    NSUInteger sectionIndexTitlesCount = [[self sectionIndexTitles] count]; 
    NSMutableArray *dataSource = [NSMutableArray arrayWithCapacity:sectionIndexTitlesCount]; 
    NSUInteger index = 0; 
    for (index = 0; index < sectionIndexTitlesCount; index++) { 
     [dataSource addObject:[NSMutableArray array]]; 
    } 
    SEL selector = @selector(displayName); 
    index = 0; 
    for (TDTIndividual *individual in individuals) { 
     NSInteger sectionNumber = [[UILocalizedIndexedCollation currentCollation] sectionForObject:individual collationStringSelector:selector]; 
     [[dataSource objectAtIndex:(NSUInteger)sectionNumber] addObject:individual.objectID]; 
     ++index; 
    } 
    return dataSource; 
} 

Приведенный выше код работает нормально, но время, затраченное вторым на цикл, слишком велико, если число людей велико, есть ли лучший способ сделать это?

Answer 1

Мы не знаем вашу структуру данных или какие операции вы используете в некоторых методах. Было бы хорошо, если бы вы могли измерить время компиляции, которое используют некоторые функции. У вас может быть идея в instruments или measure that in code.

Тем не менее, возможно, вы можете перебрать свой [UILocalizedIndexedCollation currentCollation] и добавить к нему объекты. Вероятно, будет более эффективным, чем проверка для каждого объекта, в каком разделе он соответствует.

Answer 2

Как отмечает @ Tiago-Almeida, мы ничего не знаем о ваших структурах данных. Мы также не знаем, что вы подразумеваете под «большим» числом людей. И его рекомендация использовать инструменты, чтобы увидеть, где идет время, очень актуальна.

Однако, что бросается в глаза, это одна из причин, по которой представление таблицы работает так, чтобы позволить источнику данных ленить загружать свои данные. Если у вас есть большое количество людей, может быть запретительно загружать их в гигантский массив массивов спереди.

Таким образом, вы можете либо:

• Измените структуры данных аккомпанемента, так что он не требует перебора всего списка, чтобы отсортировать их в секцию каждый раз, когда вам нужен вид таблицы. Честно говоря, этот подход - мой первый инстинкт, как будто я знал, что число людей может быть большим. Я бы не захотел повторять весь список повторно. Возможно, вы могли бы изменить свои геттеры/сеттеры, чтобы автоматически поддерживать эти массивы секций, чтобы они уже присутствовали, когда они вам нужны?

• Выполняйте некоторые работы асинхронно. Загрузите управляемое количество людей, создайте не изменяемую копию массивов для использования в качестве источника данных (обязательно сделайте глубокую копию), а затем выполните оставшуюся часть работы в фоновом режиме. Затем периодически обновляйте источник данных с помощью новой не изменяемой копии и вызывая refreshData в основном потоке.

Очевидно, что асинхронный подход не является идеальным, так как таблица может «прыгать» на пользователя, особенно если они пытаются прокручивать таблицу сразу. Но если нет другого выбора, и общее время загрузки все еще управляемо, то это намного лучший опыт для пользователя, чем просто блокировка до тех пор, пока весь массив не будет отсортирован/загружен.