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

Сборка с помощью компилятора Linaro GCC с агрессивными опциями оптимизации. Писк сезона, используется почти во всех ядрах. Особую популярность этот метод получил после того, как организация Linaro с помощью каких-то непонятных синтетических тестов продемонстрировала 400% — й (!) прирост производительности Android, собранного с помощью своего компилятора. В реальных условиях эффективность Linaro GCC несколько ниже, но польза от него все же ощутима, так как он реально подгоняет код под особенности архитектуры ARMv7 и, если судить по личному опыту, не приносит никаких проблем в стабильность работы ни ядра, ни приложений.

Расширение возможностей управления частотой и вольтажом центрального и графического процессоров, а также использование более эффективного для планшетов и смартфонов алгоритма управления энергосбережением. Используется во всех кастомных ядрах и ядрах большинства серьезных кастомных прошивок. Подробнее эту особенность мы рассмотрим в следующем разделе. Активация более эффективных внутренних механизмов, появившихся в последних ядрах Linux. Сюда можно отнести SLQB аллокатор памяти, который, по мнению некоторых разработчиков, может быть более эффективным, чем SLUB, однако никаких экспериментальных подтверждений этому нет. Такой аллокатор используется в ядре GLaDOS для Nexus 7.

Многие разработчики любят изменять стандартный алгоритм контроля насыщения TCP (TCP Congrestion control), который регулирует размер TCP — окна на основе множества параметров, чтобы сделать поток пакетов более ровным и достичь наивысшей скорости передачи данных. Начиная с версии 2.6.19, ядро Linux по умолчанию использует эффективный алгоритм CUBIC, который также обычно применяется и в стандартных ядрах Android. Проблема только в том, что CUBIC эффективен в проводных сетях с высокой скоростью передачи данных, тогда как для 3G — и Wi — Fi — сетей гораздо лучшим выбором будет алгоритм Westwood+. Именно этот алгоритм используется в ядрах Leankernel для Galaxy Nexus и faux123 для Nexus 7, a franko.Kernel для Galaxy S II и Galaxy Nexus так и вообще включает в себя весь набор доступных алгоритмов. Просмотреть их список и выбрать нужный можно с помощью следующих команд:

sysctl net.ipv4.tcp_available_congestion_control sysctl — w net.ipv4.tcp_congestion_control=westwood

Еще один тип оптимизации: изменение стандартного планировщика ввода — вывода. Ситуация на этом поле еще более интересная, так как вместо того, чтобы разобраться в принципах работы планировщиков, некоторые

сборщики ядер просто читают в Сети документы no l/O — планировщикам для Linux и делают выводы. Среди пользователей такой подход распространен еще более сильно.

На самом деле почти все самые производительные и умные Linux — планировщики совершенно не подходят для Android: они рассчитаны на применение с механическими хранилищами данных, в которых скорость доступа к данным разнится в зависимости от положения головки. Планировщик использует разные схемы объединения запросов в зависимости от физического положения данных, поэтому запросы к данным, которые располагаются близко к текущему положению головки, будут получать больший приоритет. Это совершенно нелогично в случае с твердотельной памятью, которая гарантирует одинаковую скорость доступа ко всем ячейкам. Продвинутые планировщики принесут на смартфоне больше вреда, чем пользы, а лучший результат покажут самые топорные и примитивные. В Linux есть три подобных планировщика: •Noop (No operation) —так называемый не — планировщик. Простая FIFO очередь запросов, первый запрос будет обработан первым, второй вторым и так далее. Хорошо подходит для твердотельной памяти и позволяет справедливо распределить приоритеты приложений на доступ к накопителю. Дополнительный плюс: низкая нагрузка на процессор в силу ну очень простого принципа работы. Минус: никакого учета специфики работы девайса, из-за чего могут возникнуть провалы производительности. SIO (Simple I/O) —аналог планировщика Deadline без учета близости секторов друг к другу, то есть разработанный специально для твердотельной памяти. Две главные изюминки: приоритет операций чтения над операциями записи и группировка операций по процессам с выделением каждому процессу кванта времени на выполнение операций. В смартфонах, где важна скорость работы текущего приложения и преобладание операций чтения над записью, показывает очень хорошую производительность. Доступен в Leankernel, ядре Matrix для Nexus 4 и SiyahKernel.