Опровергнуты самые распространенные мифы об оптимизации Android

Существует множество инструкций, посвященных повышению производительности Android, и общих советов по оптимизации. Некоторые из них являются законными, а другие основаны только на теории или устаревших операционных методах в системе Android, или являются просто бессмыслицей. Сюда входят рекомендации по обмену, значения, добавленные в build.prop, и изменения переменных в ядре Linux.

Есть даже тонна «сценариев оптимизации», универсальные всплывающие ZIP-файлы, которые обещают значительно увеличить производительность, время работы от батареи и другие вещи. Некоторые из твиков могут действительно работать, но большинство из них — просто эффект плацебо, или, что еще хуже, на самом деле оказывают негативное влияние на ваше устройство.

Это не значит, что люди намеренно выпускают гнусные сценарии — в Play Store определенно есть поддельные платные приложения, но сценарии оптимизации, публикуемые на форумах Android, как правило, благими намерениями, так что случается так, что разработчик может быть неправильно информирован, или просто экспериментируя с различными оптимизациями оптимизации. К сожалению, наблюдается некоторый эффект снежного кома, особенно в сценариях оптимизации «все в одном». Небольшая горстка твиков может на самом деле что-то делать, в то время как другой набор твиков в скрипте может вообще ничего не делать — но эти скрипты передаются как волшебные пули, без какого-либо реального исследования того, что работает, а что нет. ,

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

В этой эксклюзивной статье Appuals мы расскажем о некоторых наиболее распространенных рекомендациях по «оптимизации» производительности Android, а также о том, являются ли они просто мифом или законной настройкой производительности устройства.

Своп

В верхней части списка мифов находится Android-своп, что довольно абсурдно с точки зрения того, что его считают оптимизацией для Android. Основная цель свопов — создание и подключение файла подкачки, что освободит место в памяти. Это звучит разумно на бумаге, но это действительно применимо к сервер, который почти не имеет интерактивности.

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

Некоторые энтузиасты оптимизации могут сказать, что подкачка не доставляет проблем, но это не подкачка, которая повышает производительность — это встроенный механизм Android lowmemorykiller, который регулярно убивает раздутые высокоприоритетные процессы, которые не используются. LMK был разработан специально для обработки условий нехватки памяти, вызывается из процесса kswapd и обычно убивает процессы в пространстве пользователя. Это отличается от OOMkiller (убийца нехватки памяти), но это совсем другая тема.

Дело в том, что устройство с, например, 1 ГБ ОЗУ никогда не сможет достичь необходимых данных о производительности в процессе подкачки, и поэтому подкачка абсолютно не нужна в Android. Его реализация просто чревата отставанием и приводит к снижению производительности, а не к ее оптимизации.

zRAM — устаревший и уже не эффективный

zRAM — это проверенный и эффективный метод оптимизации устройств, для старых устройств — например, устройства на основе KitKat, работающие только с 512 МБ ОЗУ. Тот факт, что некоторые люди все еще включают настройки zRAM в сценарии оптимизации или рекомендуют zRAM в качестве какого-либо современного способа оптимизации, является примером того, как люди обычно не следуют последним операционным протоколам.

zRAM предназначался для многоядерных SoC начального уровня, таких как устройства, использующие наборы микросхем MTK и 512 МБ ОЗУ. Очень дешевые китайские телефоны, в основном. Что в основном делает zRAM — это разделяет ядро ​​через поток шифрования.

Когда zRAM используется на старых устройствах с одним ядром, даже если zRAM рекомендуется на таких устройствах, большое количество задержек имеет тенденцию появляться. Это также происходит с технологией KSM (Kernel Same Page Merging), которая объединяет идентичные страницы памяти в попытке освободить место. Это на самом деле рекомендуется Google, но приводит к большим задержкам на старых устройствах, потому что постоянно активные ядра работают непрерывно из памяти для поиска дублирующих страниц. По сути, попытка запустить оптимизацию оптимизации, по иронии судьбы, еще больше замедляет работу устройства.

Сеялка — устаревшая с Android 3.0

Одним из наиболее обсуждаемых советов по оптимизации среди разработчиков Android является сеялка, и мы уверены, что кто-то может попытаться доказать, что мы не правы в этом вопросе — но сначала нам нужно изучить историю сеялки.

Приложение Seeder для Android

Да, существует большое количество отчетов, которые сообщают о лучшей производительности Android после установки на более старых устройствах Android. Тем не менее, люди по какой-либо причине считают, что это означает, что это также применимая оптимизация для современных устройств Android, что абсолютно абсурдно. Тот факт, что Seeder по-прежнему поддерживается и предлагается как «современный» инструмент уменьшения задержки, является примером дезинформации — хотя это не вина разработчика Seeder, поскольку даже на их странице Play Store отмечается, что Seeder менее эффективен после Android 4.0+. Тем не менее, по какой-то причине, Seeder все еще появляется в дискуссиях по оптимизации для современных систем Android.

