З квітня 2012 по лютий 2014 я працював у Windows Phone в команді яка називалася Device Update. В цілому я пережив 2 великі реорги (це коли перетасовують структуру команд і продуктів щоб оптимізувати взаємодію), але весь час моя команда була частиною того що умовно можна назвати командою ядра Windows Phone. Організаційно моя команда була споріднена з наступними:
- Core – команда яка займалася тим що вирізала все що можна з ядра Windows 8 і намагалася це примусити працювати на телефонах. Також в їх задачі входило примусити працювати, або знайти чому не працюють драйвери від сторонніх виробників таких якQualcomm.
- Security – на телефоні кожна програма що не є частиною ОС працює в своїй жорстко обмеженій пісочниці і не те що не має доступу, але навіть і не бачить ресурси (файли, диск, пам’ять, реєстр, мережа, …) крім тих про які їй дозволено знати. Система безпеки телефону не покладається на механізми десктопної Windows, а по суті заміняє її. Це необхідно тому що вимоги до програм на смартфоні абсолютно інші ніж до десктопних програм.
- Network and Drivers – на телефоні свій стек протоколів для WiFi, Bluetooth і усього іншого, але виглядає це як частина ОС.
- Device Update – моя команда яка відповідала за оновлення на телефоні що рештою дівізіона сприймалося як частина ОС.
Ще в Windows Phone існують такі великі команди як UI, Developers Platform, Services та інші.
Тепер невеличкий відступ про механізми Windows Update. Технологія ця існує доволі давно і добре обкатана в самій ОС, а відносно недавно і інші продукти почали оновлюватися використовуючи цей механізм. Але важливо не плутати з механізмом оновлення програм з магазину – це зовсім інша сутність ніяк не пов’язана з ОС.
Працює Windows Update приблизно так:
- клієнт питає у сервера щось типу “що в тебе є для категорії Windows/Windows Phone/XBox/Office/…”. Сервер повертає список версій: Windows 6, 6.1, 6.2 і так далі.
- Клієнт каже “о, а я Windows 6.2, що там у тебе є для мене?”. До речі оте 6.2 це версія ядра ОС.
- Сервер повертає список так званих детектоідів. Це такі логічні умови типу “значення ось цього ключа в реєстрі знаходиться між A та B”, або “версія ось такої DLL дорівнює ХХХ”, або “мова встановленна в українську”. Ну ви зрозуміли. Причому умови можуть бути які завгодно, а їх перевірку виконують так звані провайдери що реєструються на клієнті. Є провайдери для файлів, ресурсів (версія ОС, розв’язок екрану, версія драйверів), реєстру і інші. Таким чином клієнт не має уявлення як перевіряти детектоїди і що вони означають, а просто викликає відповідні провайдери. Імена детекоідів містять провайдерів, щось типу “./system/hardware/monitors/1/resolution/width”.
- Для тих детектоідів умова яких істинна серверу повертаються ідентифікатори, а сервер повідомляє які файли відповідають цим детекоідам.
- Клієнт викачує файли і робить з ними що хоче. Зверніть увагу що ні формат файлів ні що з ними робити протокол не диктує.
- Насправді там може бути кілька рівнів категорій і детектоідів, детектоіди можуть мати складні і навіть вкладені умови, один файл може бути пов’язаний з кількома детектоідами і таке інше. Але суть думаю зрозуміла.
- До речі коли ви встановлюєте Windows ваша машина отримує випадковий номер від 1 до 100 що використовується виключно механізмом оновлення. Коли ОС за розкладом перевіряє оновлення вона повідомляє серверу цей номер і той може сказати “у мене для тебе нічого нема”. Це зроблено для того щоб зменшити наватнаження на сервер який щодня без перебільшень смикають сотні мільйонів клієнтів. Також це дозволяє перевіряти оновлення на мешній аудиторії, скажімо перший тиждень віддавати його лише 1% користувачів. А от коли ви заходите в Панель Управління і натикаєте “Шукати оновлення” там то ваша ОС каже серверу “кажи що в тебе є і не дивись на мій номер”.
Коли було прийнято рішення оновлення Windows Phone зробити доступними за допомогою Windows Update (це дозволило уникнути реалізації серверної частини та деяких інструментів) то виникло кілька проблем специфічних для смартфонів, деякі з них:
- через те що батарею треба економити не можна постійно тримати у пам’яті процес яки лише раз на кілька днів буде перевіряти чи є на сервері оновлення.
- для зменшення трафіку дерево категорій та детекоідів має бути нижчим, але ширшим.
- файли не мають бути надто великими щоб у випадку поганого зв’язку не качати заново один і той же файл знову і знову. Ні, докачувати не можна, а чому – залишу вам як домашню вправу для самостійних роздумів Підкажу лише що весь сеанс від першого звернення до серверу до завершення розпакувування останнього файлу має бути транзакційним.
- через обмеження пам’яті не можна скажімо розпакувати нову версію DLL і почати її використувавати для нових процесів в той час як старі використовують стару версію.
- через обмеження дискового простору не можна розпакувати оновлення і чекати до наступного перезавантаження телефону щоб замінити ними старі файли.
Із секретів можу сказати таке що на смартфоні (і не лише Windows Phone) встановленно дві ОС, одна спеціально для того щоб встановлювати оновлення на іншу. Тобто зі сторони пристрою процес виглядає приблизно так:
- Знайти і викачати оновлення на сервері
- Запропонувати користувачу встановити їх
- Розпакувати оновлення (по суті це не нові файли, а лише те що треба змінити в існуючих)
- Перезавантажити телефон в другу ОС
- Пропатчити оновленнями файли на робочій ОС (на тому диску де встановлено робочу ОС)
- Перезавантажити телефон в робочу ОС
- В процесі завантаження виконати програми що зареєструвалися як мігратори даних зі старої версії в нову
До речі Apple так і не подужала зробити нормальні оновлення для iPhone і користувачі тупо викачують імідж (тобто цілий знімок диску) робочої ОС. Для цього їм треба тримати порожнім місце розміром таке саме як диск робочої ОС.
Із секретів можу сказати що функція “повернути до заводських настроєк” не відновлює оригінальні версії файлів, а просто стирає все з диска на якому зберігаються настройки і файли користувача, а робоча ОС залишається без змін. Таким чином якщо ви встановили хоч одне оновлення то повернути телефон у справді заводські настройки можна лише повною його перепрошивкою. Алетернативою було б мати ще один диск з оригіналами файлів, але на це ніхто з виробників не піде – робити пристрій дорожче заради сумнівної користі…
Одна з переваг переводу Windows Phone на Windows Update полягає в тому що теоретично (нижче детальніше чому теоретично) можна викладати оновлення коли Mictrosoft має їх готовими та протестованими. Десктопна Windows так і робить. Але у світі мобільного зв’язку волю диктують оператори. Жоден оператор не погодиться продавати телефони якщо вони не зможуть контролювати що саме на них встановлюється. Саме тому Microsoft не може самовільно робити доступними навіть критичні оновлення. Кожне оновлення має детекоід “оператор має бути Х”. Apple диктує свою волю операторам, у них інша ситуація. Що стосується Android то там шаленна фрагментація ринку і ніхто не зацікавлений робити доступними оновлення, краще продавати телефони з оновленою ОС і тому Google віддала оновлення на відкуп операторам та виробникам телефонів. Тобто вони їх звісно роблять, але публікацією не займаються, кому цікаво той сам робить оновлення доступними.
Я особисто вважаю що Microsoft має найвдалішу модель оновлень, але нажаль ситуація на ринку не дозволяє її задіяти.
А тепер зі сторони того хто публікує оновлення, звісно теж не всі особливості:
- треба визначити між якими версіями мають існувати оновлення. Якщо для Windows нормально мати ланцюжок 1 оновлюється в 2, 2 оновлюється в 3 і так далі та ще й з перевантаженнями між оновленнями то для телефонів це не підходить: забагато викачувати, та і клієнти викинуть телефон якщо той почне перезавантажуватися кілька разів. Тому якщо вже опублікували оновлення з 1 до 2 то треба буде публікувати і 1 в 3 та 2 в 3. Ну і так далі.
- після того як готова чергова версія (наприклад щоденний білд) треба не просто згенерувати оновлення для усих існуючих версій, але і розуміти які оновлення для чого та якось їх ділити на пакети. Наприклад у телефонів на відміну від десктопів розв’язок екрану фіксований, а тому оновлення для 600х800 та 600х1024 треба публікувати як окремі навіть якщо це єдине чим вони різняться. Додайте сюди мови (інтрефейсу, клавіатури, голосу і так далі), країну і ще багато всього і раптом з одного білда у вас виникає оновлень на кілька гігабайт.
- до речі клавіатура (та деякі подібні речі) дуже цікавий приклад. Оновлення усіх можливих мов клавіатури ставити на кожен телефон не має ніякого сенсу, а коли користувач додає собі скажімо українську клавіатуру то її можна встановити лише з повної версії файлу, а не з патчу. Таким чином деякі оновлення містять як нові версії так і оновлення і використання того чи іншого визначається складними умовами.
- оскільки смартфони захищені доволі серйозно то все що публікується має бути пошифровано і захищено сертифікатом який періодично закінчується (доволі часто).
Тепер подумає які ще є особливості в публікуванні оновлення. Скажімо MIcrosoft має нову версію до якої хоче обновити телефони. Будується імідж з якого виробники, наприклад Nokia, вибирають для кожної моделі саме те що їх цікавить. Десь не потрібна фронтальна камера, десь NFC, десь контроль трафіку, десь ще якісь фічі. Після тестування цієї версії виробник повертає імідж який вони модифікували і довопнили своїми компонентами. Тепер імідж треба підписати, згенерувати оновлення для попередніх версій і віддати операторам. Оператори вимагають гроші за тестування кожного оновлення (сотні тисяч долларів) і тому так часто як для десктопа виставляти оновлення не вийде. Власне з того що я бачив оновлення з’являються у доступі приблизно через рік після того як їх розробка завершена. Навіть зараз на наших Lumia 920 тa 1520 є не все що мав на своєму розробницькому телефоні 2 роки тому.
Так чим же займалася моя команада? А ось чим:
- Інструменти які в процесі білду генерують оновлення для попередніх версій.
- Публікація оновлень для усіх бранчів (їх було більше 150 на 2000 програмістів) теж в процесі білду. Таким чином розробники могли прошити свій телефон своїм бранчем і щоранку отримувати апдейти для нічного білда, або пропустити кілька днів і отримати апдейт що перестрибував кілька версій. Я в основному цим ось і займався.
- на пристрої – частина що сканує, скачу і готовить оновлення
- частина другої ОС що власне виконує оновлення
- фреймворк для клієнтських міграторів данних
Ось, поки на цьому зупинюся. Хотів написати більше, але вже і так багато вийшло. Задавайте питання якщо є які.