Как создавали Android View

Chet Haase, один из разработчиков первой версии Android, делится байками о команде в своей книге "Androids: The Team that Built the Android OS".

Тогда Google понятия не имели о том, как нужно разрабатывать операционные системы, поэтому собрали команду из инженеров Oracle, Microsoft, T-Mobile и т.д. У каждого, конечно, было свое мнение и видение прекрасного.

Примечательна глава о разработке системы Android View. В команде шли жаркие споры, на каком языке писать ui — Javascript или Java? Дискуссия закончилась тем, что один из инженеров, Joe Onorato, сел и за сутки написал View.java. Тот самый кирпичик в 20к строк, на котором держится весь Android UI Framework. Вот так и принимаются судьбоносные решения:

“It was basically a furious ‘Let’s get something done’ time. Took about a day, 24-hour marathon. I had Views [UI elements] up on screen.”

Mathias Agopian said of Joe, “He didn’t tell anybody. One morning he showed up and said, ‘Problem solved, it’s in Java. Now we don’t have to talk about it anymore because it’s there.’”

Самое интересное, на мой взгляд, изменение в Compose 1.10: появилось новое API для сохранения состояния — retain {}. Это аналог rememberSaveable (т.е. сохраненный объект переживает смену конфигурации), но без сериализации (т.е. смерть процесса он не переживет).

Мне кажется, в Android Developers Blog немного неудачно позиционируют это API. Да, сохранять инстанс ExoPlayer при смене конфигурации это, конечно, здорово. Но по сути ведь retain — это аналог ViewModel, который можно привязать к любой Composable функции. То есть, для привязки не нужен ни Activity, ни Fragment, ни NavEntry. Просто функция.

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

Вот несколько примеров, что возможно с retain:

— Stateful UI-компоненты. Кнопка с несколькими состояниями и сложной логикой — в собственной вьюмодели.

— Lazy список с вьюмоделью на каждый элемент. Вьюмодель создается в момент появления элементы на экране, уничтожается в момент удаления элемента из списка.

— Разные инстансы вьюмодели одного типа для элементов ViewPager.

Примеры взяты из описания опенсорсной библиотеки resaca, которая существует уже некоторое время и дает похожий на retain {} API. Но оффициальную библиотеку ведь использовать всегда приятнее.

Для чего нужны inline функции в Kotlin?

Часто этот вопрос задают на собеседованиях. И самый популярный ответ звучит примерно так: Inline функции нужны для оптимизации. С inline лямбда-аргументы функций не оборачиваются в объект, а просто вставляются в место вызова.

В целом это верно. Но такой ответ не учитывает, что JIT-компилятор JVM сам умеет инлайнить функции, если это улучшает перформанс. Мы, как разработчики, не должны (в общем случае) заниматься микрооптимизациями, которые и так делает компилятор или виртуальная машина.

А вот для чего на самом деле нужен inline:

1. Работа с generic типами. В java/kotlin действует type erasure. При компиляции вся информация о generic типах стирается. Если все же нужна информация о типе generic в рантайме, то используется inline + reified.

inline fun <reified R> List<*>.filterIsInstance(): List<R> {
    val destination = ArrayList<R>()
    for (element in this) {
        if (element is R) destination.add(element)
    }
    return destination
}

2. Non-local returns.
Inline позволяет делать возврат из вышестоящей функции прямо внутри лямбды:

fun hasZeros(ints: List<Int>): Boolean {
    ints.forEach {
        if (it == 0) return true // returns from hasZeros
    }
    return false
}

3. Сохранение контекста.
Это фича, без которой работа с Compose и Coroutines не была бы такой приятной. Лямбда внутри Inline-функции наследует весь контекст места вызова (окрашивается в тот же цвет). Например, функция List.forEach принимает обычную лямбду (не Composable), но внутри нее все равно можно вызывать Composable функции — как раз благодаря тому, что forEach — это inline функция.

@Composable
fun Items(items: List<String>) {
    Column {
        items.forEach {
            Text(it)
        }
    }
}