То, что в основном делает Seeder для Android 3.0, — это устранение ошибки, когда среда выполнения Android активно использовала файл / dev / random / для получения энтропии. Буфер / dev / random / будет работать нестабильно, и система будет блокироваться до тех пор, пока не заполнит необходимый объем данных — подумайте о мелочах, таких как различные датчики и кнопки на устройстве Android.

Автор Seeder взял Linux-демон rngd и скомпилировал его для Android-взлома, чтобы он брал случайные данные из гораздо более быстрого и более предсказуемого пути / dev / urandom и объединял их в dev / random / каждую секунду, не допуская / dev / random / истощаться. Это привело к созданию системы Android, которая не испытывала недостатка энтропии и работала намного плавнее.

Google исправил эту ошибку после Android 3.0, но по какой-то причине Seeder все еще появляется в списках «рекомендуемых настроек» для оптимизации производительности Android. Кроме того, приложение Seeder имеет несколько аналогов, таких как sEFix, которые включают в себя функциональность Seeder, будь то использование того же rngd или альтернативного хэджа, или даже просто символическая ссылка между / dev / urandom и / dev / random. Это абсолютно бессмысленно для современных систем Android.

Причина в том, что бессмысленно, потому что новые версии Android используют / dev / random / в трех основных компонентах — libcrypto, для шифрования соединений SSL, генерации ключей SSH и т. Д. WPA_supplication / hostapd, которая генерирует ключи WEP / WPA, и, наконец, несколько библиотеки для генерации идентификатора при создании файловых систем EXT2 / EXT3 / EXT4.

Поэтому, когда улучшения Seeder или Seeder на основе включены в современные сценарии оптимизации Android, в конечном итоге происходит снижение производительности устройства, поскольку rngd будет постоянно пробуждать устройство и вызывать увеличение частоты процессора, что, конечно, отрицательно влияет на потребление батареи. ,

Odex

Штатная прошивка на устройствах Android почти всегда odex. Это означает, что наряду со стандартным пакетом для приложений Android в формате APK, который находится в / system / app / и / system / priv-app /, файлы с такими же именами имеют расширение .odex. Файлы odex содержат оптимизированные приложения с байт-кодом, которые уже прошли виртуальную машину валидатора и оптимизатора, а затем записаны в отдельный файл с использованием чего-то вроде инструмента dexopt.

Таким образом, файлы odex предназначены для разгрузки виртуальной машины и предлагают ускоренный запуск odexed-приложения — с другой стороны, файлы ODEX предотвращают изменения прошивки и создают проблемы с обновлениями, поэтому по этой причине многие пользовательские ПЗУ, такие как LineageOS, распространяются без вскрышных.

Генерация ODEX-файлов осуществляется несколькими способами, например, с использованием Odexer Tool — проблема заключается в том, что это чисто плацебо-эффект. Когда современная система Android не находит файлы odex в каталоге / system, система фактически создает их и помещает в каталог / system / dalvik-cache /. Это именно то, что происходит, когда, например, вы прошиваете новую версию Android, и она на некоторое время выдает сообщение «Занят, оптимизация приложений».

Lowmemorykiller твики

Многозадачность в Android отличается от других мобильных операционных систем в том смысле, что она основана на классической модели, в которой приложения работают тихо в фоновом режиме, и нет никаких ограничений на количество фоновых приложений (если только одно не установлено в параметрах разработчика, но это как правило, рекомендуется) — более того, функциональность перехода к фоновому выполнению не останавливается, хотя система оставляет за собой право убивать фоновые приложения в ситуациях с нехваткой памяти (см., где мы говорили о lowmemorykiller и убийце нехватки памяти ранее в этом руководство).

Чтобы вернуться к механизму lowmemorykiller, Android может продолжать работать с ограниченным объемом памяти и отсутствием swap-раздела. Пользователь может продолжать запускать приложения и переключаться между ними, и система будет молча уничтожать неиспользуемые фоновые приложения, пытаясь освободить память для активных задач.

Это было очень полезно для Android в первые дни, хотя по какой-то причине оно стало популярным в форме приложений-убийц задач, которые, как правило, скорее вредны, чем полезны. Приложения-убийцы задач либо просыпаются с заданными интервалами, либо запускаются пользователем, и, по-видимому, освобождают большие объемы ОЗУ, что считается положительным моментом — больше свободной ОЗУ означает более быстрое устройство, верно? Однако это не совсем так с Android.

Фактически наличие большого объема свободной оперативной памяти может отрицательно сказаться на производительности вашего устройства и времени автономной работы. Когда приложения хранятся в оперативной памяти Android, их гораздо проще вызывать, запускать и т. Д. Системе Android не нужно выделять много ресурсов для переключения на приложение, поскольку она уже есть в памяти.

