Скрипты твики 4pda. Как работает EXPOSED

Are so lovable for all Android lovers. What they can do? It makes your phone extra ordinary and boost your smartphone by changing its internal features which are default by company OS. If you have ever tried some , I am sure you already know the importance of Best Build.prop Tweaks and their features which you can access after applying them on your device. Build Prop Tweaks can be applied on any Android running on Jellybean, Kitkat, Lollipop or Marshmallow.

For Android Lovers, we are sharing best build prop tweaks for Android . Android is the best platform for testing new awesome Tweaks & Tricks on it. If you are Android addict then you may also like design it with different Launchers and all and Build Props are the craziest thing for you.

Root Access is the main requirement for doing anything under root in your Android smartphone. We are able to use on our Rooted mobile to boost its performance and lookup. Rooting unlocks our Android phone fully and we are able to change anything in our Android features as we want. You are able to and also after rooting your device.

Many Android masters loves to test different awesome tweaks on their smartphone. They install and test different stylish on their Android devices to change its appearance. Also they loves to test different Build.prop tweaks on their Android phones.

So if you are also lover to install different types of tweaks on your smartphone then you are at a right place. Here I am going to share Build prop tweaks for JellyBean, Kitkat, Lollipop & Marshmallow Android version smartphones to boost your Android device’s performance. These are the latest new Build prop tweaks by which you can change many internal features of your Android device and boost your Android device performance. But you must need to root your Android device first to install these tweaks on your mobile. Let check out from list below.

Must Check:- | |

Build.prop is a file in our Android device which is stored in /system/path of our Android devices. It stores all Specifications, Features and Settings of our Android mobile. It is very important file of our Android device, without this file our Android device can’t able to run, Even your Android mobile can’t able to start without this file. This file is invisible this is why we never seen this file on our mobile. But we are able to find this file after rooting our Android device. And we are also able to change its setting to tweak our Android phone. Root is must needed for it because our Android operating system can’t grant permissions to touch its internal functions, so we have to root our device to grant Android device permission.

You are also able to add some more tweaks on your Android device from Build.prop file. So in this article I am going to sharing some Build.prop tweaks for JellyBean, Kitkat, Lollipop, Marhsmallow Android version phones to boost your device performance. Also I described steps for how to add Build.prop tweaks on Android in the bottom of this article.

Must Read:-

(Default value is 240. Don’t forget to install a patched market after changing it.)

(If SMS/MMS couldn’t be sent, it retries after 2 instead of 5 seconds)

(May be unstable – better have it activated)

These were the some Top Build Prop Tweaks for Android devices. I think I have covered all categorized build.prop tweaks for you. If I missed something, feel free to comment below. On Internet only these are the most popular tweaks I had founf that’s why I shared these one only.

Львиная доля системных параметров Android, скрытых от глаз пользователя, хранится в единственном файле под названием build.prop. Грамотное изменение настроек поможет вдохнуть вторую жизнь в гаджет: улучшить автономность и производительность, оптимизировать интерфейс. В статье мы покажем, как удобно редактировать build.prop, и приведём примеры полезных твиков, а также тех, которые кочуют из статьи в статью на разных ресурсах, но на самом деле не работают.

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

Всё, что вам потребуется для внесения изменений - редактор текстовых файлов и права суперпользователя. Узнать, как получить root-доступ, можно на нашем форуме вразделе прошивок для Android в теме, посвящённой вашему смартфону или планшету. Для непосредственных изменений в файле можно пользоваться обычным текстовым редактором - для этого придётся самостоятельно найти файл по пути /system/build.prop. Но намного удобнее вносить изменения с помощью специализированной программы, например,BuildProp Editor .

Перед тем как приступить к экспериментам, необходимо обязательно сделать резервную копию файла. BuildProp Editor сохраняет бэкап оригинала автоматически при первом запуске. Если же вы решите пользоваться обычным текстовым редактором, то не забудьте сделать копию вручную. Если что-то вдруг пойдёт не так, то вам будет достаточно заменить «испорченный» build.prop резервной копией, чтобы вернуть всё на свои места.

Ускорение загрузки. Современные смартфоны нередко загружаются едва ли не дольше, чем обычные ПК. Немного поколдовав над настройками в build.prop, можно с лёгкостью увеличить скорость загрузки гаджета в полтора-два раза! В этом помогут следующие настройки:

debug.sf.nobootanimation=1

ro.config.hw_quickpoweron=true

После внесения этих настроек будет изменён режим выключения гаджета, а также отключена загрузочная анимация разработчика прошивки. В результате при загрузке смартфона вы какое-то время не будете ничего наблюдать на экране. Пугаться этого не стоит: именно благодаря отключению ненужных анимаций тестовый смартфон стал загружаться всего за 30 секунд вместо прежних 50 секунд.

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

logcat.live=disable

Отключение лога уменьшит количество дисковых операций, что положительно скажется на быстродействии внутренней памяти смартфона. Правда, разница будет заметна разве что на гаджетах с медленными типами памяти: в нашем случае скорость последовательной записи возросла на 2 МБ/с.

Ускорение сети. Этот твик увеличивает размеры TCP-буферов, что поможет увеличить скорость медленного интернет-соединения, особенно при использовании мобильных сетей. Ну а прописывание DNS-серверов Google в некоторых случаях позволяет снизить время пинга.

net.tcp.buffersize.default=4096,87380,256960,4096, 16384,256960

net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960

net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960

net.rmnet0.dns1=8.8.8.8

net.rmnet0.dns2=8.8.4.4

net.dns1=8.8.8.8

net.dns2=8.8.4.4

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

