Nvidia DGX Spark — суперкомпьютер на вашем столе

NVIDIA Project Digits — персональный суперкомпьютер за $3000 с 1 петафлопсом. Разбираем чип GB10, FP4-точность и кому нужен ИИ на рабочем столе.
Павел Ельцов 27 марта 2026 в 05:20

Что если бы вычислительная мощность, которую ещё несколько лет назад можно было встретить разве что в специализированных исследовательских центрах, уместилась в корпус размером с увеличенный Mac mini и встала на ваш рабочий стол? Именно с таким вопросом NVIDIA вышла на сцену CES 2025 — и ответ оказался не риторическим.

При слове «суперкомпьютер» воображение рисует привычную картину: просторный машинный зал, стойки с оборудованием от пола до потолка, ряды вентиляторов, непрерывный гул. Такие системы строят для моделирования климата, разработки ядерного оружия, расчёта сложных физических процессов и — в последние годы всё чаще — для обучения и запуска крупных моделей искусственного интеллекта. Доступ к подобным мощностям традиционно означал либо работу в государственном исследовательском институте, либо аренду облачной инфраструктуры у технологических гигантов.\

В NVIDIA задались простым вопросом: а что если сделать это компактным? Project Digits — именно так устройство называлось на момент анонса — стал ответом на этот вопрос. Суперкомпьютер, который помещается в небольшой корпус и может стоять прямо на рабочем столе. Впрочем, к моменту выхода в продажу устройство сменило имя: с осени 2025 года оно называется NVIDIA DGX Spark.

Для кого это устройство — и для кого точно нет

Нужно сразу сказать прямо: для рядового пользователя DGX Spark бесполезен. Это не игровая машина, не мощная рабочая станция для монтажа видео и не замена привычному домашнему компьютеру. Устройство создавалось для вполне конкретной аудитории: разработчиков в сфере искусственного интеллекта, исследователей и студентов, которым нужно создавать, дообучать и запускать крупные языковые модели локально — без постоянного обращения к облачной инфраструктуре.

По замыслу NVIDIA, DGX Spark — это инструмент для прототипирования. Разработчик создаёт и тестирует модель на настольном устройстве, а когда она готова к промышленному применению, разворачивает её в облаке или в корпоративном дата-центре. Причём — и это принципиально — на той же самой программной архитектуре. Никакой переписки кода, никакой адаптации под другую платформу.

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

Операционная система — не привычная Windows, а DGX OS: специализированный дистрибутив на базе Ubuntu 24.04, настроенный под задачи искусственного интеллекта. В комплекте идут CUDA, cuDNN, TensorRT, Docker и целый набор готовых сценариев применения — от RAG-систем до мультиагентных рабочих процессов. Всё это позволяет приступить к работе практически сразу после включения.

Что внутри: архитектура GB10 Grace Blackwell

Внешне DGX Spark выглядит как типичный мини-компьютер — золотистый металлический корпус размером 150 × 150 × 50,5 мм, стилистически напоминающий уменьшенную копию легендарного DGX-1. Именно такой суперкомпьютер Дженсен Хуанг лично доставил Илону Маску в офис OpenAI в 2016 году — системы, которую принято считать отправной точкой всего нынешнего бума генеративного ИИ. Намёк на эту историю в дизайне DGX Spark вряд ли случаен.

128 гигабайт оперативной памяти и накопитель NVMe объёмом до 4 ТБ — внушительно, но вполне ожидаемо для устройства подобного класса: обученные языковые модели занимают значительное место. Самое интересное — в главном чипе. Сердце DGX Spark — GB10 Grace Blackwell Superchip, система на кристалле (SoC), разработанная совместно с компанией MediaTek.

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

GB10 объединяет графический процессор на архитектуре Blackwell — с новейшими ядрами CUDA и тензорными ядрами пятого поколения — и центральный процессор Grace с двадцатью энергоэффективными ядрами на базе архитектуры Arm (10 высокопроизводительных ядер Cortex-X925 и 10 энергоэффективных Cortex-A725). Соединяет их технология NVLink-C2C, обеспечивающая пропускную способность в пять раз выше, чем интерфейс PCIe Gen 5. Унифицированная архитектура памяти означает, что процессор и графический сопроцессор совместно используют единый пул из 128 ГБ — без накладных расходов на копирование данных между раздельными банками.

