Как я заставил игру на LibGDX тормозить: 5 ошибок из реального проекта

Найдите курс под свою цельНайдите курс под свою цель Войти barbazan 5 сен в 17:50 Как я заставил игру на LibGDX тормозить: 5 ошибок из реального проекта Средний 9 мин 9.7K Java * Разработка игр * Разработка мобильных приложений * Мнение В предыдущей статье я рассказывал, почему в 2026 году выбрал LibGDX для разработки игр на Java и какие преимущества вижу у этого фреймворка. Но выбор инструмента — это только половина дела. Даже на LibGDX вполне можно сделать игру, которая будет отлично работать на компьютере и заметно тормозить на смартфоне. В этой статье разберём пять технических ошибок, которые чаще всего приводят к проблемам с производительностью. Эта статья не про геймдизайн, монетизацию, продвижение или причины, почему ваша игра никому не нужна. Речь исключительно о технических ошибках при разработке игр на LibGDX, которые могут привести к низкому FPS, микрофризам, большому потреблению памяти, повышенному расходу батареи или проблемам при сборке под WebGL. В первую очередь речь о мобильных играх и WebGL‑версиях, которые запускаются непосредственно в браузере. На мощном десктопном компьютере многие из этих проблем могут быть практически незаметны. Я сам разрабатываю игры на LibGDX и периодически наступаю на разные грабли. Поэтому ниже не академический список оптимизаций, а вещи, на которые я бы обратил внимание уже в начале разработки. 1. Не делайте гигантские Texture Atlas Texture Atlas — одна из самых полезных вещей в LibGDX. Мы собираем множество небольших картинок в одну большую текстуру, а затем используем отдельные TextureRegion. Это позволяет SpriteBatch дольше работать с одной текстурой и уменьшает количество переключений текстур и render calls. Но тут легко переборщить. Для мобильной игры я стараюсь держать максимальный размер страницы атласа примерно в пределах 4096 × 4096. Это не означает, что LibGDX или конкретный телефон обязательно не смогут работать с 8192×8192. Всё зависит от GPU и используемого backend. Проблема в другом: большая текстура — это большая текстура. Даже если вы используете из неё всего несколько маленьких картинок, сама текстура имеет соответствующий размер и требует памяти GPU. Например, RGBA8888-текстура 4096×4096 — это примерно:

Экономика владения мобильной фермой. Сколько стоит собрать собственный парк устройств

Чтобы приложение работало одинаково хорошо у пользователей с разными моделями смартфонов, его желательно протестировать на таких же устройствах. Но что делать, если аудитория насчитывает десятки тысяч человек и у каждого разные смартфоны: у кого-то Samsung последней модели, флагманский Huawei, REALME, INFINIX или старенький Xiaomi, а кто-то из ностальгии купил iPhone 4? Разные модели, разные операционные системы… Как вариант, в таком случае можно использовать мобильную ферму — собрать свою или использовать готовое облачное решение. Привет, Хабр! Я Саша, руководитель направления поддержки в Selectel. Мне стало интересно посчитать, сколько стоит собрать мобильную ферму своими руками и насколько это целесообразно для среднего и крупного бизнеса. Что получилось — рассказываю под катом. Мобильная ферма — сервис, который позволяет удаленно запускать и тестировать приложения на реальных мобильных устройствах. С ее помощью можно проверить совместимость, функциональность и производительность приложений на разных мобильных устройствах с операционными системами Android и iOS. Так ли нужен широкий парк устройств Для начала вернемся немного назад и разберем, можно ли обойтись 2–3 популярными девайсами при тестировании. Например, бывают случаи, когда в компаниях принято тестировать приложения только на паре устройств, но с разными ОС: Android и iOS. Такая практика вполне работает, когда пользователей не так много или экономически (и репутационно) можно пожертвовать частью юзеров. Например, не критично, если у небольшой части людей поплывет верстка или не сработает кнопка. Но для FinTech, e-commerce, SaaS и других приложений, где клиентов много, а цена ошибки высока, нужен парк пошире. Любой тестировщик знает, что баги, которые не появляются на одном смартфоне или одной операционной системе, могут критически влиять на работу приложения на другом. Даже если приложение работает некорректно на устройстве, которым пользуется всего 5% аудитории, бизнес может столкнуться с последствиями. Представьте, что случится, если при обновлении банковского приложения оно перестанет открываться у части пользователей. Широкое покрытие устройств позволяет создавать качественный продукт. Тестировщик может находить баги, которые проявляются только на конкретных моделях (например, только на Honor или на старых Samsung). Соответственно, снижается количество критических ошибок в продакшене, поддерживается высокий уровень SLA, а пользователи не идут писать негативные отзывы в магазинах приложений.