Скорость передачи данных со стандартными настройками

Скорость передачи данных после редактирования build.prop

К сожалению, чудес не бывает - двукратного увеличения автономности достичь не удастся никакими твиками. Но добавить лишние 30-60 минут к времени работы гаджета вполне возможно.

Увеличение интервалов сканирования Wi-Fi. По умолчанию Android сканирует окружающие сети Wi-Fi каждые 20-90 секунд. Причём делает это даже тогда, когда Wi-Fi выключен, но разрешён фоновый поиск сетей для увеличения точности определения местоположения. Чтобы расширить данный интервал, необходимо добавить в файл build.prop строку:

wifi.supplicant_scan_interval=200

Здесь число 200 и является интервалом сканирования сетей в секундах.

Экономия заряда на LineageOS. Небольшой твик, обеспечивающий более эффективное управление спящим режимом при использовании CyanogenMod или LineageOS на смартфонах с чипсетами Qualcomm:

pm.sleep_mode=1

Ещё больше полезных твиков вы можете найти на форуме 4PDA.

Помимо действительно работающих твиков, приведённых в этой статье и в теме на форуме, существует немало таких, которые широко разошлись по Сети, но на самом деле не оказывают никакого влияния на работу системы. Соответствующее исследование провёл один из пользователей ресурса xda. Онпроанализировал исходный код AOSP и CyanogenMod и выяснил, что множество популярных твиков просто не упомянуты в исходном коде Android. Среди них есть самые разные записи.

Твики, не экономящие заряд:

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
debug.performance.tuning

video.accelerate.hw

Другие бесполезные твики. Они предназначены для отключения проверки байт-кода Dalvik и запрета выгрузки лончера из оперативной памяти. Когда-то они действительно работали, но совершенно не актуальны для современных версий Android из-за изменения внутренней архитектуры ОС:

dalvik.vm.verify-bytecode

И ещё немного различных попросту не работающих твиков:

ro.media.dec.jpeg.memcap

ro.config.nocheckin

profiler.force_disable_ulog

profiler.force_disable_err_rpt

persist.sys.shutdown.mode

ro.kernel.checkjni

Интересно, что хотя некоторые из этих записей и были полезны для старых версий Android, некоторые не работали вообще никогда, являясь своего рода плацебо. А почему подобное массовое заблуждение вообще возникло - сейчас уже и не выяснить. Впрочем, от внесения таких записей в build.prop смартфон не станет хуже работать - все недействительные записи просто будут проигнорированы.

Даже несмотря на то, что многие из рекомендуемых на форумах и различных сайтах твики вообще не функционируют, файл build.prop всё ещё остаётся неплохой возможностью улучшить интерфейс и работу вашего смартфона. Так что получайте права суперпользователя, делайте резервную копию настроек и смело экспериментируйте!

В отличие от iOS, Windows Phone и некоторых других мобильных ОС, исходный код Android открыт, благодаря чему энтузиасты могут модифицировать систему каким угодно образом и оформлять свои модификации в виде свободно распространяемых прошивок, таких как CyanogenMod, Paranoid Android и OmniROM. Такие прошивки содержат в себе огромное количество полезнейших модификаций, однако не каждый готов идти на риск, устанавливая их. К счастью, существует способ получить все преимущества кастомов на любой стоковой прошивке.

Не так давно мы уже что для Android существует система Xposed - набор библиотек и приложений, которые, работая вместе, позволяют сторонним приложениям перехватывать обращения к любым Java-классам Android и подменять их на свои собственные. Проще говоря, аналог Cydia Substrate для iOS, с помощью которого пользователь может изменять поведение и внешний вид андроид.

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

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

Xposed состоит из двух основных компонентов: модифицированной версии бинарника /system/bin/app_process, который в Android отвечает за запуск виртуальной машины Dalvik, и набора Java-классов XposedBridge.jar, который содержит код, способный перехватывать вызовы любых Java-классов и отдавать их другим классам.

Суть метода. Инсталлятор Xposed заменяет стандартный app_process на свой собственный. При загрузке операционная система стартует виртуальную машину с помощью подмененного app_process, который автоматически загружает XposedBridge.jar. По мере работы система форкает виртуальную машину для каждого запускаемого Java-приложения, включая графический интерфейс и множество системных компонентов, так что классы XposedBridge оказываются в каждом из них.

При установке Xposed-модуль реги стрирует себя в XposedBridge в качестве обработчика тех или иных Java-классов этих приложений, что дает ему возможность заменить их на свои собственные. Говоря другими словами, модули Xposed не изменяют систему, а подменяют ее компоненты на «фейковые», поэтому после отключения модуля или всего Xposed система автоматически вернется к перво начальному состоянию.

Установить и настроить Xposed довольно просто. По своей сути это обычный APK-пакет, который
после запуска разворачивает все необходимые компоненты для работы системы Xposed в систему. Получить сам пакет можно на официальном сайте (goo.gl/61rOz7). Там же, кстати, находится репозиторий модулей, однако скачивать модули вручную не придется, так как все можно сделать с помощью самого приложения.

После скачивания и установки пакета переходим в раздел «Фреймворк» и нажимаем кнопку «Установить/обновить», далее нажимаем «Быстрая перезагрузка», чтобы система подхватила установленные компоненты Xposed при следующей загрузке. В большинстве случаев этого будет
достаточно для того, чтобы подготовить Android к установке модулей. Если же речь идет о смартфоне с залоченным разделом /system (S-ON), способ установки придется изменить на «Из режима восстановления» в меню «Фреймворк Режим установки». В этом случае после нажатия
кнопки «Установить/обновить» система уйдет в перезагрузку и архив с компонентами Xposed будет автоматически прошит с помощью консоли восстановления.