Благодаря этому DGX Spark способен локально запускать языковые модели с числом параметров до 200 миллиардов. Для сравнения: GPT-3 — модель, с которой во многом началась нынешняя эпоха генеративного ИИ — содержит 175 миллиардов параметров. Если же соединить два устройства через специальный адаптер ConnectX с пропускной способностью 200 Гбит/с, объединённая система справляется с моделями до 405 миллиардов параметров — размер флагманской Llama 3.1 от Meta.

Петафлопс петафлопсу рознь: о чём умалчивают в пресс-релизах

Заявленная производительность в 1 петафлопс — квадриллион операций в секунду — звучит впечатляюще. Для сравнения: Sony PlayStation 5 Pro выдаёт около 33 терафлопс, то есть примерно в тридцать раз меньше. Однако у этой цифры есть существенная оговорка, о которой важно говорить честно.

Заявленный петафлопс относится к вычислениям с точностью FP4 — то есть к операциям с четырёхбитными числами с плавающей точкой. Для сравнения: стандартные научные расчёты ведутся с точностью FP32 (32-битные числа), а большинство современных нейросетей при обучении используют как минимум FP16. FP4 — это очень низкая точность. При ней каждое число кодируется четырьмя битами вместо шестнадцати или тридцати двух, что позволяет резко ускорить вычисления, но ценой потери точности представления числовых значений.

Кроме того, реальный показатель достигается с использованием технологии структурного прореживания (structured sparsity): она удваивает эффективную скорость вычислений, пропуская нулевые значения. Но работает это только при условии, что конкретная задача оптимизирована под этот режим — что в реальных приложениях выполняется далеко не всегда. Независимые тесты показывают реальную производительность на уровне около 100 терафлопс в формате BF16 и около 207 терафлопс в FP8 — цифры уважительные, но далёкие от рекламного петафлопса.

После выхода устройства в продажу эта тема вызвала оживлённую дискуссию в профессиональном сообществе. Критики указывали, что заявленная мощность — маркетинговая цифра, а не реальный показатель производительности для большинства задач. Один из обозревателей зафиксировал, что при работе с моделью Llama-3.1-8B устройство выдаёт около 36 токенов в секунду — ровно столько же, сколько Mac mini с процессором M4 Pro, который стоит примерно в три раза дешевле.

И всё же было бы несправедливо сводить дискуссию к простому «обману покупателей». NVIDIA действительно провела масштабную исследовательскую работу, чтобы сохранить практически приемлемую точность при переходе на FP4. На конференции HotChips в августе 2024 года компания продемонстрировала первый генератор изображений, работающий на модели с точностью FP4: результат визуально практически неотличим от FP16. Это говорит о том, что для задач инференса в нейронных сетях четырёхбитное представление чисел вполне имеет право на существование — особенно в сочетании с грамотными методами квантизации.

Немаловажно и то, что DGX Spark обладает уникальным преимуществом, которое не отражается ни в каких бенчмарках: нативная поддержка CUDA. Конкурирующие решения на базе AMD Ryzen AI Max или чипов Apple Silicon предлагают сопоставимую или даже превосходящую производительность по соотношению цена/качество — но все они лишены доступа к экосистеме CUDA, которая по-прежнему остаётся де-факто стандартом в разработке ИИ.

От анонса к реальности: как Project Digits стал DGX Spark

Путь от анонса до прилавка оказался долгим. На CES 2025 устройство обещали выпустить в мае того же года по цене 3 000 долларов. В марте 2025 года NVIDIA переименовала Project Digits в DGX Spark. Первые поставки начались лишь осенью 2025 года — и уже по цене 3 999 долларов за версию Founders Edition. К февралю 2026 года цена выросла ещё раз — до 4 699 долларов, что NVIDIA объяснила дефицитом 128-гигабайтных модулей памяти LPDDR5x.

Параллельно к выпуску устройств подключились партнёры: Acer, ASUS, Dell, Gigabyte, HP, Lenovo и MSI выпустили собственные версии на базе того же чипа GB10 — как правило, с меньшим объёмом накопителя и по более низкой цене. Рынок обозначил своё отношение к категории довольно отчётливо: сопоставимые по возможностям системы на Ryzen AI Max+ стоят существенно дешевле, хотя и проигрывают в поддержке программного стека NVIDIA.

Реальные пользователи и независимые обозреватели дали устройству в целом осторожно положительную оценку. Отмечается исключительное удобство работы с готовым программным стеком — DGX OS поставляется с предустановленными инструментами, и первую рабочую нейросетевую задачу можно запустить буквально через несколько минут после распаковки. 128 ГБ единой памяти, разделяемой между процессором и графическим ускорителем, действительно позволяют запускать модели, недоступные на большинстве потребительских устройств. Встроенный сетевой интерфейс ConnectX-7 с пропускной способностью 200 Гбит/с — компонент, который в отдельной поставке стоит от 1 700 долларов — также выгодно отличает DGX Spark от конкурентов.

