Как оптимизировать игру в unity под андроид
Перейти к содержимому

Как оптимизировать игру в unity под андроид

  • автор:

Практическое руководство по оптимизации для мобильных

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

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

Мобильные устройства не созданы одинаковыми

Информация здесь предполагает аппаратное обеспечение на уровне чипсета Apple A4, который используется в оригинальных iPad, iPhone 3GS и третьем поколении iPod Touch. Из Android предполагается устройство подобное Nexus One, или большинства устройств, работающих на Android 2.3 Gingerbread. В основном, эти устройства были выпущены в начале 2010 года. Эти устройства старее, медленнее современных, но так как они составляют большую часть рынка, их также следует поддерживать.

Есть очень быстрые и очень медленные телефоны. Вычислительные мощности мобильных устройств растут с потрясающей скоростью. Для нового поколения мобильной GPU, быть в 5 раз быстрее своего предшественника — обычное дело. Скорость мобильных устройств уже сравнима со скоростью ПК.

Для обзора технических характеристик мобильных устройств от Apple, см. Hardware.

Если вы хотите разрабатывать под мобильные устройсва, которые станут известными в будущем, или эксклюзивные high end устройства прямо сейчас, вы можете это сделать. См. Мобильные устройства будущего.

Очень низкая производительность (например, iPhone 3G или первое и второе поколение iPod touches) требует особого внимания к оптимизации. В противном случае могут возникнуть проблемы когда покупатели, не обновившие устройства, будут покупать ваши приложения. Если же вы делаете бесплатное приложение, можно не беспокоится о поддержке старых устройств.

Оптимизацию не следует считать последней стадией разработки проекта

Британский ученый Майкл А. Джексон часто цитируется своими Правилами оптимизации программ:

_Первое правило оптимизации программы: не делаете ее. Второе правило оптимизации программы (только для экспертов!): не делайте ее пока что.

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

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

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

Оптимизация: Не только для программистов

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

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

Планируйте игру так, чтобы во время исполнения она работала “плавно”.

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

  • Практические методы для оптимизации рендеринга
  • Практические методы для оптимизации скриптинга и геймплея

Профилируйте на ранней стадии и почаще

Профилирование важно, потому что оно поможет выяснить, какие оптимизации действительно приведут к большому приросту производительности, а какие являются пустой тратой вашего времени. Благодаря тому, что рендеринг обрабатывается на отдельном чипе (GPU), отрисовка одного кадра занимает в два раза меньше времени (только GPU, а не CPU + GPU). Это означает, что если CPU замедляет работу, оптимизация ваших шейдеров вообще не повысит частоту кадров, и если GPU замедляет работу, не помогут оптимизация физики и скриптов.

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

Внутренний Профайлер

Профайлер в Unity в основном используется при ориентации на iOS и Android. См. Руководство по профайлеру для основных инструкций по его использованию.

Внутренний Профайлер

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

См. Встроенный Профайлер для подробной информации о том, как это работает и включается.

Профайлер с рендерингом

Профайлер без рендеринга

Оптимизации рендеринга

В данном разделе представлены технические особенности оптимизации рендеринга. В нём показано, как запечь освещение для лучшей производительности и как разработчики игры Shadowgun делали высококонтрастные текстуры с запечённым освещением для создания красивой картинки. Если вы ищете основную информацию об оптимизации игр под мобильные платформы, ознакомьтесь со страницей Графические Методы.

Будьте изобретательны!

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

