What is the best way to set background for some view? For example 2 variants of backround:
So which of variants would be better, nine-patch or drawable xml resource?
A drawable resource is a general concept for a graphic that can be drawn to the screen and which you can retrieve with APIs such as getDrawable(int) or apply to another XML resource with attributes such as android:drawable and android:icon . There are several different types of drawables: Bitmap File.
Drawable myImage = ResourcesCompat. getDrawable(res, R. drawable. my_image, null);
A StateListDrawable is a Drawable object that uses a different image to represent the same object, depending on what state the object is in. For example, a Button can exist in one of several states (pressed, focused on, hovered over, or none of these).
My guess is, NinePatch
would be slightly faster in most cases. Here's what I found.
GradientDrawable
(the one used for rects in xml) uses this code to call through to Canvas
which in turn uses native call leading to SkCanvas
, SkDraw
and eventually SkScan
and SkBlitter
.
On the other hand, NinePatch
's draw() has almost zero Java code before the native call to NinePatch.cpp
which shortly calls NinePatchImpl.cpp
-- NinePatch_draw()
--- and that's where the magic is. The code there iterates over the marked regions and after a number of subsequent calls draws stuff using roughly the same logic in SkDraw
(only drawRect()
instead of drawPath()
) but in the end it's the same SkScan
and SkBlitter
that do the work.
All that code is pretty hard to wrap my head around instantly, but what did catch my eye is that GradientDrawable
makes two calls to the whole native stack if it has both background and stroke (look here), while in any scenario a NinePatch
only makes one.
So, without actually measuring times for both approaches I get a feeling in most cases NinePatch
wins the race: if we [awfully] roughly assume that native call stacks for drawRect()
and drawPath()
use pretty much the same logic and [another awful simplification] the parameter sets that get passed around there and are created by NinePatch
and GradientDrawable
don't affect complexity of the methods that much, then NinePatch
turns out to be roughly 2 times faster than GradientDrawable
with filling and outline. Well, provided you use a regular, 9-section 9-Patch (i.e. don't shred you 9-Patch by an awful lot of markers, making the iteration over the pieces overly effort-expensive).
Anyone who'll stumble upon this and knows more on the subject (and/or better at estimating complexity of native code), please, correct me if I'm wrong.
PS yeah, I know this is not much of a straight answer
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With