Как стать автором
Обновить

Сложные отображения коллекций в iOS: проблемы и решения на примере ленты ВКонтакте

Время на прочтение 17 мин
Количество просмотров 21K
Всего голосов 25: ↑25 и ↓0 +25
Комментарии 11

Комментарии 11

Спасибо, оч круто
спасибо)
Спасибо, очень интересно!
И хорошо показано что и в мобильной разработке можно до бесконечности копать в глубину и ширину.
Судя по примерам вы используете Obj-C, но правильно ли я понимаю, что все то же самое можно написать на swift?
Ещё интересно не проводили ли вы сравнительного тестирования похожих UI на классике и SwiftUI?
спасибо) всё так, в основном код на Obj-C, хотя уже есть отдельные модули на Swift, но описанные подходы не зависят от языка. В плане SwiftUI не подскажу, не изучал его, только слегка посмотрел в документации, что он похож на наш декларативный layout. Но в плане исследования производительности, думаю, там применимы те же подходы, так как система рендеринга должна быть общая.

“ При росте количества ограничений в layout в худшем случае вычисления могут замедлиться экспоненциально.”


Если не ошибаюсь, с iOS 12 SDK(или рантайма, нужно проверить) это уже не актуально, зависимость стала линейной.

Я немного по-другому понял доклады инженеров Apple. На сколько я понимаю, они обещают линейную производительность на отображениях без сложных связей между «соседями ветвями иерархии». То есть, если ограничения выставлены, например, только не далее связи «родитель-потомок». Не видел информации, чтобы появился более эффективный алгоритм решения системы ограничений. Но, возможно, я ошибаюсь.
Обратите внимание на методы boundingRect и sizeWithAttributes. Не советую с их помощью считать размер содержимого UILabel/UITextView/UITextField.

В достаточно серьезном докладе Как мы делаем лейаут пользовательского интерфейса — Андрей Мишанин в ответах на вопросы слушателей автор как раз упоминает, что они кэшируют размеры строчек через boundingRect...

Ваше мнение, насколько оправдано использование этих методов? Может в какой-то цифре вы сможете выразить негативные последствия их использования, т.е., предположим, вы имеете опыт, который показывает, что лишь ХХ% времени эти функции ведут себя не так адекватно как мы ожидаем?

1) Моё мнение такое, что нужно использовать связку UILabel/UITextView и методов boundingRect с предосторожностью, так как я нигде в документации не нашёл подтверждения, что в основе layout NSString/NSAttributedString лежит используемый UILabel/UITextView TextKit. То есть, тот факт, что boundingRect в каких-то случаях (в случае UILabel) совпадает с результатами работы TextKit — недокументированное поведение. Но если будет подтверждение, что в основе лежат абсолютно одни и те же методы, и в эти методы передаются абсолютно идентичные аргументы — конечно, можно использовать boundingRect + UILabel. Для примера код playground. Здесь можно заметить, что результаты UILabel.sizeThatFits и NSAttributedString совпадают, если округлить в бОльшую сторону результат boundingRect с учётом screen scale, то есть до ближайшего бОльшего количества пикселей. Для UITextView значения уже не совпадают, хотя согласно документации TextKit в UITextView тоже используется TextKit, но, явно, с другими параметрами (причём, этими параметрами мы сами можем управлять). Конечно, можно и для UITextView попробовать подобрать параметры boundingRect, но насколько это корректно и детерминировано?
2) Мы сейчас в Ленте не используем boundingRect но из прошлого опыта смутно помню, что раньше приходилось подбирать параметры и константы отступов, чтобы результат boundingRect совпадал с тем, как UILabel располагает текст внутри себя.

Спасибо за ответ и за публикацию, делитесь чаще подобным бесценным опытом!

Спасибо, будем стараться!

Зарегистрируйтесь на Хабре , чтобы оставить комментарий