Research on Android Layout Mechanism

Layout plays a significant role in quickly setting up the interface and improving the adaptability of the interface on screens with different resolutions. Here we will briefly introduce Layout of Android and study its implementation.

Android has four Layout types: FrameLayout, LinearLayout, TableLayout, and RelativeLayout.

XML Attribute of the View to be arranged in Layout:
XML attributes of items in four Layout types:
(1) layout_width
(2) layout_height
(3) layout_marginLeft
(4) layout_marginTop
(5) layout_marginRight
(6) layout_marginBottom
(7) layout_gravity

Items in FrameLayout have these attributes.
For LinearLayout
(8) layout_weight

The TableLayout row TableRow is a horizontal (horizontal) LinearLayout.

RelativeLayout has 16 align-related XML attributes.
(9) layout_abve
(10) layout_alignBaseline
(11) layout_alignBottom
(12) layout_alignLeft
(13) layout_alignParentBottom
(14) layout_alignParentLeft
(15) layout_alignParentRight
(16) layout_alignParentTop
(17) layout_alignRight
(18) layout_alignTop
(19) layout_below
(20) layout_centerHorizontal
(21) layout_centerInParent
(22) layout_centerVertical
(23) layout_toLeftOf
(24) layout_toRightOf

(1) and (2) are used to determine the width and height of the View placed in Layout: they may be fill_parent, wrap_content, or fixed pixel values.
(3) (4) (5) (6) the View placed in Layout is expected to be a distance between it and the border of Layout or other views.
(7) determine the position of the View in Layout.
(8) It is used to distribute the remaining space after all sub-views are arranged in LinearLayout to each View with this attribute according to their layout_weight.
(9) to (24) is used to determine the position of the View in RelativeLayout relative to other views in Layout or Layout.

According to the Android documentation, Android will traverse the tree composed of Layou and View nesting twice, one is the measure call, used to determine the size of Layout or View; the other is the layout call, used to determine the location of Layout or view. Of course, my own shanzhai implementation merged the two calls. That is, Layout performs a measure operation on itself before the Layout, and then recursively calls the Layout Method on The View. The size of this is definitely determined. Then, the gravity or align attribute is used to locate the location with the determined size, and the margin is used to adjust the location. The pseudocode is as follows:

Long layout (parent_leftPos, parent_topPos, parent_width, parent_height)

{

Measure (parent_width, parent_height );

While (! List. empty ())

{

HorizontalLeft = horizontalLeft-pChild-> leftMargin-pChild-> rightMargin;

VerticalLeft = verticalLeft-pChild-> topMargin-pChild-> bottomMargin;

PChild-> layout (curLeftPos, curTopPos, horizontalLeft, verticalLeft );

// Use gravity or align

// Use margin

// Scale layout size if this is a layout and it's layout_width or layout_height is wrap_content

}

// Use weight.

}

If you implement this mechanism by yourself, the difficulty is to determine the size of the View or Layout based on the layout_width and layout_height values specified by the user for View or Layout.

This is easier for View.
(1) When there is no nested Layout below it: for example, if it is a standard control Button and Its layout_width is WRAP_CONTENT or pixel value, it is OK. If layout_width is FILL_PARENT, its Layout is FILL_PARENT. If it is WRAP_CONTENT, this is an attribute conflict and can be handled according to the Layout attribute.
(2) When Layout is nested below it, this involves determining the Layout size, which is converted to determining the Layout size.

Layout is complicated.
The main Layout can be nested with each other. If the parent Layout is WRAP_CONTENT, the Child Layout is FILL_CONTENT, and the content of the Child Layout is determined after the various View Layout is completed, therefore, the View conflict handling method cannot be used directly. That is to say, if the View is not arranged during the measure call process, the content size of Layout cannot be obtained. Since we don't know the layout, we can leave the WRAP_CONTENT attribute to layout during the measure operation.

When implementing the measure method of Layout, determine your own measuredWidth and measuredHeight as much as possible (because of WRAP_CONTENT), and then send it to each sub-View or Layout for the measure call. When implementing the Layout method of layout, you must call Layout for each sub-View or layout first, then Layout is arranged based on the nature of Layout and the attributes of each View in Layout. In this way, the subnode is first arranged to obtain the size of the subnode (layer-by-layer recursive call, and all the values are determined when the View subnode is reached, and then returned recursively layer by layer, measuredWidth and measuredHeight are also determined for the upper-layer nodes ).

The last thing to note is that Layout has not fixed its own size when arranging its child View or Layout, so even if the layout attribute of some views is set, it should also be ignored. As mentioned in the Android document, if you set the layout_width of RelativeLayout to WRAP_CONTENT and set the attribute layout_alignParentRight to true for a View under RelativeLayout, this is the case of conflict. Therefore, before using these layout attributes, you must first ensure that they are all logical rows, and then expect the Layout mechanism to work correctly.

Of course, the real implementation process of Android is much more complicated than described above. However, through repeated tests on the Android plug-in Eclipse, we can also see that the implementation of Android is not flawless, it also depends on the correct use of users. Logically, conflicting layout attributes make it hard to predict its behavior.