At this part, I will describe how android work with your activity to draw on the screen.
- What is Render performance?
Android system is always run with 60 frames per second (Android redraw your activity each 16.666 ms/frame).
If you create too many things to do for render, the system will be drop frames and screen will be laggy or janky. It happens regularly when a user dragging a list view or trying to type in some data.
This is what the user easy to see and complain about.
2. Rendering pipeline.
Rendering pipeline is broken up into two key sections CPU and GPU. It works together in order to draw images on the screen.
CPU: The most common performance problem comes from a part of your view hierarchy having to be measured, torn down and rebuilt.
- This generally comes in two problematic flavors, either the display lists are being rebuilt too many times during a frame
- You’re spending too much time invalidating too much of your view hierarchy and needlessly redrawing.
Both cause taxing CPU overhead in refreshing display lists and other related cache GPU resources.
GPU: GPU performance problem only happens when we waste GPU processing time to coloring in pixels that end up getting colored in later by something else.
3. How does your activity get drawn to the screen?
CPU will collect and send all of polygon, text or image to GPU. (This is done through a common API on Android known as OpenGL ES) and then GPU will draw it on screen.
Everything need to be drawn to the screen will be converted to polygons and textures on the CPU, then pass to GPU. OpenGL ES API allows you to upload content to the GPU and then leave it there. It means if you change activity which has the same button which only has a difference in the name. Android only send a command that “Hey GPU I need a button like before which only have a new name”. CPU doesn’t calculate too much and CPU is ready for the new button.
NOTE: Optimizing for rendering performance means getting as much data on the GPU as fast as possible and leave it there without modifying it for as long as possible.
4. Overdraw
Overdraw is a term used to describe how many times a pixel on the screen has been redrawn in a single frame. Example: you have a layout like an image below. The lower layer still uses GPU to render, use the time to draw but it is invisible with the user.
With the modern layouts, it’s easy to fall into a trap where we’re stacking views to give us this beautiful, transcendent design. But also creating the same overdraw problem.
To maximize performance, you need to minimize overdraw. You can Enable Overdraw in Developer Options to check your application. Below is an example and explanation of the color on the Android when you enable the Overdraw setting.
Solution: The canvas class gives us some special methods that you can use to tell the Android framework which parts of the canvas are hidden and don’t need to be drawn. canvas.clipRect(…) and canvas.quickReject(). The canvas.quickReject(…) method allows you to check whether a specified rectangle or path would lie completely outside the currently visible regions after all transformations have been applied. You can read more at: ( https://google-developer-training.github.io/android-developer-advanced-course-concepts/unit-5-advanced-graphics-and-views/lesson-11-canvas/11-1-c-the-canvas-class/11-1-c-the-canvas-class.html)