60fps en el desarrollo móvil: qué es, cómo funciona y su impacto en el rendimiento

Qué es 60fps

60fps (60 fotogramas por segundo, frames per second) es una medida de la frecuencia de cambio de fotogramas en la que la pantalla actualiza la imagen 60 veces cada segundo. El ojo humano deja de distinguir fotogramas discretos aproximadamente a 50–60 Hz debido al efecto de persistencia de la visión, lo que hace que 60fps sea un umbral natural de fluidez para la mayoría de los usuarios.

Cada fotograma a 60fps tiene un presupuesto de tiempo fijo de 16.67 ms. Este presupuesto incluye todo: desde el procesamiento de la entrada del usuario hasta el renderizado y la salida en pantalla. Si cualquier operación — física, animación, renderizado de una escena compleja — supera este límite, la frecuencia de fotogramas cae a 30fps o menos, lo que se percibe visualmente como tartamudeo.

En el desarrollo móvil, 60fps fue durante mucho tiempo el límite debido a limitaciones de hardware: la mayoría de las pantallas antes de 2017 funcionaban a 60 Hz. Con la aparición de pantallas de 90 Hz y 120 Hz, 60fps se convirtió en el estándar mínimo, no en el objetivo superior. Sin embargo, para aplicaciones de UI, vídeo y la mayoría de los juegos casuales, 60fps sigue siendo el indicador objetivo de rendimiento.

Por qué 60 fotogramas por segundo

60 Hz es la frecuencia de la corriente alterna en las redes eléctricas de EE. UU. y Japón, que históricamente determinó la frecuencia de actualización de los primeros estándares de televisión NTSC. El estándar PAL usaba 50 Hz debido a la red europea de 50 Hz. Esta inercia histórica pasó a los monitores de ordenador y posteriormente a las pantallas móviles.

Fisiología de la visión y persistencia

El efecto de persistencia es una propiedad de la visión humana que retiene una imagen en la retina durante aproximadamente 30–50 ms después de que el estímulo desaparece. A 60fps, un nuevo fotograma llega cada 16.7 ms — antes de que desaparezca el rastro persistente del anterior, creando la ilusión de movimiento continuo. Estudios de la Universidad de Cardiff (2023) muestran que los pilotos de combate pueden distinguir un fotograma individual a 220 Hz, pero para el usuario medio, la diferencia entre 60 y 120 Hz es mucho menos perceptible que entre 30 y 60 Hz.

Estándares de la industria

Apple estableció 60fps como estándar para iOS en 2007 con el primer iPhone y lo mantuvo hasta el iPhone 13 Pro (2021). Android siguió históricamente el mismo estándar, aunque los primeros dispositivos con 90 Hz (OnePlus 7 Pro, 2019) y 120 Hz (Razer Phone, 2017) aparecieron antes. Hoy en día, 60fps es el umbral mínimo para superar la revisión en App Store y Google Play para aplicaciones con animación, aunque los requisitos formales no están documentados.

Cómo medir y controlar el FPS

La medición de FPS es el primer paso de la optimización. Sin métricas objetivas, es imposible determinar dónde se pierde rendimiento. Las plataformas móviles proporcionan herramientas de perfilado integradas y APIs de software para medir la frecuencia de fotogramas en tiempo real.

Herramientas de perfilado

Android Studio Profiler y Xcode Instruments son las herramientas principales para analizar FPS. Android Profiler muestra GPU Render Time, Frame Rate y Jank (número de fotogramas perdidos). Xcode Instruments incluye la plantilla Core Animation, que muestra la frecuencia de fotogramas, el tiempo de renderizado y el número de draw calls. Para motores de juegos, Unity Profiler y Unreal Insights proporcionan desgloses detallados del tiempo por módulo.

// Android — medición de FPS mediante FrameMetrics
window.addOnFrameMetricsAvailableListener(
    { _, frameMetrics ->
        val duration = frameMetrics[FrameMetrics.TOTAL_DURATION]
        val fps = 1000f / (duration / 1_000_000f)
        Log.d("FPS", "Frame duration: ${duration / 1_000_000} ms, FPS: $fps")
    },
    Handler(Looper.getMainLooper())
)

Limitación programática de FPS