После перезагрузки вновь запускаем инсталлятор Xposed и переходим в раздел «Загрузка». Здесь отображаются все доступные в репозитории модули, а также обновления самого Xposed. Для установки модуля просто выбираем нужный и нажимаем кнопку «Загрузка» напротив последней версии. Чтобы активировать модуль, переходим в раздел «Модули», ставим галочку напротив того, что установили, и перезагружаем смартфон.

Попробуем установить один из модулей. Для примера хорошо подойдет Tinted Status Bar. Находим его, устанавливаем, активируем в секции «Модули» инсталлятора Xposed и отправляем смартфон в перезагрузку. После загрузки пробуем запускать разные приложения. Эффект должен быть заметен сразу, это строка состояния, которая теперь меняет цвет в зависимости от цветовой схемы самого приложения (почти как в iOS 7). Вот и все, мы поменяли поведение системного компонента без установки кастомных прошивок и модификаций, прошиваемых через
recovery!


Далее я расскажу о самых интересных, необычных и полезных модулях Xposed, но сначала предупрежу о нескольких нюансах, которые надо знать перед тем, как приступить к их установке.

Первое - модули бывают преимущественно двух типов: те, что просто делают свою работу и нигде не светятся, и те, что поддаются настройке. Модули первого типа могут изменять внешний вид или поведение системы, но настроить их не удастся; либо они активны в настройках Xposed, либо отключены (пример такого модуля - Masterkey Multi-fix). Модули второго типа обычно тоже никак себя не проявляют, но создают иконку в меню приложений, которая открывает доступ к настройкам модуля. С их помощью можно активировать те или иные функции модуля и изменить его поведение (примеров таких модулей полно: App Settings, GravityBox и многие другие).


Второе - не все модули совместимы с любыми версиями Android. Некоторые из них рассчитаны на работу с определенными типами стоковых прошивок (например, с прошивками от Samsung или HTC) и могут вести себя непредсказуемо на других прошивках (хотя смартфон они не окирпичивают, конечно). Другие рассчитаны только на работу с определенной версией Android. Например, в репозитории есть два модуля GravityBox, один из которых рассчитан на работу в Jelly Bean (Android 4.1–4.3), другой - в KitKat (4.4). Чтобы не словить глюки, этот момент тоже нужно учитывать. Также следует быть осторожнее с планшетами на базе Android 4.0–4.1, в них используется несовместимый с телефонным интерфейс и многие модули не работают.

Отдельная история - кастомные прошивки. Обычно с ними никаких проблем не возникает, но случаются курьезы. Например, после установки GravityBox в OmniROM ты получишь два индикатора батареи. Происходит так потому, что в этой прошивке используется собственный, несовместимый со стоком механизм отображения индикатора батареи, о котором GravityBox ничего не знает. К счастью, проблема легко решается отключением индикатора либо в настройках самой прошивки, либо в GravityBox (останется только один индикатор).

Третье - модуль может быть не просто обособленным пакетом, а входить в состав обычного Android-приложения. Если ты установишь на смартфон приложение Greenify из Play Store, в Xposed появится соответствующий модуль. В случае с этим приложением он опционален и нужен для получения большего контроля над сном приложений. Многие другие приложения также используют Xposed для расширения своей функциональности: BubbleUPnP для стриминга аудиопотока из любого плеера, Cool Tool - для отображения разных данных в строке состояния и так далее.
Перейдем к модулям. В мой список самых самых вошли более двадцати модулей на любой вкус и цвет. Вот они:

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

Модуль способен кастомизировать строку состояния, изменять набор и расположение тайлов в шторке, позволяет изменять поведение кнопок навигации или вообще их отключить, расширяет меню перезагрузки (на манер кастомных прошивок), включает в себя реализацию PIE из Paranoid Android (аналог LMT Launcher), позволяет применить экранные фильтры, изменить поведение хардварных кнопок, поведение светодиода уведомлений и зарядки и многое-многое другое.

Фактически GravityBox - это сборник лучших функций из сторонних прошивок, с помощью которых можно изменить Android. Все функции поддаются тонкой настройке, однако в отличие от кастомных прошивок настройка производится с помощью специального и не слишком удобного меню, доступного через иконку GravityBox в меню приложений. Кроме GravityBox, в репозитории
можно найти и другие «модули-комбайны», такие, например, как Wanam и Xblast Tools, но по функционалу они уступают.

Еще один очень популярный и полезный модуль. Предназначен для изменения внешнего вида
и поведения отдельно взятых приложений. Включает в себя такие функции, как возможность изменения значения DPI (позволяет увеличивать или уменьшать размеры элементов управления
приложения), изменение размера шрифта, языка приложения. Позволяет принудительно включить полноэкранный режим для любого приложения или заблокировать гашение экрана, принудительно включить альбомную или портретную ориентацию (полезно в случае приложений, которые умеют работать только в одном режиме, например диалер) и многие другие. Одна из интересных функций - возможность показа приложения поверх экрана блокировки.

Кроме того, модуль имеет свой собственный механизм отзыва полномочий у приложений, работающий независимо от системы AppOps, которая появилась в качестве скрытой возможности
в Android 4.3. С ее помощью можно, например, запретить определенному приложению ходить в интернет или отправлять SMS. Очень удобно при борьбе с назойливой рекламой или подозрительным софтом.

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

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

Еще одна реализация многооконного режима, на этот раз из прошивки OmniROM. В отличие от модуля, описанного выше, не создает отдельное окно для приложения, а разделяет экран на две части, в которых отображается интерфейс разных приложений. Это очень похоже на встроенную функцию прошивок от Samsung, но действует в отношении любого приложения, а не только ограниченного набора стандартных приложений прошивки.