Вместе с тем критики указывают на тепловые ограничения: компактный металлический корпус объёмом 1,13 литра при длительных нагрузках заметно греется, и часть пользователей фиксировала самопроизвольные перезагрузки. Устройство потребляет значительно меньше заявленного TDP, что свидетельствует о термическом или программном ограничении производительности. Ситуацию должны исправить обновления прошивки — одно из них уже снизило потребление в режиме ожидания более чем на треть.

Намёк на будущее: NVIDIA на рынке потребительских процессоров?

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

Если компания действительно выйдет на рынок потребительских процессоров — рынок, который десятилетиями делят Intel и AMD, — последствия для индустрии сложно переоценить. GB10 уже доказал, что архитектура Arm в связке с графическим ускорителем Blackwell и унифицированной памятью работает. Остаётся вопрос: захочет ли NVIDIA идти дальше? Пока что это лишь намёки. Но в истории технологий именно так всё и начинается.

Главное — не само устройство

DGX Spark — устройство для узкой аудитории. При нынешней цене в несколько тысяч долларов, работе исключительно под управлением Linux и ориентации на профессиональные задачи ИИ оно явно адресовано не широкому потребителю. Разработчики и исследователи получили то, о чём давно мечтали: возможность работать с крупными языковыми моделями локально, без облачной зависимости и без необходимости делиться данными с внешними серверами.

Но, пожалуй, главное в этой истории — не само устройство. Главное — прецедент. Впервые в истории суперкомпьютерные вычисления в сфере искусственного интеллекта оказались в форм-факторе настольного компьютера с ценой, соответствующей профессиональной рабочей станции. Это тот самый момент, когда технология, существовавшая исключительно в серверных залах, делает шаг навстречу обычному рабочему пространству. Пусть пока — только для профессионалов. Но закономерность здесь такая же, как и всегда: сначала появляется дорогой инструмент для специалистов, а затем — через несколько лет — доступная версия для всех остальных.

 

Apple готовит три ИИ-носимых устройства — очки, кулон и AirPods с камерами

Apple ускоряет разработку трёх ИИ-носимых устройств: умные очки, кулон и AirPods с камерами. Ставка на ambient AI и Siri нового поколения.
Павел Ельцов 24 февраля 2026 в 06:24

Bloomberg сообщили, что Apple ускоряет разработку трёх ИИ-носимых устройств: умных очков, кулона-подвески и AirPods с камерами. Все три устройства строятся вокруг Siri нового поколения, которая будет использовать визуальный контекст для выполнения действий.

Умные очки конкурируют с Meta* Ray-Ban и получат две камеры: одну высокого разрешения для фото и видео, вторую — для компьютерного зрения и контекста окружения (похоже на LiDAR в iPhone). Никакого дисплея в линзах не будет — только голосовой интерфейс через Siri, динамики и микрофоны. Производство может начаться уже в декабре 2026 года с запуском в 2027-м. Apple недавно предоставила прототипы инженерам.

Кулон-подвеска размером с AirTag можно носить на одежде или как ожерелье. Две камеры, три микрофона, динамик — устройство станет «глазами и ушами» iPhone, работая как постоянно активная камера с Siri. Запуск возможен в 2027 году, но проект на ранней стадии и может быть отменён.

AirPods с камерами могут выйти уже в 2026 году. Камера низкого разрешения предназначена не для фотографий, а для передачи визуальной информации Siri — аналогично Visual Intelligence на iPhone 15 Pro.

Всё зависит от Siri нового поколения с интеграцией Google Gemini, которая даст ассистенту серьёзный апгрейд интеллекта. Без этого обновления три устройства останутся дорогими игрушками. Apple делает ставку на ambient AI — лёгкие носимые устройства для повседневного использования вместо громоздкого Vision Pro за $3499. Это тот же инстинкт, что породил Apple Watch: маленькое простое устройство, которое становится незаменимым через постоянное использование.

*Компания Meta Platforms Inc. признана экстремистской организацией и запрещена на территории РФ, также как и её продукты Facebook и Instagram.

Как создают мобильные приложения? Разбор

Сегодня мы углубимся в вопросы разработки приложений для разных мобильных операционных систем и снова попытаемся понять разницу между iOS и Android?
aka_opex 31 августа 2022 в 08:28

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

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