Чем заманивали бигтехи раньше: "Офис у метро, печеньки на кофепоинте"

Чем заманивают сейчас:

А, так вот оно зачем

Кроссплатформа против ИИ

Все, наверное, слышали, как в OpenAI навайбкодили Android приложение Sora с нуля до прода всего за 28 дней. Оригинал статьи тут.

Несколько заметок:

1. Над проектом работали 4 Senior Android разработчика. Вначале они руками написали несколько показательных фичей, засетапили инфраструктуру и кучу инструкций AGENTS.md, только после этого код начал писать ИИ агент.

2. ИИ агент плох в проектировании и архитектуре, но хорош в анализе больших кодовых баз и написании тестов. Нужно водить его за ручку и ревьюить весь код, который он пишет. Тут ничего нового.

3. По сути команда копировала iOS приложение, которое уже было выпущено на тот момент. И вот это интересно в контесте размышлений о том, насколько разработка с ИИ может убить кроссплатформу. Агенту дали доступ к репозиториям ios и бэкенда, чтобы он копировал бизнес-логику и требования оттуда. Как говорят, вышло неплохо:

We started our project with a huge stepping stone: Sora had already shipped on iOS. We frequently pointed Codex at the iOS and backend codebases to help it understand key requirements and constraints. Throughout the project we joked that we had reinvented the idea of a cross‑platform framework. Forget React Native or Flutter; the future of cross‑platform is just Codex.

Я не считаю, что это прямая замена кроссплатформы. У React Native и Flutter другой кейс применения — удешевить разработку нового приложения под несколько платформ одновременно, а не портировать одно нативное приложение на другую платформу.

А вот с применением KMP (изначальный смысл которого в том, чтобы портировать код с Android приложения в iOS) подход из статьи сильно пересекается. Впрочем, KMP, кажется, был dead on arrival (как и Swift for Android) еще до бума ИИ агентов. Уже давно нет такого количества новых мобильных проектов, чтобы тратить ресурсы на обучение/найм людей под еще одну кроссплатформу, а в существующие проекты KMP тоже затаскивать дорого и не всегда понятно, стоит ли оно того.

А вот и первые подарки

С наступающим!

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

Так вот, эта точка зрения разбивается об очевидную истину:

Работа, которую сегодня вы делегируете ИИ, является работой, которую завтра ИИ у вас отнимет.

Значит, чтобы получить преимущество, нужно как раз вдвойне сосредоточиться на том, что ИИ делать не умеет (и вряд ли научится до появления AGI).

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

Словом, ИИ может быть неплохим кодером, но ему не стать инженером.

Выходит, глобально ничего не изменилось. По-прежнему нужно учить базу computer science. Повышать уровень экспертизы в своей и смежных специальностях. Улучшать софт-скиллы. Заглядывать "под капот" технологий. Стремиться быть незаменимым.

График количества вопросов в месяц на StackOverflow (источник)

Кто знает, что случилось?)

Ray tracing in one weekend

Я тут на праздниках решил поизучать Rust. Как известно, лучший способ что-то изучить — это практика. Сначала я думал написать консольное приложение или 2D игру, но в процессе наткнулся на замечательную книгу "Ray tracing in one weekend".

Это пошаговое руководство по рендерингу реалистичных 3D изображений. Сначала рендерим простую сферу, потом добавляем тени, сглаживание, отражения, разные типы поверхностей. В конце получается вот такое изображение.

Вся теория построена на линейной алгебре (векторах) и геометрии, так что в процессе нужно вспоминать вузовскую математику. Очень рекомендую в качестве умственной гимнастики.

Примеры в книге написаны на C++, я писал на Rust и прикрутил параллелизм. Исходники тут.

Минутка троллинга

Моя любимая компьютерная игра — TES V: Skyrim — вышла в 2011 году, 15 лет назад.

