Мобильные ядра

Состояние исходных кодов ядра linux мобильных устройств на примере z4u: 

• Отсутствие документации и комментариев в файлах. Частично решаемо запуском скрипта, который проводит маленькую интеллектуальную работу над исходным кодом удаляя все комментарии и документацию из кода, и сравнивает с исходным кодом, прошедшим точно такой же фильтр, но уже из официальных исходных кодов ядра близкой версии(msm-3.4(aurora), 3.4(kernel.org)). Если все прошло нормально код заменяется на официальный. Но это помогает лишь частично так как при изменении кода скрипт не признает его как подобный. Посмотреть на результаты можно в данном репозитории. 
• Изменения в в системном разделе заблокированы, что легко решается изменением конфигурации. 
• Код ядра базируются на старом коде, если смотреть по некоторым файлам, то исходные коды уже на год полтора отстают от текущего состояния, и может содержать гигантское количество уже исправленных ошибок и не содержать новых улучшений. Что возможно и является причиной отсутствия документации, ее просто тогда не существовало, когда код писался. Как пример arch/arm/common/dmabounce.c находиться в состоянии между 0703ed2a6b260cd743adf49a8281eb064d728832 (04 Jul 2011) и 1dc8f0065cb2a274785fac9da61417908e22e0b9 (15 Aug 2012), если судить по msm-3.4.

Сборка recovery под новое устройство

Последовательность действий такова:

Подготовка окружения для сборки:

• curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
• chmod a+x ~/bin/repo
• mkdir cm10.1 && cd cm10.1
• ../repo init -u git://github.com/CyanogenMod/android.git -b cm-10.1
• ../repo sync

Версия 10.1 предпочтительна, так как с следующей версии возможны проблемы с загрузкой.

Генирируем заготовку для сборки:

• cd vendor/cm
• ./get-prebuilts
• make otatools
• PATH=$PATH:`pwd`/out/host/linux-x86/bin/
• build/tools/device/mkvendor.sh htc z4u recovery.img

Вместо htc z4u используем имена производителя и модели, но можно использовать любые значения, так как эти значения используются только как название каталогов. Образ recovery.img изначальный образ recovery с официальной прошивки не обязательный параметр, но позволяет заполнить часть значений в конфигурации. После этого в сгенерированной папках нужно поменять значения в BoardConfig.mk и в fstab. Как подсказку для заполнения последнего файла можно использовать список разделов из файла /proc/emmc или в выводе mount.

После обновления конфигурации, можно пересобрать ядро для чистоты эксперимента, конфигурацию ядра можно получить из /proc/config.gz и попытаться пересобрать ядро из исходников подобного устройства c aurora для qualcomm или другого репозитория. Наиболее удобным вариантом может быть скачать исходника с сайта разработчика устройства, пересобрать и заменить файл в сгенерированом каталоге.

• make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm z4u_defconfig 
• make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm -j 4
• cp {каталог с ядром}/arch/arm/boot/zImage device/htc/z4u/kernel

Затем можно пересобрать recovery в каталоге 10.1:

• source build/envsetup.sh
• lunch cm_z4u-eng
• . build/tools/device/makerecoveries.sh cm_z4u-eng или make recoveryzip -j 4
• fastboot flash recovery out/target/product/z4u/recovery.img

Результаты запуска нового recovery при ошибках можно попробовать посмотреть в /proc/kmsg и /proc/last_kmsg. Необязательно там что-то будет, но попробовать стоит.

Дополнительно можно посмотреть:

1. Сборка recovery
2. Презентация о портировании на новые устройство
3. Replicant Porting Guide
4. How To Port CyanogenMod Android To Your Own Device
5. Porting Android to Devices

Proxy и маршрутизация

Нет предела совершенству.

Оптимизация трафика на уровне прокси имеет несколько ограничений, если верить данным с chrome beta на мобильном телефоне, он смог уменьшить затраты трафика на 65% для сайтов благодаря тому что пропускал трафик через свои сервера и минимизировал его. Недостатков я не заметил, но если верить статистике с httparchive - крупные сайты достигли 77 пунктов в pagespeed - что достаточно не плохо на уровне среднего уровня оптимизации и с сравнение трафика пропущенного с оптимизацией с чистым трафиком покажет достаточно не плохие результаты, подобные двойному уменьшению объёма трафика.