Разберемся, что такое среда разработки? Узнаем, чем отличаются приложения под iOS и Android? Что лучше, нативные или кросс-платформенные приложения?
И зададим главные вопросы разработчику!

Где разрабатываются приложения?

Итак, разработать приложение — это примерно как сделать табуретку. Для этого вам потребуется необходимый набор инструментов и помещение, где вы будете пилить свою табуретину. На программистском такое помещение с инструментами называется среда разработки или по-научному IDE.

IDE — Integrated development environment — интегрированная (или единая) среда разработки

Для Android такой средой разработки является Android Studio, а для iOS – Xcode.

Среда разработки – это просто программа, где есть всё что вам нужно для создания приложения. Тут есть:

  • где писать код,
  • где отлавливать баги,
  • встроенный эмулятор, в котором вы можете сразу тестировать приложение,
  • и даже визуальный редактор интерфейса, в котором вы можете двигать всякие элементы интерфейса прям как в PowerPoint.

Окей, двигаемся дальше.

На каких языках пишутся приложения?

Приложения под разные платформы пишут на разных языках программирования. Большую часть кода под iOS пишут на Objective-C и Swift, а под Android на Java и Kotlin.

Swift и Kotlin – это более современные и дружелюбные языки программирования. Эти языки очень похожи, вплоть до того, что некоторые участки кода могут совпадать на 70% и даже больше.

Вот пример функции которая на основе текущего дня и вида погоды создает сообщение о прогнозе.

Интересно, что Swift создан только для разработки под iOS. А вот на Kotlin можно писать под разные платформы, и под Windows, и под Linux, и даже под iOS. Думаю, это одна из причин радости разработчиков, когда Kotlin добавили в Android Studio. Это было на Google I/O в 2017 году.

Из чего состоят приложения?

С языками и средой разработки разобрались. Но из чего состоят приложения, и как они работают изнутри?

Разберем на примере Android.

Тут все приложения состоят из четырёх основных компонентов, это:

  1. Активность (activity)
  2. Сервис (service)
  3. Широковещательный приемник (broadcast receiver)
  4. Поставщик содержимого (content provider)

Чтобы вас сильно не грузить, подробнее остановимся на двух из них: Активностях и сервисах.

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

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

Каждая Активность имеет свой жизненный цикл. Выглядит он вот так сложно:

Но если упростить, активность может находиться в одном из четырех состояний:

  1. Запущена
  2. На паузе
  3. Остановлена
  4. Уничтожена

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

Иными словами активность не может работать в фоне. Для этого в Андроиде существует другой компонент — сервис (service)

Сервисы — очень удобная штука. При помощи сервисов в Android очень легко можно реализовать любые фоновые задачи: воспроизведение музыки, скачивание файлов, навигацию и прочее, прочее.

Сложность только одна, можно сильно увлечься с фоновыми процессами и сожрать весь заряд аккумулятора.

iOS и фоновые задачи

А вот в iOS проблемы совсем иного рода. В качестве аналога Сервисов тут есть шутка, которая называется Background Task, то есть буквально фоновая задача.

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

Из плюсов: вряд ли какое-то приложение сожрет в фоне батарейку на вашем iPhone. Из минусов — вам придется постоянно тыкать в экран пока грузится видосик в Telegram.

Тем не менее, частично такие ограничения можно обойти и реализовать практически тоже самое, что можно сделать на Android.

Иными словами, разработка для iOS и Android очень похожа. Отсюда возникает вопрос, а можем ли мы написать одно приложение, которое будет работать и на iOS и Android? На самом деле можем, но с оговорками.

Когда перед разработчиком стоит задача погнаться сразу за двумя зайцами, то есть разработать приложение сразу под две ОС. У него есть три пути:

  1. Использовать нативную разработку,
  2. Использовать кросс-платформенную разработку
  3. Использовать гибридную разработку.

В чем разница?

Нативные, кросс-платформенные и гибридные разработки

Итак, нативная разработка — это самый прямолинейный, понятный, и при этом, наверное, самый затратный путь.

От англ. native — родной, естественный

В этом случае под каждую операционную систему пишется отдельное приложение с использованием родных для этой системы языков и инструментов, то есть для iOS нативные приложения пишутся в среде разработки Xcode на языках Objective-C и Swift. А для Android используют Android Studio и языки Java и Kotlin.

