Весь прошлый год я плотно работал с ExoPlayer и решил написал статью про это.

Что внутри?
- Как ускорить процесс загрузки
- Как улучшить разрешение
- Как предотвратить ошибки воспроизведения
- Ловушки и уроки
- Производительность с Jetpack Compose
- Влияние улучшений на продуктовые метрики

Вот обосрались, так обосрались! Даже жалко. Не так давно Google выкатили обновление Play (которое, как мы знаем, ставится автоматом, в обход всего). Обновление оказалось с приколом, часть пользователей получили нерабочие Pixel смартфоны. И кажется, пока не нашлось ни одного способа решить проблему удаленно на стороне Гугла. Вместо этого они где-то в третьей жопе своих форумов предлагают нормальным людям поставить ADB и повыполнять разного в терминальчике. Причем описан только golden path (в обоих, сука, смыслах: и когда все идет хорошо, и когда «спасибо, что только обоссали»), про приколы работы ADB в разных окружениях людям, видимо, придется расспрашивать Gemini.

#google #pixel #bug

Analysis of Android settings during a forensic investigation
https://blog.digital-forensics.it/2024/01/analysis-of-android-settings-during.html

DIY: Твоя собственная библиотека для инъекции зависимостей

Лучший способ понять, какая библиотека для инъекции зависимостей вам нужна, — начать писать свою! Автор пишет DI-библиотеку и применяет ее на достаточно простом, но прикладном кейсе.

👉 Анти-паттерн. Если вы протаскиваете зависимость через десятки классов, только ради использования в последнем
👉 Автор изобретает заново шаг за шагом Google Guice, затем Dagger 1 и в конечном счете Dagger 2. Достаточно показательно, как приходили к существующим решениям в библиотеках
👉 Интересно было посмотреть, как генерируются factory-классы через KSP
👉 Красивая работа с аннотациями, которую можно рассматривать в отрыве от статьи

А что вы используете в проекте?

Jake Wharton решил исследовать как лучше делать маппинг набора значений в одну строку и какую лучше выбрать реализацию для этого по скорости/памяти. Массивы с лямбдой инициализации значений будут довольно полезны

#performance

Обновление приложения до targetSdk 34

Обязательное обновление targetSdkVersion ожидается, предположительно, в августе этого года. Добавляем задачку в беклог ближайшего спринта и не переживаем о предупреждениях из Google Play

👉 Если вы используете foreground сервисы, то для них появился foregroundServiceType, который нужно будет определить в манифесте
👉 Обновление Android привело к обновлению OpenJDK до 17. А это значит что могло сломаться: регулярные выражения, ProGuard и десериализация UUID.
👉 При использования BluetoothAdapter.getProfileConnectionState требуется BLUETOOTH_CONNECT (Должен быть и в манифесте и запрашиваться в рантайме)
👉 Ограничения для Intent. Тщательно проверьте, как используется android:exported в ваших приложениях. Неявный Intent может быть отправлен только к android:exported="true”
👉 У BroadcastReceiver новый параметр - ContextCompat.RECEIVER_EXPORTED. Добавляем его в зависимости от того, как вы с ним работаете
👉 Динамически подгружаемый код должен быть помечен как readOnly перед использованием
👉 Ограничения на работу с ZipFile. Теперь будет кидаться ошибка, если в имени есть модификаторы пути до файла ".." или "/".
👉 Расширение ограничений при запуске приложений в фоне. Добавляем еще один параметр в PendingIntent.

В целом, ассистент миграции поможет вам перевести приложение на новое SDK, но лучше самостоятельно проверить, что все упомянутые моменты были переведены верно, иначе рискуете получить неверное поведение приложения или просто краш

PriorityDispatcher - CoroutineDispatcher, который работает на основе приоритетов. Проблема с том, что задать приоритет для корутины не получится в рамках единого Dispatcher. Создаются отдельные с с заданным приоритетом

#coroutines

#Article #Medium #Recomposition

Jetpack Compose: Strong Skipping Mode Explained

Начиная с версии 1.5.4+ Compose компилятора, в Compose появился Strong skipping mode — новая экспериментальная фича, предназначенная для еще большей оптимизации количества рекомпозиций. Подробнее — в сегодняшней статье.

