Введение в операционные системы

• оригинал: pages.cs.wisc.edu/~remzi/OSTEP/Homework/homework.html
• оригинал: github.com/remzi-arpacidusseau/ostep-code
• моя личная адаптация: github.com/bykvaadm/OS/tree/master/ostep
• Часть 3: Введение в планировщик

• Часть 1: Intro
• Часть 2: Абстрация: процесс
• Часть 3: Введение в API процессов
• Часть 4: Введение в планировщик
• Часть 5: Планировщик MLFQ

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

Вся эта магия происходит благодаря тому, что Android предоставляет фреймворк с базовыми компонентами. Мы не управляем этими компонентами, а лишь можем реагировать на колбэки, которые есть во фреймворке. Процессом приложения управляет система. 

В первой части совсем немного расскажу про Binder, про то, как происходит запуск Activity, как стартует процесс приложения и как на вызов Activity влияют флаги и launch mode. Во второй части будет про то, как вызываются методы жизненного цикла Activity, что происходит при сворачивании приложения, и более подробно расскажу про старт первой Activity.

В прошлой статье я описал, как стартует процесс нашего приложения, что такое ActivityStarter и как стартуют все Activity.

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

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

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

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

Все выпуски

• проблему широковещательного шторма
• работу и настройку протокола STP и его модификаций (RSTP, MSTP, PVST, PVST+)
• технологию агрегации интерфейсов и перераспределения нагрузки между ними
• некоторые вопросы стабильности и безопасности
• как изменить схему существующей сети, чтобы всем было хорошо

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

Заодно разберемся с таким понятием, как неявные анимации.

Для хранения объектов Swift использует две структуры данных: стек и кучу. Управление распределением памяти подразумевает выделение памяти под объект (аллокацию) и ее последующее высвобождение (деаллокацию).

Render Loop крутится — кадры мутятся

Доброго времени суток, уважаемые читатели. Здесь я начинаю свой цикл статей о работе с графикой в iOS.

В моих планах разобраться с работой базовых механик отрисовки и углубиться к таким вещам как AVFoundation, Metal.

Но а пока хочется понять как работает из коробки отрисовка наших любимых кнопок, которые мы не устаем красить. Как достичь 60 кадров в секунду. Магические слова, что заставят возжелать наш интерфейс любого.

В октябре 2020 года в техническую поддержку Авито стали обращаться пользователи с проблемами нагрева девайса и просадками FPS вплоть до полного фриза iOS-приложения. Проблема, как казалось, была глобальной. Она не относилась к какой-то конкретной функциональности приложения и поэтому не подходила в бэклоги продуктовых команд. Выход был один: засучить рукава и самому разобраться, что пошло не так. Не даром же я performance engineer.

Введение

Спойлер - нет! Ну, не совсем. Мы привыкли воспринимать UI как визуальную составляющую, но ведь UI – это User Interface. Так вот, интерфейс – это то, с помощью чего пользователь взаимодействует с нашим приложением. В случае с графическим интерфейсом пользователь его видел и воспринимает информацию. Однако он статичный и, когда пользователь хочет взаимодействовать с ним, он использует другие интерфейсы: тачскрин, клавиатуру или мышку. Да, это тоже интерфейсы. И UIKit как раз таки отвечает не за графический интерфейс, а за распознавание пользовательских жестов и их обработку.

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

Так как же он устроен? У нас же есть базовый класс UIView и куча его стандартных наследников. Мы можем сами создавать свои вью и как угодно их кастомизировать. И все это видим на экране. Почему тогда UIKit и UIView – это не про графический интерфейс? Давайте разбираться.