Таким образом, во многих универсальных сценариях оптимизации используются одни и те же методы, некоторые из которых полностью устарели или вредны в долгосрочной перспективе. Таким образом, большинство сценариев оптимизации «все-в-одном» представляют собой не что иное, как нарезанные вместе рекомендуемые настройки, без четкого представления о том, как и почему эти оптимизации «работают - пользователи затем запускают сценарии и заявляют, что их производительность внезапно повышается ( когда на самом деле, скорее всего, это был очень простой акт перезагрузки устройства, который вызвал повышение производительности , поскольку все в оперативной памяти устройства очищается) .
В этой эксклюзивной статье Appuals мы выделим некоторые из наиболее распространенных рекомендаций для ' оптимизация » Производительность Android, и являются ли они просто мифом или законным изменением производительности устройства.
Обмен
В верхней части списка мифов стоит Android-своп, что довольно абсурдно с точки зрения оптимизации Android. Основная цель подкачки - создать и подключить файл подкачки, который освободит место для хранения в памяти. Звучит разумно на бумаге , но это действительно применимо к сервер , в котором практически нет интерактивности.
Если вы регулярно используете свопинг в своем телефоне Android, это приведет к серьезным задержкам, связанным с проскальзыванием кеша. Представьте, например, что приложение пытается отобразить графику, которая хранится в подкачке, которая теперь должна повторно загрузить диск после освобождения места путем размещения подкачки данных с другим приложением. Это действительно грязно.
Некоторые энтузиасты оптимизации могут сказать, что подкачка не вызывала проблем, но это не подкачка, повышающая производительность - это встроенный механизм Android. Убийца памяти , который будет регулярно уничтожать раздутые высокоприоритетные процессы, которые не используются. LMK был разработан специально для обработки условий нехватки памяти, вызывается из kswapd process, и обычно убивает процессы пользовательского пространства. Это отличается от OOMkiller (убийца вне памяти), но это совсем другая тема.
Дело в том, что устройство, например, с 1 ГБ ОЗУ, никогда не сможет получить необходимые данные о производительности в свопе, поэтому своп абсолютно не нужен в Android. Его реализация просто чревата лагом и приводит к деградация в производительности, а не в оптимизации.
zRAM - устаревший и неэффективный
zRAM - проверенный и эффективный метод оптимизации устройства для старые устройства - подумайте об устройствах на базе KitKat, которые работают только с 512 МБ ОЗУ. Тот факт, что некоторые люди до сих пор включают настройки zRAM в сценарии оптимизации или рекомендуют zRAM как своего рода современную настройку оптимизации, является примером того, что люди обычно не следуют последним рабочим протоколам.
zRAM была предназначена для многоядерных SoC начального уровня бюджетного диапазона, таких как устройства, использующие наборы микросхем MTK и 512 МБ ОЗУ. В принципе, очень дешевые китайские телефоны. В основном zRAM разделяет ядро через поток шифрования.
Когда zRAM используется на старых устройствах с одноядерный даже если на таких устройствах рекомендуется использовать zRAM, могут возникать большие задержки. То же самое происходит с технологией KSM ( Слияние одной и той же страницы ядра) который объединяет идентичные страницы памяти в попытке освободить место. На самом деле это рекомендуется 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 / file для получения энтропии. / Dev / random / buffer станет нестабильным, и система будет заблокирована до тех пор, пока не будет заполнено необходимое количество данных - подумайте о таких мелочах, как различные датчики и кнопки на устройстве Android.
Автор Сидера взял Linux-демона rngd , и скомпилирован для Android inastroil, так что он берет случайные данные из гораздо более быстрого и предсказуемого пути / 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, и, наконец, несколько библиотек для генерации ID при создании файловых систем EXT2 / EXT3 / EXT4.
Так когда Сеялка или улучшения, основанные на сидерах, включены в современные сценарии оптимизации Android, что в конечном итоге деградация в производительности устройства, потому что rngd будет постоянно пробуждать устройство и вызывать повышение частоты процессора, что, конечно, отрицательно сказывается на расходе заряда батареи.
Одекс
Стандартная прошивка на Android-устройствах почти всегда odex. Это означает, что наряду со стандартным пакетом для приложений Android в формате APK, находящимся в / system / app / и / system / priv-app /, имена файлов совпадают с расширением .odex. Файлы odex содержат оптимизированные приложения для байт-кода, которые уже прошли через виртуальную машину валидатора и оптимизатора, а затем записаны в отдельный файл с использованием чего-то вроде dexopt инструмент.
Таким образом, файлы odex предназначены для разгрузки виртуальной машины и предлагают ускоренный запуск приложения odexed - с другой стороны, файлы ODEX предотвращают модификации прошивки и создают проблемы с обновлениями, поэтому по этой причине распространяются многие пользовательские ПЗУ, такие как LineageOS. без ODEX .
Создание файлов ODEX выполняется несколькими способами, например с помощью Odexer Tool - проблема в том, что это чисто эффект плацебо. Когда современная система Android не находит файлы odex в каталоге / system, система фактически создает их и помещает в каталог / system / dalvik-cache /. Это именно то, что происходит, например, когда вы запускаете новую версию Android и на некоторое время выдает сообщение «Занят, оптимизация приложений».
Настройки Lowmemorykiller
Многозадачность в Android отличается от других мобильных операционных систем в том смысле, что она основана на классической модели, в которой приложения работают в фоновом режиме, и нет ограничений на количество фоновых приложений ( если он не установлен в параметрах разработчика, но это обычно не рекомендуется) - кроме того, не останавливается функционал перехода к фоновому выполнению, хотя система оставляет за собой право убивать фоновые приложения в ситуациях с нехваткой памяти ( (посмотрите, где мы говорили о lowmemorykiller и out-of-memory killer ранее в этом руководстве) .
Чтобы вернуться к Убийца памяти Механизм Android может продолжать работать с ограниченным объемом памяти и отсутствием раздела подкачки. Пользователь может продолжать запускать приложения и переключаться между ними, а система незаметно завершает неиспользуемые фоновые приложения, чтобы попытаться освободить память для активных задач.
В первые дни это было очень полезно для Android, хотя по какой-то причине оно стало популярным в виде приложений-убийц, которые, как правило, скорее вредны, чем полезны. Приложения-убийцы задач либо просыпаются через определенные промежутки времени, либо запускаются пользователем и, кажется, освобождают большие объемы оперативной памяти, что считается положительным моментом - чем больше свободной оперативной памяти, тем быстрее устройство, верно? Однако в Android дело обстоит иначе.
Фактически, наличие большого количества свободной оперативной памяти может нанести вред производительности вашего устройства и времени автономной работы. Когда приложения хранятся в оперативной памяти Android, их намного проще вызывать, запускать и т. Д. Системе Android не нужно выделять много ресурсов для переключения на приложение, потому что оно уже есть в памяти.
Из-за этого таск-киллеры уже не так популярны, как когда-то, хотя новички в Android по-прежнему склонны полагаться на них по некоторым причинам ( недостаток информации, к сожалению) . К сожалению, на смену таск-киллерам пришла новая тенденция. Убийца памяти настройки механизмов. Это было бы, например, MinFreeManager app, и основная идея состоит в том, чтобы увеличить накладные расходы на ОЗУ, прежде чем система начнет убивать фоновые приложения.
Так, например, стандартная оперативная память работает на границах - 4, 8, 12, 24, 32 и 40 МБ, и когда свободное пространство для хранения 40 МБ заполнено, одно из кешированных приложений, загружаемых в память но не работает будет прекращено.
Таким образом, в Android всегда будет не менее 40 МБ доступной памяти, чего достаточно, чтобы разместить еще одно приложение, прежде чем Убийца памяти начинает процесс очистки - это означает, что Android всегда будет делать все возможное, чтобы использовать максимальный объем доступной оперативной памяти, не мешая работе пользователя.
К сожалению, некоторые энтузиасты домашнего пивоварения начали рекомендовать, чтобы значение было увеличено, например, до 100 МБ, прежде чем LMK вступит в силу. Теперь пользователь фактически терять RAM (100-40 = 60), поэтому вместо использования этого пространства для хранения внутренних приложений система будет хранить этот объем памяти. свободный , без всякой цели.
Тюнинг LKM может быть полезно для гораздо более старых устройств с 512 ОЗУ, но кому они принадлежат? 2 ГБ - это современный «бюджетный диапазон», в наши дни даже устройства с 4 ГБ ОЗУ считаются «средним уровнем», поэтому настройки LMK действительно устарели и бесполезны.
Настройки ввода / вывода
Во многих сценариях оптимизации для Android вы часто найдете твики, касающиеся подсистемы ввода-вывода. Например, давайте посмотрим на ThunderBolt! Скрипт, который содержит эти строки:
эхо 0> $ я / очередь / ротация; echo 1024> $ i / queue / nr_requests;
Первая строка даст инструкции планировщика ввода-вывода для работы с SSD, а вторая увеличивает максимальный размер очереди ввода-вывода со 128 до 1024 - потому что переменная $ i содержит путь к дереву блочных устройств в / sys, и сценарий запускается в цикле.
После этого вы найдете строку, относящуюся к планировщику CFQ:
эхо 1> $ я / очередь / iosched / back_seek_penalty; эхо 1> $ я / очередь / iosched / low_latency; эхо 1> $ я / очередь / iosched / slice_idle;
Далее следуют другие строки, принадлежащие другим планировщикам, но в конечном итоге первые две команды бессмысленны, потому что:
Современное ядро Linux по умолчанию способно понять, с каким типом носителя данных оно работает.
Длинная очередь ввода-вывода ( например 1024) бесполезен на современном устройстве Android, на самом деле бессмыслен даже на настольном компьютере - его действительно рекомендуется только на сверхмощные серверы . Ваш телефон не является мощным сервером Linux.
Для устройства Android практически нет приложений с приоритетом ввода-вывода и механического драйвера, поэтому лучшим планировщиком является очередь noop / FIFO, поэтому этот тип планировщика « настройка » не делает ничего особенного или значимого для подсистемы ввода-вывода. Фактически, все эти команды многоэкранного списка лучше заменить простым циклом:
для i в / sys / block / mmc *; do 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% доступной RAM, система переключится на последующую операцию записи в синхронном режиме - без предварительного буфера. Это означает, что работа по записи на диск приложения будет заблокирован, пока данные не будут записаны на диск (Также известный как «отставание»).
Вы должны понимать, что даже если размер буфера не достигает 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! В скрипте используется более разумное значение, но в целом оно все еще бессмысленно:
если ['$ 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-bytecode 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.shutdownHersist.sys.shutdownТеги андроид Развитие 12 минут на чтение