CADisplayLink en iOS y Choreographer en Android son mecanismos del sistema que sincronizan el renderizado con la frecuencia de actualización de la pantalla. CADisplayLink llama a un método con cada nuevo fotograma, pasando un timestamp para el cálculo del retardo. Choreographer en Android hace lo mismo pero admite callbacks para diferentes fases del fotograma: entrada, animación, recorrido, renderizado. El desarrollador puede suscribirse a Choreographer.FrameCallback y medir el tiempo entre fotogramas.

Optimización para unos 60fps estables

60fps estables significa que ningún fotograma supera el presupuesto de 16.7 ms. Incluso un fotograma largo por segundo crea un tartamudeo notable. La optimización se divide en tres niveles: CPU, GPU y memoria. Cada uno de ellos puede convertirse en un cuello de botella.

Optimización de CPU: Layout y Measure

El pase de layout es uno de los principales consumidores de tiempo de CPU en Android e iOS. Jerarquías complejas de View, ConstraintLayouts anidados y drawables pesados crean cadenas largas de measure y layout. Para aplicaciones de UI, usa una jerarquía plana de View (profundidad de no más de 3–4 niveles), reemplaza los RecyclerViews anidados por ConcatAdapter, y para listas en iOS — usa compositional layout con prefetching.

Optimización de GPU: Overdraw y Draw Calls

Overdraw es el renderizado repetido de los mismos píxeles. Cada capa de View, fondo o imagen bajo un elemento transparente aumenta el número de operaciones de píxeles. En Android, usa Debug GPU Overdraw en Developer Options; en iOS — Xcode Debug View Hierarchy. Reduce el overdraw eliminando fondos innecesarios y usando banderas opacas: en Android — @drawable con android:opaque, en iOS — isOpaque = true para UIKit.View.

Los draw calls son el número de comandos de renderizado enviados a la GPU. Las GPUs móviles modernas manejan 200–400 draw calls por fotograma a 60fps. Superar este número causa caídas de rendimiento. Combina sprites en atlas de texturas, usa batching y evita el renderizado individual de cada elemento mediante un draw call separado.

Memoria y recolección de basura

Los congelamientos por GC son una de las principales causas de FPS inestable en aplicaciones JVM y Kotlin. La recolección de basura en Android puede tomar hasta 30–50 ms, causando que se salten 2–3 fotogramas consecutivos. Evita asignaciones en bucles de animación, usa pools de objetos y preasigna memoria. En iOS, el problema es menos crítico debido a ARC, pero los ciclos de retención y los desbordamientos del autorelease pool también crean microtartamudeos.

Para los juegos, 60fps no es solo un estándar sino una ventaja competitiva. Estudios de Newzoo (2024) muestran que los juegos con FPS inestable por debajo de 60 reciben un 40% más de reseñas negativas en Google Play. Unity y Unreal Engine proporcionan perfiladores integrados para monitorear el tiempo de renderizado: en Unity es Frame Debugger, en Unreal — GPU Visualizer, que muestran el tiempo exacto de cada draw call y shader. Los 60fps estables son especialmente importantes para juegos de acción, donde cada fotograma perdido puede costarle al usuario la superación de un nivel.

Más allá de 60fps y altas frecuencias

Las pantallas de 90 Hz y 120 Hz están cambiando el listón de rendimiento objetivo. Para aplicaciones que funcionan en dispositivos ProMotion, el FPS objetivo puede ser 120, y el presupuesto de fotograma se reduce a 8.3 ms. Esto requiere un código dos veces más eficiente, especialmente en draw calls y renderizado GPU.

La ventaja de las altas frecuencias no es solo la fluidez: 120fps reduce el input lag perceptible en 8–10 ms, lo que es crítico para juegos y aplicaciones interactivas. Sin embargo, la diferencia entre 60 y 120fps requiere un enfoque individual: para aplicaciones de UI (desplazamiento, animaciones), 90fps puede ser un compromiso óptimo entre fluidez y consumo de energía, ya que renderizar 120 fotogramas por segundo consume un 30–40% más de energía que 60.

Apple proporciona una API para seleccionar la frecuencia preferida: preferredFramesPerSecond en CADisplayLink. Android antes de la API 30 no daba control directo sobre la frecuencia, pero a partir de Android 12, el desarrollador puede establecer el RefreshRate a través de WindowManager, solicitando 60, 90 o 120 Hz según el tipo de contenido.