Зеркало статьи 👉 тут

Магические файлы .bak в SharedPreferences

Всем привет!

Наткнулся на крайне занятную статью, которая рассказывает о работе механизма SharedPreferences с файлами с расширением .bak

До этого момента, я даже не знал, что так можно. Оказывается, если внутри SP есть файл, например, credentials.xml и рядом лежит credentials.xml.bak, то при загрузке этого файла первый будет удален, файл бекапа будет переименован и использоваться, как оригинальный, что подтверждается анализом исходников.

Это может помочь, если у вас есть возможность записать файл в директорию, но приложение проверяет наличие файла перед записью

if(file.exists()) abort();

Я пока с таким не сталкивался, но однозначно буду иметь это поведение ввиду.

Ну или по крайней мере проверю, может оно вообще не так, но по коду выглядит логично :)

#android #sharedprefs

Я понял, что не публиковал тут шаблон EditorConfig для Android-проектов. Недавно обновил его под последнюю версию IDE — добавил парочку новых настроек и поправил порядок и заголовки в файле, чтобы они соответствовали изменениям в UI.

Что за EditorConfig?

EditorConfig — это спецификация файла конфигурации для кодстайла. Самые общие опции типа indent_size и insert_final_newline заложены в саму спецификацию. Прелесть в том, что эти опции понимают все редакторы кода, а значит будет меньше головной боли когда открываешь файлы проекта в VS Code или ещё где-то. Некоторые IDE поддерживают специфичные для них настройки кодстайла, например, все настройки относящиеся к IDEA начинаются с ij_ и настроить там можно практически всё то же самое, что и в Settings > Code Style.

И всё-таки зачем его использовать?

Согласен, идея шаринга настроек кодстайла между разными IDE звучит не убедительно. Не самый частый кейс, к тому же есть ограниченное количество общих настроек. Забудьте, есть причины гораздо круче:

1️⃣ Самое очевидное — пошарить кодстайл между всеми разработчиками. Добавляете файлик .editroconfig в корень проекта и теперь у всех разработчиков одинаковые настройки IDE и автоформатирование работает одинаково (можно ещё EditorConfig в required plugins добавить, чтобы убедиться, что плагин у всех точно включен и настройки не будут игнорироваться).
Такой способ шаринга кодстайла лучше чем распространение через Export/Import архива с настройками или добавление файлов из .idea/ в репозиторий. Во-первых, потому что формат EditorConfig не зависит от версии IDE. Во-вторых, вносить изменения в него куда проще, а проигнорировать их не получится (как в случае с распространением через архив).

