Anthony Cargile.
An overview of the iphone architecture

The Coffe Desk

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



Архитектура iPhone

     Эта многоуровневая (цветная , не для дальтоников) диаграмма будет служить графическим представлением всего процесса ввода/вывода iPhone. Компьютерные инженеры должны, вероятно, начать с основания, а программисты с вершины.
(Видно, что есть и аппаратный и процессорный уровни. Причина состоит в том, что аппаратное обеспечение обращаются к активным чипам периферийных устройств, например, гироскоп или дисплей, тогда как процессор больше работает с набором команд ARM на уровне асемблера - чтобы избежать возможных конфликтов. Чтобы разобраться см. описание уровней ниже.)

Пример 1: Аппаратный уровень обращается уровню приложений: Гироскоп

     Самый легкий способ разобраться - это пример. Итак, будем использовать гироскоп (обнаруживает переворот iPhone). Начинаем с аппаратного уровня:
     1 Физически гироскоп обнаруживает изменение положения, устанавливает бит (или изменяет содержимое регистра) указывая на изменение.
     2 Программный уровень обнаруживает изменение, отмечает, что значение идентифицирующее положение iPhone изменилось (в отличии от ошибки), и посылает прерывание процессору по системной шине для обработки.
     3 AMR процессор iPhone получает прерывание, и обращается к программе (ISR) обработки прерывания в оперативной памяти, которую ОС iPhone настроила во время инициализации драйвера.
     4 ISR, функция (подпрограмма), расположенная в пределах кода iPhone OS, определяет прерывание и начинает его обработку при помощи соответствующего драйвера. OС посылает сигнал в текущее активное приложение Unix-style сигнала.
     5 Этот сигнал обрабатывается согласно спецификации C/Objective-C в режиме реального времени, так как компилятор и компоновщик iPhone конструируют приложение специально для этого, а не для непосредственной обработки сигнала. Objective -C в режиме реального времени пересылает сигнал приложению, как framework сообщение, сначала проверяя, подходит ли текущее приложение для обработки сообщения.
     6 Если сообщение может быть обработано при помощи метода (подпрограмма) в рамках приложения, то сообщение принимается и обрабатывается.
     В нашем примере с гироскопом приложение настроит интерфейс для широкоэкранного(landscape) формат отображения. В зависимости от типа сообщения, framework может также проверить, указывает ли приложение на ошибку в обработке сообщения, и в этом случае может выполнить дополнительные действия.
     Этот пример дает представление о процессе, в котором события аппаратного уровня обрабатываются программным уровнем. Этот тот же самый процесс используется для ввода с сенсорного дисплея, звукового ввода, и ввода с камеры. Кнопки на сверху и снизу iPhone являются более специфичными для ОС, однако: кнопка меню просто посылает сигнал завершения в приложение, таким образом оно может выполнить любые заключительные задачи (такие как запись файла, и т.д.), тогда как самая верхняя кнопка инициирует режим управления/планировщика питания, который просто приостанавливает текущее приложение и выключает сенсорный дисплей чтобы сохранить продлить время службы аккумуляторной батареи.

Пример 2: Программный уровень у аппаратному уровню: Отображение

     Теперь, когда мы привели пример того, как приложение iPhone получает сообщения аппаратного уровня, можно посмотреть на то, как приложение запрашивает действие аппаратуры . Для этого примера мы будем использовать графическое отображение:
     1 Приложение, в донный момент загруженное в память и стартующее, хочет показать изображение для заставки. Предположим, что процесс погрузки изображения завершен, и мы теперь просто должны показать изображение на сенсорном дисплее аппаратного уровня, чтобы пользователь мог его увидеть.
     2 Приложение создаёт API (структуру) запрашивающее, что-то вроде - (void) setBackgroundImage, передавая ссылку на изображение в пределах запроса (который находится, на самом низком уровне, стартовом адресе памяти или ссылке на жесткий диск там, где изображение сохранено, тип изображения, и размер изображения).
     3 API/framework получает вызов функции, и делает «грязную работу» перевода высокоуровневой обработки изображения в набор вызовов Objective-C в режиме реального времени, которые в дальнейшем сделает соответствующие вызовы библиотеки C.
     4 (Динамически связанная) библиотека C, получив ряд вызовов функции от Objective-C и соответствующих структур во время выполнения и API, далее модифицирует функции в системные вызовы на асслемблерном уровне (через прерывания программного уровня), которые может обработать ядро iPhone OS.
     5 Ядро iPhone ОС, получив системные вызовы в формате ассемблера от библиотеки C, далее вызывает соответствующие драйверы (драйвер сенсорный дисплей, в нашем случае) для взаимодействия с аппаратным уровнем. Драйверы, на самом низком уровне, установят регистры чипа сенсорного дисплея, чтобы отобразить нужные цвета в соответствующих координатах, для показа изображения согласно запросу приложения.
     6 Теперь мы достигли аппаратного уровня, где физический экран дисплея изменяется, чтобы показать изображение для просмотра пользователем.

     Вы можете задаваться вопросом, почему есть три различных вызова API/ framework/library, должны говорить ядру о начале работы с аппаратным уровнем. Это, мой друг, является одной из радостей работы с Unix-подобной операционной системой: обеспечение дружественного для разработчика интерфейса высокого уровня почти 40-летней архитектурой операционной системы (напоминают, что XNU основан на Mach ядре, и использует старый Unix системный вызова к ядру). frameworks/API - набор функций, которые разработчик хочет видеть, чтобы сделать его/ее приложение взаимодействующим с устройством на базе iPhone OS. Хорошо framework, который является частью выполнения Objective-C в режиме реального времени, является действительно только набором вызовов функции на верхнем уровне (и расширения C, режима реального времени Obj-C), чтобы сделать более дружественным для разработчика интерфейс запутанной (и недокументированный) библиотека C. Библиотека C находится ниже Objective-C реального времени, и фактически делает Obj-C таковым, обеспечивая истинные объектно-ориентированные динамические расширения языка C (в отличие от C ++, который только выглядит, как объектно-ориентированный). Библиотека C динамически связана с от Objective-C реального времени, для «перевода» сообщения, требующего использования нижнего уровня системных вызовов UNIX, где iPhone OС может обработать их нужным образом.
     Этот процесс можно видеть, при использовании GDB в приложении iPhone главным образом стандартном “2-м потоке? данного приложения с низкоуровневыми запросами приводящими к dyld_*(динамическое редактирование) системным вызовам или даже процессорным прерываниям, реализованным непосредственно на ассемблере.
     Некоторые читают это и думают, “Ну и дела, почему разработчики просто не пользуются библиотекой C или непосредственными системными вызовами?”, и ответ : оба варианта являются излишне сложными в реализации, и в значительной степени недокументированными. Вы хотели бы терять в два раза больше времени на разработку приложения, используя библиотеку C, если гораздо легче использовать Objective-C API и framework? И, у Apple есть их собственные функции библиотеки C, которые они не документируют, и Вы, вероятно, никогда не захотите ими пользоваться при разработке приложения (и компилятор/компоновщик это делать).



