Xamarin.Forms provides not only the ability to share UI across targets, but common application features such as AppLinks for deep linking<\/a>, Navigation<\/a>, MessagingCenter<\/a>, and DependencyService<\/a>, as well as several pieces needed for cross-platform UI alerts, action sheets, toolbars, status bars, etc. When you start adding comparable implementations to a Xamarin.Android app, you start to see the difference in performance disappearing. This begins to explain what\u2019s going on, so what’s in your control to impact startup? Here are my top five tips to tune your startup experience across iOS, Android, and UWP targets.<\/p>\n We often want to load fresh data as soon as our application has launched, but this will only slow down the first screen from appearing and populating. Use state from a previous run or have content ready to go that is for the first run.<\/p>\n If you application is already offline ready, and we recommend it is, then you’re all set to populate the content for your first screen instantly. Azure Mobile Apps<\/a> and Realm with Azure<\/a> are great options.<\/p>\n When you must<\/em> go to the web for your first run content, provide some UI telling the user what you\u2019re doing by using a loading indicator. This is also a perfect opportunity to replace the blank part of your screen with useful placeholder content to reinforce why this screen exists, what the user can expect from the app or just something fun! Whatever your choice here, just don\u2019t leave a screen empty<\/strong>.<\/p>\n Payload Tips<\/strong> Minimize your web payload to just what you need. Don\u2019t spend time on expensive processes like parsing strings, rather deliver your data as it needs to be represented.<\/p>\n<\/blockquote>\n Images and video are heavy and can drastically slow down the initial rendering of a screen. Reduce reliance on heavy assets and optimize any media you use for the necessary dimensions. Don\u2019t rely on the OS to resize the assets for you.<\/p>\n For Android target screens<\/a>, assets are placed in folders representing their density.<\/p>\n There\u2019s also a special density of When you put a large image in the To manage that many densities\u00a0and that many assets, it\u2019s highly beneficial to use an application such as Sketch<\/a> and\/or Zeplin<\/a> to generate multiple sizes from a single design source.<\/p>\n Xamarin.Android 7.0<\/a> recently added an experimental option to pre-crunch PNG files called AndroidExplicitCrunch<\/a>. This further reduces the size of your assets (and application), speeds up build time, and ensures they are optimized for runtime. To enable this, edit the text of your Android The App.xaml XAML is a popular and expressively powerful way to declare your user interface. If you opt to stay in C# and build your UI there, it\u2019s naturally compiled along with the rest of your code, giving you compile-time checking and speed. When you want that same benefit while using XAML, you enable XAML Compilation<\/a> (XAMLC). This will compile your XAML into Intermediate Language (IL) and add it to your compiled assembly, resulting in faster startup and runtime performance. Let\u2019s look at how you can enable this:<\/p>\n At the application level, you may declare your XAMLC options and it will impact your entire app.<\/p>\n When you want to set XAMLC options at the class level, you can!<\/p>\n When XAMLC is enabled you\u2019ll get compile time XAML checking on most all properties and UI will render faster. File size may remain unchanged or grow slightly as you are trading Convenience comes at a cost, as usual. It might be a very small cost, but you want to leave no stone unturned when tuning for performance. While NuGet packages are awesome for leveraging other libraries, the reality is that the more (and larger) assemblies your mobile application depends on naturally slows down the execution as calls pass across boundaries. Xamarin.Forms, for example, inspects all assemblies for `[ExportRenderer]` attributes and currently has no method to opt-in or opt-out. This is something we’re working to improve.<\/p>\n Weigh the pros\/cons of each dependency and, when possible, bring that code into your main application. Your mileage may vary, so give it a look. This is an often overlooked performance consideration that may pay dividends for you.<\/p>\n I\u2019m calling this bonus because we still classify AOT as experimental on Android and it won\u2019t apply to everyone. Of course, iOS uses AOT and the LLVM compiler by default, so there\u2019s nothing to do there.<\/p>\n Enable the experimental Android AOT<\/a> and get immediate improvement in startup as well as overall speed by reducing some Just-In-Time compilation overhead. The price paid is an increase in the size of your APK, so you should try this out and weigh the pros and cons for your application. To enable AOT, open your project configuration and check the box.<\/p>\n While not directly applicable to startup improvement, one of our awesome mobile solutions architects Brandon Minnick<\/a> has shared his collection of build optimization configurations. Check it out on GitHub<\/a>.<\/p>\n These are just a few of my favorite tips, and they can apply to all screens of your application, not just the startup screen. I could go on about flattening layout, optimizing measuring in layout cycles, and more. Much of that and more is covered in our Xamarin.Forms Performance guide<\/a>.<\/p>\n1. Load Local Content First<\/h3>\n
\n
2. Optimize Your Assets<\/h3>\n
\n
\n
nodpi<\/code> that tells Android to not scale the resources regardless of screen density.<\/p>\n<\/blockquote>\nldpi<\/code> folder and use that asset on a screen of xxhdpi<\/code>, Android will scale it up. This is slow and will bloat your runtime memory consumption, sometimes even to the point of crashing your application; I\u2019ve done it.<\/p>\ncsproj<\/code> and amend the PropertyGroup<\/code> for your build configuration:<\/p>\n<PropertyGroup>\n ...\n <AndroidExplicitCrunch>true<\/AndroidExplicitCrunch>\n<\/PropertyGroup><\/pre>\n
3. Lazy Load Anything You Don\u2019t Need Immediately<\/h3>\n
Resources<\/code> is a convenient place to put styles, fonts, and other resources that you’ll use throughout your application, but it’s also all loaded at startup. If you\u2019re trying to erase every unnecessary millisecond from your startup time, remove anything here that you don\u2019t need and lazy load it by page or in another method.<\/p>\n4. Enable XAML Compilation<\/h3>\n
using Xamarin.Forms.Xaml;\n...\n[assembly: XamlCompilation (XamlCompilationOptions.Compile)]\nnamespace PhotoApp\n{\n ...\n}<\/pre>\nusing Xamarin.Forms.Xaml;\n...\n[XamlCompilation (XamlCompilationOptions.Compile)]\npublic class HomePage : ContentPage\n{\n ...\n}<\/pre>\n.xaml<\/code> file size for IL in the assembly.<\/p>\n5. Reduce Number of Assemblies<\/h3>\n
Bonus 1: Ahead of Time Compilation (AOT)<\/h3>\n
![\"\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/44\/2019\/03\/Android_Build_Settings_General_Callout.png\")
\nNote: AOT is available on Xamarin Android 5.1 and 7.0+<\/em><\/p>\nBonus 2: Build Time Improvements<\/h3>\n
What\u2019s Next<\/h2>\n