Существует множество инструкций, посвященных повышению производительности Android, и общих советов по оптимизации. Некоторые из них являются законными, а другие основаны только на теории, либо на устаревших методах работы в системе Android, либо представляют собой просто бессмыслицу. Сюда входят рекомендации по замене мест, значения, добавленные в build.prop, и изменения переменных в ядре Linux.
Существует даже тонна «сценариев оптимизации», флешируемых файлов .zip «все в одном». которые обещают значительно увеличить производительность, время автономной работы и многое другое. Некоторые настройки действительно могут работать, но большинство из них являются просто эффектом плацебо или, что еще хуже, оказывают негативное влияние на ваше устройство.
Это не значит, что люди намеренно выпускают гнусные скрипты – в Play Store определенно есть поддельные платные приложения, но оптимизация сценарии, выпущенные на форумах Android, обычно имеют благие намерения, но так получилось, что разработчик может быть неправильно проинформирован или просто экспериментировать с различными настройками оптимизации. К сожалению, имеет место своего рода эффект снежного кома, особенно в сценариях оптимизации «все-в-одном». Небольшая горстка настроек может на самом деле сделать что-то , в то время как другой набор настроек в скрипте может вообще ничего не делать, но эти скрипты передаются как волшебные пули без какого-либо реального расследования. в том, что работает, а что нет.
Таким образом, многие универсальные сценарии оптимизации используют одни и те же методы, некоторые из которых полностью устарели или вредны в долгосрочной перспективе. Таким образом, большинство сценариев оптимизации «все-в-одном» представляют собой не что иное, как нарезанные вместе рекомендуемые настройки, без четкого представления о том, как и почему эти оптимизации «работают – пользователи затем запускают сценарии и заявляют, что их производительность внезапно повышается. ( на самом деле, скорее всего, это был очень простой акт перезагрузки устройства, который вызвал повышение производительности , , поскольку все в ОЗУ устройства очищается) .
В этой эксклюзивной статье Appuals мы выделим некоторые из наиболее распространенных рекомендаций по « оптимизации» производительности Android, а также будут ли они просто миф или законное изменение производительности устройства.
Swap
В верхней части списка мифов находится Android-своп – что довольно абсурдно с точки зрения оптимизации под Android. Основная цель подкачки – создать и подключить файл подкачки, который освободит место для хранения в памяти. Это звучит разумно на бумаге , но действительно применимо к серверу , у которого почти нет интерактивности.
Когда вы используете регулярная подкачка вашего телефона Android, это приведет к серьезным задержкам, связанным с проскальзыванием кеша. Представьте, например, что приложение пытается отобразить графику, которая хранится в подкачке, которая теперь должна повторно загрузить диск после освобождения места путем размещения подкачки данных с другим приложением. Это действительно беспорядочно.
Некоторые энтузиасты оптимизации могут сказать, что подкачка не вызывала проблем, но это не подкачка, повышающая производительность – это встроенный механизм Android lowmemorykiller , который будет регулярно уничтожать раздутые высокоприоритетные процессы, которые не используются. LMK был разработан специально для обработки условий нехватки памяти, вызывается из процесса kswapd и обычно уничтожает процессы пользовательского пространства. Это отличается от OOMkiller (убийца нехватки памяти) , но это совсем другая тема.
Дело в том, что устройство, например, 1 ГБ ОЗУ никогда не может достичь необходимых данных о производительности в свопе, поэтому своп абсолютно не нужен в Android. Его реализация просто чревата запаздыванием и приводит к снижению производительности, а не к ее оптимизации.
zRAM – устаревший и уже не эффективный
zRAM – проверенный и эффективный метод оптимизации устройств для старых устройств – подумайте об устройствах на основе KitKat, которые работают только с 512 МБ оперативной памяти. Тот факт, что некоторые люди до сих пор включают настройки zRAM в сценарии оптимизации или рекомендуют zRAM как своего рода современную настройку оптимизации, является примером того, что люди обычно не следуют последним рабочим протоколам.
zRAM был предназначен для бюджетные многоядерные SoC начального уровня, такие как устройства, использующие наборы микросхем MTK и 512 МБ ОЗУ. В принципе, очень дешевые китайские телефоны. По сути, zRAM разделяет ядро через поток шифрования.
Когда zRAM используется на старых устройствах с одноядерным , даже если zRAM рекомендуется для таких устройств, как правило, возникают большие задержки. Это также происходит с технологией KSM ( Объединение одинаковых страниц ядра) , которая объединяет идентичные страницы памяти в попытке освободить место. На самом деле это рекомендуется Google, но это приводит к большим задержкам на старых устройствах, потому что постоянно активные основные элементы постоянно работают из памяти для поиска повторяющихся страниц. По иронии судьбы, попытка запустить настройку оптимизации еще больше замедляет работу устройства.
Seeder – Устаревший с Android 3.0
Один из наиболее обсуждаемых советов по оптимизации среди разработчиков Android – это seeder , и мы уверены, что кто-то может попытаться доказать, что мы неправы по этой теме, но сначала нам нужно изучить историю сидера.
Да, существует большое количество отчетов, в которых отмечается повышение производительности Android после установки на гораздо более старые устройства Android . Однако люди по какой-то причине считают, что это означает, что это также применимая оптимизация для современных устройств Android , что абсолютно абсурдно.. Тот факт, что Seeder по-прежнему поддерживается и предлагается как « современный» инструмент для уменьшения задержек, является примером дезинформации – хотя это не вина разработчика Seeder, поскольку даже на их странице в Play Store отмечается, что Seeder менее эффективен после Android 4.0+. Тем не менее, по какой-то причине Seeder все еще появляется в обсуждениях оптимизации для современных систем Android.
То, что Seeder в основном делает для Android 3.0, – это устранение ошибки, из-за которой среда выполнения Android будет активно использовать/dev/random/file. приобрести энтропию. /Dev/random/buffer станет нестабильным, и система будет заблокирована до тех пор, пока не заполнит необходимый объем данных – подумайте о таких мелочах, как различные датчики и кнопки на устройстве Android.
Seeder’s автор взял Linux-demon rngd и скомпилировал для Android inastroil, чтобы он брал случайные данные из гораздо более быстрого и предсказуемого пути/dev/urandom и объединял их в dev/random/every во-вторых, не позволяя/dev/random/исчерпать себя. Это привело к тому, что система Android не испытывала недостатка энтропии и работала намного более плавно.
Google устранил эту ошибку после Android 3.0, но по какой-то причине Seeder все еще появляется на «рекомендуемые настройки» для оптимизации производительности Android. Кроме того, у приложения Seeder есть несколько аналогов, таких как sEFix, которые включают функциональность Seeder, независимо от того, используется ли тот же rngd или альтернативный hasged , или даже просто символическая ссылка между /dev/urandom и/dev/random. Это абсолютно бессмысленно для современных систем Android.
Причина, по которой это бессмысленно, заключается в том, что новые версии Android используют/dev/random/в трех основных компонентах – libcrypto для шифрование SSL-соединений, генерация ключей SSH и т. д. WPA_supplication/hostapd, который генерирует ключи WEP/WPA, и, наконец, несколько библиотек для генерации идентификатора при создании файловых систем EXT2/EXT3/EXT4.
Поэтому, когда в современные сценарии оптимизации Android включены усовершенствования на основе Seeder или Seeder, в конечном итоге происходит снижение производительности устройства, потому что rngd будет постоянно пробуждать устройство и вызывать увеличение частоты процессора, что, конечно, отрицательно сказывается на расходе заряда батареи.
Odex
Стандартная прошивка на устройствах Android почти всегда odex. Это означает, что наряду со стандартным пакетом для приложений Android в формате APK, находящимся в/system/app/и/system/priv-app/, имена файлов совпадают с расширением .odex. Файлы odex содержат оптимизированные приложения с байт-кодом, которые уже прошли через виртуальную машину валидатора и оптимизатора, а затем записаны в отдельный файл с использованием чего-то вроде инструмента dexopt ..
Таким образом, файлы odex предназначены для разгрузки виртуальной машины и предлагают ускоренный запуск приложения odex – с другой стороны, файлы ODEX предотвращают модификации прошивки и создают проблемы с обновлениями, поэтому для этого причина, по которой многие пользовательские ПЗУ, такие как LineageOS, распространяются без ODEX .
Создание файлов ODEX выполняется несколькими способами, например с помощью Odexer Tool – проблема в том, что его чисто эффект плацебо. Когда современная система Android не находит файлы odex в каталоге/system, система фактически создает их и помещает в каталог/system/dalvik-cache/. Это именно то, что происходит, например, когда вы запускаете новую версию Android и на какое-то время выдает сообщение «Занят, оптимизация приложений».
Настройки Lowmemorykiller
Многозадачность в Android отличается от других мобильных операционных систем в том смысле, что она основана на классической модели, в которой приложения работают в фоновом режиме, и нет ограничений на количество фоновых приложений ( , если он не установлен в параметрах разработчика, но обычно это не рекомендуется) – кроме того, функция перехода к фоновому выполнению не останавливается, хотя система оставляет за собой право отключить фоновые приложения в ситуации с нехваткой памяти ( смотрите, где мы говорили о lowmemorykiller и out-of-memory killer ранее в этом руководстве) .
Чтобы вернуться к lowmemorykiller , Android может продолжать работать с ограниченным объемом памяти и отсутствием раздела подкачки. Пользователь может продолжать запускать приложения и переключаться между ними, а система автоматически завершает неиспользуемые фоновые приложения, чтобы попытаться освободить память для активных задач.
Это было очень полезно для Android в первые дни, хотя по какой-то причине оно стало популярным в виде приложений-убийц, которые, как правило, более вредно, чем полезно. Приложения-убийцы задач либо просыпаются через определенные промежутки времени, либо запускаются пользователем и, кажется, освобождают большие объемы оперативной памяти, что считается положительным моментом – чем больше свободной оперативной памяти, тем быстрее устройство, верно? Однако в случае с Android дело обстоит не так.
На самом деле большой объем свободной оперативной памяти может отрицательно сказаться на производительности вашего устройства и времени автономной работы. Когда приложения хранятся в оперативной памяти Android, их намного проще вызывать, запускать и т. Д. Системе Android не нужно выделять много ресурсов для переключения на приложение, потому что оно уже есть в памяти.
Из-за этого таск-киллеры не так популярны, как когда-то, хотя новички в Android по какой-то причине все еще склонны полагаться на них (, к сожалению, информации не хватает) . К сожалению, на смену таск-киллерам пришла новая тенденция, тенденция настройки механизма lowmemorykiller .. Это может быть, например, приложение MinFreeManager , и основная идея состоит в том, чтобы увеличить накладные расходы ОЗУ до того, как система начнет убивать фоновые приложения.
Так, например, стандарт Оперативная память работает с границами – 4, 8, 12, 24, 32 и 40 МБ, и когда свободное пространство для хранения 40 МБ заполнено, одно из кешированных приложений, которое загружается в память , но не работает будет прекращен.
Таким образом, в Android всегда будет не менее 40 МБ доступной памяти, чего достаточно для размещения еще одного приложения перед lowmemorykiller начинает процесс очистки – это означает, что Android всегда будет делать все возможное, чтобы использовать максимальный объем доступной оперативной памяти, не мешая взаимодействию с пользователем.
К сожалению, некоторые энтузиасты домашнего пивоварения рекомендовали установить значение увеличивается, например, до 100 МБ до того, как LMK сработает. Теперь пользователь фактически потеряет ОЗУ (100-40 = 60), поэтому вместо использования этого пространства для хранения внутренних приложений система будет k освободите этот объем памяти бесплатно , совершенно бесполезно.
Настройка LKM может быть полезна для гораздо более старых устройств с 512 ОЗУ, но кому они больше принадлежат? 2 ГБ – это современный «бюджетный диапазон», даже устройства с 4 ГБ ОЗУ в наши дни считаются «средним диапазоном», поэтому настройки LMK действительно устарели и бесполезны.
Ввод-вывод настройки
Во многих сценариях оптимизации для Android вы часто найдете настройки, касающиеся подсистемы ввода-вывода. Например, давайте взглянем на ThunderBolt! Скрипт, содержащий следующие строки:
echo 0> $ i/queue/rotational; echo 1024> $ i/queue/nr_requests;
первая строка даст инструкции планировщика ввода-вывода для работы с SSD, а вторая увеличивает максимальный размер очереди ввода-вывода со 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 по умолчанию способно понять, с каким типом носителя оно работает.
Длинный ввод -output queue ( например, 1024) бесполезен на современном устройстве Android, на самом деле бессмысленен даже на настольном компьютере – это действительно только рекомендуется закончилось на высокопроизводительных серверах . Ваш телефон не является мощным Linux-сервером.
Для Android-устройства практически нет приложений с приоритетом ввода-вывода и нет механического драйвера, поэтому лучшим планировщиком является noop/FIFO- очередь, поэтому этот тип планировщика « tweak» не делает ничего особенного или значимого для подсистемы ввода-вывода. Фактически, все эти команды многоэкранного списка лучше заменить простым циклом:
for i in/sys/block/mmc *; doecho noop> $ i/queue/schedulerecho 0> $ i/queue/iostatsdone
Это включит планировщик noop для всех дисков из накопления статистики ввода-вывода, что должно иметь положительное влияние по производительности, хотя и очень крошечный и почти полностью незначительный.
Еще одна бесполезная настройка ввода-вывода, часто встречающаяся в сценариях производительности, – это увеличенные значения упреждающего чтения для SD-карт размером до 2 МБ. Механизм упреждающего чтения предназначен для раннего чтения данных с носителя до того, как приложение запросит доступ к этим данным. Таким образом, ядро будет пытаться выяснить, какие данные потребуются в будущем, и предварительно загружает их в оперативную память, что, таким образом, должно сократить время возврата. На бумаге это звучит великолепно, но алгоритм упреждающего чтения чаще неверен , что приводит к совершенно ненужным операциям ввода-вывода, не говоря уже о большом потреблении оперативной памяти.
В RAID-массивах рекомендуются высокие значения упреждающего чтения от 1 до 8 МБ, но для устройств Android лучше всего оставить значение по умолчанию 128 КБ.
Настройки системы управления виртуальной памятью
Другой распространенный метод «оптимизации» – настройка подсистемы управления виртуальной памятью. Обычно это нацелено только на две переменные ядра, vm.dirty_background_ratio и vm.dirty_ratio, которые предназначены для настройки размера буфера для хранения «грязных» данных. Грязные данные – это, как правило, данные, которые были записаны на диск, но их еще больше в памяти и они ждут записи на диск.
Типичные значения настроек в обоих Linux distros и Androis для подсистемы управления виртуальными машинами будет выглядеть примерно так:
vm.dirty_background_ratio = 10vm.dirty_ratio = 20
Итак, что он пытается сделать, так это то, что когда грязный буфер данных составляет 10% от общего объема ОЗУ, он пробуждает поток pdflush и начинает записывать данные на диск – если операция записи данных на диск будет слишком интенсивный , буфер будет продолжать расти, и когда он достигнет 20% доступной RAM, система переключится на последующую операцию записи в синхронном режиме – без предварительного буфера. Это означает, что работа приложения по записи на диск будет заблокирована до тех пор, пока данные не будут записаны на диск (также известное как «задержка»).
Что вы должны понимать, так это что даже если размер буфера не достигает 10% , система автоматически запускает pdflush через 30 секунд. Комбинация 10/20 довольно разумна, например, на устройстве с 1 ГБ ОЗУ это будет равно 100/200 МБ ОЗУ, что более чем достаточно с точки зрения пакетных записей, где скорость часто ниже записи скорости в системе NAND. -memory или SD-карта, например, при установке приложений или копировании файлов с компьютера.
По какой-то причине авторы сценариев пытаются поднять это значение еще выше, до абсурда.. Например, мы можем найти в сценарии оптимизации Xplix частоту 50/90.
sysctl -w vm.dirty_background_ratio = 50sysctl -w vm.dirty_ratio = 90
На устройстве с 1 ГБ памяти это устанавливает ограничение для грязного буфера на 500/900 МБ, что совершенно бесполезно для устройства Android, потому что оно будет работать только под постоянная запись на диск – то, что происходит только на тяжелом сервере Linux.
ThunderBolt! Сценарий использует более разумное значение, но в целом оно все еще довольно бессмысленно:
if ["$ mem" -lt 524288]; thensysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776]; thensysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; elsesysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi;
Первые две команды запускаются на смартфонах с 512 МБ ОЗУ, вторая – с 1 ГБ, а остальные – с объемом более 1 ГБ. Но на самом деле есть только одна причина для изменения настроек по умолчанию – устройство с очень медленной внутренней памятью или картой памяти. В этом случае разумно разложить значения переменных, то есть сделать что-то вроде этого:
sysctl -w vm.dirty_background_ratio = 10sysctl -w vm.dirty_ratio = 60
Затем, когда система перенапряжения записывает операции, без необходимости записи данных на диск, до последнего не будет переключаться в синхронный режим, что позволит приложениям уменьшить задержку при записи.
Дополнительные бесполезные настройки и настройки производительности
Есть гораздо больше «оптимизаций», которые на самом деле ничего не делают. Большинство из них просто не имеют никакого эффекта, в то время как другие могут улучшить некоторые аспекты производительности, в то же время ухудшая работу устройства другими способами ( обычно сводится к производительности по сравнению с разрядкой батареи). .
Вот несколько дополнительных популярных оптимизаций, которые могут оказаться полезными, а могут и не оказаться полезными, в зависимости от системы и устройства Android.
- Ускорение – небольшое ускорение для повышения производительности и снижения напряжения – немного экономит батарею.
- Оптимизация базы данных – теоретически это должно улучшить производительность устройства, но его сомнительно.
- Zipalign – По иронии судьбы, несмотря на встроенную функцию выравнивания содержимого Android SDK в APK-файле, в магазине вы можете найти множество программ, не передающихся через zipalign.
- Отключите ненужные системные службы, удалив неиспользуемые системные и редко используемые сторонние приложения. По сути, удаление вредоносного ПО.
- Пользовательское ядро с оптимизацией для конкретного устройства (опять же, не все ядра одинаково хороши).
- Уже описан планировщик ввода-вывода noop.
- Алгоритм насыщения TCP Westwood – более эффективно используется в Android Cubic по умолчанию для беспроводных сетей, доступен в настраиваемых ядрах.
Бесполезно сборка настроек. prop
LaraCraft304 с форума разработчиков XDA провело исследование и обнаружило, что впечатляющее количество настроек/system/build.prop, которые рекомендуются для использования «экспертами», не существуют в исходники AOSP и CyanogenMod. Вот список:
ro.ril.disable.power.collapsero.mot.eri.losalert.delayro.config.hw_fast_dormancyro.config.hw_power_savingwindowsmgr.max_events_per_secpersist.cust.tel.eonsrocity.max.fling .min.fling_velocityro.kernel.checkjnidalvik.vm.verify-bytecodedebug.performance.tuningvideo.accelerate.hwro.media.dec.jpeg.memcapro.config.nocheckinprofiler.force_disable_ulogprofileters.Head_disable_disable_ulogprofileters.For_disable_disable_ulogprofilers.force_disable.