In-depth analysis of Android's custom layout

[[124174]]

Words written in front:

This article was written by Lucas Rocha, a former Firefox Android engineer (now working for Facebook). The article analyzes four common custom layout solutions in Android, and explains their respective advantages and disadvantages and the comparison between the four solutions by combining the sample projects written for these four Android custom layout solutions. After reading this article, I have a better understanding of Android custom layout, so I translated it into Chinese while I was in high spirits. The original link is here.

As long as you have written an Android program, you must have used several built-in layouts of the Android platform - RelativeLayout, LinearLayout, FrameLayout, etc. They can help us build Android UI very well.

These built-in layouts already provide many convenient components, but in many cases you still need to customize your own layouts.

To sum up, custom layout has two major advantages:

1. Make your UI display more efficient by reducing view usage and traversing layout elements faster;
2. You can build UIs that cannot be implemented by existing views.

In this blog post, I will implement four different custom layouts and compare their pros and cons: composite view, custom composite view, flat custom view, and async custom views.

The code implementation can be found in the android-layout-samples project on my github. This app uses the four custom layouts mentioned above to achieve the same UI effect. They use Picasso to load images. The UI of this app is just a simplified version of the twitter timeline - no interaction, only layout.

Ok, let’s start with the most common custom layout: composite view.

Composite View

Composite views (also known as compound views) are the simplest way to combine multiple views into a reusable UI component. The implementation of this method is as follows:

1. Inherits the relevant built-in layout.
2. Fill a merge layout in the constructor.
3. Initialize member variables and point to the internal view via findViewById().
4. Add custom APIs to query and update the view state.

TweetCompositeView is a composite view. It inherits from RelativeLayout and fills the tweet_composite_layout.xml file. It also exposes the update() method to update its state in the adapter.

Custom Composite View

The TweetCompositeView implementation mentioned above can meet most situations. But it doesn't work in some cases. Suppose you now want to reduce the number of subviews and make layout elements more efficient.

At this point we can look back and see that although composite views are relatively simple to implement, there is still a lot of overhead when using these built-in layouts - especially more complex containers such as LinearLayout and RelativeLayout. Due to the implementation of built-in layouts on the Android platform, the system needs to handle many layout combinations and multiple measurements of subviews in one layout element traversal - the layout_weight attribute of LinearLayout is a common example.

Therefore, you can customize the calculation and positioning logic of subviews for your app, so that you can greatly optimize your UI. This approach is what I will introduce next, custom composite view.

As the name implies, a custom composite view is a composite view that overrides the onMeasure() and onLayout() methods. Therefore, compared to the previous composite view that inherits RelativeLayout, we now need to go a step further and inherit the more abstract ViewGroup.

TweetLayoutViewcode is implemented using this technique. Note that this implementation does not inherit LinearLayout like TweetComposiveView does, which avoids the use of the layout_weightcode attribute.

This laborious process uses the ViewGroup's measureChildWithMargins() method and the underlying getChildMeasureSpec() method to calculate the MeasureSpec for each child view.

TweetLayoutView can’t correctly handle all possible layout combinations but it doesn’t have to. We will definitely need to optimize our custom layout for our specific needs, and this approach will allow us to write simple and efficient layout code.

Flat Custom View

As you can see, custom composite views can be implemented simply by using the ViewGroup API. Most of the time, this implementation can meet our needs.

However, if we want to go a step further - optimize the key parts of our application UI, such as ListViews, ViewPager, etc. What if we merge all TweetLayoutView subviews into a single custom view and manage it uniformly? This is what we are going to discuss next, flat custom view - see the picture below.

The left side is CUSTOM COMPOSITE VIEW, and the right side is FLAT CUSTOM VIEW

A flat custom view is a completely customized view that is fully responsible for the calculation, position arrangement, and drawing of its internal subviews. Therefore, it directly inherits View instead of ViewGroup.

