This chapter is from the book
This chapter is from the book
This chapter is from the book
Hierarchy Viewer
Hierarchy Viewer is the unsung hero of layout optimization. It hasn’t seen a whole lot of change since the early versions, but it still remains a great go-to tool for figuring out what is happening with your layouts. It can be used for simply figuring out why a view doesn’t display or to figure out why a hierarchy is slow to load. It can even output your views as a PSD, allowing you to inspect positioning and colors with precision that is hard to match from simple screenshots.
If your device is running Android 4.0 (or lower) and is unlocked, everything should just work. If it’s running 4.0 (or lower) and it is locked, you can use the ViewServer class from Romain Guy (https://github.com/romainguy/ViewServer) in your app (be sure to add the internet permission). If your device is running Android 4.1 or newer, you need to set an environment variable called ANDROID_HVPROTO with a value of ddm. In Windows, you can open My Computer, Property, Advanced, Environment Variables, and click New to create it. For Mac you’ll open .bash_profile in your home directory (note that the file starts with a dot, which means it is hidden by default). Add a line that contains export ANDROID_HVPROTO=ddm and save the file. Now type source ~/.bash_profile from the command line (this causes the file to be re-read so that the variable is immediately set). For Linux, you can follow the same steps as for Mac but the file is .bashrc in your home directory.
Open Android Device Monitor (under the Tools menu and the Android submenu). The Hierarchy Viewer is a different perspective, so open the Window menu and click the Open Perspective option. Select Hierarchy View and click OK. If you haven’t already connected your device and opened the screen you want to inspect, do so now.
On the left side, you should see your device(s) listed. Select it and click the “Load view hierarchy” button (that’s the icon next to the refresh button; you can also click the downward-facing triangle and select the option there). If the icon is grayed out, that typically means there is an issue communicating with the device and more details should be available in the console (usually on the bottom right). If you’ve already followed the directions from two paragraphs ago and it’s still gray, you can also try closing out Android Studio (and anything else that might be communicating with the device) and then run Android Device Monitor directly (run monitor from the Android SDK tools directory).
Once the view hierarchy has loaded, the left window will show view properties, the center of the screen will be the detailed view hierarchy, the top right will be an overview, and the bottom right is the layout view that lets you see what portion of the screen the selected view is responsible for (the bottom right may be showing the console tab, so just click the Layout View tab). Your screen should look like Figure 10.11.
)
Figure 10.11 After the view hierarchy has been loaded, this is what you should see
Each gray box in the tree view (the center window) represents a view. The boxes can have the class type (e.g., LinearLayout), the memory address, the ID (e.g., id/content), performance indicators, and a view index. The view index shows you the view’s position within the parent, where the first child is position 0. The performance indicators are simply colored circles that indicate the time it took to measure the view, the time it took for the layout pass, and the time it took to draw the view. Newer versions of Hierarchy Viewer require you to click the icon with the three circles to obtain the layout times. These indicators on the gray boxes are broken into three groups. If a view is within the fastest 50% of views for the given indicator (e.g., draw time), that view will be green for that circle. If it’s in the 50% of slow views, it will be yellow. If it is the slowest of all the views, it is red. It’s important to realize these are relative indicators, so a view hierarchy that is extremely fast and efficient will still have a view with a red indicator for each circle just as an extremely slow hierarchy will.
By clicking a gray box, you can see an image of the view, a count of how many views this view represents (a 1 indicates the view itself; a 2 indicates the view plus a child view), and the exact times for measuring, laying out, and drawing the view. In the view properties (the left window), you can see virtually everything you could want to know about a view. This is extremely helpful when troubleshooting.
Finding Missing Views
One particularly handy use of Hierarchy Viewer is to figure out why a given view isn’t showing up. There are many different reasons a view might not appear on the screen, so being able to see all the view’s properties in one place plus a visual representation of the views in your hierarchy is incredibly useful. You can quickly see that a view’s alpha is 0 or its visibility is set to invisible. You can tell if the view was sized incorrectly or positioned incorrectly. Before Android was blessed with Lint checks, pretty much every developer at one point (or many points) would have a LinearLayout and some child views with their widths set to match_parent, run the app, and then wonder why only the first child showed up. Simple things like forgetting the default orientation is horizontal can leave you with unexpected results, but Hierarchy Viewer can easily show you where a view is positioned and seeing it on the right edge of the screen instead of below the previous view is usually enough to get the developer to realize the simple mistake.
Eliminating Unnecessary Views
The biggest benefit Hierarchy Viewer can bring is helping you understand the complexity of your view hierarchy and eliminate extra views. The more complex your hierarchy, the longer your UI thread has to lock up on measuring, laying out, and drawing your views. You should look for views that have only a single child because those are often extraneous views that are easy to remove. You should also look for several sibling TextViews because you can often consolidate them (details are later in this chapter). It’s a good idea to look for invisible views too. Although they aren’t drawn, views that have visibility set to INVISIBLE are still measured and even a view that is GONE will slow down your view lookups and take up memory. If you sometimes need some views on a given screen but not always, use a ViewStub instead of inflating the entire view hierarchy and not drawing it. It’s also a good idea to look out for views entirely outside of the screen (such as views that have been animated off the screen); it doesn’t do any good to waste processing power on something that will never be seen.
Exporting to PSD
One of the extremely powerful but often overlooked features of Hierarchy Viewer is the ability to export a layout hierarchy as a Photoshop Document (a PSD file). This can be hugely valuable to designers, so make sure they are aware of this functionality. There is a rather forgettable-looking button above the tree view that appears to be three overlapping squares. That’s the Capture Layers button. If you do not see it, you can also click the downward-facing triangle to get the list of options and select it from there. The resulting PSD can take a while to be generated, so be patient. If it fails, you will see an error in the console and can try again (occasionally it helps to reconnect the hardware device or restart the emulator).
Because this PSD is not using any advanced features such as layer masks, you can actually open it in GIMP and other tools as well. Along with the techniques discussed earlier in the chapter, this is an excellent method of detecting overdraw.
Exporting to a PSD is a great way for a developer and a designer to speak the same language. The designer can inspect in detail exactly what is going on with a layout by tweaking the layers and then tell the developer which layer has an issue (the layers are named after the view IDs when present, making it extra easy to associate a layer with a view). This also gives the designer the opportunity to make changes to further optimize the design. Perhaps initially a view seemed best at 50-percent opacity, but now the designer can tweak how opaque a view is just like any layer in Photoshop and determine that 40% is actually better.
One thing to note is that the layers are all rasterized. In simplistic terms, the pixels that each view creates are what are actually exported as layers. TextViews do not create actual Photoshop text layers, for instance. That also means that if you have a complex view that’s drawing shapes, text, and images, only the resulting pixels are exported, so you can’t see what each “layer” of that view looks like.