Learn about Android Graphics & Animations from Google's Android UI Toolkit team
Why Stack Overflow recommends it
Stack Overflow users link it when answering Android questions about bitmap formats, memory use, the graphics and window architecture, and why animated views do not move their click targets.
Recommended by 4 people across 4 different months, 2011 to 2014.
What it is
A 2010 Devoxx talk by Android UI Toolkit engineers Romain Guy and Chet Haase covering the Android graphics architecture, bitmap formats and performance, drawing tools such as Paints and Shaders, and animation APIs. It includes demos, slides and code examples, plus a preview of what was coming in Gingerbread.
What people said
Recommends pumpkee · 2011-04 · Stack Overflow · on “Does displaying of Android 2D Graphics use EGL library?”
Check out this vid Learn about Android Graphics [this video] ! At 6:30 the graphics architecture is exdplained. I recommend watching the whole thing tough. Lots of useful information.
Recommends jtt · 2012-02 · Stack Overflow · on “Android OOM, memory is never released”
This is quite a topic that is kind of hard to tackle, specifically if you keep a reference to your Bitmaps, then you start overloading memory. This is because images are VERY heavy in terms of memory/VM. You should have a look at what Romain Guy says about graphics and Bitmaps and how to handle it. Here: [this video] [LINK] They are lengthy videos, but have lots of good information and some of this includes how to handle this with best practices.
Recommends Mark · 2013-02 · Stack Overflow · on “Android, fastest way to draw a bitmap to canvas”
please see this [LINK] blog post by Romain Guy. A video version is available here [this video] . Don't use ARGB_4444 anymore. It is deprecated. Each pixel is only allocated 4 bits per channel (hence the name). ARBG_8888 offers 16,777,216 colors instead of ARBG_4444's 4,096, but uses 4 bytes per pixel instead of 2. In Gingerbread, Android made ARGB_8888 the standard format for Surface [LINK] and increased memory allotment per process because of it. It is more efficient to set your Window's [LINK] and (assuming you are using streamlined SurfaceView [LINK] ) SurfaceHolder's format to RGBA_8888 [LINK] . This avoids format changes which are noticeably slower. Other tips include: Limit alpha compositin
Recommends Tooroop · 2013-10 · Stack Overflow · on “Android TextView: onClick after Moving TextView”
When you are doing animations the TextView is only visualy moved (the graphic rendering representation is only moved on the screen) but the real TextView object stays on the old position. You have to manually (programatically) move the TextView to the new position. Take a look at this presentation [this video] from Romain Guy and Chet Haase. Chet Haase is taking about this issue at the 42:00 min. Take a look at the whole presentation if you have time. They are talking about some really usefull things.
Cites Timo Ohr · 2011-01 · Stack Overflow · on “Draw high res animations with high frame rate on Android”
Probably won't help with performance, but if those bitmaps are resources you might want to consider using an AnimationDrawable . If not, try to extend Drawable and implement the Animatable interface. Views already have built-in support for animating drawables, no need to use a handler for that. One way to improve performance might be to match the bit-depth of the drawables to those of your current window. Romain Guy did a keynote on this and animations in general once: [this video]
Cites pierrotlefou · 2011-10 · Stack Overflow · on “Android GUI architecture - relation between Surface/view/window/canvas”
========================= UPDATE: After several days googling and experiments [LINK] , I have found the answers for most of those dumb questions. See the answers I submitted. ========= What is the responsibility of Android Window? Here are some questions: Is it responsible for collecting and dispatching the input? What is the relationship between the view and window? Same as the relationship between surface and window in DFB? What is the relationship between an activity and window? Will each Activity has a window? Is it possible to create a window from application ? And when it is necessary? Does Android support multi-window? EDIT: Add more questions: What is responsibilities of various clas
Cites 김준호 · 2013-05 · Stack Overflow · on “What is an Android window?”
[UPDATE] (Let me share what I've learned about Window after original answer) In one sentence, A Window is a rectangular area which has one view hierarchy . Colored rectangles in below image are windows. As you can see, there can be multiple windows in one screen, and WindowManager [LINK] manages them. Window list in current screen can be obtained via Hierarchy Viewer [LINK] , or adb shell dumpsys window . Window list in Hierarchy Viewer example : (Below is original answer) I had the same question, and I hope this could help you guys. According to Android Developer Documentation [LINK] , "Each activity is given a window in which to draw its user interface." and, Dianne Hackborn [LINK] , who i
Cites Vlad · 2014-04 · Stack Overflow · on “Placing an ImageView over a transparent SurfaceView”
I have a SurfaceView with a transparent background, on which i draw stuff, and on top of that i want an ImageView to be drawn. In order for the SurfaceView to be transparent i have to set surfaceView.setZOrderOnTop(true) , but the problem is that now, my surfaceview's canvas is drawn on top of the imageview, which makes sense because of setZOrderOnTop(true) . My question is, is there a way to achieve what i want? a SurfaceView with transparent background and an ImageView on top of it? Thanks, Vlad Edit: Ok so this isn't possible. See fadden's answer below, or [this video] for deeper understanding.