Работает сразу после установки и перезагрузки; приложение, запущенное с рабочего стола, откроется в полноэкранном режиме, если же в момент запуска экран уже будет занят другим приложением, то он разделится надвое. Имеет те же проблемы совместимости, что и XHaloFloatingWindow, но сам по себе гораздо полезнее. Не поддерживает фирменные самсунговские возможности, такие как drag’n’drop между приложениями. К слову сказать, в настоящий момент многооконный режим из OmniROM выпилен (по причине падений некоторых приложений), поэтому можно использовать данный модуль для замены.

Данный модуль выполняет одну простую функцию: запрещает отдельно взятым приложениям автоматически запускаться на этапе загрузки ОС. Дело в том, что по умолчанию Android не позволяет регулировать автозапуск приложений, как это можно сделать в любой настольной ОС. Приложение, имеющее полномочие android.permission.RECEIVE_BOOT_COMPLETED, будет автоматически запущено системой при загрузке, и сделать с этим ничего не получится.

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

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

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

Минус модуля - он платный. По умолчанию устанавливается триальная двухнедельная версия, а для покупки полной придется заплатить один доллар. Кстати, чтобы получить доступ к другим ползункам громкости (громкость мультимедиа и будильника), необходимо потянуть вниз чуть ниже статусбара, пока на последнем отображается основной ползунок.

Три модуля для изменения поведения и внешнего вида сообщений, появляющихся на экране при определенных событиях (toast message).

Burnt Toast добавляет к сообщению иконку приложения, его вызвавшего (с возможностью кастомизации). Jelly Toast заменяет ущербный стиль оформления сообщений в KitKat (со скругленными углами и широкой рамкой) на простой и лаконичный из Jelly Bean.

EnhancedToast объединяет в себе функции двух предыдущих модулей и позволяет блокировать сообщения от выбранных приложений (большинство из них действительно бесполезны), в том числе с возможностью фильтрации по regexp (будут показаны только те сообщения, что попадают под шаблон). Как дополнительный бонус предоставляется поддержка Tasker, с помощью которого можно настроить автоматическое управление функциями модуля.

Второй в моем личном списке наиболее полезных модуль (после StatusbarVolume). Делает одну простую вещь - автоматически разворачивает сокращенные ссылки перед их открытием в приложении. Зачем это нужно, когда любой браузер развернет их самостоятельно? Затем, что ссылка, ведущая, например на youtube.com, play.google.com или facebook.com, в стандартной ситуации открывается не в браузере, а в соответствующем приложении, что правильно и очень удобно.

Однако, если ссылка будет сокращена, система не сможет понять, кому ее отдать, и отправит дефолтовому браузеру, который появится на экране, развернет ссылку и лишь затем отдаст ее клиенту (и это в лучшем случае, в худшем - откроет внутри себя).

CrappaLinks решает эту проблему, перехватывая интенты, содержащие ссылку на HTTP-ресурс, и автоматически разворачивает ее в случае необходимости. Платить за это приходится некоторым замедлением при открытии ссылок, но это все равно быстрее, чем запуск браузера. В целом musthave-модуль для всех, кто часто сидит в твиттере или других соцсетях.

Достаточно стандартный блокиратор звонков, отличие которого от других реализаций заключается в том, что он работает на самом низком уровне ОС, там, где происходит передача информации от демона rild к звонилке. В итоге встроенная звонилка даже не узнает о произошедшем звонке. Другие подобные приложения действуют на пользовательском уровне и, по сути, просто кладут трубку сразу после звонка, предварительно отключив звук; из-за этого можно словить множество глюков вроде кратковременного включения экрана, кратковременного звука звонка и проскакивающих иконок пропущенного звонка. Часть функционала доступна только после покупки ключа: блокировка исходящих звонков, блокировка звонков с приватных и скрытых номеров.

Простой брандмауэр, позволяющий отключать передачу данных для отдельно взятых приложений в зависимости от типа сети. По сути, представляет собой аналог DroidWall с более правильной реализацией: не зависит от iptables, которого нет во многих стоковых прошивках, активируется еще до начала загрузки основных компонентов ОС, благодаря чему утечки исключаются (DroidWall запускается уже после полной загрузки ОС), правила активны всегда, а не назначаются заново при изменении сетевого подключения.

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

Sense 5/6 Toolbox - набор твиков и хаков для стоковых прошивок от HTC.
HTC One Tweaker - твики и хаки для HTC One.
MotoGuide - сборник твиков и хаков для Moto X.
Chrome New Tab - заставляет Chrome всегда открывать новые ссылки в новой вкладке.
Phab7 - позволяет переключаться между телефонным и планшетным режимами.
Ok Google for 3rd party launchers - добавляет автоматическое распознавание голоса в сторонние лаунчеры.
Master Key multi-fix - закрывает знаменитый баг Master Key.
NetworkSpeedIndicator - добавляет в строку состояния индикатор скорости передачи данных.
CpuTemp in Statusbar - показывает темпера туру процессора в строке состояния.
Holo Themer - позволяет на лету переключаться между светлой и темной темой оформления приложений.
YouTube AdAway - блокирует рекламу в приложении YouTube.
Allow Fullscreen Youtube with HDMI - активирует по-настоящему полноэкранный режим при выводе картинки из плеера YoutTube по HDMI.
AppOpsXposed - открывает доступ к функции AppOps (см. выше).
Complete Action Plus - позволяет кастомизировать диалоги выбора файлов и приложений.
DitheredHoloBackground - делает задний фон приложений истинно черным, без градиента (полезно для AMOLED-дисплеев).
DoubleTapToSleep - отправляет смартфон в сон после двойного тапа по строке состояния.
Extended Xposed Translation Component - автоматически переводит на русский прошивку MIUI.
Hide Apps Xposed - позволяет скрыть приложения в меню стандартного лаунчера.
Instagram Downloader - позволяет скачивать фото из Instagram.
Vine Downloader - позволяет скачивать видео из Vine.
LG PIE Support - поддержка функции PIE для прошивок от LG.
Multiple Users for phone - активирует много пользовательский режим на смартфоне.
neXus navbarz - позволяет изменять внешний вид и поведение софтверных кнопок навигации.
ScreenOffAnimation - набор анимаций выключения экрана.
UnbelovedHosts - позволяет применять свои собственные версии файла /etc/hosts без изменения основного (для блокировки рекламы).
Xposed Full Screen Call Picture - выводит фото звонящего абонента на полный экран (без обрезания снизу).
Xposed GEL Settings - кастомизатор для Google Now Launcher.

