- Litmus test your appYour app has a performance problem if it does not instantly respond -to a user action, stutters, or makes the user wait at any point. -This lesson introduces the most basic performance test for your app, -and a process for iteratively finding and fixing performance problems.
- - -
- Litmus test your appTo find out whether your app has performance issues, you don't need fancy - tools.
- -Do the following:
- -
- Approach performance problems methodicallyIf these hands-on tests didn't reveal any performance problems,
- -If you gathered any notes related to performance, then performance is a problem for your - app.
- -Once you have subjectively established that your app could benefit from performance tuning, we - have two recommendations for an objective and systematic approach to finding and fixing - performance problems faster.
- - - -Android and Android Studio come with many - - performance profiling tools - to help you - identify performance problems and track down where they are in your code. And after you have - changed your code, run the tools again to measure the impact of your change. Compare results to - make sure you've fixed the right problem, and find out whether you need to - make additional performance improvements.
- -To learn more about why you should use tools, see - Tools Not Rules.
- - - -When optimizing your application, you must be able to measure its state, make changes, and - then evaluate the performance differences of these changes. Thus, the Performance Tuning - Lifecycle is built around the concept of "What you can measure, you can - optimize".
- -The Performance Tuning Lifecycle (Figure 1), consists of three phases: - gather information, gain insight, and take action.
- -
- - Figure 1. The Performance Tuning Lifecycle. -
-
-
- Gather Information.
- Use the
-
- performance profiling tools
- to capture data
- about your app. Since most tools are specialized, you may need to run several tools.
-
- Gain Insight.
- Take the time to understand what your gathered data means for your app.
- You may need to go through several iterations of gathering information and gaining insight to
- pinpoint what the problem (or problems!) is.
- 
- Take Action.
- Take all the information and all the insights, and determine and evaluate
- different ways to solve your problem. Taking action can take different forms, and what you decide
- to do depends on your situation and context, which may also include coding resources, budgets,
- and deadlines.
And once you've taken action, verify that your changes had the desired - outcome:
- -
-
- Gather a second set of data.
-
- Compare it to your original data.
-
- Make more changes...
- and repeat this process until your app consistently responds smoothly to all user actions, never
- stutters, and never makes the user wait. On all target devices.
To learn more, see - The Performance Tuning Lifecycle.
- - - - - - -
- Start improving performance
- - Everything you need to know about improving your app’s performance.
- - - - Test you app's performance -This series of lessons teaches you how to improve the performance of your - Android applications using a workflow of gathering data, analyzing the data, and - taking action based on your insights.
At the heart of your app is the hierarchy of views that makes up the user interface and the - visual experience of users. With feature-rich apps, this hierarchy grows large and complex and - can become a source of performance problems. The most likely symptom you will see is a generic - general slowness of the app, especially when rendering complex views to the screen.
- -Simplifying or rearranging the view hierarchy of your app can improve performance, especially - on lower-end devices and earlier versions of Android. As an added benefit, your app will become - easier to maintain overall.
- -Analyzing the view hierarchy is an example of using several tools together to pinpoint and fix - performance problems. It is also an example of eliminating another inefficiency first, so that - your data becomes more precise.
- - -
- Analyze the view hierarchyIf you have not done so already, reduce overdraw by removing unnecessary backgrounds. This - will remove a common source of overdraw that is not related to your view hierarchy. See - - Visualizing and Reducing Overdraw.
- -
- Possible optimizationsHierarchy Viewer can help identify these specific issues that are directly related to the - structure of the view hierarchy.
- -Minimizing these issues can improve performance, especially on older devices. For your own - benefit, these simplifications will make your code easier to maintain and profile in the - future.
- -
- Remove extraneous viewsRemove views that do not contribute to the final image.
- -
To identify views that do not contribute to the final image on the screen:
- -
- - Figure 1. Views 2 and 3 are fully obscured and can be safely removed. -
-Eliminate from your code the views that are completely covered, never displayed, or outside - the screen.
- -
- Simplify nested layoutsSimplify nested layouts that trigger multiple layout passes.
- -Some layout containers, such a RelativeLayout, require two layout passes in order to finalize - the positions of their child views. As a result, their children also require two layout passes. - When you nest these types of layout containers, the number of layout passes increases - exponentially with each level of the hierarchy.
- -For example, a view inside a grid view inside a list view inside a relative layout could get - laid out 8 times(!) as shown in Figure 2.
- -
- - Figure 2. Example of layout pass multiplication. -
-Watch out for the following containers and conditions:
- -measureWithLargestChild layout weightUsing any of these containers as
- -can result in noticeable performance penalties.
- -For more information, see - Double Layout Taxation.
- - - - -Consider whether you can achieve the same layout using a container configuration that does not - result in these exponential numbers of layout passes. For example:
- -In addition, you can apply all the techniques mentioned in this document to simplify the view - hierarchy.
- -For more tips, see - - Optimizing Layout Hierarchies.
- - - -
- Reduce the number of viewsIf your user interface has many simple views, you may be able to combine some of them without - diminishing the user experience, as shown in Figure 3.
- - -
- - Figure 3. Example of combining views. -
-Both the changes below may affect how you present information to the user and will include - design trade-offs. Remember that performance is more important than anything else for your - app's success, and opt for simplicity wherever you can.
- -
- Flatten the view hierarchyDoes your view hierarchy have parts that look like the nested arrangement on the left of - Figure 4?
- -
- - Figure 4. This deep view hierarchy can be flattened to improve performance. -
-Flatten the view hierarchy by replacing nested linear layouts with relative layouts wherever - possible. See - - Optimizing Layout Hierarchies.
- - - -Watch a screencast which shows how to apply all these techniques to simplify a view - hierarchy. See - - Optimizing Layouts with Hierarchy Viewer.
- -Use the - Lint tool - on your layout files to search for possible view hierarchy optimizations. See - - Optimizing Layout Hierarchies: Use Lint.
- diff --git a/docs/html/training/app/rendering/index.jd b/docs/html/training/app/rendering/index.jd index 19d274b8af9a4..733131e0aff15 100644 --- a/docs/html/training/app/rendering/index.jd +++ b/docs/html/training/app/rendering/index.jd @@ -1,92 +1,4 @@ -page.title=Rendering Performance +page.title=Optimizing Rendering Performance page.tags=render -page.article=true + @jd:body - -The most common performance problems are related to how your app draws, and how that - eventually appears on the user's screen.
- -Finding rendering problems is an iterative process of using hands-on testing to - identify problem spots, harness tools to discover the underlying cause, and improve your code. - See also - Test Your App's Performance.
- -Optimizing rendering performance means to remove unnecessary work, simplify structures - and processes, manage bitmaps properly, and be mindful of the natural constraints imposed by the - hardware and the Android system.
- -The result of great rendering performance is instantly INVISIBLE to your users. That - is, your app runs so fast and smoothly, that users fully focus on their task, not on your - app's UI and performance.
- -You can test for and improve common rendering problems by using the tools and strategies - recommended in this course.
- -Every time your app draws a pixel on the screen, it takes time. Every time your app draws a - pixel that has already been drawn, it wastes time. Drawing a pixel more than once per screen - refresh is called overdraw, and it's a common problem affecting - the performance of modern applications. To be efficient, every time your app refreshes the - screen, it should draw every changed pixel only once.
- -For example, an app might draw a stack of 52 overlapping cards, with only the last card fully - visible. Completely drawing the 51 cards that are underneath and partially covered, is an example - of overdraw.
- -
- - Figure 1. Example of card stack with potential overdraw. -
-Watch the - Understanding Overdraw - video - for a detailed introduction, and see the rest of this page for more on finding and fixing - overdraw.
- - - -Note: Reducing overdraw can save significant GPU resources and greatly - decrease the time it takes to draw a frame. Reducing overdraw may have a significant impact, if it - is the biggest performance issue your app has; or it may have no noticeable impact, if you are on - a fast device, or if your app has other, much bigger performance issues.
- - -
- Test for overdrawYou can visualize overdraw using color tinting on your device with the - Debug GPU Overdraw tool. -
- -To turn on Debug GPU Overdraw on your mobile device:
- -See - Debug GPU Overdraw - for a full tutorial, or try the Debug - GPU Overdraw Codelab.
- - -
- Interpret the Debug GPU Overdraw outputAs a general rule, if at any given point your app is drawing something that the user does not - see, don't draw it. More specifically, Debug GPU Overdraw highlights can guide - you to the following issues:
- -
- Eliminate unnecessary backgroundsSearch your code for android:background, and for each
- background, determine whether it's needed and visible on the screen.
Removing unnecessary backgrounds is a quick way of improving rendering performance. An - unnecessary background may never visible, because it's completely covered by - everything else the app is drawing in that view. For example, a parent's default - background that is overdrawn by the children's custom backgrounds.
- -You can remove backgrounds by removing the android:background? line of code in an view.
Before:
- -- <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" - xmlns:tools="http://schemas.android.com/tools" - android:id="@+id/activity_chatum_latinum_container" - android:layout_width="match_parent" - android:layout_height="match_parent" - android:background="@android:color/white" <===== Background - tools:context=".MainActivity" - tools:ignore="MergeRootFrame" /> -- -
After:
- -- <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" - xmlns:tools="http://schemas.android.com/tools" - android:id="@+id/activity_chatum_latinum_container" - android:layout_width="match_parent" - android:layout_height="match_parent" - tools:context=".MainActivity" - tools:ignore="MergeRootFrame" /> -- - -
- Clip generouslyFind areas that are drawn unnecessarily and clip generously.
- -When you are using custom views, you may be redrawing areas of the screen that have not - changed.
- -For each update, even if only a portion of a custom view has changed, the entire view must be - rebuilt. This is most common for views that use Canvas for drawing. For example, if you draw a - small circle in a corner of the view, the whole view gets rebuilt.
- -The Android system does to a good job at culling views that are 100% invisible or overlapped - by another view, but cannot eliminate more complex views, for example those that include - text transparency or rounded corners.
- -Before you draw a custom view, test whether it's visible at all. If it is - visible, only draw the portions that the user sees.
- -See - Overdraw, ClipRect, QuickReject.
- - diff --git a/docs/html/training/app/rendering/profile-gpu.jd b/docs/html/training/app/rendering/profile-gpu.jd deleted file mode 100644 index 56a65fb5fefe5..0000000000000 --- a/docs/html/training/app/rendering/profile-gpu.jd +++ /dev/null @@ -1,356 +0,0 @@ -page.title=Improve GPU Rendering Performance -meta.tags="android, performance", "app" -page.tags="app" -page.article=true -@jd:body - - - - -The most common issues that can make your app slow are related to the process of drawing on - the screen. Android provides the - Profile GPU Rendering - tool on your - device to analyze the rendering performance of your app. The Profile GPU Rendering tool draws a - graph on the screen to show the rendering performance of each window.
- -This page introduces how to use the Profile GPU Rendering tool and interpret its graphs, and, - depending on your findings, suggests what to try next to optimize your app's - performance.
- -For a quick overview of the tool and how to use it, watch the embedded - Profile GPU Rendering video. - Then profile your app and analyze the results following the steps - below.
- - - - - -
- Graph the rendering performance of your appTurn on Profile GPU Rendering:
- -You are going to see a chart of multi-colored bars on your screen, similar to Figure 1. Each - vertical bar represents one frame of rendering for that activity, that is, one redrawing of the - window on the screen.
- -
- - Figure 1. Profile GPU Rendering graph. -
-The height and coloring of a bar, as shown in Figure 1, indicate how fast each frame was - created, and how much time different phases of the rendering process required.
- -The green line marks 16 milliseconds. If a bar crosses that line, it took more than 16 - milliseconds to create and draw that window on the screen. If this happens often, or if any bars - cross the line by a lot, users can probably notice a delay or stutter while using the app.
- - - -
- Interpret the Profile GPU Rendering graphLook at the colored segments of the bars that cross the green 16 millisecond line, in - particular any segments that are much taller than their neighbors.
- -If you see that
- -
- Advanced AnalysisTo improve the performance of your app, you may need to take one, some, or all of the actions - on this page. You may need to use more additional tools or investigate other sources of performance - issues.
- -For example:
- -
- Blue: Updating views takes too longThe blue Update segment of the bar represents the time used by the CPU to create and update - all the views for this rendering of the screen. This is part of a processing sequence called the - invalidation pipeline. To learn more about the invalidation pipeline, see - Views, Invalidations, and Performance - and Double Layout Taxation.
- - - - - -If this blue bar segment is tall, it can indicate that your app does too much work creating - and updating views, or is updating too many views or views that are too complex.
- -
- Blue: Speed up view updatingReduce overdraw.
- -Simplify complex view hierarchies.
- -Optimize onDraw() for custom views.
- -
- Purple: Transferring resources is too slowThe purple segment of the bar represents the time the GPU Driver spent transferring resources - from the CPU to the GPU. Moving a significant amount of data between processors takes time, and - the larger the data to be moved, the longer the delay in execution. - See CPU, GPU, and your Android.
- - - - -
- Purple: Reduce bitmap sizes
- Red: Submitting commands to the GPU is too slowThe red segment of the bar represents the time spent by Android's 2D renderer issuing commands - to OpenGL to draw and redraw display lists. The height of the red bar is proportional to how much - time was spent submitting commands to the GPU for the total of all views that need to be redrawn. - Display lists that do more complex operations contribute more time to the overall size of the red - bar. The size of the red bar is an indicator of the complexity of the display - lists' operations. The number of display lists does not directly - correlate to the size of the red bar.
- -
- Red: Reduce the number of commandsReduce overdraw.
- -Limit alpha blending.
- -
- Orange: The CPU is waiting for the GPUThe orange segment of the bar represents the length of time that the CPU is waiting for the - GPU to finish its work. After transferring data to the GPU, the CPU waits for the GPU to - acknowledge receipt. If this bar segment gets tall, it means the app is doing too much complex - work on the GPU, and the GPU is unable to keep up with the data flow from the CPU.
- -
- Give less work to the GPUSimplify complex view hierarchies.
- -Optimize drawing.
- -The following checklist summarizes common rendering problems and solutions. -For each problem, learn how users are affected, how to diagnose, and how to -approach fixing it. Use the linked resources for details on the suggested solutions.
- - - -What the user sees:
- The most likely symptom is a generic general slowness of screen
- rendering, as well as stuttering animations.
Use this tool:
-
- Debug GPU Overdraw
What you see:
- Red-colored views indicate multiple layers of unnecessary drawing.
Problem:
- Your app redraws the same pixels multiple times, resulting in
- overdraw.
Solution:
- If you are drawing pixels on the screen that the user never sees, you might
- be able to improve drawing performance by removing unnecessary backgrounds, reorganizing views,
- and applying clipping techniques to custom views.
Optimize your app:
- Reduce Overdraw,
- Simplifying View Hierarchies,
- and
- Apply Clipping.
What the user sees:
- The most likely symptom is a generic general slowness of the app,
- especially when rendering complex views to the screen.
Use this tool:
- Hierarchy Viewer
What you see:
- A view hierarchy that is deeper than wide, with a lot of nesting. When
- you profile your view hierarchy, there are red dots in leaf nodes.
- See
- Profiling with Hierarchy Viewer.
Problem:
- The more complex and deep your view hierarchy, the more likely it is that a
- simple change to a view can trigger multiple passes through large parts of this hierarchy to
- recalculate the sizes, positions, and layout of affected views.
Solution:
- Flatten and simplify your view hierarchies. Try different layouts. Combine
- views.
Optimize your app:
-
- Simplify Complex View Hierarchies.
Use these tools:
- On your mobile device, in Developer Options, turn on
- Profile GPU Rendering
- and GPU View Updates.
What you see:
- In Profile GPU Rendering, for bars that cross the 16 millisecond threshold, the
- blue updated segment in particular may be large. The M release of Android adds additional color
- segments, and the Measure/Layout segment may also be larger than expected.
In GPU View Updates, portions of the screen will flicker wildly in response to user - actions:
- -Every time a view changes, the display lists are invalidated and have to be - recreated and executed.
- - Solution:While it is impossible to avoid invalidations, minimizing how often they - happen, and how many views are affected, can improve your app's - performance.
- - Optimize your app:Minimize view invalidations. See - Views, Invalidations, and - Performance - and Double Layout Taxation.
- - - - -What the user sees:
- Slow response to user-initiated actions. Sluggish scrolling.
Use these tools:
- Hierarchy Viewer.
- On your mobile device, in Developer
- Options, turn on
- Profile GPU Rendering
- and GPU View Updates.
What you see:
- In Profile GPU Rendering, for bars that cross the 16 millisecond threshold, the
- blue segment in particular may be large. In GPU View Updates, large portions of the whole screen
- will flicker wildly in response to user actions. In Hierarchy Viewer, look for red dots in the
- measure and layout phases, especially on leaf nodes.
Problem:
- Changing the position or size of a view can trigger a cascade of calculations
- throughout your view hierarchy to adjust neighboring and parent views.
Solution
- You might be able to improve rendering performance by rearranging or
- simplifying your view hierarchy, or by using different layout containers.
Optimize your app:
-
What the user sees:
- App slows down whenever views and animations use alpha
- rendering.
Use this tool:
- Profile GPU Rendering.
- Also, in Developer options, turn on
- Show Hardware Layers Updates. The screen will flash green for every hardware layer update. Note
- that for pre-M (API level 22 and below), you have to use hardware layers explicitly (e.g.
- mView.animate().alpha(0).withLayer().start()), while for API levels 23 and above, the system does
- this for you automatically.
What you see:
- In the Profile GPU Rendering graph, orange bar segments may be tall,
- because the CPU is waiting for the GPU to finish all this work. On our device, the screen will
- flash green while your app slows down. See
-
- Optimizing Hardware Layers for an example.
Problem:
- From a performance perspective, fade and transparency effects are expensive,
- because you have to draw every pixel and possibly whole parts of your view hierarchy multiple
- times.
Solution:
- You might be able to improve drawing performance by controlling how the
- renderer uses hardware layers and by using alpha rendering sparingly.
Optimize your app:
- Eliminate non-critical alpha rendering and use hardware layers
- effectively. Learn more on The Hidden Cost of Transparency
- and
- Hardware Acceleration
What the user sees:
- Intermittent drops in frame rate, and crashes in the worst
- case.
Use these tools:
- Memory Monitor
- and Heap Viewer.
What you see:
- In Heap Viewer, look for large bitmap
- objects. In Memory Monitor, you'll see an unhealthy number of garbage
- collection events.
Problem:
- Once loaded, your app's bitmaps are uncompressed, which
- not only uses up memory but also affects garbage collection.
Solution:
- You might be able to increase available memory, reduce garbage collection
- overhead, and increase rendering performance by using smaller bitmap pixel formats.
Optimize your app:
- Consider Smaller Pixel Formats. See Smaller Pixel Formats.
What the user sees:
- Intermittent drops in frame rate, and crashes in the worst
- case.
Use these tools:
- Memory Monitor
- and Heap Viewer.
What you see:
- In Heap Viewer, look for large bitmap objects. In Memory Monitor,
- you'll see and unhealthy number of garbage collection events.
Problem:
- If the bitmaps your app is loading are larger than what is being displayed on
- the screen, they unnecessarily use memory space.
Solution:
- You might be able to increase available memory and rendering performance be
- pre-scaling your bitmaps.
Optimize your app:
- Use Pre-scaled Bitmaps.
What the user sees:
- Intermittent drops in frame rate, and crashes in the worst
- case.
Use these tools:
- Memory Monitor
- and
- Allocation Tracker.
What you see:
- In Allocation Tracker, look for bitmap objects. In Memory Monitor, you
- may see an unhealthy number of garbage collection events.
Problem:
- Your app is loading a stream of bitmaps that are each only used for a short
- time.
Solution:
- You might be able to improve memory usage and rendering performance by using
- object pools to reuse existing bitmap objects, and be reusing and caching bitmaps and
- textures.
Optimize your app:
- Reuse Bitmaps
- and consider using Object Pools.
- Consider using the Glide Library.
-
diff --git a/docs/html/training/training_toc.cs b/docs/html/training/training_toc.cs
index 36a400e2a9a09..04af2df344c30 100644
--- a/docs/html/training/training_toc.cs
+++ b/docs/html/training/training_toc.cs
@@ -1848,11 +1848,10 @@ results."