Ускоряем наш Android

MIUI, базирующаяся на Android 2.3.7 меня утомила необходимостью постоянно следить за качеством софта на тему жручести батареи. Проведёшь жёсткую оптимизацию, вытянешь до 30..32 часов работы, проходит пара недель — снова живёт лишь часов 20. И это в хороших условиях. Как начнёшь по городу и метро мотаться, сменяя БС за БС, так и с утра до вечера может не хватить.

Помню по прошлогодним экспериментам, что под 4.x было всё на этот счёт вполне прилично. Но хватало своих глюков. Особенно убивали тормоза, которые неизбежно приходили через какое-то время после начала использования.

Решил посмотреть, что за прошедшие месяцы изменилось. Порылся по форумам, посмотрел, что хвалял. Скачал сперва расхваленный Nik Project и… нарвался сходу на баг новой только что вышедшей его версии. Тогда перепрошился на CM 10.1 RC1…

Что сказать, работает, вроде бы, всё нормально. С камерой есть лёгкие глючки (в процессе фокусировки экран мигает зелёным, но на снимках это не сказывается). FM-радио отсутствует (говорят, что лечится, не разбирался). В остальном — всё ок. Со всеми плюсами и минусами Android 4. Но, главное — «из коробки» и после восстановления всего софта сутки держит уверенно. Ну а если экономно — то и двое суток. Но мне экономно не нужно

Но — пол бочки дёгтя. Через некоторое время работы снова начинает методично тормозить. Сперва немного, потом всё жестче. До полных подвисов. На форумах народ на это наступал. Ничего лучше, кроме как перезагружатся — не придумал. Терпел я это безобразие несколько дней, а со вчерашнего (т.е. уже позавчерашнего) дня сел разбираться. WTF?

Сразу резюме (детективную историю поиска по тупиковым путям опускаю) — не хватает памяти! При активной работе на обжитой машинке очень быстро память оказывается забитой Гуглоплюсами, Фейсбуками и прочими Гуглокартами.



При этом наблюдается две симптоматики:

1. Пока свободной памяти до 200Мб — всё летает вообще фантастически. Когда становится меньше 100Мб — начинает притормаживать. Если свободной памяти меньше 70Мб — тормоза очень сильные. Мегабайт 20-30 — всё, система встаёт колом. Она очень опрометчиво избавляется от кешей и буферов и опаньки. Флеш без кеша в наше время всё ещё крайне тормозной. Будь система поумнее, она бы убивала фоновые приложения, не трогая буфера и кеш. Но — увы. Поубиваешь процессы, освободишь память — всё на короткое время снова шустрит. Но — на короткое. Потому что через считанные минуты убиенный софт снова запущен. Уж как только я с этим не боролся. Мелкий эффект есть, но в целом — ужасно.

2. Как только кончается память, Android начинает убивать приложения. Но по каждому чиху снова их запускает. Убивая другие. И тут же снова запускает их, убивая запущенные перед этим. Снова страшные тормоза. Жор батареи. Особенно это заметно при поездках по городу. Постоянные смены БС провоцируют массу внутренних процессов постоянно дёргая весь софт…

Тут я опускаю серию экспериментов с отрыванием сервисов, интентов, раздачи приоритетов процессам — нехватка памяти не компенсируется ни чем.

И вот тут, наконец, я дозрел до «взрослого» решения

Своп!

Нет, я не стал извращаться жёстко, переразбивая карточку, создавая новый раздел… Я просто слепил своп-файл на карточке, смонтировал его… И эффект не передаваемый Нет, совсем идеально всё не стало, Андроид держит свободную память в районе 80-90Мб, что для идеальной плавности маловато, но в целом система реально перестала тормозить! Выделил 256Мб под своп, сейчас занято уже 235Мб. Надо будет выделить больше. Вы представляете, во что выливается нехватка 235Мб при свободной памяти в 80-90Мб? То-то же! Но самый шикарный эффект даже не от прекращения жёстких тормозов, а от того, что софт перестаёт убиваться от нехватки памяти. Теперь тяжёлые приложения стартуют не совсем мгновенно, конечно, т.к. грузятся, всё же, из свопа, но очень быстро. Половина секунды вместо многих секунд полной начальной инициализации. И они — «живые», в том состоянии, в котором оставались. Ибо далеко не весь софт восстанавливает целиком состояние, как положено. И на это нужно, опять же, время. А тут — через пол-часа активной работы в десятке приложений возвращаешься в читалку — а она сразу готова к работе, не переоткрывает заново книжку. Потому что не убивалась

А теперь — непосредственно рецепты для заинтересованных

— Необходим root.

