да, только автор пишет специфично код

Он пишет как надо

Скорее всего просто забыли зарефакторить, а начинали с активити

Скорее всего просто забыли зарефакторить, а начинали с активити

о чем я и говорю)

Я в джавачате пояснял, почему так писать надо

Можно PR сделать

представь такую простынку на 100+ строк кода. хотя можно было сделать inflate xml

А разве инфлейт не медленнее?

Скорее всего просто забыли зарефакторить, а начинали с активити

BaseFragment от объекта наследуется

Я в джавачате пояснял, почему так писать надо

Можешь форварднуть?

А разве инфлейт не медленнее?

я разницы не особо замечаю (как пользователь)

Сто лет назад писал, но вкратце: это работает и на старых версиях ведра - раз Это работает быстрее, чем создание активити и не надо ебаться с ненужным лайфсайклом (там даже configChanges=orientation|screenSize) Это позволяет какие хочешь анимации мутить и даже делать свайп по кнопке назад, чего не очень позволяют фрагменты

Сто лет назад писал, но вкратце: это работает и на старых версиях ведра - раз Это работает быстрее, чем создание активити и не надо ебаться с ненужным лайфсайклом (там даже configChanges=orientation|screenSize) Это позволяет какие хочешь анимации мутить и даже делать свайп по кнопке назад, чего не очень позволяют фрагменты

про последнее не думал<. Спс

Инфлейт не медленнее. Когда парсится xml он все равно переводится в обычные вызовы методов. Так что единственные потери на парсинг xml, и то они совсем не критичны

Инфлейт не медленнее. Когда парсится xml он все равно переводится в обычные вызовы методов. Так что единственные потери на парсинг xml, и то они совсем не критичны

Xml вроде в апк бинарный

Все экраны там в рантайме отрисовываются

Это меньше чтения с диска и опять же можно забить на смену ориентации

Только код становится нечитаемым

Все там читаемо :)

для новичков действительно сложно, да

Хз. Ненавижу построение разметки в коде

Все там читаемо :)

Хз. Ненавижу построение разметки в коде

А мне норм)

Все экраны там в рантайме отрисовываются

зато ловишь удивительные баги иногда. у меня виджет отправки фото/видео был поверх локскрина

зато ловишь удивительные баги иногда. у меня виджет отправки фото/видео был поверх локскрина

У меня активити иногда поверх локскрина рисовалась

для новичков действительно сложно, да

Я придерживаюсь политики, чем меньше кода, тем лучше (в разумных пределах). Тогда сложнее проебаться. Но если создание вьюх в коде оправдано, то пожалуйста

Оно в андроиде оправдано еще как

Надо натив активити делать?

Оно в андроиде оправдано еще как

Видимо пока мне удавалось обходиться без этого)

Оно в андроиде оправдано еще как

прекрасно обхожусь без этого

Во-первых, как я уже сказал, это меньше чтения с диска Во-вторых, если наловчиться, можно отрисовывать всё прямо в методе onDraw - и таким образом у тебя будет элемент списка из одной вьюхи, а ради одной вьюхи хмл уже городить нет смысла

и это будет работать максимально быстро

один onDraw - да

GLSurfaceView.Renderer

Во-первых, как я уже сказал, это меньше чтения с диска Во-вторых, если наловчиться, можно отрисовывать всё прямо в методе onDraw - и таким образом у тебя будет элемент списка из одной вьюхи, а ради одной вьюхи хмл уже городить нет смысла

т.е. ресурсы всегда принудительно читаются с носителя и кеша нет?))

и это будет работать максимально быстро

Ты видимо что-то очень крутое пишешь где для тебя коричневая производительность до таких оптимизаций?

Бля. Свайп

Критична производительность

т.е. ресурсы всегда принудительно читаются с носителя и кеша нет?))

Вот точнее смотреть надо уже код андроида Но как минимум в первый раз это с диска читать надо :)

Можно трассирнуть

При surfaceChanged

Ты видимо что-то очень крутое пишешь где для тебя коричневая производительность до таких оптимизаций?

