Рассказываю, как повторить.

1. Подготовьте компьютер

Установите Codex, Claude Code, Cursor или Antigravity и запустите инструмент локально на компьютере.

Для работы с телевизором понадобится ADB (Android Debug Bridge). Его тоже можно попросить установить и настроить через ИИ.

2. Включите отладку на телевизоре

Подключите телевизор и компьютер к одной домашней сети.

Откройте настройки, найдите раздел «Об устройстве» и семь раз нажмите на номер сборки. Затем включите отладку в меню разработчика.

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

3. Узнайте IP-адрес и модель

IP-адрес находится в настройках сети, а модель — в разделе «Об устройстве».

Можно просто сфотографировать экран и отправить снимок ИИ. Пусть сам разбирается.

4. Дайте ИИ задание

Я использовал примерно такой запрос:

У меня Android TV, модель [МОДЕЛЬ], IP-адрес [IP].
Подключись к телевизору через ADB и оптимизируй его работу.
Сначала сохрани текущие настройки и подготовь возможность отката. Проверь установленные приложения и покажи, какие можно безопасно отключить. Ничего не удаляй без моего подтверждения.
Обязательно сохрани YouTube, Lampa.
Проверь проблему со сбросом времени и возможность настройки YouTube через локальный сетевой обход, если он подходит моей сети.
Сделай лёгкий главный экран в стиле Apple TV.
Работай со штатной прошивкой, не сбрасывай телевизор, сохрани аккаунты и данные приложений.
Измерь свободную оперативную память до и после оптимизации. После всех изменений перезагрузи телевизор, проверь работу приложений и подготовь отчёт.

5. Подтвердите подключение

Когда телевизор запросит разрешение на ADB-отладку, подтвердите его.

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

Что получилось на моём Xiaomi MiTV-MSSP1

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

Состояние Свободная RAM До очистки≈437 МБ После очистки и перезагрузки≈949 МБ С новым интерфейсом после перезагрузки≈940 МБ

Итог: +503 МБ свободной оперативной памяти. Это в 2,15 раза больше, чем было изначально!

Причём новый лаунчер практически не повлиял на результат: после его установки и перезагрузки свободной памяти осталось около 940 МБ.

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

И всё это без перепрошивки, сброса настроек и потери данных.

Бонус: как настроил YouTube без платных сервисов

На Xiaomi с Android TV 9 установил ByeByeDPI 1.8.2 из официального репозитория автора.

Для моего телевизора подошёл APK armeabi-v7a, поскольку Android на нём 32-разрядный.

Настройки выставил следующие:

• Режим: КВN — локальная обработка трафика непосредственно на телевизоре.

• Фильтр приложений: белый список, только стандартный YouTube для Android TV — com.google.android.youtube.tv.

• DNS: 8.8.8.8.

• IPv6 внутри обхода: выключен.

• Автозапуск при включении телевизора: включён.

• Использование своей командной строки: включено.

В аргументы вписал:

-I0.0.0.0 -o1 -a1 -r-6+se -T3

Нажал «Подключить» и подтвердил системный запрос Android.

Результат: YouTube начал загружать обложки и рекомендации, два тестовых ролика успешно воспроизводились. Автозапуск после перезагрузки тоже проверил — работает.

Но есть нюанс: это настройки, которые сработали именно на моей сети. У другого провайдера может потребоваться подбор стратегии.

Важно: если включить Happ или WireGuard, подключение ByeByeDPI будет заменено. Android обычно позволяет использовать только одно активное КВN-подключение одновременно.

P. S. Для тех, кто вообще не хочет платить за ИИ

Необязательно покупать подписку на Codex, Claude или Cursor.

Можно воспользоваться бесплатным доступом к DeepSeek и попросить его подготовить ADB-команды для очистки системы, настройки лаунчера и установки ByeByeDPI.

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

Главное — правильно сформулировать задачу и не разрешать ИИ бездумно удалять системные приложения. Сначала список на проверку, затем отключение с возможностью отката.

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

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

Однажды я выкатил небольшое обновление и стал ждать обычного редеплоя. Но GeoConquest не поднялась: сервер пытался загрузить в память уже накопленные территории и не справился. К тому моменту игроки захватили больше 13 миллионов гексов.

Важно: никто не захватил 13 миллионов одним махом. Это был общий результат игры, который серверу предстояло восстановить после перезапуска. Данные не пропали, у меня были резервные копии, но игра оказалась недоступна — и я не знал, когда удастся вернуть её в строй.

Я тогда временно поднял лимит heap, чтобы сервер хотя бы запустился. Но мысль «добавить ещё памяти» не могла быть решением навсегда. Позже даже попытка поднять лимит с 4 до 5 ГБ не помогла. А в голове крутилась совсем простая мысль: что будет, когда игроки захватят ещё миллион гексов? Неужели придётся покупать сервер подороже?

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