— Дальше два варианта. Первый — совсем простой. Качаем бесплатный Swapper for Root - Приложения на Google Play , запускаем, отмечаем «Active Swap on Boot» выбираем размер свопа и... готово.

— Второй вариант — для Ъ-линуксоидов

— Нужно подключиться к командной строке Андроида. Можно это сделать (вероятно) через adb shell, но я по старой привычке цепляюсь через QuickSSHd - Приложения на Google Play

— Выполняем следующие команды:

1. # Создаём своп-файл
2. busybox dd if=/dev/zero of=/mnt/sdcard/swap.swp bs=1K count=256K
3.  
4. # Инициализируем его
5. mkswap /mnt/sdcard/swap.swp
6.  
7. # Включаем
8. swapon /mnt/sdcard/swap.swp
9.  
10. # Говорим Андроиду довольно жёстко сбрасывать в своп данные
11. # Можно попробовать не 90, а, скажем, 50 :)
12. echo 90 > /proc/sys/vm/swappiness

Всё, вручную всё сделали, всё должно работать. Использование свопа можно оценить по команде free:



(продолжение завтра, как проснусь )

Продолжение наблюдений. За 8 часов с момента выдёргивания из розетки активно работающий коммуникатор (синхронизация, уведомления) просел до 80% заряда. Значит, общее время работы в режиме активного ожидания — около 40 часов выходит. Похоже, есть небольшая прибавка, но — совсем небольшая. В режиме ожидания ротация приложений, вероятно, проходит реже, потому и особого оверхеда на это дело не было.

Своп немного расчистился, занято около 220Мб. Часть приложений (например, таки, читалка ) закрылись. Но машинка по сравнению с тем, что было, просто летает.

Перед сном включил своп (вручную извращаться не стал, через упомянутый выше Swapper) на коммуникаторе жены (там, вообще, всего 512Мб оперативки, тормозило часто даже без всяких толстых социальных сетей). Заработало явно шустрее. Т.е. с вечера всё летало, сейчас пишу ей на работу — «как коммуникатор», говорит — «нормально» (а вчера готова была его разбить — потом я и наоптимизировался ). Только, пишет, музыка стала глючить. По описанию только не понял, но, похоже, в каких-то условиях стала затыкаться. Надо будет посмотреть, как вернётся. Может, приоритеты подкрутить (об этом напишу подробнее в следующий раз). Правда, у неё хитрая организация памяти — в /mnt/sdcard монтируется встроенная флешка, а SD-карточка — в подкаталог в ней. Swapper этого не понял, потому пока своп во внутренней флеш-памяти. Надо будет поберечь её, перекинуть вручную на карточку.

Решил посмотреть ситуацию с моим планшетом, Asus Transformer TF300T. Я уже не раз жаловался на чудовищные тормоза IO Wait на нём. Возможно, ситуация облегчится, если выделить побольше на буфера. С ним пока сходу не вышло. Сперва пощупал приложение Swapper 2. Оно, с виду, заявлено функционала побольше, чем у Swapper. Можно сразу swappines выставить. Позволяет отключить своп, когда карточка монтируется для доступа к ней по USB (осторожнее на этот счёт, кстати, можно, наверное, завесить машинку. Мне-то проще, я ни один девайс как Mass storage не использую, по USB данные не качаю). Реально оказался негодным, так как возможные размеры свопа у него смешные, а любой размер не выставить. Снёс, поставил Swapper. Пишу — сделать своп на 500Мб. Бодро отрапортовал «ок», заглядываю терминалкой, free — фигушки, своп нулевой. Пробую включить вручную — ругается на ошибку. То ли ядро стоковое своп не поддерживает вообще, то ли связано с тем, что там Android 4.2 и многопользовательская система, так что /mnt/sdcard — сменный. Надо будет разобраться позднее. Всю прошивку менять пока не готов, но кастомное ядро можно будет попробовать поставить, если дело в нём.

Да, кстати, чтобы поковыряться с системой, не обязательно ставить abd на десктоп или разбираться с ssh. Можно из эмулятора терминала прямо с устройства ковыряться (хотя не так удобное, как из нормального ssh под Linux ):

Подсказки. Как проверить, есть ли поддержка свопа в вашем ядре:

1. # zcat /proc/config.gz | grep -i swap                      
2. CONFIG_SWAP=y
3. CONFIG_RING_BUFFER_ALLOW_SWAP=y

В данном случае на планшете, как оказалось, есть. Так что причина в другом.

Расшифровка: в виртуальном файле /proc/config.gz лежит запакованный конфиг ядра, с которым оно собиралось. zcat выводит на экран (точнее, в stdout) распакованный архив. grep — фильтрует вывод, оставляя только строки, в которых есть указанная подстрока.

