Uso de capa de hardware en vista personalizada onDraw

Así que estoy tratando de entender cómo puedo utilizar correctamente la aceleración de hardware (cuando esté disponible) en una View personalizada que se anima persistentemente. Esta es la premisa básica de mi onDraw() :

 canvas.drawColor(mBackgroundColor); for (Layer layer : mLayers) { canvas.save(); canvas.translate(layer.x, layer.y); //Draw that number of images in a grid, offset by -1 for (int i = -1; i < layer.xCount - 1; i++) { for (int j = -1; j < layer.yCount - 1; j++) { canvas.drawBitmap(layer.bitmap, layer.w * i, layer.h * j, null); } } //If the layer's x has moved past its width, reset back to a seamless position layer.x += ((difference * layer.xSpeed) / 1000f); float xOverlap = layer.x % layer.w; if (xOverlap > 0) { layer.x = xOverlap; } //If the layer's y has moved past its height, reset back to a seamless position layer.y += ((difference * layer.ySpeed) / 1000f); float yOverlap = layer.y % layer.h; if (yOverlap > 0) { layer.y = yOverlap; } canvas.restore(); } //Redraw the view ViewCompat.postInvalidateOnAnimation(this); 

Estoy habilitando capas de hardware en onAttachedToWindow() y desactivándolas en onDetachedFromWindow() , pero estoy tratando de entender si realmente lo estoy usando. Esencialmente, el bucle i/j que llama drawBitmap() nunca cambia; Lo único que cambia es la traducción de Canvas . ¿Es el Bitmap guardado automáticamente en la GPU como una textura detrás de las escenas, o hay algo que necesito hacer manualmente para hacerlo?

¿En qué vista (s) está configurando View.LAYER_TYPE_HARDWARE exactamente? Si está configurando una capa de hardware en la vista que contiene el código de dibujo mostrado anteriormente, está haciendo que el sistema haga mucho más trabajo de lo necesario. Dado que sólo dibuja mapas de bits, no necesita hacer nada aquí. Si llama a Canvas.drawBitmap() el framework almacenará en caché la textura resultante de OpenGL en su nombre.

Sin embargo, podría optimizar su código un poco más. En lugar de llamar a drawBitmap() , puede usar vistas secundarias. Si mueve a estos niños utilizando los métodos offset*() (o setX() / setY() ), el framework aplicará otras optimizaciones para evitar llamar de nuevo a los métodos draw() .

En general, las capas de hardware deben establecerse en vistas que son costosas de dibujar y cuyo contenido no cambiará a menudo (así que prácticamente lo contrario de lo que estás haciendo 🙂

Puedes usar el Tracer de Android para OpenGL ES para ver si tu vista emite comandos de OpenGL.

Desde developer.android.com

Tracer es una herramienta para analizar OpenGL para sistemas embebidos (ES) en su aplicación Android. La herramienta le permite capturar comandos de OpenGL ES y imágenes marco a fotograma para ayudarle a entender cómo se ejecutan los comandos gráficos.

También hay un tutorial sobre Android Performance Study de Romain Guy que describe su uso casi paso a paso.

  • ¿Lista de animaciones de la transición de la visión de androide?
  • Android Imageview rellena el ancho de la pantalla
  • Android: programaticamente setId es da una advertencia Esperado recurso de tipo id
  • Guardar el estado de WebView y restaurar en ANDROID
  • Android - ¿Cómo pasar la cookie para cargar url con webview?
  • ¿Qué es android: layout_marginStart
  • Configuración de la posición de la vista en el nivel 7 de la API mediante programación
  • ViewPager dentro de CoordinatorLayout cubre otras vistas en API> = 21
  • Animación de Android - Estado de vista inicial
  • Elemento compartido animación entre RecyclerView elemento y CollapsingToolbar dentro de la misma actividad
  • ¿Cómo aplicar una transparencia (enfoque?) Al pulsar cualquier elemento (como lo hace Google)?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.