Отрисовка текста одна из самых тяжёлых графических операций: она требует расчета текста на основе шрифта, размера текста, длины строки, переносов и прочих параметров. Поэтому важно заботиться о том чтобы при наличие большого количества теста на экране (например отображение большой статьи либо списка с множеством элементов в каждом из которых содержится текст). Для того чтобы оптимизировать отображение текста если следующие приемы:
* Отключение автоматического переноса на новую строку слов (нужно смотреть подходит ли это для вас, по умолчанию опция включена)
* #PrecomputedText - асинхронная подготовка текста для отрисовки (доступна в #AndroidX)
* Использование #Prefetch в #RecyclerView
* Разбиение большого текста на части и отображение их в #RecyclerView (к сожалению, будут проблемы с выделением на стыке частей)

Такие оптимизации позволяют ускорить отображение текста на Main Thread до 0.2-0.4 секунды вместо нескольких

Подробнее на эту тему рекомендую посмотреть
https://youtu.be/vXqwRhjd7b4

Автор: @ArtemBagritsevich

#ArchitectureComponents - это уже некий стандарт в Android разработке, поэтому разработчики допускают много ошибок, в связи с чем есть паттерны, котрых надо придерживаться, и антипаттерны, которых надо избегать, при работе с этим компонентом.

Что важно знать о работе с #LiveData, чем поделились на #AndroidDevSummit18:
* LiveData - это не Stream (или Observable из Rx), а скорее Holder значения.

* Не стоит создавать дополнительный lifecycle внутри #ViewModel, лучше использовать Transformation. Как пример, приводится оператор map который преобразует #LiveData на слое репозитория в #LiveData c данными с UI слоя, что является более безопасным подходом.

* #MediatorLiveData. Я не являюсь большим поклонником кастомных операторов, так как большинство задач можно решить используя стандартные операторы, однако они приводят пример того как написать map используя MediatorLiveData.

Антипатерны:
* Не используйте #LiveData для загрузки больших данных(например json файлов), помните что её назначение это хранение информации и всё что в неё попадёт будет висеть в памяти.

* Стоит два раза подумать перед тем как создать LiveData обзёрвать и влиять на значение которой могут разные объекты, это может привести к конфликтам и морганию UI. Намного лучше создавать разные инстансы LiveData каждый раз, вместо тогоч тобы разделять одну между классами.

* Не стоит возвращать #MutableLiveData так как её можно изменять, используйте #LiveData.

В заключении несколько советов:
* #LiveData создана для конкретной цели, так что если вам нужно проделать цепочку трансформаций, то лучше использовать Rx.
* В случае если #LiveData никак не связана с UI советуют использовать callback-и, хотя я вижу и другие места, где хорошо подходит, но главное - "Всегда думайте перед тем как использовать новодный паттерн во всех частях вашего приложения".

Личного из моего опыт, часто приходится сталкиватся с тем, что операторы для #LiveData нужны. Не столько много как для Rx, и не такие сложные, но все таки это позволяет упрощать жизнь. В таком случае я рекомендую обратить внимание на библиотеку "Lives".

Эта библиотека содержит все в себе множество операторов (около 20 штук), которыми часто пользуются в Rx и они легкие:

filter() - эмитирует только те значения, которые удовлетворяют предикату

val origLiveData = MutableLiveData<Int>()
val newLiveData = origLiveData.filter { it > 2 }

nonNull() - Возвращает NonNullLiveData, которая эмитирует только не null значения

https://github.com/adibfara/Lives

#ProjectTreble - очень хорошая инициатива от Google, представленная на #GoogleIO17, которая позволяет упростить обновление устройств, отделив Android Framework on реализации Vendora: драйверов, работы с новыми датчиками и пр. Применение такого подхода стало обязательным для всех устройств, которые выпускаются с Android O и более новыми версиями ОС.
https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html

В рамках #AndroidDevSummit18 показали преимущества Project Treble - #GenericSystemImage (GSI). Технология позволяет вам запустить голый Android, не дожидаясь обновления от производителя. Производители устройств используют GCI (который строится на последних исходниках #AOSP) для проверки реализации интерфейса производителя на их устройствах.

Это дает разработчикам возможность на чистой версии Android на основе AOSP на любом Treble совместимом устройстве.

Подробности
https://android-developers.googleblog.com/2018/11/an-update-on-project-treble.html

#Firebase #Predictions

Firebase - это прекрасный набор сервисов для создания мобильных приложений. Теперь в релиз вышел ещё один из них Predictions.

Этот сервис позволяет на основе машинного обучения сегментирование пользователей на основе их будущего поведения. В итоге полученные группы могут использоваться для таргетированная #RemoteConfig, #CloudMessaging, #InAppMessaging и A/B Testing.

Релиз Predictions также добавил новых функций:
* Prediction Health - позволяет понять насколько точным является предсказание поведения, смотреть информацию о сегментах и на основе каких данных они были созданы
* Export to BigQuery

Подробности в статье
"Predictions graduates to general availability to provide smarter user segmentation"

Замечательный парень Jake Warton, сделавший для Android сообщества множества полезных вещей, и я уверен, что библиотека в разработке которой он принимал участие есть в 99% проектов на Android.

Выступил с замечательным докладом на Droidcon London и рассказал о том, как сделать вашу жизнь с #Dagger лучше.

#AssistedInjection
Позволяет эффективно передавать параметры в ваши зависимости. Например, когда у вас есть Presenter, ViewModel и пр в которую вам надо передать id данных, отображаемых на текущем экране. В чистом Dagger это делается через костыли, описываемое решение позваоляет избавиться от Subcomponent, lateinit и пр. в пользу генерируемых Factory.

https://github.com/square/AssistedInject

не смущайтесь версии 0.3.0. Jake не готов сделать ее 1.0 из-за пустяков. Она полностью стабильно по его заявлению.

Выглядет это так

#InflateInjection
Аналогично AssistedInjection, но предназначено для передачи зависимостей напрямую в конструктор View и работает на основе LayoutInflater.Factory.

#Dagger #Performance #Gradle

Dagger 2 сделал много полезного
* Избавил нас от рефлексии в Runtime, добавив вместо этого annotation processing во время сборки. Одна из больших проблем, что не было возможности его инкремтной сборки до Gradle 4.7.
* Сделал сгенерированный код читабельным, чтобы он был проще для понимания человеку.

К сожалению, за все это пришлось заплатить временем сборки проекта, но есть способ это исправить:
* Первое что надо сделать - обновиться до последней версии Dagger (на сегодня 2.19) и Gradle (4.10.2).

* Используя икрементальный режим annotation processor в Dagger 2
* Отключить форматирование генерируемого кода (это занимает около 40% времени работы annotation processor Dagger).

build.gradle
tasks.withType(JavaCompile).configureEach {
options.compilerArgs += [
"-Adagger.formatGeneratedSource=disabled",
"-Adagger.gradle.incremental=enabled"
]
}

// Для проектов с Kotlin где используется kapt
kapt {
arguments {
arg("dagger.formatGeneratedSource", "disabled")
arg("dagger.gradle.incremental", "enabled")
}
}

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

Подробнее о различных флагах комиляции Dagger 2 читайте

https://google.github.io/dagger/compiler-options

Обратите внимание на режим "fastInit" который может позволить вам ускорить инициализацию вашего графа при старте приложения, тем самым ускорив появление первого экрана

Пример с #InflationInject