Слово автора:
Это статья написана мной, т.е. , с использованием , которая не претендует на универсальность и открытие «Америки».Скорее она предназначена для ознакомления и в качестве деления личным опытом и размышлениями, ну и чутку для науки))))

Введение:
Данные скрипты-твики для init.d призванны улучшить работу гуглофона и настроить его под свои нужды.
Для работы твиков необходима поддержка init.d прошивкой вашего аппарата, а также .
Однако, поддержку init.d можно эмулировать с помощью таких программ как или , включив соответствующие пункты в программах. Причем в mcTweaker реализовано множество твиков для вашего аппарата.
Напомню, что в кастомных прошивках BusyBox может быть установлен, да и многие твики уже реализованы!
Все Вы делаете на свой страх и риск! Для манипуляций нужен root-доступ!

Общая информация:
Скрипты-твики необходимо класть по пути /system/etc/init.d/ :

Для редактирования/добавления/удаления скриптов я пользовался .
Если у Вас нет папки init.d , то значит скрипты работать не будут 100% !

Каждый файл скрипта начинается со строчки:

#!/system/bin/sh
Далее вставляется код твика, например: echo "500" >
echo "1000" >
Образец файла скрипта

#!/system/bin/sh
echo "500" > /proc/sys/vm/dirty_expire_centisecs
echo "1000" > /proc/sys/vm/dirty_writeback_centisecs

Файл скрипта называем по-любому, но так чтобы сами могли распознать их, например, Battery_tweak - твик аккумулятора.

Твики:
1)Твики скорости интернет-соединения

echo "0" > /proc/sys/net/ipv4/tcp_timestamps;
echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse;
echo "1" > /proc/sys/net/ipv4/tcp_sack;
echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle;
echo "1" > /proc/sys/net/ipv4/tcp_window_scaling;
echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes;
echo "30" > /proc/sys/net/ipv4/tcp_keepalive_intvl;
echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout;
echo "404480" > /proc/sys/net/core/wmem_max;
echo "404480" > /proc/sys/net/core/rmem_max;
echo "256960" > /proc/sys/net/core/rmem_default;
echo "256960" > /proc/sys/net/core/wmem_default;
echo "4096, 16384, 404480" > /proc/sys/net/ipv4/tcp_wmem;
echo "4096, 87380, 404480" > /proc/sys/net/ipv4/tcp_rmem;

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

echo "4096" > /proc/sys/vm/min_free_kbytes
echo "0" > /proc/sys/vm/oom_kill_allocating_task;
echo "0" > /proc/sys/vm/panic_on_oom;
echo "0" > /proc/sys/vm/laptop_mode;
echo "0" > /proc/sys/vm/swappiness
echo "50" > /proc/sys/vm/vfs_cache_pressure
echo "90" > /proc/sys/vm/dirty_ratio
echo "70" > /proc/sys/vm/dirty_background_ratio

3)Твики ядра

echo "8" > /proc/sys/vm/page-cluster;
echo "64000" > /proc/sys/kernel/msgmni;
echo "64000" > /proc/sys/kernel/msgmax;
echo "10" > /proc/sys/fs/lease-break-time;
echo "500, 512000, 64, 2048" > /proc/sys/kernel/sem;

4)Увеличиваем время жизни аккумулятора

echo "500" > /proc/sys/vm/dirty_expire_centisecs
echo "1000" > /proc/sys/vm/dirty_writeback_centisecs

5)Твик скорости чтения sd-карты(увеличение кеша карты)

echo "2048" > /sys/devices/virtual/bdi/179:0/read_ahead_kb;

6)Дефрагментация файлов баз данных?

for i in \
`find /data -iname "*.db"`
do \
sqlite3 $i "VACUUM;";
done

7)Отключаем логгеры(не будут записываться лог-файлы)

rm /dev/log/main

8)Настраиваем пороги, при которых будет происходить выгрузка приложений при нехватке памяти

echo "2048, 3072, 6144, 15360, 17920, 20480" > /sys/module/lowmemorykiller/parameters/minfree

9)Твики управления кэша

LOOP=`ls -d /sys/block/loop*`;
RAM=`ls -d /sys/block/ram*`;
MMC=`ls -d /sys/block/mmc*`;
for j in $LOOP $RAM
do
echo "0" > $j/queue/rotational;
echo "2048" > $j/queue/read_ahead_kb;
done

10)Твики процессора?

SAMPLING_RATE=$(busybox expr `cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency` \* 750 / 1000)
echo 95 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo $SAMPLING_RATE > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