Почему HTML-таймер из чата не будит телефон, и что с этим делать

Войти fedorovbtc 8 сен в 10:20 Почему HTML-таймер из чата не будит телефон, и что с этим делать Простой 3 мин 4.4K Разработка мобильных приложений * JavaScript * Веб-разработка * Кейс Знакомый попросил ChatGPT написать ему интервальную тренировку: 40 секунд работа, 20 отдых, восемь кругов, одним HTML-файлом. Чат выдал нормальный код, в браузере всё бегает и пикает. Положил телефон на пол, начал отжиматься — тишина. Экран погас, и вместе с ним погас таймер. Он спросил у чата «почему», и получил длинный список: PWA с Wake Lock, PWA с заранее склеенной аудиодорожкой (тишина → гонг → тишина → гонг), Capacitor, «соберите APK». Четыре совета, и три из них — обходные манёвры вокруг одного простого факта, который в туториалах обычно не пишут. Веб-страница не умеет будильник Не «пока не умеет», а по решению платформ. Пройдусь по механизмам, в которые все упираются: setTimeout / setInterval живут, пока жива страница. Вкладка ушла в фон — таймеры троттлятся до раза в минуту, потом страница замораживается целиком. Safari на iOS делает это особенно охотно. Notifications API умеет показать уведомление, но только пока страница или её service worker бодрствуют. Запланировать «покажи в 10:33» нельзя. Notification Triggers — была ровно такая спецификация (showTrigger: new TimestampTrigger(t)). Chrome прогнал origin trial в 2020–2021 и закрыл проект. Нигде не вышло и не выйдет. Service worker просыпается от push с сервера и засыпает через десятки секунд. Своего расписания у него нет. Web Push работает, в том числе на iOS 16.4+ для PWA на главном экране. Но это сервер: HTTPS, VAPID, подписки, бэкенд, который в нужную секунду шлёт сообщение. Для продукта — нормально. Для таймера на сорок строк из чата — ну такое: чтобы телефон пикнул через 45 минут, нужно поднять и вечно крутить сервер. Так что классический «будильник на HTML» — , цикл с new Date(), тег

Скорость команды разработки — свойство системы, а не скорость самого быстрого ковбоя на Диком Западе

Скорость команды часто пытаются измерить количеством сильных разработчиков. Но самый быстрый человек в хаотичной системе обычно не ускоряет команду. Он просто первым начинает компенсировать её проблемы. В большом проекте скорость чаще теряется не в коде, а между мыслью «надо поменять вот это» и моментом, когда изменение можно будет увидеть, обсудить, проверить и выпустить. Представьте: большое iOS приложение для широкой аудитории, несколько рынков, которые собираются из одного проекта, часто обновляющиеся данные и экраны, которые product хочет менять быстрее, чем новый релиз успевает дойти до пользователей. В такой среде архитектура нужна не для красивой схемы. Она нужна, чтобы изменения были дешёвыми. Запускать модули отдельно Одна из самых дорогих операций в большом проекте — дождаться полной сборки. Разработчик может прийти поправить один экран, изменить несколько строк и затем ждать, пока соберётся весь продукт: соседние модули, ресурсы, зависимости и части, которые не имеют отношения к задаче. А если сделать так, чтобы крупные разделы можно было запускать отдельно — только с нужной функциональностью? Это даёт простой эффект: изменение быстрее видно, его не страшно переделать. Можно изолированно проверить несколько связанных экранов, а новому разработчику не нужно сначала разобраться во всём проекте, чтобы принести пользу в одном разделе. Если результат долго ждать, люди начинают гадать, но если его можно увидеть быстро — проверяют гипотезы. Экраны отдельно, но не приложения Но отдельный запуск разделов не значит, что каждый экран становится отдельным приложением. Другая частая ловушка мобильной разработки — разложить один экран на множество формальных ролей и файлов. В итоге логика оказывается размазана так, что для изменения одной кнопки нужно пройти весь ритуал: понять, где живёт событие, кто передаёт его дальше и в каком из слоёв лежит нужное состояние. Для многих экранов достаточно пяти вещей: View — то, что видит пользователь. Model — состояние экрана: загрузка, данные, ошибка, выбранный элемент. Input — с чем экран открывается. Output — что он возвращает, когда закончил работу. Builder — место, где собираются зависимости.