2️⃣ Более гибко настраивать кодстайл. К примеру, вы решили, что ненавидите wildcard-импорты и запрещаете их использование в проекте. При этом в скриптах .kts хочется их разрешить. Как это сделать средствами IDE? Не знаю. А в EditorConfig можно определять разный кодстайл для разных файлов и каталогов. Для .kt один кодстайл, для .kts немного другой. Для res/*.xml один, для остальных XML-файлов другой.

3️⃣ IDE-независимость. Я там чуть выше сказал забыть про шаринг настроек между IDE, но всё-таки упомяну, что во Fleet (новом редакторе от JetBrains) формат EditorConfig вообще считается основным форматом для настройки кодстайла. Помимо IDE формат EditorConfig понимает, например, ktlint. То есть это отличная точка синхронизации для любых инструментов, которые хотят знать про кодстайл проекта.

Ок, продал, но зачем нужен шаблон?

Файл EditorConfig можно создать для своего проекта из настроек IDE, но у этого способа есть один минус — не всегда понятно какие опции что означают. Чтобы сгладить этот минус, я сгруппировал опции в файле таким образом, чтобы иерархия совпадала с тем как эти опции отображаются на экране настроек в IDE. Теперь можно легко сопоставить опцию в конфиге с пунктом настроек и понять что она делает.

Шаблон не стоит использовать "as is", проверьте, что настройки не противоречат кодстайлу проекта. Если ваша IDE уже настроена в соответствии с кодстайлом, проще всего экспортировать ваши настройки в формат EditorConfig и посмотреть насколько сильно они отличаются от шаблона (для этого можно предварительно отсортировать строки и взять diff).

#tooling

Чего ждать от Java ближайшие 10 лет?

Новые фичи в Java не создаются в вакууме, а объединяются в группы с конкретной целью. Каждый релиз — небольшие шаги в сторону этой цели. Расскажу про основные текущие проекты.

⭐️ Project Loom

Цель: добавить легковесные(виртуальные) потоки

Самая заметная фича со времён Stream API. Большинство проектов получат огромный буст от внедрения виртуальных потоков. Что важно — с минимальными изменениями в коде.

В Java 21 вышло базовое апи по работе с виртуальными потоками. Предстоит ещё много работы внутри JVM и в рамках языка, чтобы удобно управлять тысячами задач.

⭐️ ZGC / Shenandoah

Цель: сборщик мусора с минимальными паузами

Сборщики чуть отличаются по реализации, но задача одна — обеспечить минимум простоя во время сборки мусора. Разумеется, не бесплатно. Паузы уменьшаются, но увеличивается расход памяти и снижается пропускная способность.

Для большинства проектов это не актуально. Сборщик по умолчанию G1 отлично работает и становится лучше с каждым релизом.

⭐️ Project Panama

Цель: упростить работу с native кодом и памятью за пределами JVM

Проект делится на 2 направления:

🔹 Новый вариант JNI

Нужен для работы с библиотеками, которые не написаны на Java, и вряд ли когда-нибудь будут: работа с графикой, манипуляции с ОС, сетью и тд. Текущий JNI очень старый, работает медленно и не безопасен. Поэтому пишут новый:)

🔹 Работа с памятью за пределами JVM

Нужна проектам, которые хотят управлять памятью без посредничества Java. Самим делать сборку мусора, сжимать и раскладывать данные по определённым структурам.

⭐️ Project Amber

Цель: упростить язык, добавить новые конструкции

Самые "народные" фичи, которые часто попадают в обзоры и статьи: var, текстовые блоки, records, pattern matching, sealed классы, string templates и так далее.

Что-то получается хорошо, что-то не очень. Где-то много пафосных разговоров про data-oriented programming. Есть странные фичи, вроде упрощения написания Hello world.

⭐️ Project Leyden

Цель: ускорить время старта Java программ

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

⭐️ Project Valhalla

Цель: оптимизировать работу с данными

Здесь так же два направления:

🔹 Создать value types — объект с полями и методами, работа с которым идёт как с примитивом:
✅ Передаётся по значению
✅ Компактно лежит в памяти
✅ Не может быть null

🔹 Создать общую схему работы с примитивами, объектами и value types, избавить разработчика от мыслей про boxing/unboxing

❓ А когда будет готово?

Плохая новость — реализации всех проектов растягиваются на десятки лет.

10 лет — не преувеличение. Лямбда-выражения в java обсуждались с 2004 года, а увидели свет только в 2014.

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

На java пишут большие системы, которые работают десятки лет. Поэтому основательный подход абсолютно оправдан😌

Продолжаем разбирать прикольные уязвимости. На этот раз у нас уязвимость в библиотеке Jetpack Navigation. Суть ее в том, что она позволяет стороннему приложению открыть любой экран атакуемого приложения и передать туда параметры. Круто звучит? Вот и я так думаю. А Google не считает это уязвимостью и после получения репорта нам ответили, что "поправят документацию". Не будь как Google, исправляй ошибки в своих приложениях! И знай чем грозит использование библиотеки Navigation.

штош: Джейк сдержал слово и аргументированно рассказал, почему не стоит использовать toolchain-ы в ваших билдах! Приглашаю к ознакомлению 🧑‍💻
https://jakewharton.com/gradle-toolchains-are-rarely-a-good-idea/

decomposer - Gradle плагин для декомпиляции Java bytecode от Jetpack Compose Compiler Plugin. В результата получается Java класс. Позволит понять вам что происходит под капотом и погрузиться глубже

#tooling @compose_broadcast

Список ресурсов по безопасности Android

AboutLibraries автоматически собирает все зависимости и лицензии Gradle-проекта и предоставляет легко интегрируемые UI-компоненты для сред Android и Compose. Делает это во время компиляции и предлагает простые API для их визуализации в приложении. Никаких накладных расходов во время выполнения. Сильное кэширование. Поддерживаются любые gradle-зависимости. Поддерживает Kotlin Multiplatform.

AboutLibraries на GitHub: https://github.com/mikepenz/AboutLibraries
Платформа: Android
⭐️: 3.5K

Продолжаю рубрику #насмотренность. Сегодня смотрим на inline-классы. На мой взгляд это одна из самый недооценённых фичей Котлина. Подозреваю, что это потому что потребность в inline-классах неочевидна. Попробую это исправить.

Напомню. Inline-класс это обёртка над другим типом. Он должен иметь строго один параметр в основном конструкторе — значение которое мы оборачиваем. При компиляции вместо нашего класса будет подставлено обёрнутое значение. То есть класс есть, а лишних аллокаций нет. Красота!

Минутка духоты: На самом деле обёрнутое значение не всегда будет инлайниться. Принцип работы похож на (un)boxing примитивов. Но это тема для отдельного поста.

1️⃣ Объявление собственных примитивов

Примитивные типы это то, что должно работать быстро. Мы ожидаем, что примитивы передаются по значению, то есть для них не создаётся объект в куче. Звучит как работа для inline-класса, ведь если в него завернуть примитив, то и перформанс получим как у примитива.

За примером далеко ходить не надо — UInt и другие беззнаковые типы в Kotlin это inline-классы. Но вот где действительно разгулялись с примитивами, так это в Jetpack Compose. Цвета раньше передавались либо как Int в формате 0xAARRGGBB, либо как класс, теперь же Color это inline-class. Получаем все удобства класса и легковесность примитива. Кроме цветов есть ещё Dp, Size, Offset и т.д. (для типов, состоящих их нескольких свойств, например Size, под капотом используется упаковка данных в один примитив). Так что, если вас как и меня мучил вопрос почему нет ничего страшного в том, что мы на каждой рекомпозиции создаём объекты, это потому что на самом деле никаких объектов нет.

2️⃣ Дешевые enum'ы

Помните совет гугла заменять enum'ы на Int с аннотацией @IntDef? Потом Jake Wharton рассказал, что R8 умеет оптимизировать enum'ы и мы выдохнули.
Так вот если всё-таки нужно заменить enum на примитив, inline-классы помогут обойтись без сомнительных конструкций с @IntDef, которые опираются только на стат. анализ.

Примеры этого подхода, опять же, можно посмотреть в Compose: TextAlign , TextOverflow и LineBreak. Да, к сожалению, при таком подходе в when нет проверки, что покрыты все ветви, но на этот компромисс я готов пойти.

3️⃣ Обёртки

Наиболее частое применение inline-классов — создание обёрток над другими типами, чтобы:
👉 Получить более строгую типизацию. Например, чтобы не ошибиться когда у нас много ID-шников одинакового типа у разных сущностей. Или более явно указать в сигнатуре функции, что "этот параметр должен быть не какой угодно строкой, а именно номером телефона". Это работает благодаря важному свойству inline-классов, что их нельзя сравнивать с другими типами. Попытка такого сравнения выкинет ошибку на этапе компиляции.
👉 Сузить скоуп для утилитарных функций. Вот есть у нас номер карты пользователя в формате строки. Мы хотим делать с этим номером много всякого: форматировать группами по 4 цифры, вывести маскированный номер карты вида *1234 и т.д. Можно сделать кучу экстеншенов на String, которые будут видны когда нужно и когда не нужно, а можно завести inline-класс и явно определить что с ним можно делать.
👉 Добавить новые свойства обёртнутой сущности. Добавить @Immutable ко спискам? Запросто.

Напоследок пример где и типизация важна, и новые свойства добавляются. Помните как в onMeasure нам прилетают Int'ы, с которыми нужно работать исключительно через утилитарный класс MeasureSpec? В Compose вместо этого прилетает один класс Constraints и мы сразу, без похода в документацию, понимаем набор действий, который можно совершать с этим классом. Ну не красота ли?