Нативные приложения считаются самыми быстрыми, надежными и вообще чувствуют себя в родной ОС как дома. Каждое такое приложение, как костюм сшитый на заказ. Из преимуществ — такой костюм идеально сидит, из недостатков — для каждой ОС приходится шить свой отдельный костюм.

Поэтому существует очень манящая идея кросс-платформенной разработки. Представляете, вы пишите один код, который работает на разных платформах. Звучит как настоящая мечта для заказчика. Нужно вдвое меньше разработчиков, вдвое меньше времени и, чисто теоретически, вдвое меньше бюджет. Более того есть масса инструментов, то есть фреймворков, которые позволяют это сделать: React Native, Flutter, Xamarin, Cordova, Ionic, Titanium Appcelerator, Vue Native.

Самые популярные — React Native и Flutter.

Естественно, каждый из таких фреймворков обещает, что их кросс-платформенное приложение будет ничем не хуже нативного, но на практике всё не так.

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

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

Но какой из этих подходов круче? 

Нативные приложения — приложения, созданные с помощью инструментов, которые предоставляют владельцы ОС. Обычно они выглядят наиболее органично среди «родных» приложений ОС. Но, для каждой системы нужно делать свою версию приложения, так как у всех разные инструменты для создания таких приложений.

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

Гибридные приложения сочетают в себе нативные и кросс-платформенные части. Можно сказать, что они являются проявлением длительного, если не бесконечного, поиска баланса между стоимостью разработки приложения и его способностью приносить пользу для бизнеса.

Любое приложение разрабатывается для достижения какой-то цели. При выборе технологий важно учитывать несколько факторов, которые могут быть не всегда очевидны:

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

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

Кросс-платформенный подход, например React-Native, тут может отлично сработать. Почему?

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

Какой подход использовался при разработке приложения «МойОфис Документы»?

Наше приложение можно рассмотреть как показательный пример нативного приложения. Расскажем подробнее, из чего оно состоит.

Приложение “МойОфис Документы” можно разделить на две части:

  1. Файловый менеджер (ФМ)
  2. Редактор документов

ФМ — это пример классического набора относительно стандартных функций: авторизация, работа с сетью, показ списка объектов с помощью стандартных UI элементов.

Редакторы — совсем другая история. Их «сердцем» является общее ядро, написанное на C++. За счет этого мы получаем полную унификацию того, как выглядят и ведут себя редакторы на всех платформах на которых мы умеем работать. Цена этой унификации конкретно нашего приложения — необходимость работы с C++, языком который сложно назвать стандартным для мобильной разработки. Что интересно, из-за ядра мы вполне можем назвать наше приложение гибридным, т.к. в нем есть кросс-платформенная часть. Разница лишь в том, что в такой кросс-платформе код ядра работает даже быстрее, чем если бы он был написан на наших «нативных» Java и Kotlin.

Помимо ядра у нас есть нестандартные элементы интерфейса, которые так же критичны к производительности. Я люблю приводить в качестве примера логику рендеринга документов. Этот компонент состоит из двух частей: логика ядра, которая рисует содержимое документа в буфер и логика рисования этого буфера уже на экране. Почему так работает — отдельная история, но сейчас важно, что это позволяет нам находить баланс между скоростью рисования содержимого и эффективным потреблением памяти и CPU. (Тут нужно вставить видео в котором включен developer mode в рендеринге, добавит наглядности)

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

Под какую платформу сложнее программировать iOS или Android?

После совместных обсуждений мы пришли к выводу, что сложность именно в работе примерно одинакова. Обе системы сейчас стремительно движутся в общем направлении как по фичам, так и по подходам к разработке (kotlin ~ swift, ComposeUI ~ SwiftUI). Отличия, конечно, остаются, но они не такие значительные чтобы о них говорить в контексте “сложнее-проще”. Другой вопрос, что порог входа в iOS по прежнему выше, чем в Android: вам нужен мак и айфон для того чтобы начать.

А можно ли написать приложение вообще без кода?

На сегодняшний день, действительно, существуют технологии, которые позволяют создавать некоторый вид приложений буквально не написав ни строчки кода. Чтобы понять как это работает можно вернуться к предыдущей теме. На разработку удобнее смотреть не бинарно (нативное или кросс-платформенное), а как на непрерывный процесс поиска наиболее оптимального способа решать бизнес-задачи. Двигаясь от нативной к полностью кросс-платформенной разработке мы также двигаемся по пути абстрагирования от конкретных платформ и ОС к технологиям которые позволяют сфокусироваться только на бизнес-задачах. Зерокодинг — это пример крайнего положения на спектре разработки. Тут вас ждет огромное количество ограничений: внешний вид, потенциально реализуемые фичи, производительность, полная зависимость от конкретной компании. С другой стороны, вы получаете возможность запустить первую версию приложения буквально за выходные. А в некоторых случаях это может быть крайне важно.