Спустя 13 лет я всё‑таки опубликовал своё первое приложение. Без малейшего навыка программирования

Идея о создании какого‑либо приложения засела в моей голове еще с 2013 года, после того как я купил данную книгу. Она дала старт паразитирующей мысли в голове, что создавать приложения — это то, чем бы я хотел заниматься. Автор этой книги рассказывает, как придумывает приложения, работает из любой точки мира, зарабатывает миллионы и живет свою лучшую жизнь. Вдохновения оказалось недостаточно, и навыка программирования у меня так и не появилось. А без него на тот момент создать приложение было нереализуемо. С тех пор уже прошло около тринадцати лет. Гештальт так и висел незакрытым, пока не появились нейросети. Что было до Знакомство с нейронками началось, как и у большинства — с генерации картинок в Midjourney и тому подобное. Потом был GPT, через него я писал всякого рода плагины для Obsidian, для личного использования. Как пример, библиотека по прочитанным книгам:

чатах Telegram распространяется стикер в 269 байт, который приводит к вылету приложения

чатах Telegram распространяется стикер размером в 269 байт, который приводит к вылету мобильного и десктопного приложения. Внутри стикера спрятана звезда с параметром в 10³⁸ точек. Клиент Telegram пытается её отрисовать, но это приводит к сбою в работе и закрытию приложения (технический обзор инцидента). Проблема вызвана специально созданным вредоносным стикером Lottie. Стикер содержит красную звезду, конфигурация формы которой включает чрезвычайно большое значение: layers[0].shapes[0].pt.k = 10e38. Это значение принимается серверами Telegram как допустимое/безопасное содержимое стикера. Однако при рендеринге стикера клиентом рендерер интерпретирует это значение как количество точек/лучей звезды. В результате клиент пытается обработать астрономически большое количество геометрических элементов (10^38), исчерпывая ресурсы рендерера и вызывая сбой клиента Telegram. Важное отличие заключается в том, что вредоносный стикер проходит серверную валидацию, но вызывает состояние отказа в обслуживании во время рендеринга на стороне клиента. Поскольку поражённый контент хранится в истории группы, открытие группы заставляет клиента загрузить и отрендерить вредоносный стикер, что приводит к немедленному сбою. Это фактически делает поражённую группу недоступной из клиента. Если такую же нагрузку можно доставить в произвольные группы, проблема потенциально может быть использована как DoS-атака на стороне клиента против групп Telegram.

VK Видео проведет трансляцию Rustore Mobile Gamedev Conf 2026

ноября VK Видео проведет трансляцию ежегодной конференции наших партнеров RuStore Mobile GameDev Conf 2026. Это крупнейшая в России конференция для мобильной игровой индустрии и премия для лучших игр и приложений года. В прямом эфире будут: выступления представителей ведущих игровых студий кейсы продвижения, монетизации и развития мобильных приложений обзоры ключевых изменений в индустрии и трендов, аналитика рынка вручение Премии RuStore 2026

Apple выпустила руководства по адаптации приложений для складного iPhone Duo