Две разные нагрузки

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

У GeoConquest оказалось две отдельные проблемы роста. Первая — сам мир: игроки захватывают всё больше гексов, и их нужно хранить и показывать на карте. Вторая — количество одновременных действий: игроки двигаются, оставляют следы, запрашивают карту. Оптимизация одной нагрузки не решает другую.
И ещё третья проблема - скорость расчёта захватов стала уже неприлично долгой.

Я отдельно занялся частыми запросами, следами и отображением игроков. По графику загрузки процессорных ядер стало видно, что среднее напряжение немного снизилось и пиков стало меньше. Но вопрос оставался: что будет, если кто-то захватит ещё миллион гексов — или даже сто миллионов?

А одна из первых попыток разобраться с памятью дала обратный результат: прогрев сервера занял аж 4 минуты 40 секунд, а расход RAM вырос ещё примерно на 0,8 ГБ. Тут уже стало понятно, что нужно менять сам подход к данным.

Карта перестала помещаться в одну копию

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

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

После переключения карта стала загружаться из базы, а в памяти оставались только недавно просмотренные фрагменты. Потребление памяти основным процессом снизилось примерно с 3,7 до 1,86 ГБ. Перезапуск, который раньше занимал до 170 секунд, на этом этапе сократился примерно до 72. При ручной проверке карты около 84% запросов обслуживались из памяти, среднее время ответа было около 45 миллисекунд.

Но это была проверка прокруткой карты, почти без одновременных захватов. Она не доказывала, что игра уже выдержит тысячи игроков. Зато стало ясно, что у нас появился запас для следующего шага. Я смог выдохнуть и уже не бояться нависающей угрозы.

Миллионы гексов — сотни тысяч записей

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

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

В итоге 15,64 миллиона игровых гексов удалось представить примерно 354 тысячами укрупнённых записей — примерно в 44 раза меньше. На одном из промежуточных этапов все территории занимали около 36,5 МБ RAM. После финального этапа весь игровой процесс использовал около 645 МБ оперативной памяти; собственно JavaScript heap — около 292 МБ.
Для моего сервера с 8 ГБ RAM запас более чем достаточный.

Тогда же перезапуск удалось сократить до 18–20 секунд. Но это улучшение оказалось не вполне устойчивым: после следующего выката один из перезапусков снова занял около 170 секунд. Так что я не хочу выдавать промежуточную цифру за гарантированную скорость после всех изменений.

Последний шаг был уже про ожидание захвата. В локальной эмуляции тяжёлого реалистичного примера расчёт сократился с 9,36 до 1,45 секунды — примерно в 6,5 раза. На проде к расчёту добавляется запись результата, поэтому это не обещание, что каждый захват теперь занимает ровно столько же. Но это хороший признак: расчёт наконец тоже начал ускоряться, а не только занимать меньше памяти. В реальности скорость захватов увеличилась в десятки раз, потому что записывать в БД владельцев гексов теперь тоже быстрее (из-за сворачивания через h3).

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

Попробуйте GeoConquest в Google Play или через браузер.

В деревне Тайна закрыли обучение в 8-м и 9-м классах, а школьников перевели в Астафьевку, примерно в 12 км. Но четыре восьмиклассника продолжают ходить в родную школу. Несколько учителей занимаются с ними бесплатно, несмотря на запрет от руководства — отчасти тайно (вероятно, уже не тайно — после выхода материала).

«С нас потребовали объяснительную записку. А я не отрицаю: уроки веду для этих восьмиклассников. Мне, как говорится, за державу обидно»,

— говорит учитель географии.

Жителей в деревне — чуть больше 100, почти все подписались под обращением губернатору и президенту о сохранении школы. Но оптимизация неостановима.

Казалось бы, в чем проблема, если есть автобус? Жители отвечают, что дороги плохие, зимой их не чистят, при -25 автобус замерзает, а дети много пропускают, тогда как рядом есть родная школа. Отношение учителей к приезжим хуже, а детям сложно влиться в коллектив. Да и школа — последний оплот, без неё населенный пункт вымрет. Местные жители говорят:

«За 300 лет она сколько пережила, эта деревня? И гражданскую, и голод, и Великую Отечественную войну. Но оптимизации не выдержит».

А родители 8-классников комментируют:

«Мы бунтари. Называют нас „неугодные, бунтари“ и направляют все органы, чтобы наказать».

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

В Астафьевской школе детям записали 119 пропусков. На родителей составили протоколы по статье 5.35 КоАП и передали материалы комиссии по делам несовершеннолетних.