Но все же они тоже не спасут - если присутствует большой объем данных описывающих состояние передающихся на каждый запрос, как противоположность передачи только существенных изменений - никакая оптимизация не поможет, так как если разбить трафик на такие части: 

• анонимные данные, не зависящие от клиента, 
• данные специфичные для клиента, 
• информация о смене состояния. 

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

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

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

Ядро и телефон

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

Или если по порядку: 

Скачать компилятор можно с AOSP, где лежит стандартный компилятор уже "оптимизированный" под сборку Android, что дает нам большой процент вероятности, что у нас все же что-то соберется. Хотя тут тоже могут быть скрытые проблемы модифицированный компилятор использованный при сборке, но такой случай маловероятен иначе на устройстве не будут работать приложения собранный стандартным компилятором из NDK.

Получение конфигурации ядра тоже достаточно простая операция можно получить установив эмулятор терминала на устройство или запустив adb и сделав копию /proc/config.gz.  С конфигурацией тоже могут быть проблемы: отсутствие этой конфигурации по указанному пути, так как производитель решил сэкономить таким образом место, заблокированный доступ к системным каталогам, заблокированный запуск стандартный утилит, заблокированный доступ к системным областям, не стандартные устройства или их не канонические названия, производитель модифицировал стандартное устройство по своему усмотрению - в общем проблемы могут быть даже здесь. Но в основном все же доступ к конфигурации есть, заблокирован только доступ к dmesg, записи или чтению системных устройств - чтобы нельзя было получить прошивку или заменить ее. 

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

Для разработчиков конечного устройства вопрос универсальности или использования одобренных или обсуждённых с сообществом решений вообще теряет смысл, у них несколько иная цель - выпуск продукта в ограниченные сроки, c ограниченной поддержкой вида "работает - не трогай", что приводит к неочень хорошим результатам на всех уровнях. Как пример, это может быть такая ситуация: в прошивке используется как MARCH значение платформы описание, которой отстутстует в исходниках ядер для других устройств стандартного ядра которое дается производителем SOC, врезультате у нас есть описание чипа из спецификации устройства, но описания как иммено оно сконфигурировано нет. И нужно дожидатся открытия исходникой ядра иммено под это конечное устройство, что может произходить достаточно не быстро или вообще не произойти никогда. Следущая проблема качество этих исходных кодов, так как эти исходники собирались только для одного устойства с четко определенным списком функций, никто не обновляет эти ядра из общего хранилища кодов и не возвращает наработки обратно. Как следствие в коде отстутвуют проверки присутствия каких-то опций или наоброт отсутствия их, зависимости между элементами не проверяются и код можно собирать только в том виде как он есть, без изменений и только одим жестко определенным способом. 

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

Такая же ситуация происходит и с другими частями системы, берется какая-то версия программного обеспечения и модифицируется под какой-то конечный продукт и не обновляется из основного для продукта репозитория, и как результат, все части проверены как рабочие только в ограниченной экосистеме без взаимного обмена новшествами между различными копиями изначально одного продукта. Что имеет некоторую положительную сторону как проверенный годами стабильный продукт, с коллекцией ошибок уже давным давно исправленных в родственных продуктах или отсутствием каких-то приятных свойств, вида большая производительность, новые виды поддерживаемых форматов или отображений. Сложность изменения или переноса каких то частей на другие платформы, в любом из возможных смыслов, как другую аппаратную платформу, другой список оборудования, другое предназначение устройства или использование программной части в другом окружение или с другим списком оборудования. И сборка ядра сводится к поиску похожих устройств или упоминания нужного устройства в исходниках для других моделей на сайтах AOSP, Cyanogwwnmod, Aurora и попытках собрать ядро которое загрузится после сборки на устройстве если повезет. 

Для сборки можно использовать такую последовательность команд: 

1. make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm menuconfig 
2. make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm -j 4 
3. fastboot boot bzImage

Оптимизация через уменьшение

Лучший код тот, который не написан. 

Очистка html от пробельных символов:

Достоинства: 

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

Недостатки: 