Из-за этого убийцы задач не так популярны, как раньше, хотя новички в Android по-прежнему склонны полагаться на них по некоторым причинам (к сожалению, нехватка информации). К сожалению, новый тренд заменил задачу-убийц, тренд настройки механизма низкого уровня памяти. Это может быть, например, приложение MinFreeManager, и основная идея заключается в увеличении объема оперативной памяти, прежде чем система начнет убивать фоновые приложения.

Так, например, стандартное ОЗУ работает на границах — 4, 8, 12, 24, 32 и 40 МБ, а при заполнении свободного места в 40 МБ одно из кэшированных приложений загружается в память, но не работает будет прекращено.

Таким образом, в основном у Android всегда будет как минимум 40 МБ доступной памяти, что достаточно для размещения еще одного приложения до того, как lowmemorykiller начнет процесс очистки — это означает, что Android всегда будет стараться использовать максимальный объем доступной ОЗУ, не мешая работе. Пользовательский опыт.

К сожалению, кое-что, что начинали любители домашних пивоваров, рекомендовали, чтобы это значение было увеличено, например, до 100 МБ, прежде чем LMK заработает. Теперь пользователь фактически потеряет ОЗУ (100 — 40 = 60), поэтому вместо использования этого пространства для хранения В конечных приложениях система будет сохранять этот объем памяти свободным, абсолютно бесполезным для этого.

Настройка LKM может быть полезна для более старых устройств с 512 ОЗУ, но кому они больше принадлежат? 2 ГБ — это современный «бюджетный диапазон», даже устройства ОЗУ объемом 4 ГБ в наши дни считаются «средними», поэтому настройки LMK действительно устарели и бесполезны.

Твики ввода / вывода

Во многих скриптах оптимизации для Android вы часто найдете твики, которые касаются подсистемы ввода / вывода. Например, давайте взглянем на ThunderBolt! Скрипт, который содержит следующие строки:

echo 0> $ i / очередь / ротация;
echo 1024> $ i / queue / nr_requests;

Первая строка содержит инструкции планировщика ввода-вывода при работе с твердотельным накопителем, а вторая увеличивает максимальный размер ввода-вывода в очереди со 128 до 1024, поскольку переменная $ i содержит путь к дереву блочных устройств в / sys, и скрипт выполняется в цикле.

После этого вы найдете строку, относящуюся к планировщику CFQ:

echo 1> $ i / queue / iosched / back_seek_penalty;
echo 1> $ i / queue / iosched / low_latency;
echo 1> $ i / queue / iosched / slice_idle;

Далее следуют дополнительные строки, которые принадлежат другим планировщикам, но в конечном итоге первые две команды не имеют смысла, потому что:

Современное ядро ​​Linux способно понять, с каким типом носителя он работает по умолчанию.

Длинная очередь ввода-вывода (например, 1024) бесполезна на современном устройстве Android, на самом деле она бессмысленна даже на настольном компьютере — она ​​действительно рекомендуется только на мощных серверах. Ваш телефон не является мощным сервером Linux.

Для устройства Android практически нет приложений с приоритетом ввода-вывода и нет механического драйвера, поэтому лучшим планировщиком является очередь noop / FIFO, так что этот тип планировщика «твик» не делает ничего особенного или значимого для Подсистема ввода / вывода. Фактически, все эти многоэкранные команды списка лучше заменить простым циклом:

для i in / sys / block / mmc *; делать
echo noop> $ i / queue / scheduler
echo 0> $ i / queue / iostats
сделанный

Это позволило бы планировщику noop для всех накопителей накапливать статистику ввода-вывода, что должно оказать положительное влияние на производительность, хотя и очень незначительное и практически ничтожное.

Другой бесполезный трюк ввода-вывода, часто встречающийся в сценариях производительности, — это увеличение значений упреждающего чтения для карт SD до 2 МБ. Механизм упреждающего чтения предназначен для раннего чтения данных с носителя до того, как приложение запросит доступ к этим данным. Таким образом, ядро ​​будет пытаться выяснить, какие данные понадобятся в будущем, и предварительно загрузить их в оперативную память, что, таким образом, должно сократить время возврата. На бумаге это звучит замечательно, но алгоритм упреждающего чтения чаще всего ошибочен, что приводит к совершенно ненужным операциям ввода-вывода, не говоря уже о большом потреблении ОЗУ.

В RAID-массивах рекомендуются высокие значения опережающего считывания от 1 до 8 МБ, но для устройств Android лучше оставить значение по умолчанию, равное 128 КБ.

Система управления виртуальной памятью

