Представьте себе простой UITableView со списком из 200 строк.Некоторые из этих строк являются пользовательскими, маскирующимися под строки заголовка UI Section
и имеющими поддержку sticky , когда они достигают вершины.
Очень похоже на стандартную iOS Contacts app.
Когда пользователь прокручивает табличное представление, он отслеживает расположение этих строк пользовательского раздела в scrollview и управляет, когда они должны придерживаться, и когда они должны быть отпущены, чтобы прокрутить верхнюю часть для других строк раздела.чтобы заменить его.
func scrollViewDidScroll(_ scrollView: UIScrollView) {
...
for sectionRow in allSectionRows {
let sectionRowRect = tableView.rectForRow(at: sectionRow.indexPath)
let rowPositionY = sectionRowRect.origin.y + -tableView.contentOffset.y
// ... compare rowPositionY if it has reached or passed
// its sticky location in tableview
}
...
}
Хотя это хорошо работает для отслеживания местоположения каждой строки, я обнаружил, что масштабирование с помощью ~ 50 строк сечения создает снижение производительности.Вызывая медленные устройства iOS к прокрутке со скоростью ~ 10-15 кадров в секунду, что нарушает плавность работы пользователя.
В моем тестировании было показано, что tableView.rectForRow()
и tableView.contentOffset.y
являются виновниками во время обработки.Удаление любого из них немедленно улучшает плавную прокрутку.Конечно, тогда это нарушает функциональность.
Я пробовал кэшировать sectionRowRect = tableView.rectForRow(at: sectionRow.indexPath)
, но затем получаю странный артефакт, где rowPositionY
, кажется, дрейфует.
Какие возможные оптимизации можно рассмотретьразрешить этот цикл?