• затраты ресурсов на очистку; 
• дополнительное место для отказа. 

Очистка и объединение файлов css: 

Достоинства: 

• минимизация кода и удаление пробельных символов как следствие сокращения объёма трафика; 
• возможность поменять последовательность тегов; 
• удаление лишних стилей в случае перекрытия частей стиля в последующем коде. 

Недостатки: 

• возможно усложнение отладки из-за изменений в исходном коде; 
• дополнительные затраты ресурсов. 

Очистка и объединение файлов js: 

Достоинства: 

• минимизация кода и удаление пробельных символов как следствие сокращения объёма трафика; 
• возможность удалить или оптимизировать код; 
• ускорение работы кода как результат удаления "мертвого кода" и ускорения разбора. 

Недостатки: 

• возможно усложнение отладки из-за изменений в структуре исходного кода; 
• дополнительные затраты ресурсов.

Свободная модель мира

Продукт позволяющий создавать 3d карту мира (аналогичный Google Street View или другим подобным продуктам других компаний), но построенный на принципах OpenStreetMap, когда изменять карту может каждый желающий и может при желании создать свой сервис основываясь на исходных кодах этого продукта, может иметь успех из-за таких достоинств:

• упрощение навигации в местах которые мало интересны крупным компаниям и интересны волонтерам;
• навигация с изображением, что предполагается увидеть проще, чем плоская карта с ориентацией по компасу и особенностям расположения дороги;
• расширения возможностей продуктов 'дополненной реальности' картинку с таких устройств можно анализировать на подобность уже существующим в базе изображений с уточнение координат в условиях недостаточной точности GPS c сохранением этих изображений на основном сервисе для уточнения информации и построение более точной модели. Или иными словами - снимается текущая картинка и вместе с текущими примерными координатами отправляется на сервис - там ищется подобная картинка и уточняется точное направление взгляда относительно карты - эти данные передаются обратно и показывается более точное направление движения, чем достигается более точная навигации по абстрактной пересеченной местности - где две дорожки ведущих примерно в том же направлении или находящиеся близко могут вести в различные места с различными условиями передвижения, что важно при езде на велосипеде или пеших походов - где размер дорожки может быть гораздо меньше чем при езде на автомобиле по городу / трассе, когда расстояние между дорожками минимум сравнимо с десятками метров и ошибка в несколько десятков метров не страшна;
• как исходные данные можно использовать уже снятые фотографии с гео-тегами, или что даст более точную информацию видео с видео регистраторов или action камер с дополнительными треками положений. Использование продуктов дополненной реальности носимых на голове и закрывающий часть обзора скорее всего будет не удобно так как будет только отвлекать при активных перемещениях.
• подобную систему можно также использовать для виртуальных экскурсий походов по удаленных или по каким-то причинам не доступным местам. Или создания реалистичных видео игр на основе реальных мест;
• возможность иметь собственный клон сервиса с собственными данными.

Проблемы данного сервиса подобны проблемам игр с масштабными пространствами и картографических сервисов:

• удобный формат хранения данных с возможностью четкой привязки к местности и достаточной точностью создания объектов;
• возможность быстрого отсечения не видимых или не значимых на данной увеличении позиции объектов;
• большие объёмы хранимой информации;
• отображение на конечном устройстве: различные виды устройств и не полная поддержка WebGL на устройствах;
• большой объем информации при передаче на устройство;
• математическая сложность преобразования изображений в 3d модель;
• преобразование видео сводиться к предыдущему пункту, но имеет один побочный эффект при качественном преобразовании можно в результате получить новое видео с улучшенным качеством изображения и новый формат видео базирующийся на описании позиции наблюдателя и расположения 3d моделей, где отдаленный объекты если в видео встречается этот объект ближе с большим разрешением или качеством, по всему видео будет обладать этими же качествами, что может несколько улучшить качество визуального восприятия;
• сложность создания моделей объектов что изменяются или изменяют свою позиции между кадрами.

Уменьшение нагрузки на оптимизирующий прокси

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

Сервер может поступить после этого следующим образом: 

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

Если пользователь согласен с полным проецированием трафика то в первом запросе передаются также приватная информация и контент преимущественно отдается с кеширующей инфраструктуры или зеркал.