Apple опубликовала серию гайдов для разработчиков о подготовке приложений к складному iPhone Duo. Подборка включает в себя шесть видеороликов и новый раздел Human Interface Guidelines. В них компания рассказывает, как приложения должны работать на двух дисплеях, обходить сгиб экрана, менять расположение элементов управления и поддерживать несколько окон. Существующие приложения будут работать на iPhone Duo без пересборки, но степень их адаптации зависит от версии SDK. Сборка с iOS 27 оставит поля на внутреннем и наружном дисплеях, а SDK iOS 27.1 позволит занять всю доступную площадь и автоматически перестроит стандартные панели навигации. Один из главных советов от команды Apple — не создавать отдельный интерфейс для каждого положения смартфона. Приложение должно реагировать на доступное пространство, а не название устройства или его ориентацию. Для этого рекомендуют опираться на классы размеров, геометрию сцены, безопасные области и системные контейнеры SwiftUI и UIKit. В некоторых положения iPhone Duo верхние и нижние панели становятся вертикальными и перемещаются к краю экрана. Благодаря этому система сохраняет больше места по высоте и оставляет кнопки в зоне досягаемости большого пальца.

Anthropic раскрыла сеть из дейтинговых приложений с ИИ‑персонажами, работающими на Claude

Anthropic раскрыла детали масштабной мошеннической сети (проект получил кодовое имя GTG-15001) из дейтинг‑приложений, построенной на базе нескольких ИИ-систем. Студия из Китая развернула более 20 мобильных приложений для знакомств, где 75% всех «мэтчей» создавались не людьми, а ИИ‑персонажами, работающими на базе Claude. «Разработчики этой сети использовали Claude для масштабирования деятельности, поддерживая непрерывное общение от лица тысяч различных персонажей. Реальные люди и модели других провайдеров обеспечивали выполнение узкоспециализированных задач: трансляцию живого видео, реальные ответные действия, быстрые подсказки для отправки сообщений в одно касание (с функцией автодополнения) и обработку изображений», — пояснили в Anthropic. Фактически это был гибридный людской и ИИ-конвейер из нескольких компонентов и слоёв управления. Например, за две недели апреля 2026 года в рамках развития этого проекта только Claude сгенерировал более 4,7 тыс. уникальных женских персонажей и создал около 2,36 млн сообщений как минимум с 25 тыс. пользователями. Один ИИ‑профиль в среднем общался с пятью разными пользователями. Промпты в проекте запрещали ИИ-персонажам признаваться в том, что они автоматизированы. Также ИИ нужно было всегда уклоняться от любых просьб с предоставлением видео или фото. Для наполнения живым контентом в проекте были задействованы фрилансеры, которые составляли около четверти профилей. Эти реальные люди также по указанию организаторов проходили нужные проверки на «подлинность» у обычных пользователей в приложениях GTG-15001, которые ИИ не может имитировать. Например, если нужно было организовать живой видеозвонок с пользователем и оставить реальный отзыв в соцсетях. Причём фрилансеры не выполняли все задания самостоятельно. Дополнительные ИИ-модели подсказывали людям три варианта нужных ответов на выбор, отдельно занимались оценкой привлекательности фотографий, а также генерировали привлекательные аватары для поддельных персонажей. Проект после активного развития с помощью ИИ перешёл на монетизацию через внутренние кредиты, которые настоящие пользователи покупали за реальные деньги. Работникам-фрилансерам в этом мошенничестве платили за каждое сообщение, видеозвонок и подписку в соцсетях. Примечательно, что команда разработчиков этого проекта готовилась к проверкам от магазинов разных платформ. В мобильных приложениях проекта был секретный режим, который активировался только во время ревью в App Store или Play Store, а после одобрения отключался. Также встроенный браузер для платежей в приложениях перенаправлял средства сторонним процессингам. Например, эту функцию разработчики удалённо отключали на время проверки в магазинах приложений. В Anthropic заявили что подобная масштабная схема получилось очень экономичной для разработчиков, которым не нужно было нанимать сотню операторов, так как Claude поддерживал тысячи диалогов одновременно. Фактически в этом проекте настоящие люди подключались только для верификации и заверения настоящих пользователей с деньгами, что этот проект реальный. Такой способ развития проекта позволил снизить маржинальную стоимость каждого нового поддельного персонажа и позволил масштабировать проект до десятков тысяч пользователей без необходимости увеличения команд для поддержки приложений. В итоге Anthropic заблокировала аккаунты