If you want to find examples of such apps in real life, it’s easy - turn on the “Show layout boundaries” option in your phone’s “Developer mode” and then open apps like Twitter, Gmail, or Pocket, which all use flat custom views in their list UIs.

The main benefit of using a flat custom view is that it can greatly compress the app's view hierarchy, allowing for faster layout element traversal and ultimately reducing memory usage.

Flat custom view can give you the most freedom, just like you are drawing on a blank piece of paper. But such freedom comes at a price: you can't use existing view elements, such as TextView and ImageView. Yes, it is easy to draw text on Canvas, but how do you implement ellipsizing (that is, truncation of overlong text)? Similarly, it is easy to draw pictures on Canvas, but how to scale them? These restrictions also apply to touch events, accessibility, keyboard navigation, etc.

So the bottom line of using flat custom view is: only apply flat custom view to the core UI part of your app, and the rest directly rely on the view provided by the Android platform.

TweetElementViewcode is a flat custom view. To make it easier to implement, I created a small custom view framework called UIElement. You can find it in the canvascode package.

UIElement provides a measure/layout API similar to the Android platform. It includes TextView and ImageView without a graphic interface, and these two elements include several required features - see TextElementcode and ImageElementcode respectively. It also has its own inflatercode to help instantiate UIElement from the layout resource file code.

Note: UIElement is still in a very early stage of development, so there are still many flaws, but in the future as UIElement continues to improve it may become very useful.

You might think that the code for TweetElementView looks simple, that’s because the actual code is all inside TweetElementcode — in fact, TweetElementView plays the role of hosting code.

The layout code in TweetElement is very similar to TweetLayoutView's, but it uses different code when requesting images using Picasso because TweetElement doesn't use ImageView.

Async Custom View

As we all know, the Android UI framework is single-threaded. This single thread brings some limitations. For example, you cannot traverse layout elements outside the main thread - however, this is very beneficial for complex and dynamic UIs.

If your app has a complex layout of items in a ListView (like most social apps do), then you are likely to see frame skipping when you scroll the ListView, because the ListView needs to calculate the view size code and layout code for the new content that is about to appear in the list. The same problem will also appear in GridViews, ViewPagers, etc.

If we can perform layout traversal on subviews that have not yet appeared on a thread other than the main thread, can we solve the above problem? In other words, calling the measure() and layout() methods on the subviews will not occupy the main thread's time.

So async custom view is an experiment that allows subview layout traversal to happen outside the main thread. This idea was inspired by the video about Facebook's Paperteam async node framework.

Since we can never access the UI components of the Android platform outside the main thread, we need an API to measure and layout the content of this view without directly accessing this view. This is exactly the function that the UIElement framework provides me.

AsyncTweetViewcode is an async custom view. It uses a thread-safe AsyncTweetElementcode factory classcode to define its content. The specific process is that a Smoothie child loadercode creates, pre-measures and caches (in memory for direct use later) a temporarily invisible AsyncTweetElement on a background thread.

Of course I made some compromises in implementing this asynchronous UI, because you don't know how to display layout placeholders of arbitrary height. For example, you can only resize them once on a background thread when the layouts are passed asynchronously. So when an AsyncTweetView is about to be displayed and there is no suitable AsyncTweetElement in memory, the framework will force the creation of an AsyncTweetElement code on the main thread.

Also, the preloading logic and memory cache expiration time setting need to be well implemented to ensure that the cache layout in memory is used as much as possible in the main thread. For example, using LRU cache code in this solution is not a wise choice.

Despite these limitations, the initial results using async custom views are promising. I will certainly continue to explore this area by refactoring the UIElement framework and using other classes of UI. Let's wait and see.

Summarize

When it comes to layout, the deeper our customization, the less we can rely on the Android platform. So we should also avoid premature optimization and only fully customize the layout in areas that can really improve the quality and performance of the app.

This is not a black-and-white decision. There are many solutions between the two extremes of using platform-provided UI elements and completely customizing them - from simple composite views to complex async views. In actual projects, you may combine several solutions in this article to write an excellent app.