Ну как минимум телеграму S Edition это позволяло отлично работать на HTC Desire

просто такая погоня за скоростью напоминает мне фразу про преждевременную оптимизацию

Я это все просто изучаю чтобы конкурсный телеграм со временем допилить и выложить, да так, чтобы не позорно было называть его быстрым

Это я еще про переиспользование битмапов и LMDB не говорил

Я это все просто изучаю чтобы конкурсный телеграм со временем допилить и выложить, да так, чтобы не позорно было называть его быстрым

Интересно. Спасибо за инфу)

Это я еще про переиспользование битмапов и LMDB не говорил

Обожаю так делать

Вот у меня в конкурсном клиенте как раз можно улучшить вот эти несколько моментов: одно вью на элемент списка, стек вью вместо фрагментов, переиспользование битмапов с помощью использования libjpeg из последних версий андроида

А сможешь дать ссылку на конкретный пример где вся отрисовка через один onDraw происходит?

думаю, можно самому написать

только хитТесты надо самому считать

Это мне напоминает winapi с WM_PAINT'ом, и прочие фреймворки, рисующие виджеты в один проход

https://github.com/DrKLO/Telegram/search?utf8=✓&q=ondraw https://github.com/DrKLO/Telegram/search?utf8=✓&q=staticlayout&type=Code

Фигасе, в урле галочки

ага, сам только сейчас заметил

прикольная фича

Я это все просто изучаю чтобы конкурсный телеграм со временем допилить и выложить, да так, чтобы не позорно было называть его быстрым

надеюсь он будет лучше официального. потому что он умудряется лагать при заходе в определенные чаты)

дай угадаю: там где спамят эмодзи

в телеграме замена эмодзи в UI-треде, это плохо

А почему не в async task?

дай угадаю: там где спамят эмодзи

нет, текст / фото

А почему не в async task?

его еще кто-то использует для задач с ui?

А почему не в async task?

не знаю кстати асинктаски тоже так себе вещь

А в чем тогда? В thread?

ну да

в идеале ты должен еще следить за количеством выполняемых Thread'ов и иметь возможность их приостанавливать, если тебе нужно

повторяться не буду, что в айфоне именно так и происходит

А с юи через хэндлер?

Да Я правда уже не помню, куда я в своем таскменеджере запихнул Looper.prepare и вообще у меня такое ощущение что я его выпилил

ERROR: S client not available

Но с другой стороны работают же Message.sendToTarget как-то

я не опускаюсь на такой низкий уровень сам. использую Otto

я не опускаюсь на такой низкий уровень сам. использую Otto

Аналогично

Было бы все плавно, если бы андроид был real-timeOS

Но тогда ограничения были бы просто прокрустовы

вот однажды я все-таки доберусь до разработки под BB10, посмотрю что там такого сложного

ну кроме того что Qt там четвертый

и то так все об этом говорят, будто это что-то плохое

А гцц есть?

А гцц есть?

Ты про GCC? Там же аналогичный QCC (QNX C Compiler)

Во qnx

Вот то, что C++11 там неполный, насколько я помню — это да, но есть буст же

Это да

Было бы все плавно, если бы андроид был real-timeOS

Нет. Проблема не в этом

да, согласен

Проблема в диспетчеризации

И локировках

И gc:"а не почистить ли мне память"?

С gc утрирую?

Это я еще про переиспользование битмапов и LMDB не говорил

А lmdb зачем? Не проще использовать mmap?

Ну это если тебе БД нужна

Просто линукс и так обычно preempt и rt там лишнее

ксамарин реально на всех мобилах аппу поднимает или это какой-то костыль?

тоже прочел хабр?

где они объявили, что ксамарин бесплатен?)

теперь

ага и жетбрейнсы райдер пилят, очень это все странно

не

платформозависимый код остается все равно

всмысле? там нет абстракции ui?

ксамарин реально на всех мобилах аппу поднимает или это какой-то костыль?

Просто там есть либмоно

И дотнет-адаптеры