Мобільна оптимізація WebGL: кроки та підводні камені

1. Інший режим, а не менший десктопний GPU

Майже кожен мобільний GPU (Apple, Arm Mali, Qualcomm Adreno, Imagination PowerVR) використовує плиткове відкладене рендерингу (TBDR): екран розбивається на маленькі плитки, і геометрія та шейдинг кожної плитки повністю обробляються у швидкій пам'яті на чіпі перед одноразовим записом у основну пам'ять. Ось чому деякі звички, вироблені на десктопі, активно шкодять продуктивності на мобільних:

• Зчитування з framebuffer посеред кадру (наприклад, ручний depth pre-pass з подальшим повноекранним зчитуванням) змушує до раннього скидання плитки, що набагато дорожче на TBDR-апаратурі, ніж на десктопному рендерері з негайним режимом.
• Уніфікована пам'ять означає, що GPU і CPU ділять ту саму фізичну RAM — немає окремого бюджету VRAM, на який можна покластися, і великі текстури безпосередньо конкурують з рештою пам'яті сторінки.
• Немає запасу для стійкої частоти. Мобільні SoC розраховані на набагато нижчу термальну межу, ніж десктопний GPU з активним охолодженням — див. розділ 5.

2. Обмежте devicePixelRatio

Сучасний телефон повідомляє devicePixelRatio 2.6-3+. Рендеринг canvas WebGL з таким повним співвідношенням означає, що кожен фрагментний шейдер виконується приблизно в 9 разів частіше, ніж при 1x — заради покращення чіткості, яке ледь помітне на маленькому екрані, розташованому на відстані витягнутої руки.

const pixelRatio = Math.min(window.devicePixelRatio, 1.5); // 1.5-2 — хороше значення для мобільних за замовчуванням
renderer.setPixelRatio(pixelRatio);
renderer.setSize(window.innerWidth, window.innerHeight);

Для симуляцій, важких за fill-rate (системи частинок, симуляції рідин, будь-що з великими повноекранними проходами шейдерів), розгляньте ще агресивніший підхід: рендерити внутрішньо у частці від CSS-розміру і дозволити canvas масштабуватися через CSS, що коштує майже нічого порівняно з шейдингом кожного пікселя в нативному розширенні.

// Внутрішнє розширення рендеру 0.75x, масштабоване браузером через CSS
const renderScale = 0.75;
renderer.setSize(
  window.innerWidth * renderScale,
  window.innerHeight * renderScale,
  false // false = не чіпати розмір CSS, лише буфер малювання
);
renderer.domElement.style.width = '100%';
renderer.domElement.style.height = '100%';

3. Точність шейдера: уникайте переповнення highp

Кваліфікатори точності GLSL ES (lowp, mediump, highp) на мобільних — не просто рекомендації: багато мобільних GPU виконують математику фрагментного шейдера mediump на дійсно вужчих апаратних шляхах, ніж highp, а деякі старіші мобільні GPU взагалі не підтримують highp у фрагментному шейдері (специфікація дозволяє тихо переходити на mediump).

Найпоширеніший тихий баг, специфічний лише для мобільних: симуляція, що накопичує пройдений час в uniform-змінній mediump (або з відкатом від highp), через кілька хвилин починає показувати помітне тремтіння або смуги, коли накопичене значення перевищує точність mediump при такій величині — на десктопі з повною підтримкою highp все працює добре, і ламається лише на телефоні в руках ваших користувачів.

// Періодично скидайте uniform-змінні на основі часу замість вічного накопичення
const t = (performance.now() % 100000) / 1000; // обгортається кожні ~100с
material.uniforms.uTime.value = t;

4. Бюджети draw call і текстурної пам'яті

Орієнтовні, консервативні початкові бюджети для телефону середнього класу (Android 2-3-річної давності або старіший iPhone) порівняно з типовим десктопом:

• Групуйте геометрію / використовуйте InstancedMesh — об'єднання статичних мешів або інстансинг повторюваних об'єктів (частинки, дерева, комірки сітки) напряму скорочує draw call — найтісніший бюджет на мобільних.
• Стиснені текстури — постачайте текстури KTX2/Basis Universal (транскодовані в ASTC на сучасних мобільних GPU, ETC2 як відкат) замість сирих PNG/JPEG, декодованих у повний RGBA8 у пам'яті GPU; це саме по собі може скоротити VRAM текстур у 4-8 разів.
• Мипмапи завжди — зменшені текстури без мипмап сильно б'ють по пропускній здатності кешу текстур на мобільних; завжди генеруйте мипмапи для всього, що переглядається з різної відстані.

5. Термальний тротлінг

У телефона немає активного охолодження. Тривале високе навантаження на GPU нагріває SoC, доки термальне керування ОС не знизить частоту GPU (і часто CPU) — іноді на 30-50% нижче пікової — щоб залишитися в безпечних температурах. Це означає:

• Симуляція, що показує плавні 60fps у перші 30 секунд, може впасти до 35-40fps після 3-5 хвилин безперервної гри, без жодної зміни коду і без дій користувача.
• Тротлінг нелінійний і специфічний для пристрою — флагманський телефон з паровою камерою переносить набагато більше стійке навантаження, ніж бюджетний телефон у тонкому пластиковому корпусі, навіть за схожих пікових результатів бенчмарку.

// Мінімальний регулятор адаптивної якості
let quality = 1.0;
function animate(now) {
  const dt = (now - lastTime) / 1000;
  lastTime = now;
  if (dt > 1 / 45) quality = Math.max(0.5, quality - 0.02); // відстаємо → знижуємо
  else if (dt < 1 / 58) quality = Math.min(1.0, quality + 0.005); // є запас → повільно піднімаємо
  particleSystem.setActiveCount(Math.floor(maxParticles * quality));
  requestAnimationFrame(animate);
}

6. Тач-введення замість миші/клавіатури

Кожен десктоп-орієнтований патерн взаємодії потребує тач-дружного еквіваленту — немає hover, немає правого кліку, і часто взагалі немає клавіатури:

// Мінімальне відстеження відстані для щипка-масштабування
let lastPinchDist = null;
canvas.addEventListener('touchmove', (e) => {
  if (e.touches.length === 2) {
    const [a, b] = e.touches;
    const dist = Math.hypot(a.clientX - b.clientX, a.clientY - b.clientY);
    if (lastPinchDist !== null) {
      const delta = dist - lastPinchDist;
      camera.position.multiplyScalar(1 - delta * 0.003); // масштаб через зміну відстані
    }
    lastPinchDist = dist;
    e.preventDefault(); // зупиняє прокрутку/масштабування сторінки
  }
}, { passive: false });

canvas.addEventListener('touchend', () => { lastPinchDist = null; });

7. Тестування на реальних пристроях

Емульований «мобільний» режим Chrome DevTools (панель пристрою) лише симулює розмір екрана й тач-події — шейдери все одно виконуються на драйвері десктопного GPU, що не дає корисного сигналу про реальну продуктивність мобільного GPU, відкати точності чи термальну поведінку.

1. Підключіть Android-телефон через USB з увімкненим USB-налагодженням, потім відкрийте chrome://inspect на десктопі — він перелічує відкриті вкладки телефону з живим посиланням «inspect» у справжні DevTools, що працюють проти реального пристрою.
2. На iOS підключіть iPhone/iPad через кабель, увімкніть Web Inspector у Налаштування → Safari → Додатково, потім відкрийте меню Develop у Safari на Mac, щоб приєднатися до сторінки, що виконується на пристрої.
3. Тестуйте на найстарішому пристрої, з якого ваша аналітика показує значущий трафік, а не на власному найновішому телефоні — результат 60fps на актуальному флагмані нічого не говорить про 3-річні Android-пристрої середнього класу, які зазвичай є справжнім довгим хвостом.