¿Qué debo usar para un mejor rendimiento, nueve parches o un recurso xml extraíble?

¿Cuál es la mejor manera de establecer el fondo para algunas vistas? Por ejemplo, 2 variantes de backround:

Fondo con el gradiente, las esquinas redondeadas y la frontera
Fondo con sólo un color y esquinas redondeadas

Entonces, ¿cuál de las variantes sería mejor, nueve parches o dibujable xml recurso?

Mi suposición es, NinePatch sería un poco más rápido en la mayoría de los casos. Esto es lo que encontré.

GradientDrawable (el utilizado para rects en xml) utiliza este código para llamar a través de Canvas que a su vez utiliza la llamada nativa que conduce a SkCanvas , SkDraw y eventualmente SkScan y SkBlitter .

Por otra parte, el draw () de NinePatch tiene código Java casi cero antes de la llamada nativa a NinePatch.cpp que en breve llama NinePatchImpl.cpp – NinePatch_draw() — y ahí es donde está la magia. El código allí itera sobre las regiones marcadas y después de un número de llamadas subsecuentes dibuja la materia usando aproximadamente la misma lógica en SkDraw (solamente drawRect() vez de drawPath() ) pero en el extremo es el mismo SkScan y SkBlitter que hacen el trabajo.

Todo ese código es bastante difícil de envolver mi cabeza al instante, pero lo que me llamó la atención es que GradientDrawable hace dos llamadas a toda la pila nativa si tiene fondo y trazo ( mira aquí ), mientras que en cualquier escenario un NinePatch sólo hace uno.

Por lo tanto, sin medir los tiempos realmente para ambos enfoques tengo la sensación de que en la mayoría de los casos NinePatch gana la carrera: si asumimos [terriblemente] que las pilas de llamadas nativas para drawRect() y drawPath() usan prácticamente la misma lógica y [another horrible Simplificación] los conjuntos de parámetros que se pasan por ahí y son creados por NinePatch y GradientDrawable no afectan a la complejidad de los métodos que mucho, entonces NinePatch resulta ser aproximadamente 2 veces más rápido que GradientDrawable con relleno y contorno. Bueno, siempre que use un 9-Patch regular de 9 secciones (es decir, no lo destruya 9-Patch por una gran cantidad de marcadores, haciendo la iteración sobre las piezas excesivamente costosas).

Cualquier persona que se tropiece con esto y sabe más sobre el tema (y / o mejor en la estimación de la complejidad del código nativo), por favor, me corrija si estoy equivocado.

PS sí, sé que esto no es mucho de una respuesta directa