Другой распространенный метод «оптимизации» — это настройка подсистемы управления виртуальной памятью. Обычно это предназначается только для двух переменных ядра, vm.dirty_background_ratio и vm.dirty_ratio, которые предназначены для настройки размера буфера для хранения «грязных» данных. Грязные данные — это, как правило, данные, которые были записаны на диск, но их еще больше в памяти и они ожидают записи на диск.

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

vm.dirty_background_ratio = 10
vm.dirty_ratio = 20

Итак, что он пытается сделать, это то, что, когда грязный буфер данных составляет 10% от общего объема ОЗУ, он пробуждает поток pdflush и начинает записывать данные на диск — если операция записи данных на диск будет слишком интенсивной, буфер будет продолжать расти, и когда он достигнет 20% доступной оперативной памяти, система переключится на последующую операцию записи в синхронном режиме — без предварительного буфера. Это означает, что работа по записи на диск приложения будет заблокирован, пока данные не будут записаны на диск (AKA «лаг»).

Следует понимать, что даже если размер буфера не достигает 10%, система автоматически запускает pdflush через 30 секунд. Комбинация 10/20 довольно разумна, например, на устройстве с 1 ГБ ОЗУ это будет равно 100/200 МБ ОЗУ, что более чем достаточно с точки зрения серийной записи, где скорость часто ниже скорости записи в системе NAND -память или SD-карту, например, при установке приложений или копировании файлов с компьютера.

По какой-то причине авторы сценариев пытаются поднять это значение еще выше, до абсурдных показателей. Например, мы можем найти в скрипте оптимизации Xplix частоту 50/90.

sysctl -w vm.dirty_background_ratio = 50
sysctl -w vm.dirty_ratio = 90

На устройстве с 1 ГБ памяти это устанавливает ограничение для грязного буфера в 500/900 МБ, что совершенно бесполезно для устройства Android, потому что оно будет работать только при постоянной записи на диск — то, что происходит только на тяжелых Сервер Linux.

ThunderBolt! Скрипт использует более разумное значение, но в целом все еще довольно бессмысленно:

if ["$ mem" -lt 524288]; тогда
sysctl -w vm.dirty_background_ratio = 15;
sysctl -w vm.dirty_ratio = 30;
elif ["$ mem" -lt 1049776]; затем
sysctl -w vm.dirty_background_ratio = 10;
sysctl -w vm.dirty_ratio = 20;
еще
sysctl -w vm.dirty_background_ratio = 5;
sysctl -w vm.dirty_ratio = 10;
Fi;

Первые две команды выполняются на смартфонах с 512 МБ ОЗУ, вторая — с 1 ГБ, а другие — с объемом более 1 ГБ. Но на самом деле есть только одна причина изменить настройки по умолчанию — устройство с очень медленной внутренней памятью или картой памяти. В этом случае целесообразно распределить значения переменных, то есть сделать что-то вроде этого:

sysctl -w vm.dirty_background_ratio = 10
sysctl -w vm.dirty_ratio = 60

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

Дополнительные бесполезные твики и настройки производительности

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

Вот некоторые дополнительные популярные оптимизации, которые могут или не могут быть полезны, в зависимости от системы Android и устройства.

  • Ускорение — небольшое ускорение для повышения производительности и пониженного напряжения — экономит заряд батареи.
  • Оптимизация базы данных — Теоретически это должно повысить производительность устройства, но это сомнительно.
  • Zipalign — по иронии судьбы, несмотря на встроенную функцию выравнивания контента в Android SDK в APK-файле, в магазине вы можете найти множество программ, не передаваемых через zipalign.
  • Отключите ненужные системные службы, удалив неиспользуемые системные и редко используемые сторонние приложения. По сути, удаление вирусов.
  • Кастомное ядро ​​с оптимизацией под конкретное устройство (опять же, не все ядра одинаково хороши).
  • Уже описан планировщик ввода / вывода noop.
  • Алгоритм насыщения TCP Westwood — более эффективно используется по умолчанию в Android Cubic для беспроводных сетей, доступен в пользовательских ядрах.

Бесполезные настройки build.prop

LaraCraft304 с форума разработчиков XDA провел исследование и обнаружил, что внушительное количество настроек /system/build.prop, рекомендуемых для использования «экспертами», не существует в исходном AOSP и CyanogenMod. Вот список:

ro.ril.disable.power.collapse
ro.mot.eri.losalert.delay
ro.config.hw_fast_dormancy
ro.config.hw_power_saving
windowsmgr.max_events_per_sec
persist.cust.tel.eons
ro.max.fling_velocity
ro.min.fling_velocity
ro.kernel.checkjni
dalvik.vm.verify-байткод
debug.performance.tuning
video.accelerate.hw
ro.media.dec.jpeg.memcap
ro.config.nocheckin
profiler.force_disable_ulog
profiler.force_disable_err_rpt
ersist.sys.shutdown.mode
ro.HOME_APP_ADJ
Ссылка на основную публикацию
Adblock
detector