Android, из чего состоит прошивка ROM 
Сегодня я постараюсь объяснить, что такое прошивка популярным языком, рассчитанным на неискушенного пользователя.
Для начала давайте определимся с происхождением самого этого термина.
Итак, что такое прошивка, в изначальном понимании этого термина. Давным давно, когда вычислительные устройства были большими и некоторые их экземпляры занимали целые комнаты, их встроенная (постоянная) память изготавливалась весьма оригинальным образом.
Каждая ее ячейка состояла из небольшого кольца, выполненного из специального материала – феррита, который легко намагничивается. И в каждое кольцо продевалось две петельки провода, предназначенные для записи (намагничивания), стирания (размагничивания) и считывания информации из этого кольца. А информации в нем хранилось всего лишь один бит: 0 – когда кольцо размагничено и 1, когда намагничено. Знаете, сколько таких колец нужно, чтобы обеспечить устройству 1 гигабайт встроенной памяти? Я вам скажу: всего лишь 8 589 934 592 штуки.
И вот процесс продевания проводов в эти кольца при изготовлении постоянной памяти для старых устройств так и назывался – прошивка.
А теперь вернемся к нашим планшетам и смартфонам. Они, как и любой современный компьютер работают под управлением операционной системы (Windows, Linux, iOS, Android и т.п), которая полностью отвечает за их работу. Иными словами, если внутреннее железо компьютера – это его мозг, то операционная система – это его сознание, которое управляет компьютером.
Без операционной системы любой компьютер, планшет или смартфон – набор мертвого железа. И если на компьютер, операционную систему мы устанавливаем, записывая ее на его жесткий диск, то в планшете или смартфоне операционная система хранится в его внутренней памяти, занимая часть тех 4, 8, 16, 32 или даже 64 гигабайт, которые имеют современные устройства.
Вы наверное уже догадались, что именно эта процедура «установки» операционной системы на планшет или смартфон и называется прошивкой, поскольку система записывается (прошивается) в его постоянную, внутреннюю память.
Теперь вы понимаете, что выражение «сменить пошивку» на планшете или телефоне означает примерно то же самое, что «переустановить Виндовс» на компьютере.
Кроме того, и сам файл с операционной системой, которая записывается на устройство называют прошивкой. Так как начинка или «мозги» у каждого планшета или телефона разные, прошивка создается для каждого устройства отдельно. Прошивки бывают двух типов:
1. Официальные, выпущенные производителем устройства, которые или автоматически загружаются на планшет или телефон через интернет подключение (так называемые прошивки по «воздуху»). Их также чаще всего можно скачать на планшет с сайта производителя и установить вручную. Этот тип прошивок еще часто называют обновлением системы.
2. Самодельные прошивки, их еще называют «кастомные» или «альтернативные». Обычно это улучшенные или доработанные независимыми разработчиками официальные прошивки. К ним также относятся прошивки основанные на официальных версиях «чистой» операционной системы Android от компании Google, такие как CyanogenMod или MIUI.
Рассмотрим состав прошивки , на примере состава прошивки от ZTE , в принципе она с небольшими изменениями идентична на всех Android устройствах
0.25 Мб.) — предзагрузчик. Обеспечивает связь телефона с FlashTool-ом в «режиме USB» для прошивки, а также обеспечивает запуск устройства. Предположительно грузит в оперативную память uboot и передаёт ему управление.
dsp_bl (
0.75 Мб.) — Малоизвестная вещь. Судя по названию микропрограмма процессора. Порча его превращает телефон в планшет без комуникаций. Какими потом прошивками не прошивай телефон беспроводные сети работать не будут. Решение: прошить рабочий dsp_bl. (Только MT65x3, MT65x5, MT65x7!)
nvram (
3.0 Мб.) — хранит калибровки железок, IMEI, MAC-адреса BT и WIFI и другое. Точка монтирования /data/nvram.
seccnfg (
0,125Мб.) — неизвестная штука, обычно содержит только пустоту «FF FF. «.
uboot (
0.375 Мб.) — загрузчик операционной системы + драйверы для инициализации основного оборудования (дисплей, процессор, GPIO).
boot (
6.0 Мб.) — ядро и драйверы операционной системы (камеры, датчики, сенсоры). Точка монтирования /.
recovery (
6.0 Мб.) — минисистема (система в ядре) функцией которой является только резервирование/восстановление приложений системы, сброс до заводских установок. В расширенном recovery функционал конечно же намного богаче.
secstatic (
1.156 Мб.) — sec_ro , зачем нужно не понятно, при стирании на Android 2.2.1 и 2.3.5 ничего не происходит. На Android 2.2.2 (преимущественно у Fly-ying) этот раздел занимает хороший кусок ROM и в нём находятся службы Google. Точка монтирования /system/secro. Файловая система yaffs2.
misc (
0.375 Мб.) — неизвестная штука, обычно содержит только пустоту «FF FF. «.
logo (
3.0 Мб.) — Первая картинка при включении, картинка зарядки. На 95% содержит только пустоту «FF FF. «.
expdb (
0.65 Мб.) — неизвестная штука, обычно содержит только пустоту «FF FF. «.
system (
160-210 Мб.) — системный раздел Android. Тут всё что относится к функционированию аппарата, от «морды» до поддерживаемых функций операционной системы. Всё, что здесь изменяется не подлежит востановлению заводским сбросом. Точка монтирования /system. Файловая система yaffs2.
cache (
62.0 Мб.) — раздел для расположения временных файлов. Обычно используется приложениями («Маркет», «ROM Manager» . ). При утрате содержимого раздела функционирование системы не пострадает. Неверное же содержимое может привести к зависанию при загрузке устройства. Полностью стирается при заводском сбросе. Точка монтирования /cache. Файловая система yaffs2.
userdata (
220-290 Мб.) — data, это раздел для установки программ календарей, телефонок, профилей, настроек различных программ и системы. При утрате содержимого раздела обычно* функционирование системы не страдает. Неверное же содержимое может привести к зависанию при загрузке устройства. Полностью стирается при заводском сбросе. Точка монтирования /data. Файловая система yaffs2.
Источник
Ускорение запуска программ с помощью Preload
Preload — демон, работающий в фоне, который собирает информацию о наиболее часто используемых программах, кеширует их и используемые ими библиотеки, что приводит к повышению скорости загрузки программ. Используя Preload вы можете с пользой потратить гигабайты неиспользуемой оперативной памяти (конечно если они у вас есть).
Инсталяция
Настройка
Конфигурация программы храниться в файле /etc/preload.conf, стандартные значения должны подойти большинству пользователей. Но если вы хотите настроить все по своему, милости просим. Ниже описаны самые основные настройки, подробности, как всегда в документации или в статье, написанной разработчиком Preload.
Опция / Значение по умолчанию / Описание
model.cycle / 20 [секунд] / Как часто Preload будет опрашивать систему на предмет используемых программ и библиотек.
model.halflife / 168 [часов] / Как часто Preload будет забывать старую, накопившуюся информацию. Каждый раз, накопленная статистика будет терять 50% своего значения.
model.minsize / 2000000 [байт] / Нечто вроде ограничения на размер программы или библиотеки, на которую будет Preload обращать внимание. Если вы хотите, чтобы кешились мелкие программки — уменьшите значение, только для крупных, соответственно увеличьте это значение.
Использование памяти, считается по формуле:
(Всего RAM x model.memtotal) + (RAM доступная при старте x model.memfree) + (Кеш x model.memcached)
model.memtotal / -10%
model.memfree / 100%
model.memcached / 30%
Стандартные значения, как уже упоминалось, должны подойти большинству людей, так что не меняйте их без особой на то необходимости.
Статистика
Если вам интересно, какие ресурсы на данный момент использует Preload, можете посмотреть на это в его лог-файле:
sudo tail -f /var/log/preload.log
Еще больше информации можно получить, глянув на файл /var/lib/preload/preload.state
Но вам совершенно не обязательно обращать внимание на все эти файлы, позитивные результаты будут и без этого.
А теперь цифры
Пройдет немного времени, прежде чем Preload определит и поймет ваши типичные программы для работы, так что не надо надеяться, что увеличение скорости загрузки произойдет прямо сейчас.
Источник
«Холодный» запуск Android-приложения
Всем приветъ! Давно ничего не писал.
Это будет серия постов о процессе «холодного» запуска Android приложения, с момента нажатия на иконку и до создания процесса приложения.
Общая схема
Открывая «окно»…
Перед тем как запустить новый процесс приложения, system_server создает стартовое окно используя метод PhoneWindowManager.addSplashScreen():
Стартовое окно это то, что пользователь будет видеть пока запускается само приложение. Окно будет отображаться до тех пор пока не будет запущена Activity и не будет отрисован первый кадр. То есть пока не будет завершен «холодный» запуск. Пользователь может видеть данное окно длительное время, поэтому постарайтесь сделать его приятным.
Содержимое стартового окна берется из drawable-ресурсов windowSplashscreenContent и windowBackground запускаемого Activity. Банальный пример такого окна:
Если пользователь восстанавливает Activity из режима последнего экрана(Recent screen), при этом на нажимая на иконку приложения, то system_server вызывает метод TaskSnapshotSurface.create(), чтобы создать стартовое окно из уже сделанного скриншота.
Как только стартовое окно показано пользователю, system_server готов запустить процесс приложения и вызывает метод ZygoteProcess.startViaZygote():
В коде видно, что метод ZygoteProcess.zygoteSendArgsAndGetResult() отправляет аргументы запуска через сокет Zygote-процессу.
«Разделение» Zygote-ы
Каждый процесс приложения запускается с помощью форкания(разделения) от существующего Zygote-процесса…
Вкратце об этом я писал в предыдущей статье про запуск Android-а. А теперь давайте посмотрим поглубже на происходящие процессы.
Когда система загружается процесс Zygote стартует и выполняет метод ZygoteInit.main():
Как вы видите метод ZygoteInit.main() делает 2 важные вещи:
- Подгружает все необходимые системные библиотеки и ресурсы Android-фреймворка. Подобная предзагрузка не только экономит память но еще и экономит время запуска приложений.
- Далее он запускает метод ZygoteServer.runSelectLoop(), который в свою очередь запускает сокет и начинает слушать вызовы данного сокета.
Когда же на сокет приходит команда на форкинг процесса, метод ZygoteConnection.
processOneCommand() обрабатывает аргументы используя метод ZygoteArguments.parseArgs() и запускает метод Zygote.forkAndSpecialize():
На заметку: Начиная с Android 10 есть оптимизационная фича под названием Unspecialized App Process, которая имеет пул не специализированных Zygote-процессов, для еще более быстрого запуска приложений.
Приложение запустилось!
После форка дочерний процесс запускает метод RuntimeInit.commonInit(), который устанавливает дефолтный UncaughtExceptionHandler. Далее, процесс запускает метод ActivityThread.main():
Тут происходят две интересные вещи:
- Метод ActivityThread.main() создает новый поток(Thread) и вызывает метод Looper.loop(), в котором будет запущен новый инстанс Looper-а. Он будет привязан к новому потоку(который становится MainThread-ом aka UiThread) и будет работать(теоретически) бесконечно. Looper привязавшись, будет ожидать сообщений для того чтобы поместить их к своему MessageQueue.
- Далее, метод ActivityThread.attach() делает IPC-запрос к методу ActivityManagerService.attachApplication()system_server-а, тем самым давая понять, что MainThread нашего приложения запущен и готов к работе.
Контроль над приложением
В процессе system_server метод ActivityManagerService.attachApplication() вызывает метод ActivityManagerService.attachApplicationLocked(), который завершает настройку запускаемого приложения:
Парочка ключевых выводов:
- Процесс system_server делает IPC-запрос к методу ActivityThread.bindApplication() в процессе нашего приложения, который направляет запрос к методу ActivityThread.handleBindApplication() в MainThread-е приложения.
- Сразу после этого, system_server планирует запуск Pending Activity, Service и BroadcastReciever-ов нашего приложения.
- Метод ActivityThread.handleBindApplication() загружает APK-файл и компоненты приложения.
- Разработчики имеют возможность немного повлиять на процессы перед запуском метода ActivityThread.handleBindApplication(), так что именно здесь должен начаться мониторинг холодного запуска приложения.
Давайте немного подробно разберем 3-ий пункт и узнаем что и как происходит при загрузке компонентов и ресурсов приложения. Порядок шагов такой:
- Загрузка и создание инстанса класса AppComponentFactory.
- Вызов метода AppComponentFactory.instantiateClassLoader().
- Вызов метода AppComponentFactory.instantiateApplication() для загрузки и создания инстанса класса Application.
- Для каждого объявленного ContentProvider-а, в порядке приоритета, вызов метода AppComponentFactory.instantiateProvider() для загрузки его класса и создания инстанса, после вызов метода ContentProvider.onCreate().
- И наконец, вызов метода Application.onCreate().
Эпилог
Мы начали изучать «холодную» загрузку с очень обще-абстрагированного уровня:
Теперь мы знаем, что происходит «под капотом»:
Ну что же, это был длинный пост. Но это не все! В следующих постах мы продолжим глубокое погружение в процесс запуска Android-приложения. Оставайтесь с нами!
Источник
