Android developers use the term layout to mean one of two things. Both definitions apply to this tutorial, and are, unfortunately used interchangeably in the Android development community. The two definitions of layout are: Android user interfaces can be defined as layout resources in XML or created programmatically. A layout defines the visual structure for a user interface, such as the UI for an activity or app widget. You can declare a layout in two ways: The Android framework gives you the flexibility to use either or both of these methods for declaring and managing your application\'s UI. For example, you could declare your application\'s default layouts in XML, including the screen elements that will appear in them and their properties. You could then add code in your application that would modify the state of the screen objects, including those declared in XML, at run time. The advantage to declaring your UI in XML is that it enables you to better separate the presentation of your application from the code that controls its behavior. Your UI descriptions are external to your application code, which means that you can modify or adapt it without having to modify your source code and recompile. For example, you can create XML layouts for different screen orientations, different device screen sizes, and different languages. Additionally, declaring the layout in XML makes it easier to visualize the structure of your UI, so it\'s easier to debug problems. As such, this document focuses on teaching you how to declare your layout in XML. If you\'re interested in instantiating View objects at runtime, refer to theViewGroup and View class references. Defining an XML Layout Resource The most convenient and maintainable way to design application user interfaces is by creating XML layout resources. This method greatly simplifies the UI design process, moving much of the static creation and layout of user interface controls and definition of control attributes, to the XML, instead of littering the code. It creates a potential distinction between UI designers (who concern themselves more with layout) and developers (who know Java and implement application functionality). Developers can still alter the content of a screen programmatically when necessary. Complex controls, like ListView or GridView, are usually populated with data programmatically. XML layout resources must be stored in the /res/layout project directory (or, in the case of alternative resources, in a specially named sub-directory). It’s common practice to create an XML layout resource for each screen in your application (closely tied to a specific Activity), but this is not required. You could, in theory, create an XML layout resource and use it for different activities, supplying different data on the screen. You can also componentized your layout resources and include them within one another, if needed. The following is a simple XML layout resource, a template with a LinearLayout con.

1. Android developers use the term layout to mean one of two things. Both definitions apply to this
tutorial, and are, unfortunately used interchangeably in the Android development community.
The two definitions of layout are:
Android user interfaces can be defined as layout resources in XML or created programmatically.
A layout defines the visual structure for a user interface, such as the UI for an activity or app
widget. You can declare a layout in two ways:
The Android framework gives you the flexibility to use either or both of these methods for
declaring and managing your application's UI. For example, you could declare your
application's default layouts in XML, including the screen elements that will appear in them and
their properties. You could then add code in your application that would modify the state of the
screen objects, including those declared in XML, at run time.
The advantage to declaring your UI in XML is that it enables you to better separate the
presentation of your application from the code that controls its behavior. Your UI descriptions
are external to your application code, which means that you can modify or adapt it without
having to modify your source code and recompile. For example, you can create XML layouts for
different screen orientations, different device screen sizes, and different languages. Additionally,
declaring the layout in XML makes it easier to visualize the structure of your UI, so it's easier to
debug problems. As such, this document focuses on teaching you how to declare your layout in
XML. If you're interested in instantiating View objects at runtime, refer to theViewGroup and
View class references.
Defining an XML Layout Resource
The most convenient and maintainable way to design application user interfaces is by creating
XML layout resources. This method greatly simplifies the UI design process, moving much of
the static creation and layout of user interface controls and definition of control attributes, to the
XML, instead of littering the code. It creates a potential distinction between UI designers (who
concern themselves more with layout) and developers (who know Java and implement
application functionality). Developers can still alter the content of a screen programmatically
when necessary. Complex controls, like ListView or GridView, are usually populated with data
programmatically.
XML layout resources must be stored in the /res/layout project directory (or, in the case of
alternative resources, in a specially named sub-directory). It’s common practice to create an
XML layout resource for each screen in your application (closely tied to a specific Activity), but
this is not required. You could, in theory, create an XML layout resource and use it for different
activities, supplying different data on the screen. You can also componentized your layout
resources and include them within one another, if needed.