Подписывайтесь на МойОфис ВКонтакте, будьте в курсе новостей разработки приложений. 

Установить бесплатные редакторы для решения повседневных задач на домашнем компьютере или мобильном устройстве: ПК, Google Play StoreAppStore

Battlefield 2042 отложили до 19 ноября

Еще одна игра становится жертвой разработки во время пандемии коронавируса. На этот раз Battlefield 2042: радует, что релиз отложен всего на месяц.
aka_opex 20 сентября 2021 в 06:05

Следующая часть игры Battlefield, действия которой будут происходить в 2042 году отложена. Ранее Battlefield 2042 должна была выйти 22 октября. Теперь релиз состоится 19 ноября.

Сообщение об этом было опубликовано в твиттер-аккаунте игры. Генеральный деректор серии игр Battlefield в студии Dice Скотт Габриэльсон отметил, что релиз игры отложен по причинам, связанным с пандемией коронавируса.

«Учитывая масштаб и размах игры, мы надеялись, что наши команды вернутся в студии вместе, когда мы будем готовиться к запуску», — сказал Габриэльсон. «Но в текущих условиях, мы не можем работать в офисе и обеспечивать безопасность наших сотрудников. В итоге большая часть команды разработке продолжает выполнять тяжелую работу, сидя дома. Поэтому мы решили взять дополнительное время, чтобы полностью реализовать Battlefield 2042 и наше видение игры».

DICE обещала поделиться подробностями о предстоящем открытом бета-тесте Battlefield 2042 в конце этого месяца. Хотя задержка означает, что поклонникам серии придется подождать дольше, но игра все равно выйдет в 2021 году, в отличие от таких проектов как Dying Light 2 и Horizon Forbidden West.

Cyberpunk 2077 вернётся в PlayStation Store?

Кроме патчей и багфиксов в CD Project Red планирует разработку ещё двух высокобюджетных проектов. Воистину наполеоновские планы.
aka_opex 16 апреля 2021 в 02:57

Глава CD Project Red Адам Кичински надеется, что благодаря патчу 1.2 игра Cyberpunk 2077 сможет вскоре вернуться в магазин PlayStation Store в ближайшее время.

В интервью Reuters он сообщил, что в планах CD Project Red никогда не было идеи забросить Cyberpunk 2077.

«Мы уверены, что сможем сделать игру такой, что будем ей гордиться и спустя годы она будет успешно продаваться.» — отметил он. Также он сказал, что польская компания постоянно находится на связи с Sony и надеется, что вскоре игра вернётся в магазин PlayStation Store.

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

Apple всё ещё экономит на новых технологиях и исследованиях

Илья Рябов 15 мая 2016 в 05:08

Чтобы остаться «на коне» и обеспечить достойное будущее, крупные компании тратят миллиарды долларов на исследования и разработки.

Аналитическая контора Strategy& опубликовала рейтинг корпораций, которые выделяют на Researsh & Development больше всего средств.
(далее…)

Приложения для Windows Phone приносят разработчикам больше денег

Егор Беляков 29 февраля 2016 в 03:21

Аналитики из InMobi представили статистику по заработку тысячи разных разработчиков мобильных приложений за 2015 год.

Оказалось, что больше всех получают специалисты, создающие решения для Windows Phone.
(далее…)

Разработчик Falcon Pro присоединился к Twitter

Илья Рябов 8 августа 2015 в 05:16

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

Сегодня стало известно, что Жоаким Верже из Falcon Pro присоединился к команде Twiiter, занимающейся разработкой официального приложения для Android.
(далее…)

Google выпустила референсное приложение Universal Music Player

Илья Рябов 13 марта 2015 в 06:20

Google создала демонстрационное приложение под названием Universal Music Player специально для разработчиков .

Universal Music Player

Его главная задача — показать программистам, как может выглядеть одна и та же программа на разных типах устройств.
(далее…)

Google перезапускает проект Experiments

Илья Рябов 25 февраля 2015 в 05:28

24 февраля в рамках проекта Chrome Experiments появилось тысячое приложение, объединяющее предыдущее 999.

Chrome Experiments

Компания Google решила отпраздновать юбилей и перезапустила проект, основанный в 2009 году.
(далее…)