А пока продолжу топикстарт.

Освобождение памяти — это хорошо. Но это не единственный способ сделать нужный софт побыстрее. В Linux каждый процесс может работать с разным уровнем приоритета. Чем значение приоритета («nice» в терминах Linux) меньше, тем он выше. По умолчанию софт запускается с нулевым приоритетом. То, что менее важно, можно запустить с приоритетом ниже среднего, тогда значение nice будет положительным. То, что важно — можно запустить с nice отрицательным. Значения принимают величины от -20 до +19. Но крайними значениями лучше не увлекаться. Хватит игр в диапазоне ±1..10

Под Android имеет смысл поднять приоритет вещам, отзывчивость которых особенно важна. Например, телефонному модулю, звонилке. Или даже оболочке, лончеру, чтобы вызывалась при нажатии на кнопку Home быстро. Желательно также иметь высокий приоритет для GUI и системы отрисовки.

Переназначение приоритета выполняется командой renice, которая принимает два параметра — новый приоритет и цифровой идентификатор нужного процесса.

pid процесса можно получить командой pidof, указав имя его в качестве аргумента. Скажем, звонилка DialerOne — это процесс с именем kz.mek.DialerOne.

1. # pidof kz.mek.DialerOne
2. 24688
3. # renice -5 24688

Ну и чтобы ручками не задавать pid, команды можно скомбинировать:

1. renice `pidof kz.mek.DialerOne`

Обратные слеши (которые на кнопке «~» и «Ё», под Esc) указывают, что надо выполнить команду внутри них и результат подставить в вызывающую команду.

Посмотреть текущий приоритет процесса можно в списке, выводящимся по ps -p:

1. # ps -p | less
2. ...
3. USER     PID   PPID  VSIZE  RSS   PRIO  NICE  RTPRI SCHED   WCHAN    PC         NAME
4. root      1     0     388    156   20    0     0     0     c0127cdc 0000eaa8 S /init
5. root      2     0     0      0     20    0     0     0     c00b49a4 00000000 S kthreadd
6. root      3     2     0      0     20    0     0     0     c00a0cec 00000000 S ksoftirqd/0
7. root      6     2     0      0     -2    0     1     1     c00d815c 00000000 S rcu_kthread
8. root      7     2     0      0     0     -20   0     0     c00b0330 00000000 S khelper
9. root      8     1     0      0     20    0     0     0     c009f100 00000000 Z swapper
10. root      9     2     0      0     20    0     0     0     c00b011c 00000000 S kworker/u:1
11. root      12    2     0      0     0     -20   0     0     c00b0330 00000000 S suspend_sys_syn
12. root      13    2     0      0     0     -20   0     0     c00b0330 00000000 S suspend
13. root      343   2     0      0     20    0     0     0     c00ef7dc 00000000 S sync_supers
14. root      345   2     0      0     20    0     0     0     c00f05cc 00000000 S bdi-default
15. root      347   2     0      0     0     -20   0     0     c00b0330 00000000 S kblockd
16. …

(колонка NICE, выход из просмотра по less — кнопка «q»).

Так список получается очень большим. Можно вырезать только то, что нам надо:

1. # ps -p | grep -i dial                                                                            
2. u0_a45    24083 12697 288580 11152 20    0     0     0     ffffffff 40116ec0 S com.android.voicedialer
3. u0_a152   24688 12697 341292 28180 15    -5    0     0     ffffffff 40116ec0 S kz.mek.DialerOne

Я для себя установил примерно такой набор NICE:

1. renice -10 `pidof com.android.systemui`
2. renice -3 `pidof surfaceflinger`
3. renice -5 `pidof com.cyanogenmod.trebuchet`
4. renice -3 `pidof com.nuance.swype.dtc`
5. renice -10 `pidof com.android.phone`
6. renice -10 `pidof kz.mek.DialerOne`

Дальше — как прописать эти параметры в автозагрузку.

А карточку своп не скушает быстро? В смысле превышения 10 тыщ циклов перезаписи. Или там умный драйвер, в разные странички пишет?

Неприятность, блин. При включении свопа на флешку в DHD машинка часто виснет. На планшете TF300T на флешке и у жены на Galaxy W во внутренней памяти — всё ок. А на DHD — виснет :-/ Отдельным разделом пробовал — никакой разницы. Сделал своп во внутреннюю память — сперва было ок, потом, ночью, завис с авторестартом. Правда, потом, до утра, всё ок было. Посмотрим, как будет.

Если будет продолжать виснуть, надо будет пробовать другое ядро, что ли? Ну да хоть на TF300T реально работать много лучше стало