Архитектура iPhone

     Диаграмма, которую мы показали выше, предназначается для представления архитектуры iPhone ОС. Вот описание уровней:
Уровень приложений: Работающее сейчас приложение iPhone, купленное через app store (если не используется jailbrаke оборудование ). Это приложение было собрано в машинный код от Apple-iPhone распределенных компилятором, и связано с Objective-C и C выполнением библиотеки компоновщика. Это приложение также полностью работает в пользовательском пространстве среды iPhone OS.
Frameworks / API: Cocoa Touch, вызовы OpenGL верхнего уровня, они все здесь. Эти API вызывают просто Apple-распределенные заголовки из iPhone SDK, с некоторыми динамическими связями в режиме работы. Они находятся в верхней части Objective-C, так как многие из них написаны на Objective-C.
Objective-C Runtime: Этот уровень состоит из Objective-C динамически связанных библиотек реального времени, а также основных библиотек C. Библиотека C создает условия для исполнения Objective-C так, что я просто объединил их в один уровень (хотя я бы, вероятно, назвал его «исполняемые библиотеки»).
iPhone OS: Это ядро, драйверы и сервисы, которые составляют операционную систему iPhone. Иногда это называется iPhone OС, iPhone OСX, или просто OС X, но это все относится к одному и тому же: он расположен между пользовательским и аппаратным уровнями.
Processor: Не столько физический чип ARM(содержится в пределах аппаратного уровня), сколько обращения к набору команд ARM и таблице дескрипторов прерываний настроенных iPhone OS во время загрузки и инициализация драйвера.
Firmware: Хотя мы называем всю OС «программируемым оборудованием» иногда (особенно при jailbreakе), этот уровень ссылается на специфичный для чипа код, который или содержится с памятью в/вокруг непосредственно периферии, или в пределах драйвера периферийного оборудования (пример: сенсорный экран или гироскоп)
Hardware: Достаточно очевидно, однако относится к физическим чипам припаянным к схеме iPhone's. Фактические процессор входит в этот уровень, но набор инструкций и таблиц дескрипторов содержатся в «процессорном» уровне.

В заключении

     Как заключительную деталь, хочу указать кое-что о планировщике iPhone OС и о том, как он работает в тесной связи с управлением питанием iPhone. Я упоминал ранее, как кнопка на iPhone/iPod приостанавливает работающее в настоящее время приложение, чтобы войти в режим экономного питания. Они демонстрируют особенности управления питанием заложенные в iPhone, для увеличения времени работы аккумулятора, так же как способность планировщика остановить работающую в настоящее время программу и возобновить её позже.
     Сам планировщик способен управлять всеми фоновыми процессами iPhone, но вплоть до 3.0 beta это было ограничено приложениями Apple, таким как Почтовое приложение.
Планировщик/ядро очевидно отслеживает, какой из процессов активен, чтобы послать сигналы (полученные как сообщения через библиотеки) к нужному процессу, вместо того, чтобы сообщить, что iPhone был только наклонен, управляющему фоном почтовому приложению, а не Сафари.
     Jailbrake iPhone/iPod в состоянии управлять фоновыми приложениями текущей версии OС, значит есть или недокументированный системный вызов для этого, или модифицированные Jailbrake планировщики iPhone. Я больше склоняюсь к варианту недокументированной функциональности, так как это кажется более логичным, и jailbreaking предоставляет доступ к C реального времени для дизассемблирования и изучения этих недокументированных функций.
     Тем не менее, я рад, что Apple, наконец, позволила официальным приложениям работать в фоновом режиме. Доступ к этой функциональности будет не только на пользу многим разработчикам, но и исключит одну из причин взлома iPhone / iPod.