- What Is Android?
- Application Fundamentals
Framework Topics
- Activities
- Services
- Content Providers updated
- Intents and Intent Filters
- Processes and Threads
- User Interface
  - XML Layouts
  - Input Events
  - Menus
  - Action Bar updated
  - Dialogs
  - Notifications
  - Drag and Drop
  - Styles and Themes
  - Custom Components
  - Binding to Data with AdapterView
  - Common Layout Objects
  - How Android Draws Views
- Application Resources
- Data Storage
- Security and Permissions
- The AndroidManifest.xml File
- Graphics new!
- Animation
- RenderScript
- Multimedia and Camera updated
- Copy and Paste
- Location and Maps
- App Widgets
- Bluetooth
- Near Field Communication updated
- USB
- Session Initiation Protocol
- Search
- Device Administration
- Testing
Android Market Topics
- Publishing on Android Market
- Application Licensing
- In-app Billing
- Market Filters
- Multiple APK Support
Developing
- Introduction
- Managing Virtual Devices
- Using Hardware Devices
- Managing Projects
- Building and Running
- Debugging
- Testing
- Tools
Publishing
- Publishing Overview new!
- Preparing for Release updated
- Signing Your Applications
- Versioning Your Applications
Best Practices
- Compatibility
- Supporting Multiple Screens
- Supporting Tablets and Handsets new!
- UI Guidelines updated
- Designing for Accessibility
- Designing for Performance
- Designing for Responsiveness
- Designing for Seamlessness
- Designing for Security new!
Web Applications
- Web Apps Overview
- Targeting Screens from Web Apps
- Building Web Apps in WebView
- Debugging Web Apps
- Best Practices for Web Apps
Appendix
- Android API Levels
- App Install Location
- Supported Media Formats updated
- Intents List: Google Apps
- AIDL
- Glossary

User Interface >

How Android Draws Views

When an Activity receives focus, it will be requested to draw its layout. The Android framework will handle the procedure for drawing, but the Activity must provide the root node of its layout hierarchy.

Drawing begins with the root node of the layout. It is requested to measure and draw the layout tree. Drawing is handled by walking the tree and rendering each View that intersects the invalid region. In turn, each View group is responsible for requesting each of its children to be drawn (with the draw() method) and each View is responsible for drawing itself. Because the tree is traversed in-order, this means that parents will be drawn before (i.e., behind) their children, with siblings drawn in the order they appear in the tree.

When a View's measure() method returns, its getMeasuredWidth() and getMeasuredHeight() values must be set, along with those for all of that View's descendants. A View's measured width and measured height values must respect the constraints imposed by the View's parents. This guarantees that at the end of the measure pass, all parents accept all of their children's measurements. A parent View may call measure() more than once on its children. For example, the parent may measure each child once with unspecified dimensions to find out how big they want to be, then call measure() on them again with actual numbers if the sum of all the children's unconstrained sizes is too big or too small (i.e., if the children don't agree among themselves as to how much space they each get, the parent will intervene and set the rules on the second pass).Drawing the layout is a two pass process: a measure pass and a layout pass. The measuring pass is implemented in measure(int, int) and is a top-down traversal of the View tree. Each View pushes dimension specifications down the tree during the recursion. At the end of the measure pass, every View has stored its measurements. The second pass happens in layout(int, int, int, int) and is also top-down. During this pass each parent is responsible for positioning all of its children using the sizes computed in the measure pass.

an exact numberThe measure pass uses two classes to communicate dimensions. The View.MeasureSpec class is used by Views to tell their parents how they want to be measured and positioned. The base LayoutParams class just describes how big the View wants to be for both width and height. For each dimension, it can specify one of:

FILL_PARENT, which means the View wants to be as big as its parent (minus padding)
WRAP_CONTENT, which means that the View wants to be just big enough to enclose its content (plus padding).

There are subclasses of LayoutParams for different subclasses of ViewGroup. For example, RelativeLayout has its own subclass of LayoutParams, which includes the ability to center child Views horizontally and vertically.

MeasureSpecs are used to push requirements down the tree from parent to child. A MeasureSpec can be in one of three modes:

UNSPECIFIED: This is used by a parent to determine the desired dimension of a child View. For example, a LinearLayout may call measure() on its child with the height set to UNSPECIFIED and a width of EXACTLY 240 to find out how tall the child View wants to be given a width of 240 pixels.
EXACTLY: This is used by the parent to impose an exact size on the child. The child must use this size, and guarantee that all of its descendants will fit within this size.
AT_MOST: This is used by the parent to impose a maximum size on the child. The child must guarantee that it and all of its descendants will fit within this size.

How Android Draws Views

Framework Topics

Android Market Topics

Developing

Publishing

Best Practices

Web Applications

Appendix

How Android Draws Views

更多相关文章

随机推荐