Простой способ ускорить работу Android смартфона или планшета

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

Кроме подсистемы I/O, принято также тюнинговать подсистему управления виртуальной памятью. Зачастую изменению подвергаются только две переменные ядра: vm.dirty_background_ratio и vm.dirty_ratio, которые позволяют регулировать размер буферов для хранения так называемых грязных данных, то есть тех данных, которые были записаны на диск приложением, но еще до сих пор находятся в оперативной памяти и ждут, пока они будут записаны на диск.

Стандартные значения этих переменных в десктопных Linux-дистрибутивах и Android примерно следующие:

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

При этом важно понимать, что, даже если размер буфера не достиг 10%, система так или иначе запустит поток pdflush через 30 с. Что нам дают эти знания? Фактически ничего, что мы могли бы использовать в своих целях

Комбинация 10/20% вполне разумна и, например, на смартфоне с 1 Гб памяти составляет примерно 100/200 Мб памяти, чего более чем достаточно в условиях редких всплесков записи, скорость которых зачастую ниже скорости записи в системную NAND-память или SD-карту (при установке софта или копировании файлов с компа). Но создатели скриптов оптимизации с этим, конечно же, не согласны.

Например, в скрипте Xplix можно найти примерно такие строки (в оригинале они намного длиннее из-за проверок на количество оперативной памяти и использования BusyBox):

Данные команды применяются к устройствам с 1 Гб памяти, то есть устанавливают лимиты «грязного» буфера, равные (примерно) 500/900 Мб. Такие высокие значения абсолютно бессмысленны для смартфона, так как работают только в условиях постоянной интенсивной записи на диск, то есть опять же для высоконагруженного сервера. В ситуации со смартфоном они будут ничем не лучше стандартных. Кстати, в скрипте ThunderBolt! применяются гораздо более разумные (и близкие к стандартным) значения, но я сомневаюсь, что от их применения пользователь заметит хоть какую-то разницу:

Первые две команды выполняются на смартфонах с 512 Мб оперативки, вторые — с 1 Гб, третьи — с более чем 1 Гб. Но на самом деле есть только одна причина изменять стандартные значения — девайс с очень медленной внутренней памятью и/или картой памяти (привет китайцам). В этом случае разумно разнести значения переменных, то есть сделать примерно так:

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

Вердикт: лучше не трогать.