Предыдущая часть серии, Oblivion, вышла еще на 5 лет раньше и сильно уступала в графике и геймплее (см. мемы oblivion npc dialogue), поэтому команда энтузиастов взялась портировать Oblivion на движок Skyrim, и назвали этот симбиоз Skyblivion.

Дело шло у них туго и дату выпуска постоянно отодвигали (начали еще в 2012 году), но вот уже побещали выпустить первую играбельную версию в 2025 году.

Так вот, я давно за этим делом не следил, а недавно случайно узнал, что:

1. Разрабы Skyblivion не успели к 2025 и перенесли запуск на 2026

2. Вместо этого сами Bethesda внезапно анонсировали и выпустили официальный Oblivion Remastered в апреле 2025 (т.е. по сути Skyblivion нафиг больше не нужен)

3. В качестве утешения разработчикам Skyblivion (которые потратили на него ~14 лет) выдали бесплатные ключи для игры в официальный ремастер

Вот это я понимаю high level троллинг

При просмотре видео на ютубе все чаще ловлю себя на том, что активно пытаюсь понять, а не нейрослоп ли это? Живой ли человек вещает по ту сторону экрана? Если еще год назад сгенерированный контент легко отличался, то сейчас вообще не очевидно. Киберпанк все ближе

Раз уж все мы по-тихоньку переползаем из IDE обратно в терминалы, поделюсь своим любимым теперь клиентом для git.

Lazygit. Это консольное приложение (TUI) на go. Очень крутой и понятный интерфейс, работает молниеносно, все команды отображаются на экране. Сильно упрощает жизнь, если нужно сделать что-то посложнее, чем pull-commit-push.

Просто посмотрите видео разработчика, где он показывает работу с lazygit. Я вот после просмотра понял, что не умел пользоваться гитом.

Тем временем Дядюшка Боб (автор Чистого Кода) разучился писать код без ИИ

Average вакансия в 2026

Исследователи из Anthropic тут опубликували бумагу, в которой говорят, что (внезапно!) ИИ мешает людям развивать свои профессиональные навыки и обучаться новым:

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

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

И вообще, если люди продолжат бездумно использовать ИИ, то со временем просто некому будет этот ИИ контролировать (ну или это будут спецы на вес золота, видимо):

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

Самое забавное тут то, что сами Antropic активно так вайбкодят: разработчик Claude Code, Boris Cherny, вообще гордится тем, что не написал руками ни строчки кода за декабрь

Общался недавно с тимлидом компании, где разрабатывают приложения на KMP, с нативным UI.

Они нанимают мобильных разработчиков без разделения на Android и iOS — если разработчик делает какую-то фичу, то он ее делает и на Android и на iOS одновременно (т.е. пишет UI на Compose и на SwiftUI).

Интересный момент, когда я спросил:

— Нет ли у вас проблем с онбордингом иосеров в проект? Насколько трудно им разобраться в KMP?

— Нет, на самом деле, даже наоборот, иосеры у нас быстро погружаются в KMP, а вот у андроидеров возникают трудности с SwiftUI. Видимо, андроидеры слишком избалованы качественным тулингом в Android Studio :)

Так вот почему Apple делают такие прекрасные продукты для пользователей, но такие плохие для разработчиков. Чтобы не расслаблялись)

История о том, что будет, если не ревьюить вайб-код: DeFi‑протокол Moonwel потерял около 1.78 млн долларов из-за ошибки в коде, которую сделал Opus 4.6

В PR, который был помечен, как «Co-Authored-By Claude Opus 4.6», оказалась неправильно прописана формула подсчета цены на cbETH (это обертка над Ethereum).

В итоге вместо положенных 2200$ фактическая цена некоторое составляла чуть больше одного доллара.

Арбитражные боты среагировали бодро: погасили кучу долгов за копейки и накупили cbETH на кругленькую сумму. К тому времени, как разработчики заметили баг, сумма ущерба уже составляла ≈ 1.78 млн долларов.

F

В Java, оказывается, собираются добавить nullable типы и уже начали работу над ними

Что с лицом, Kotlin