2012-06-27 9 views
7

Estoy renderizando objetos a través de OpenGL, y obtuve un buen framerate suave de 60 fps en la mayoría de las situaciones. HASTA HAGO algo pesado en un hilo de fondo, como ir a buscar cosas desde una API REST, procesarla y agregar objetos al gráfico (cosas de baja prioridad, me preocupa más la fluidez de UI). El procesador hará una pausa por un período muy largo, de hasta 1 segundo (aproximadamente, mientras se ejecuta el hilo de fondo), y luego continuará como si nada hubiera sucedido. Me di cuenta de esto porque una animación se inicia al mismo tiempo, y se atasca durante este período. El hilo de fondo está configurado con la prioridad mínima, y ​​la recolección de basura puede tomar hasta 100-200ms, pero no el segundo completo. Cuando establezco un punto de depuración en cualquier lugar de la tarea en segundo plano, la representación continúa sin problemas, sin retrasos.Android: Renderizaciones de OpenGL cuando se ejecuta una tarea de fondo pesado

¿Es posible que mi hilo de fondo pesado muera de hambre en el hilo de OpenGL? Si es así, ¿qué puedo hacer?

+0

¿En qué GPU estás probando? –

+0

Parece sospechosamente como [este rastro de rendimiento] (http://stackoverflow.com/q/9612959/1262542) ... –

+0

No sé qué GPU, es un Galaxy Nexus. Voy a probarlo en el simulador cuando llegue a casa. – manmal

Respuesta

1

¡Por supuesto! Una GPU necesita ser alimentada con datos, y eso es hecho por la CPU. Entonces, si algo en el sistema se cuela, como E/S o procesamiento de CPU, entonces la GPU no se puede alimentar. Por ejemplo, la animación se realiza tradicionalmente en la CPU. Esta es la razón por la que obtienes muchos juegos en la PC obteniendo mayores velocidades de cuadro con los mismos chips gráficos pero con diferentes CPUs.

También estoy de acuerdo en que la creación de perfiles es una muy buena idea. Si puede, sugeriría crear perfiles para asegurarse de que en realidad es la llamada REST, o si la llamada REST es una de muchas cosas

Una cosa que noté sobre el procesamiento REST, y esto me sucedió a mí. Dado que REST a veces procesa muchas cadenas, y si no usas StringBuilder, puedes terminar disparando una gran cantidad de recolección de basura. Sin embargo, no parece que estés obteniendo esto.

+1

Entonces, ¿por qué debería el planificador tener permitido poner un hilo de fondo antes de alimentar el tubo de la GPU? No tiene ningún sentido. Si es así, ¿por qué los ingenieros de Google no le dieron más prioridad a ese hilo de representación? – manmal

+0

A veces Java tiene que liberar RAM, especialmente en el caso de una llamada REST, que tiende a hacer un poco de procesamiento de cadena –

+1

Ya mencioné que la recolección de basura no puede ser el problema aquí, porque las pausas de GC no son tan largo. Son más como 100-200ms al máximo, no 1.5 segundos. – manmal

Cuestiones relacionadas