Перед тем как нырнуть под капот

  • Встроенные шейдеры
    • Изучите исходный код встроенных шейдеров. Зачастую, когда вам требуется создать новый отличающийся по функционалу шейдер, можно просто взять и соединить части пары уже готовых шейдеров.
    • Из каждого поверхностного шейдера генерируется CG шейдер, который затем полностью компилируется. Если вы добавите #pragma debug в начало вашего поверхностного шейдера, то когда вы откроете скомпилированный шейдер через инспектор, вы увидите промежуточный CG код. Это удобно для изучения того, как на самом деле рассчитывается определённая часть шейдера, и, кроме того, это может быть удобно для переноса в CG шейдер некоторых аспектов, желаемых от поверхностного шейдера.
    • Большое количество вспомогательного кода для шейдеров включено в каждый шейдер. Обычно этот код не используется, но иногда вы можете встретить шейдеры, в которых вызываются такие методы как WorldReflectionVector, которые нигде не определены. В Unity есть несколько встроенных включаемых в шейдеры файлов, котоые содержат эти вспомогательные методы. Чтобы найти определённую функцию, вам придётся поискать по всем включаемым файлам.
    • Эти файлы являются значительной частью внутренней структуры, используемой Unity для упрощения процесса написания шейдеров. Файлы предоставляют такие вещи как тени в реальном времени, различные типы освещения, карты освещения, поддержка нескольких платформ.

    Shadowgun в деталях

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

    На странице Графические методы мы использовали золотую статую в Shadowgun в качестве примера отличной оптимизации. Вместо использования карты нормалей для придания их статуи чёткого силуэта, они просто запекли в текстуру детали освещения. Мы расскажем вам как и почему вам следует использовать аналогичный подход в вашей игре.

    Шейдерный код для расчётов в реальном времени против запечённой золотой статуи

    // This is the pixel shader code for drawing normal-mapped // specular highlights on static lightmapped geometry // 5 texture reads, lots of instructions SurfaceOutput o; fixed4 tex = tex2D(_MainTex, IN.uv_MainTex); fixed4 c = tex * _Color; o.Albedo = c.rgb; o.Gloss = tex.a; o.Specular = _Shininess; o.Normal = UnpackNormal(tex2D(_BumpMap, IN.uv_BumpMap)); float3 worldRefl = WorldReflectionVector (IN, o.Normal); fixed4 reflcol = texCUBE (_Cube, worldRefl); reflcol *= tex.a; o.Emission = reflcol.rgb * _ReflectColor.rgb; o.Alpha = reflcol.a * _ReflectColor.a; fixed atten = LIGHT_ATTENUATION(IN); fixed4 c = 0; half3 specColor; fixed4 lmtex = tex2D(unity_Lightmap, IN.lmap.xy); fixed4 lmIndTex = tex2D(unity_LightmapInd, IN.lmap.xy); const float3x3 unity_DirBasis = float3x3( float3( 0.81649658, 0.0, 0.57735028), float3(-0.40824830, 0.70710679, 0.57735027), float3(-0.40824829, -0.70710678, 0.57735026) ); half3 lm = DecodeLightmap (lmtex); half3 scalePerBasisVector = DecodeLightmap (lmIndTex); half3 normalInRnmBasis = saturate (mul (unity_DirBasis, o.Normal)); lm *= dot (normalInRnmBasis, scalePerBasisVector); return half4(lm, 1); 
    // This is the pixel shader code for lighting which is // baked into the texture // 2 texture reads, very few instructions fixed4 c = tex2D (_MainTex, i.uv.xy); c.xyz += texCUBE(_EnvTex,i.refl) * _ReflectionColor * c.a; return c; 

    Отрисовка в тексель

    Свет, просчитываемый в реальном времени, несомненно выдаёт картинку лучшего качества, но увеличение производительности от запечённой версии просто колоссально. Так как это делается? Для этой цели был создан инструмент редактора под названием Render to Texel. Учтите, что вам потребуется Unity PPRO для использования этого инструмента. Таков процесс запекания освещения в текстуру:

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

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

    • Создайте нечто классно выглядящее не беспокоясь о производительности.
    • Используйте инструменты на подобие встроенного в Unity lightmapper’а, а также расширения редактора, на подобие Render to Texel и Sprite Packer для запекания освещения во что-то, что очень просто рендерить.
      • Создание собственных инструментов — лучший способ это сделать, вы можете создать идеальный инструмент, специально для решения любой проблемы в вашей игре.
    • Создайте шейдеры и скрипты для модуляции ваших запечёных результатов для придания им в некотором роде “блеска”; привлекающий внимание эффект, для создания иллюзии динамического освещения.

    Концепция частоты освещения

    Так же как низкие и высокие частоты в аудио-дорожке, у изображений тоже есть высокочастотные и низкочастотные компоненты, и лучше всего по-разному их обрабатывать при отрисовке, аналогично тому, как для стерео используются сабвуферы и динамики верхних частот для полноты звучания. Один из способов визуализации разных частот изображения — использовать фильтр “High Pass” в Photoshop. Filters->Other->High Pass. Если вы ранее работали с аудио, название High Pass покажется вам знакомым. По сути он отсекает все частоты ниже X, параметра, который вы передаёте фильтру. Для изображений, Gaussian Blur (размытие по Гауссу) — эквивалент Low Pass.

    Это применимо к графике реального времени, т.к. частота — хороший способ разделения вещей для их обработки. Например, в простой среде с картами освещения, итоговая картинка получается совмещением карты освещения, которая является низкой частотой, с текстурами, которые являются высокой частотой. В Shadowgun, низкочастотный свет быстро применяется к персонажам с помощью зондов освещения (light probes), высокочастотный свет подделывается с помощью простого bumpmapped шейдера с произвольным направлением света.

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

    Частота на практике: декомпозиция Shadowgun

    • Верхняя строка
      • Ultra-Low-Frequency Specular Vertex Light (Dynamic) | High Frequency Alpha Channel | Low Frequency Lightmap | High Frequency Albedo
    • Средняя строка
      • Specular Vertex Light * Alpha | High Frequency Additive Details | Lightmap * Color Channel
    • Низ
      • Итоговая сумма

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

    Lightmapped with Virtual Gloss Per-Vertex Additive
    Shader "MADFINGER/Environment/Virtual Gloss Per-Vertex Additive (Supports Lightmap)" < Properties < _MainTex ("Base (RGB) Gloss (A)", 2D) = "white" <>//_MainTexMipBias ("Base Sharpness", Range (-10, 10)) = 0.0 _SpecOffset ("Specular Offset from Camera", Vector) = (1, 10, 2, 0) _SpecRange ("Specular Range", Float) = 20 _SpecColor ("Specular Color", Color) = (0.5, 0.5, 0.5, 1) _Shininess ("Shininess", Range (0.01, 1)) = 0.078125 _ScrollingSpeed("Scrolling speed", Vector) = (0,0,0,0) > SubShader < Tags < "RenderType"="Opaque" "LightMode"="ForwardBase">LOD 100 CGINCLUDE #include "UnityCG.cginc" sampler2D _MainTex; float4 _MainTex_ST; samplerCUBE _ReflTex; #ifndef LIGHTMAP_OFF float4 unity_LightmapST; sampler2D unity_Lightmap; #endif //float _MainTexMipBias; float3 _SpecOffset; float _SpecRange; float3 _SpecColor; float _Shininess; float4 _ScrollingSpeed; struct v2f < float4 pos : SV_POSITION; float2 uv : TEXCOORD0; #ifndef LIGHTMAP_OFF float2 lmap : TEXCOORD1; #endif fixed3 spec : TEXCOORD2; >; v2f vert (appdata_full v) < v2f o; o.pos = mul(UNITY_MATRIX_MVP, v.vertex); o.uv = v.texcoord + frac(_ScrollingSpeed * _Time.y); float3 viewNormal = mul((float3x3)UNITY_MATRIX_MV, v.normal); float4 viewPos = mul(UNITY_MATRIX_MV, v.vertex); float3 viewDir = float3(0,0,1); float3 viewLightPos = _SpecOffset * float3(1,1,-1); float3 dirToLight = viewPos.xyz - viewLightPos; float3 h = (viewDir + normalize(-dirToLight)) * 0.5; float atten = 1.0 - saturate(length(dirToLight) / _SpecRange); o.spec = _SpecColor * pow(saturate(dot(viewNormal, normalize(h))), _Shininess * 128) * 2 * atten; #ifndef LIGHTMAP_OFF o.lmap = v.texcoord1.xy * unity_LightmapST.xy + unity_LightmapST.zw; #endif return o; >ENDCG Pass < CGPROGRAM #pragma vertex vert #pragma fragment frag fixed4 frag (v2f i) : SV_Target < fixed4 c = tex2D (_MainTex, i.uv); fixed3 spec = i.spec.rgb * c.a; #if 1 c.rgb += spec; #else c.rgb = c.rgb + spec - c.rgb * spec; #endif #ifndef LIGHTMAP_OFF fixed3 lm = DecodeLightmap (tex2D(unity_Lightmap, i.lmap)); c.rgb *= lm; #endif return c; >ENDCG > > > 

    Lightprobes with Virtual Gloss Per-Vertex Additive

    Shader "MADFINGER/Environment/Lightprobes with VirtualGloss Per-Vertex Additive" < Properties < _MainTex ("Base (RGB) Gloss (A)", 2D) = "white" <>_SpecOffset ("Specular Offset from Camera", Vector) = (1, 10, 2, 0) _SpecRange ("Specular Range", Float) = 20 _SpecColor ("Specular Color", Color) = (1, 1, 1, 1) _Shininess ("Shininess", Range (0.01, 1)) = 0.078125 _SHLightingScale("LightProbe influence scale",float) = 1 > SubShader < Tags < "RenderType"="Opaque" "LightMode"="ForwardBase">LOD 100 CGINCLUDE #pragma multi_compile LIGHTMAP_OFF LIGHTMAP_ON #include "UnityCG.cginc" sampler2D _MainTex; float4 _MainTex_ST; float3 _SpecOffset; float _SpecRange; float3 _SpecColor; float _Shininess; float _SHLightingScale; struct v2f < float4 pos : SV_POSITION; float2 uv : TEXCOORD0; float3 refl : TEXCOORD1; fixed3 spec : TEXCOORD3; fixed3 SHLighting: TEXCOORD4; >; v2f vert (appdata_full v) < v2f o; o.pos = mul(UNITY_MATRIX_MVP, v.vertex); o.uv = v.texcoord; float3 worldNormal = mul((float3x3)_Object2World, v.normal); float3 viewNormal = mul((float3x3)UNITY_MATRIX_MV, v.normal); float4 viewPos = mul(UNITY_MATRIX_MV, v.vertex); float3 viewDir = float3(0,0,1); float3 viewLightPos = _SpecOffset * float3(1,1,-1); float3 dirToLight = viewPos.xyz - viewLightPos; float3 h = (viewDir + normalize(-dirToLight)) * 0.5; float atten = 1.0 - saturate(length(dirToLight) / _SpecRange); o.spec = _SpecColor * pow(saturate(dot(viewNormal, normalize(h))), _Shininess * 128) * 2 * atten; o.SHLighting = ShadeSH9(float4(worldNormal,1)) * _SHLightingScale; return o; >ENDCG Pass < CGPROGRAM #pragma vertex vert #pragma fragment frag fixed4 frag (v2f i) : SV_Target < fixed4 c = tex2D (_MainTex, i.uv); c.rgb *= i.SHLighting; c.rgb += i.spec.rgb * c.a; return c; >ENDCG > > > 

    Рекомендации

    GPU оптимизация: альфа-тестирование

    Некоторые GPU, в частности те, что можно найти в мобильных устройствах, испытывают большую нагрузку при альфа-тестировании (или при использовании операций discard и clip в пиксельных шейдерах). Вам следует заменить альфа-тест шейдеры шейдерами с альфа-смешиванием, если это возможно. Там где альфа-тестирования не избежать, вам следует свести к минимуму общее количество альфа-тестируемых пикселей.

    Сжатие текстур для iOS

    Некоторые изображения, особенно, если используется PVR сжатие текстур для iOS/Android, подвержены визуальным артефактам в альфа-канале. В таких случаях, вам может потребоваться подстройка параметров сжатия PVRT прямо в вашем ПО для работы с изображениями. Вы можете сделать это установив PVR export plugin или с помощью PVRTexTool от компании Imagination Tech, создателей формата PVRTC. Итоговое сжатое изображение с расширением .pvr будет напрямую импортировано редактором Unity и указанные параметры сжатия будут сохранены. Если текстура, сжатая в PVRTC не выдаёт желаемого визуального качества, или вам требуются особенно чёткие изображения (а они могут понадобиться, особенно для GUI), тогда вам следует задуматься об использовании 16-битных текстур вместо 32-битных. Сделав это, вы снизите требования к пропускной способности памяти и к количеству свободного места на диске на половину.

    Сжатие текстур для Android

    Все устройства под управлением Android с поддержкой OpenGL ES 2.0 также поддерживают формат сжатия ETC1; потому приветствуется использование формата текстур ETC1 в качестве предпочитаемого там где это возможно.

    Если целиться на определённую архитектуру графического оборудования, такую как Nvidia Tegra или Qualcomm Snapdragon, имеет смысл использовать проприетарные форматы сжатия, доступные для этих архитектур. Android Market также позволяет фильтровать на основе поддерживаемого формата сжатия текстур, то есть дистрибутив (.apk) с, например, текстурами, сжатыми в DXT, может быть не допущен к скачиванию на устройство, которое не поддерживает такое сжатие.

    Упражнение (только для Unity PRO)

    Скачайте Render to Texel. Запеките освещение на вашей модели. Прогоните результат через High Pass фильтр в Photoshop. Измените шейдер “Mobile/Cubemapped” shader, включённый в пакет Render to Texel так, чтобы недостающие детали низкочастотного освещения были заменены на вершинный свет.

    Practical guide to optimization for mobiles

    This guide is for developers new to mobile game development, who are probably feeling overwhelmed and are either planning and prototyping a new mobile game or porting an existing project to run smoothly on a mobile device. This guide should also be useful as a reference for anyone making mobile games or browser games that target old PCs and netbooks.

    Optimization is a broad topic, and how you do it depends a lot on your game. Because of this, this guide is best read as an introduction or reference rather than a step-by-step guide that guarantees a smooth product.

    Мобильные устройства не созданы одинаковыми

    The information here assumes hardware around the level of the Apple A4 chipset, which is used on the original iPad, the iPhone 3GS, and the third generation iPod Touch. On the Android side, that would mean an Android phone such as the Nexus One, or most phones that run Android 2.3 Gingerbread. Most of these devices were released around early 2010. Out of the app-hungry market, these devices are the older, slower portion, but they should be supported because they represent a large portion of the market.

    The very low-end Apple mobile devices (such as the iPhone 3G) and the first and second generation iPod Touches are extremely limited, and even more care must be taken to optimize for them. However, there is some question as to whether consumers who have not upgraded their device will be buying apps at all. So, unless you are making a free app, it might not be worthwhile to support the old hardware.

    There are much slower and much faster phones out there, and the computational capability of mobile devices is increasing at an extraordinary rate. It’s not unheard of for a new generation of a mobile GPU to be five times faster than its predecessor. That’s incredibly fast when compared to the PC industry.

    Оптимизацию не следует считать последней стадией разработки проекта

    British computer scientist Michael A. Jackson is often quoted for his rules of program optimization:

    “The first rule of program optimization: don’t do it. The second rule of program optimization (for experts only!): don’t do it yet.”

    His rationale was that, considering how fast computers are and how quickly their speed is increasing, there is a good chance that, if you program something, it will run fast enough. Additionally, if you try to optimize too heavily, you might over-complicate things, limit yourself, or create bugs.

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

    Throughout this guide, we will try to point out situations where an optimization would help a lot, versus situations where it would just be frivolous.

    Optimization: not just for programmers

    Artists also need to know the limitations of the platform, and the methods that are used to get around them, so they can make creative choices that pay off without having to re-produce work.

    • More responsibility can fall on the artist if the game design calls for atmosphere and lighting to be drawn into Textures instead of being baked.
    • Whenever anything can be baked, artists can produce content for baking instead of real-time rendering. This allows them to ignore technical limitations and work freely.

    Design your game for a smooth runtime

    These two pages detail general trends in game performance, and explain how you can best design your game to be optimized or how you can intuitively figure out which things need to be optimized if you’ve already gone into production.

    • Практические методы для оптимизации рендеринга
    • Практические методы для оптимизации скриптинга и геймплея

    Профилируйте на ранней стадии и почаще

    Profiling is important because it helps you discern which optimizations will pay off with big performance increases and which ones are a waste of your time. Because of the way that rendering is handled on a separate chip (GPU), the time it takes to render a frame is not the time that the CPU takes plus the time that the GPU takes. Instead, it is the longer of the two.

    That means that if the CPU is slowing things down, optimizing your Shaders won’t increase the frame rate at all, and if the GPU is slowing things down, optimizing physics and scripts won’t help at all.

    Often, different parts of the game and different situations perform differently as well. This means one part of the game might cause 100 millisecond frames entirely due to a script, and another part of the game might cause the same slowdown but because of something that is being rendered. At the very least, you need to know where all the bottlenecks are if you’re going to optimize your game.

    Unity Profiler

    You can use the main Profiler in Unity when targeting iOS, Android or Tizen. See documentation on the Profiler for basic instructions on how to use it.

    Internal profilers

    Android and iOS both have a built-in internal profiler, which spews out text every 30 frames. It can help you figure out which aspects of your game are slowing things down (such as physics, scripts, or rendering), but it doesn’t go into much detail (for example, it can’t tell you which script or renderer is the culprit).

    • If the profiler indicates that most of your processing time is spent in rendering, see documentation on Rendering Optimizations
    • If the profiler indicates that most of your processing time is spent outside of rendering, see documentation on Scripting Optimizations

    See documentation on Internal profilers for information on how they work and how to turn them on.

    Table of contents

    • Практическое руководство по оптимизации мобильных — Графические Методы
    • Практическое руководство по оптимизации мобильных — Методы Скриптинга и Геймплея
    • Практическое руководство по оптимизации мобильных — Оптимизации Рендеринга
    • Практическое руководство по оптимизации мобильных — Оптимизация Скриптов

    Unity (C#) — Как оптимизировать Android игру под различные экраны?

    Есть ли какие-либо автоматические способы изменять размер фона/спрайтов под различные экраны или нужно делать в ручную? Если в ручную то как именно?

    Отслеживать
    задан 10 июн 2018 в 22:07
    57 10 10 бронзовых знаков

    1 ответ 1

    Сортировка: Сброс на вариант по умолчанию

    Если вы спрашиваете об объектах на игровой сцене, то самый простой вариант решения проблемы — поднимать камеру 🙂 т.е при старте рассчитывайте разрешение экрана и поднимайте камеру до уровня, когда всё будет помещаться.
    Чтобы не было каких-то «пустых» участков, можете расширить поле каким-то «затычками».

    Если вы говорите про интерфейс, то вам в помощь компонент CanvasScaler и настройка якорей (anchor). У Unity есть небольшой мануал на эту тему

    Отслеживать
    ответ дан 12 июн 2018 в 7:59
    5,128 1 1 золотой знак 11 11 серебряных знаков 17 17 бронзовых знаков
    Спасибо. Нужно было узнать и то, и то)
    13 июн 2018 в 17:19
    @Артём, если вопрос решён — пометьте ответ, как решающий) это закроет вопрос.
    13 июн 2018 в 17:57

    • android
    • c#
    • unity3d
      Важное на Мете
    Похожие

    Подписаться на ленту

    Лента вопроса

    Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

    Дизайн сайта / логотип © 2024 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2024.4.30.8466

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *