Вопрос на 16 КБ: почему так важны изменения в памяти Android и как подготовить приложение

Как Android-разработчик, я люблю разбираться в причинах крупных архитектурных изменений платформы. Иногда изменение, которое на первый взгляд кажется неясным и незначительным, сильно влияет на пользовательский опыт и процесс разработки. Переход на размер страницы памяти в 16 килобайт (КБ) в Android 15 — одно из таких изменений.

Годами Android управлял памятью блоками по 4 КБ. Но с появлением современных устройств с большим объёмом оперативной памяти это стало неэффективным. С 1 ноября 2025 года Google Play требует, чтобы все новые приложения и обновления для Android 15 (API 35) или выше были совместимы с этим новым размером страницы в 16 КБ.

Если ваше приложение полностью написано на Kotlin/Java, вы, вероятно, можете расслабиться. Но если ваше приложение использует нативный код (C/C++) — а вы удивитесь, как много таких приложений используют благодаря сторонним SDK, — вам нужно действовать прямо сейчас.

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

Зачем: что вообще такое страница памяти?

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

Однако ваше приложение не видит этого беспорядка. Операционная система Android предоставляет вашему приложению «волшебную карту» (виртуальную память), которая создаёт впечатление, что у него есть собственное, идеально организованное хранилище. Операционная система выступает в роли «менеджера хранилища», преобразуя запросы из личной карты вашего приложения в фактическое местоположение в общем хранилище.

Этот менеджер не работает с отдельными байтами; это было бы слишком медленно. Вместо этого он управляет памятью блоками фиксированного размера, называемыми страницами. На протяжении всей истории Android этот размер составлял 4 КБ. Новый размер страницы в 16 КБ означает, что стандартный блок памяти, с которым работает ОС, теперь в четыре раза больше.

Выгода: почему большие страницы означают более высокую производительность

Так зачем же это изменение? Всё дело в аппаратном компоненте процессора, называемом буфером ассоциативной трансляций (TLB).

Представьте себе TLB как карманный блокнот менеджера склада. Это небольшой, сверхбыстрый кэш, в котором хранятся последние обращения к памяти.

• Попадание (Hit) в TLB происходит, когда запрошенная ячейка памяти находится в блокноте. Тогда получение данных происходит невероятно быстро.
• Промах (Miss) TLB происходит, когда её там нет, что приводит к медленному обращению к «главному журналу» (главной таблице страниц в оперативной памяти).

Ключевой момент заключается в том, что блокнот (TLB) имеет фиксированное количество строк. При объёме страниц 16 КБ каждая строка в этом блокноте дает в четыре раза больше памяти. Эту концепцию я называю «охватом TLB».

Больший охват означает меньше медленных промахов. Это не просто теория, у Google есть цифры, подтверждающие это:

• Время запуска приложения: в среднем на 3.16% быстрее (до 30% для некоторых приложений!)
• Энергопотребление: на 4.56% ниже во время запуска
• Запуск камеры: до 6.60% быстрее

Это фундаментальная оптимизация, которая повышает эффективность всей экосистемы.

Влияние: упадет ли моё приложение?

И вот здесь мы подходим к сути проблемы для нас, разработчиков. Приложение может упасть , если оно использует нативный код (C/C++). Это может быть ваш собственный код NDK или, что чаще, сторонний SDK, который вы используете.

Проблема в выравнивании данных (Memory Alignment). Старая нативная библиотека могла быть построена с жёстко запрограммированным предположением, что новый блок памяти начинается каждые 4096 байт. В системе с 16 КБ этот адрес теперь находится в середине более крупного блока.

Когда ОС обнаруживает попытку загрузки данных такой библиотекой, она распознаёт «нарушение правил» и завершает операцию, чтобы предотвратить повреждение памяти.

Возможно, именно на это указывает сбой SIGSEGV в вашем Logcat.

План действий: трёхшаговое руководство по обеспечению совместимости

Итак, мы понимаем проблему. Хорошая новость в том, что её решение простое.

Шаг 1: аудит вашего приложения

Для начала выясните, используете ли вы нативный код. Проще всего воспользоваться APK Analyzer в Android Studio (Build > Analyze APK…). Если внутри вашего APK есть папка lib, значит, нативный код есть.

Также следите за выводом сборки. Новый инструмент проверки Lint в Android Studio будет заблаговременно предупреждать о найденных библиотеках, не использующих Memory Alignment.

Шаг 2: обновление и перекомпиляция

В большинстве случаев решение — пересборка с использованием современных инструментов.

• Если вы пишете собственный код на C/C++, убедитесь, что используете Android Gradle Plugin 8.5.1+ и NDK r28+. Эти версии автоматически поддерживают выравнивание по 16 КБ.
• Если код взят из SDK, проверьте примечания к выпуску библиотеки и обновите её до версии, явно совместимой с 16 КБ.

Также проверьте свой нативный код на наличие жёстко заданных допущений о размере страницы.

ПЛОХО ❌

// Hardcoded assumption will crash!
#define PAGE_SIZE 4096
void* myBuffer = memalign(PAGE_SIZE, size);

ХОРОШО ✅

// Ask the OS for the real page size
#include <unistd.h>
long pageSize = sysconf(_SC_PAGESIZE);
void* myBuffer = memalign(pageSize, size);

Шаг 3: тестирование и проверка

Не просто делайте новую сборку и надейтесь. Тестируйте. Проще всего использовать эмулятор Android. При создании нового AVD выберите образ системы с «Размер страницы 16 КБ» в имени для Android 15 и выше.

Если у вас есть физическое устройство серии Pixel 8 или 9, вы также можете включить опцию разработчика для перезагрузки в нативном режиме 16 КБ.

Обходные пути и задел на будущее

Аварийный выход: если вы застряли на старой версии AGP (ниже 8.5.1), вы можете воспользоваться временным решением. Добавьте useLegacyPackaging = true в блок packingOptions файла build.gradle, чтобы избежать проблем с установкой.

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging = true
        }
    }
}

Для Android 16: чтобы избежать появления диалогового окна с предупреждением в будущих версиях ОС, вы можете включить режим совместимости, добавив android:pageSizeCompat="true" в ваш AndroidManifest.xml.

<application android:pageSizeCompat="true" ...>

Заключительные выводы

Это существенное, но управляемое изменение. Если вы что-то хотите запомнить, пусть это будет:

• Производительность — движущая сила: это изменение пойдет на пользу всей экосистеме Android
• Цель — нативный код: риск исходит почти исключительно от приложений, использующих нативный код C/C++
• Следуйте трёхэтапному плану: аудит, обновление и тестирование
• Не пропустите срок: 1 ноября 2025 года это станет обязательным

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

Счастливого программирования!

Источник