2. The following is a simple XML layout resource, a template with a LinearLayout containing a
TextView and an ImageView, defined in XML:
Android to improve the user interaction:
On devices running Gingerbread or earlier, the screen was drawn completely in software (there
was no GPU requirement). However, device screens were getting larger and pixel density was
increasing, placing strain on the ability of the software to render the screen in a timely manner.
Honeycomb added tablets, further increasing screen sizes. To account for this, GPU chips were
added, and apps had the option to run the rendering using full GPU hardware acceleration.
For apps targeting Ice Cream Sandwich and higher, GPU hardware acceleration is on by default;
pushing most rendering out of the software and onto dedicated hardware sped up rendering
significantly.
Jelly Bean 4.1 (and 4.2) “Project Butter” made further improvements to avoid jank and jitter, in
order to make your apps “buttery smooth.” By improving timing with VSYNC (better scheduling
frame creation) and adding additional frame buffering, Jelly Bean devices skip frames less often.
When building these improvements, the Android team built a number of great tools to measure
screen drawing, the new VSYNC buffering and jank, and released these tools to developers.
Solution
Android developers use the term layout to mean one of two things. Both definitions apply to this
tutorial, and are, unfortunately used interchangeably in the Android development community.
The two definitions of layout are:
Android user interfaces can be defined as layout resources in XML or created programmatically.
A layout defines the visual structure for a user interface, such as the UI for an activity or app
widget. You can declare a layout in two ways:
The Android framework gives you the flexibility to use either or both of these methods for
declaring and managing your application's UI. For example, you could declare your
application's default layouts in XML, including the screen elements that will appear in them and
their properties. You could then add code in your application that would modify the state of the
screen objects, including those declared in XML, at run time.
The advantage to declaring your UI in XML is that it enables you to better separate the
presentation of your application from the code that controls its behavior. Your UI descriptions
are external to your application code, which means that you can modify or adapt it without
having to modify your source code and recompile. For example, you can create XML layouts for
different screen orientations, different device screen sizes, and different languages. Additionally,
declaring the layout in XML makes it easier to visualize the structure of your UI, so it's easier to

3. debug problems. As such, this document focuses on teaching you how to declare your layout in
XML. If you're interested in instantiating View objects at runtime, refer to theViewGroup and
View class references.
Defining an XML Layout Resource
The most convenient and maintainable way to design application user interfaces is by creating
XML layout resources. This method greatly simplifies the UI design process, moving much of
the static creation and layout of user interface controls and definition of control attributes, to the
XML, instead of littering the code. It creates a potential distinction between UI designers (who
concern themselves more with layout) and developers (who know Java and implement
application functionality). Developers can still alter the content of a screen programmatically
when necessary. Complex controls, like ListView or GridView, are usually populated with data
programmatically.
XML layout resources must be stored in the /res/layout project directory (or, in the case of
alternative resources, in a specially named sub-directory). It’s common practice to create an
XML layout resource for each screen in your application (closely tied to a specific Activity), but
this is not required. You could, in theory, create an XML layout resource and use it for different
activities, supplying different data on the screen. You can also componentized your layout
resources and include them within one another, if needed.
The following is a simple XML layout resource, a template with a LinearLayout containing a
TextView and an ImageView, defined in XML:
Android to improve the user interaction:
On devices running Gingerbread or earlier, the screen was drawn completely in software (there
was no GPU requirement). However, device screens were getting larger and pixel density was
increasing, placing strain on the ability of the software to render the screen in a timely manner.
Honeycomb added tablets, further increasing screen sizes. To account for this, GPU chips were
added, and apps had the option to run the rendering using full GPU hardware acceleration.
For apps targeting Ice Cream Sandwich and higher, GPU hardware acceleration is on by default;
pushing most rendering out of the software and onto dedicated hardware sped up rendering
significantly.
Jelly Bean 4.1 (and 4.2) “Project Butter” made further improvements to avoid jank and jitter, in
order to make your apps “buttery smooth.” By improving timing with VSYNC (better scheduling
frame creation) and adding additional frame buffering, Jelly Bean devices skip frames less often.
When building these improvements, the Android team built a number of great tools to measure
screen drawing, the new VSYNC buffering and jank, and released these tools to developers.