As you get comfortable with XAML you'll start to see the power of what you can achieve. With this power comes the responsibility to understand the performance implications of your actions. Each view (Grids, StackLayouts, Labels, etc.) adds overhead to the page as it is rendered. You'll want to make sure you limit how many views you add.

Layout performance optimization

The most important aspect of layout-level optimization is knowing when you should be using which layout. As a XAML developer you should be aware of how each of these layouts work and what the drawbacks are of using each of them.


    A layout that’s capable of displaying multiple children, but that only has a single child, is wasteful. For example, a StackLayout __with a single child does not make sense.
    In addition, don’t attempt to reproduce the appearance of a specific layout by using a combination of other layouts, as this results in unnecessary layout calculations being performed, and at the end of the day it doesn’t make much sense. For example, don’t attempt to reproduce a Grid _layout by using a combination of StackLayouts._
    Don’t set the VerticalOptions and HorizontalOptions of a layout unless required. The default values for it, i.e.LayoutOptions.Fill and LayoutOptions.FillAndExpand, allow for the best layout optimization.
    Changing these properties has a cost and consumes memory, even when setting them to the default values. Hence, if your requirement is fulfilled using Fill/FillAndExpand, not mentioning it during the views creation is the best practice.
    Avoid using a RelativeLayout _**_if at all possible. It has significant overhead and is never recommended.
    When using an AbsoluteLayout, avoid using the AbsoluteLayout.Autosize __property whenever possible.
    Pack your views in the constructor rather than OnAppearing.
    Bypass transparency—if you can achieve the same (or close enough) effect with full opacity, do so.


    Reduce the depth of layout hierarchies by specifying Margin property values, allowing the creation of layouts with fewer wrapping views. For more information, check out the Margins and Padding documentation.
    When using a Grid, try to ensure that there as few rows and columns as possible that are set to Auto, which makes the engine perform additional calculations. Instead, use fixed-size rows and columns if possible.
    Set rows and columns to occupy a proportional amount of space with the GridUnitType.Star.


    When using a StackLayout, ensure that only one child is set to LayoutOptions.Expands. This property ensures that the specified child will occupy the largest space that the StackLayout can give to it. Note: It is wasteful to perform these calculations more than once.
    Don’t call any of the methods of the Layout class, as they result in the performance of expensive layout calculations. Instead, it's likely that the desired layout can be obtained by setting the TranslationX and TranslationY properties. Alternatively, you can subclass the Layout<View> class to achieve the desired layout behavior.
    Avoid calling Layout() (and especially ForceLayout()).


    Update Label only when required, as changing the size of a label can result in the entire screen layout being recalculated.
    Don’t set a Label’s VerticalTextAlignment/HorizontalTextAlignment property unless required.
    Set the LineBreakMode of any label to NoWrap whenever viable.


    Including a ListView inside a ScrollView is a very bad practice. Always avoid it. Use the ListView's Header and Footer properties instead.
    Do not use TableView where you can use a ListView. TableViews are usually recommended for a setting like UI.
    Use ListViewCachingStrategy.RecycleElement when you can. This is not the default caching strategy.
    Use DataTemplate selectors to facilitate heterogeneous views within a single ListView. Don’t override OnBindingContextChanged to update and achieve the same effect.
    Avoid passing IEnumerable<T> as a data source to ListViews. Instead, try to use IList<T>, because IEnumerable<T> collections don't support random access.
    Nesting ListViews is a bad practice. Instead, use groups within a single ListView. Nesting is explicitly unsupported and will break your application.
    DO use HasUnevenRows where your ListView has rows of differing sizes. If the content of the cell is modified dynamically (perhaps after loading it from the database), be sure to call ForceUpdateSize() on the cell.
    Avoid deeply nested layout hierarchies. Use AbsoluteLayout or Grid to help reduce nesting.
    Avoid specific LayoutOptions other than Fill (Fill is the cheapest to compute).


    Images on Android do not down-sample. Always remember this as it’s one of the reasons your app reaches OOM.
    Set Image.IsOpaque to true if possible.
    Load images from Content instead of Resources.


    Avoid using the CarouselPage as much as possible; instead use a CarouselView within a ContentPage. The reason for this is that CarouselPage loads all the data at once, which hampers performance at extreme levels.
Additional Resources:
Last modified 10mo ago