11)Перенос dalvik-кеша в раздел cache, чтобы разгрузить раздел data

CACHESIZE=$(df -k /cache | tail -n1 | tr -s " " | cut -d " " -f2)
if [ $CACHESIZE -gt 80000 ]
then
echo "Large cache detected, moving dalvik-cache to /cache"
if [ ! -d /cache/dalvik-cache ]
then
busybox rm -rf /cache/dalvik-cache /data/dalvik-cache
mkdir /cache/dalvik-cache /data/dalvik-cache
fi

Busybox chown 1000:1000 /cache/dalvik-cache
busybox chmod 0771 /cache/dalvik-cache

# bind mount dalvik-cache so we can still boot without the sdcard
busybox mount -o bind /cache/dalvik-cache /data/dalvik-cache
busybox chown 1000:1000 /data/dalvik-cache
busybox chmod 0771 /data/dalvik-cache
else
echo "Small cache detected, dalvik-cache will remain on /data"
fi

12)Удаление кэша, tmp-файлов и прочего мусора

#remove cache, tmp, and unused files
rm -f /cache/*.apk
rm -f /cache/*.tmp
rm -f /data/dalvik-cache/*.apk
rm -f /data/dalvik-cache/*.tmp

if [ -e /data/system/userbehavior.db ]
then
rm -f /data/system/userbehavior.db
fi

if [ -d /data/system/usagestats ]
then
chmod 400 /data/system/usagestats
fi

if [ -d /data/system/appusagestats ]
then
chmod 400 /data/system/appusagestats
fi

#remove main log
if [ -e /dev/log/main ]
then
rm -f /dev/log/main
fi

13)Изменение приоритета процессов-только стандартных. Желательно перед использованием проверить название процессов на вашем аппарате. Призвано увеличить плавность работы аппарата и сделать отклик более приятным)

renice -20 "pidof com.android.phone"
renice -19 "pidof com.android.inputmethod.latin"
renice -19 "pidof com.swype.android.inputmethod"
renice -17 "pidof com.android.systemui"
renice -9 "pidof com.android.settings"
renice -9 "pidof com.android.vending"
renice -6 "pidof com.sec.android.app.camera"
renice -6 "pidof com.sec.android.app.fm"
renice -6 "pidof com.google.android.apps.maps"
renice -4 "pidof com.google.android.apps.googlevoice"
renice -3 "pidof android.process.media"

p.s. Повторяюсь, все манипуляции над вашим аппаратом лежат на вашей совести! При использовании программ-твикеров типа mcTweaker удаляйте свои пользовательские скрипты да бы избежать неприятныз ситуаций и всегда делайте бэкап!
p.p.s. Статья будет пополняться новой информацией по мере возможности! Вопросы задаем в комментариях!

Прикрепленный файл #1:

Внимание! У вас нет прав, для просмотра скрытого текста.

Блуждая по форумам и разного рода сайтам, посвященным Android, мы постоянно сталкиваемся с советами, как увеличить производительность смартфона. Одни рекомендуют включить swap, другие - добавить специальные значения в build.prop, третьи - изменить переменные ядра Linux. Подобного рода рецептов в разных вариантах можно найти огромное количество, что на XDA, что на 4PDA. Но работают ли они на самом деле?

Пользуясь самыми разными *nix-системами на протяжении последних десяти лет, я всегда удивлялся, с каким упорством некоторые, казалось бы, грамотные пользователи смартфонов пытаются впихнуть общественности свои идеи оптимальной настройки Android и лежащего в его основе ядра Linux. И ладно бы дело ограничивалось легким тюнингом подсистемы управления виртуальной памятью или включением экспериментальных опций. Нет, обычно нам предлагают применить длиннющие скрипты, изменяющие буквально каждую переменную ядра, перемонтирующие файловые системы с разными странными опциями, включающие swap, активирующие различные системные демоны и выполняющие еще миллиарды различных операций.

Нет, ну можно, конечно, предположить, что ядро Linux, Android и фирменные прошивки для смартфонов разрабатывают безграмотные идиоты, работу которых необходимо кардинальным образом переделывать, но на практике почему-то оказывается, что самые известные инструменты тюнинга, опубликованные на XDA, - это не что иное, как сборная солянка из огромного количества разрозненных рекомендаций, придуманных непонятно кем и неизвестно зачем. Абсурд ситуации доходит того, что в этих инструментах можно обнаружить строки, без изменений скопированные из скриптов для увеличения производительности Linux-сервера в условиях высоких нагрузок (я не шучу, взгляни на содержимое известного скрипта ThunderBolt!).

В целом ситуация более чем запутанная. Все советуют всё, никто не советует ничего, а те, кто что-то понимает, сидят и, попивая чай, смеются над происходящим балаганом. Но попробуем все-таки разгрести всю эту кашу.

Начнем со swap - самой абсурдной идеи из всех, что только можно придумать для применения в смартфонах. Ее смысл в том, чтобы создать и подключить файл подкачки, за счет чего удастся освободить полезное пространство в оперативной памяти. Сама по себе идея, конечно, здравая, но только если речь идет о сервере, которому интерактивность никуда не упирается. На смартфоне регулярно используемый файл подкачки приведет к неиллюзорным лагам, возникающим вследствие промахов мимо кеша, - достаточно представить, что будет, если приложение попытается отобразить одну из своих пиктограмм, а она окажется в свопе, который придется вновь загружать с диска, предварительно освободив место путем помещения в своп данных другого приложения. Ужас.

Некоторые юзеры могут возразить, что на самом деле после включения swap никаких проблем не возникает, но за это надо благодарить механизм lowmemorykiller, который регулярно убивает особо раздувшиеся и давно не используемые приложения. Благодаря ему девайс с 1 Гб памяти может никогда и не дойти до необходимости сброса данных в своп. Он же и является причиной того, почему в отличие от Linux-десктопа в Android своп не нужен.

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

Swap действительно очень медленный, и даже на десктопе его существование зачастую неоправданно, но что, если обмануть систему? Создадим виртуальный диск прямо в оперативке с встроенной функцией сжатия данных, подключим его как swap - и вуаля. Функция сжатия данных довольно дешева даже для современных мобильных процессоров, поэтому мы сможем расширить размер оперативки практически без потерь производительности.

Идея настолько правильная, что даже Google рекомендует применять zRAM для основанных на KitKat устройствах в том случае, если объем оперативки не превышает 512 Мб. Загвоздка только в том, что способ работает лишь для современных бюджетников, то есть устройств, основанных на многоядерных бюджетных процах от какой-нибудь MTK и 512 Мб оперативки. В этом случае поток шифрования можно вынести на отдельное ядро и вообще не париться о производительности.

На устаревших устройствах с одним ядром, для которых «гуру форумов» и рекомендуют применение данной технологии, мы вновь получим лаги, причем в довольно большом количестве. То же, кстати, относится и к технологии KSM (Kernel SamePage Merging), которая позволяет объединять одинаковые страницы памяти, освобождая таким образом пространство. Она также рекомендована Google, но на старых девайсах приводит к еще большим лагам, что вполне логично, учитывая постоянно активный ядерный поток, который непрерывно ходит по памяти в поисках дубликатов страниц (а так ли много этих дубликатов на самом деле?).

Вердикт: зависит от устройства, в большинстве случаев замедляет систему.

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

Если вкратце, то баг состоял в том, что некоторые высокоуровневые компоненты среды исполнения Android активно использовали файл /dev/random для получения энтропии/соли. В какие-то моменты буфер /dev/random опустошался, и система оказывалась заблокирована до момента его заполнения необходимым количеством данных. А так как заполнялся он тем, что поступало с разных датчиков, кнопок и сенсоров смартфона, то времени на эту процедуру уходило столько, что пользователь успевал заметить лаг.

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

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

Все, кто пробовал, наперебой кричат об эффективности решения, однако, если верить Рикарду Серкейре (Ricardo Cerqueira) из компании Cyanogen, в современных версиях Android /dev/random используется всего тремя компонентами: libcrypto (для шифрования SSL-соединений, генерации ключей SSH и так далее), wpa_supplicant/hostapd (для генерации WEP/WPA-ключей) и несколькими библиотеками для генерации случайных ID при создании файловых систем ext2/3/4.

Эффективность приложения в современном Android, по его мнению, связана вовсе не с пополнением пула /dev/random, а с тем, что rngd постоянно пробуждает устройство и заставляет его повышать частоту процессора, что позитивно сказывается на производительности и негативно на батарее.

Вердикт: плацебо.

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

Смысл существования файлов odex в том, чтобы разгрузить виртуальную машину и таким образом ускорить запуск приложений (стоковых). С другой стороны, файлы odex мешают вносить в прошивку модификации, создают проблемы с обновлением, и по этой причине многие кастомные ROM’ы (включая CyanogenMod) распространяются без них. Вернуть (точнее, сгенерировать) файлы odex можно разными способами, в том числе с помощью простых утилит/скриптов вроде Odexer Tool. Пользоваться ими легко, и многие «эксперты» советуют это делать.

Проблема только в том, что это чистейшее плацебо. Не обнаружив odex-файлов в каталоге /system, система сама создаст их при следующей загрузке и поместит в каталог /system/dalvik-cache/. Именно этим она занимается, когда при загрузке новой прошивки на экране появляется сообщение «Идет оптимизация приложений…». В отношении приложений из маркета это тоже, кстати, работает. Но на этапе установки софта.

Вердикт: плацебо.

Реализация многозадачности в Android сильно отличается от других мобильных ОС и основана на классической модели. Приложения могут спокойно работать в фоне, в системе нет никаких ограничений на их количество, функциональность при переходе к фоновому исполнению не урезается. Все, как на десктопе, за исключением одной детали: система имеет полное право убить любое фоновое приложение в случае недостатка оперативной памяти или (начиная с KitKat) излишней жадности приложения к ресурсам.

Этот механизм, названный lowmemorykiller, был придуман для того, чтобы, сохраняя черты полноценной многозадачной ОС, Android мог нормально жить в условиях ограниченного объема памяти и отсутствующего swap-раздела. Пользователь может спокойно запускать любые приложения и быстро переключаться между ними, а система сама позаботится о завершении давно не используемых приложений и о том, чтобы в устройстве всегда оставалась свободная память.

В первые годы существования Android назначение данного механизма для многих пользователей было непонятным, поэтому стали популярными так называемые таск-киллеры - приложения, которые время от времени просыпались и завершали все фоновые приложения. Профитом в данном случае считалось большое количество свободной оперативки, что воспринималось как плюс, хотя никаких плюсов в этом, конечно же, не было. Зато было много минусов в виде более долгого переключения между приложениями, повышенного расхода заряда батареи и проблем c пробуждением владельца по утрам (будильник тоже убивался).

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

Но к чему это в итоге приводит? Допустим, стандартные значения границ заполнения памяти - это 4, 8, 12, 24, 32 и 40 Мб, то есть при достижении свободного объема памяти 40 Мб будет убито одно из кешированных приложений (загружено в памяти, но не запущено, это такая оптимизация Android), при 32 - Content Provider, не имеющий клиентов, 24 - одно из редко используемых фоновых приложений, затем в расход идут сервисные процессы приложений (например, сервис музыкального проигрывателя), видимые на экране приложения и текущее запущенное приложение. Разница между последними двумя в том, что «текущее» - это приложение, с которым в данный момент имеет дело юзер, а «видимое» - это то, что, например, имеет уведомление в строке состояния или отображает поверх экрана какую-либо инфу.

В целом все это значит, что в смартфоне всегда будет свободно 40 Мб памяти, которых вполне достаточно для того, чтобы вместить еще одно приложение, после чего проснется поток LKM и начнет очистку памяти. Все ОK, все довольны. Система по максимуму использует память. А теперь представим, что будет, если юзер воспользуется советом доморощенного «эксперта» и поднимет эти значения так, что последнее будет составлять, ну, допустим, 100 Мб (обычно повышаются только три последних значения). В этом случае произойдет одна простая вещь: юзер потеряет 100 – 40 = 60 Мб памяти устройства. Вместо того чтобы использовать это пространство для хранения фоновых приложений, что полезно, так как сокращает время переключения на них и заряд батареи, система будет оставлять его свободным непонятно для чего.

Справедливости ради стоит сказать, что тюнинг LKM может быть полезен для девайсов с совсем уж небольшим объемом памяти (меньше 512) и Android 4.X на борту или для временного увеличения порогов. Некоторые разработчики твиков прямо рекомендуют использовать «агрессивные» настройки только в случае запуска тяжелого софта вроде hi-end игр, а все остальное время оставаться на стандартных. В этом действительно есть смысл.

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

В скриптах, публикуемых на форумах, можно часто встретить твики подсистемы ввода-вывода. Например, в том же скрипте ThunderBolt! есть следующие строки:

Echo 0 > $i/queue/rotational; echo 1024 > $i/queue/nr_requests;

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

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

Далее следует еще несколько строк, относящихся к другим планировщикам (кстати, обрати внимание на совершенно лишние точки с запятой в конце команд). Что во всех этих строках не так? Первые две команды бессмысленны по двум причинам:

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

For i in /sys/block/mmc*; do echo noop > $i/queue/scheduler echo 0 > $i/queue/iostats done

Кроме включения планировщика noop, для всех накопителей он отключает накопление статистики I/O, что также должно позитивно сказаться на производительности (хотя это всего лишь капля в море, которая будет совершенно незаметна).

Еще один твик, который часто можно найти в скриптах тюнинга производительности, - это увеличение значения readahead для карты памяти до 2 Мб. Механизм readahead предназначен для заблаговременного чтения данных с носителя еще до того, как приложение запросит доступ к этим данным. Если ядро видит, что кто-то достаточно долго читает данные с носителя, оно пытается вычислить, какие данные понадобятся приложению в дальнейшем, и заранее загрузит их в оперативку, позволяя таким образом сократить время их отдачи.

Звучит круто, но, как показывает практика, алгоритм readahead очень часто ошибается, что приводит к лишним операциям ввода-вывода и расходу оперативной памяти. Высокие значения readahead (1–8 Мб) рекомендуются к применению на RAID-массивах, тогда как на десктопе или смартфоне лучше все оставить как есть, то есть 128 Кб.

Вердикт: кроме noop, не нужно ничего.

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

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

* vm.dirty_background_ratio = 10 * vm.dirty_ratio = 20

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

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

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

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

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

If [ "$mem" -lt 524288 ];then sysctl -w vm.dirty_background_ratio=15; sysctl -w vm.dirty_ratio=30; elif [ "$mem" -lt 1049776 ];then sysctl -w vm.dirty_background_ratio=10; sysctl -w vm.dirty_ratio=20; else 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

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

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

Существует огромное количество и более мелких оптимизаций, включая «тюнинг» сетевого стека, изменение переменных ядра Linux и Android (build.prop), но 90% из них не оказывают никакого влияния на реальную производительность устройства, а остальные 10% либо улучшают одни аспекты поведения устройства в ущерб других, либо настолько незначительно повышают производительность, что ты этого даже не заметишь. Из того, что реально действует, можно отметить следующее:

• Разгон. Небольшой разгон позволяет повысить производительность, а андервольтинг - сохранить немного батарейки.
• Оптимизация баз данных. Сильно сомневаюсь, что это даст заметный прирост скорости работы, но теория говорит нам, что работать должно.
• Zipalign. Забавно, но, несмотря на встроенную в Android SDK функцию выравнивания контента внутри APK-файлов, в маркете можно найти большое количество софта, не прошедшего через zipalign.
• Отключение ненужных системных сервисов, удаление неиспользуемых системных и редко используемых сторонних приложений (об этом я уже писал в одной из прошлых статей).
• Кастомное ядро с оптимизациями под конкретный девайс (опять же не все ядра одинаково хороши).
• Уже описанный планировщик ввода-вывода noop.
• Алгоритм насыщения TCP westwood+. Есть доказательства, что в беспроводных сетях он намного эффективнее применяемого в Android по умолчанию Cubic. Доступен в кастомных ядрах.

LaraCraft304 с форумов XDA Developers провела исследование и выяснила, что внушительное количество настроек /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.shutdown.mode
• ro.HOME_APP_ADJ

Скрипт для оптимизации баз данных настроек системы и приложений. Для работы, естественно, требуется root и BusyBox.

#!/system/bin/sh
for i in \
`busybox find /data -iname «*.db»`;
do \
/system/xbin/sqlite3 $i ‘VACUUM;’;
/system/xbin/sqlite3 $i ‘REINDEX;’;
done;