Привет всем. Нужно проверить приложение на медленном интернете, подскажите можно как-то ограничить скорость wifi соединения до 3g, 2g и т.д?
не важно эмуль или телефон
iamthevoid
iamthevoid
Точнее нет
iamthevoid
Важно)
Сергій
Можете подсказать как на процессоре amd запустить эмулятор?
https://android-developers.googleblog.com/2018/07/android-emulator-amd-processor-hyper-v.html
iamthevoid
Про эмулятор не знаю, а в настройках реального девайса можно выбрать там, где "сим карта и сеть"
Anonymous
понял, спасибо
Anonymous
да я нашел)
Mike
и если там лагает — значит, нужно оптимизировать
[некропост]
А во что обычно упираешься и как решаешь?
(у меня классика жанра — долгий measure текста, например)
Gregory
[некропост]
А во что обычно упираешься и как решаешь?
(у меня классика жанра — долгий measure текста, например)
у меня были сложные лэяуты, упрощал
Gregory
measure текста в теории тоже да, Коля в это упирался, решил тем, что начал разбивать текст на блоки
S
как в тестах замокать класс с val полями , присвоив этим полям свои тестовые значения? не менять же в оригенальном классе val на var ?
Gregory
Сергій
Konstantin
ну все пиздося щас начнется
Mike
правильный ответ — не мокать)
Dj
Неуместный совет. Котлинские классы не отличаются от джавовых.
Котлиновские чуточку лучше, там data классы есть
Konstantin
Котлиновские чуточку лучше, там data классы есть
кслову говоря - набор из сотен дата классов и десятков параметров в них генерит тысячи методов
Gregory
Котлиновские чуточку лучше, там data классы есть
это всё синтаксический сахар, жопа слипнется
Gregory
на джаве всё то же самое можно сделать, но более понятно и более явно
Michael
Gregory
а это ведь всего лишь синтаксический сахар над именованными классами
а ООП — это всего лишь синтаксический сахар, чтобы явно не передавать this
Dj
это всё синтаксический сахар, жопа слипнется
Джява так то тоже синтаксический сахар над байткодом
Konstantin
ассемблер это синтаксический сахар над перфокартами
Gregory
ну были бы те поля не val а final . что бы изменилось?
вот так я узнал, что этот val ещё и final
Dj
кслову говоря - набор из сотен дата классов и десятков параметров в них генерит тысячи методов
Это как то влияет на перформанс приложения?
Gregory
вот видите насколько джава более понятная
Mike
measure текста в теории тоже да, Коля в это упирался, решил тем, что начал разбивать текст на блоки
можешь рассказать деталей? Тоже постоянно утыкаюсь в это
Gregory
можешь рассказать деталей? Тоже постоянно утыкаюсь в это
мне кажется, @DrKLO может лучше рассказать, я в этом не особо разбирался
Mike
Эти методы не вызываются же, скорее всего просто набухает dex файл
память, скорость верификации-загрузки-линковки классов
Gregory
но там в MessageObject лежит массив из StaticLayout, это оно
Михаил
Nick
я там сперва создавал static layout для всего текста, смотрел на каком символе заканчивается 10я строка и создавал много мелких
Mike
посмотри на mockk
как же бесят все эти kkkkk-инструменты. Никогда не писали нормальный код, а тут — херак — правильные дефолты в языке, всё сломалось, котлин виноват
Nick
так вот там на новых андроидах эти 10 строк могли потом 11 занять)
Mike
так вот там на новых андроидах эти 10 строк могли потом 11 занять)
А почему в принципе много маленьких блоков быстрее, чем один большой?
Nick
я по видимости отсекал потом по мере скрола
Mike
а, всё, понял
Gregory
А почему в принципе много маленьких блоков быстрее, чем один большой?
лагала отрисовка длинных сообщений, потому что оно пыталось рисовать кучу текста за пределами экрана
Dj
лагала отрисовка длинных сообщений, потому что оно пыталось рисовать кучу текста за пределами экрана
Лол, а рекуклер не решает таких проблем?
Михаил
как же бесят все эти kkkkk-инструменты. Никогда не писали нормальный код, а тут — херак — правильные дефолты в языке, всё сломалось, котлин виноват
ну если люди привыкли - кто ж их всех будет переучивать?
Gregory
Лол, а рекуклер не решает таких проблем?
не решает, представь, что у тебя длинное сообщение высотой 10000 пикселей
Mike
Лол, а рекуклер не решает таких проблем?
решает, если разбивать сообщения не внутри вьюшки, а внутри адаптера
Mike
ну и сделать отдельные вьютайпы для начала сообщения, серединки и конца
Mike
а, во, сделать их декоратором
Dj
@grishka @Harmonizr Понял, спс
Gregory
да, Миш, ты сейчас описываешь как работала лента в ВК у меня
Konstantin
а для тех кто в таньке - чего пытаетесь сделать? рендер текста руками на канвасе?
Gregory
в таньке кек
Mike
да, Миш, ты сейчас описываешь как работала лента в ВК у меня
А, вот оно что.
Мне рассказывали, что разные части постов были разными вьютайпами, и упустили главное
Mike
а для тех кто в таньке - чего пытаетесь сделать? рендер текста руками на канвасе?
просто обсуждаем тормозные места
Nick
canvas.clipRect должен решать еще медленную отрисовку больших текстов, но это не точно
Gregory
А, вот оно что.
Мне рассказывали, что разные части постов были разными вьютайпами, и упустили главное
да, посты разбивались на post display items
Gregory
я потом этот же способ применял в конкурсном клиенте телеграма)
Gregory
общая идея — разбивать сложные вьюшки на более мелкие части, которые будет легко переиспользовать
Gregory
скажем, верхнюю часть поста, где аватарка, имя, время и кнопка меню, переиспользовать намного проще с точки зрения сложности кода, чем если бы весь пост был одной вьюшкой
Mike
привет пользователям констреинта, которые привыкли сваливать всё в кашу ;)
Gregory
сами виноваты, никогда не пользовался им
Gregory
могу что угодно сверстать на трёх системных лэяутах, frame, linear и relative
Mike
скажем, верхнюю часть поста, где аватарка, имя, время и кнопка меню, переиспользовать намного проще с точки зрения сложности кода, чем если бы весь пост был одной вьюшкой
это ещё и с точки зрения компонентного дизайн-подхода классно
Александр
Авэ графическому редактору, hehe.
Gregory
это ещё и с точки зрения компонентного дизайн-подхода классно
ага, переиспользуемые компоненты всегда хорошо
Gregory
а не котлины и эрыксы и вот это вот всё