CODEWITHSUNDEEP
c#xamlwindows-runtimewinrt-xaml
MrCSharp
MrCSharp

Reputation: 1143

Performance degrades after navigating to some pages

i have this weird problem with my WinRT app (Windows Phone only). The app is made of multiple pages, it uses an animation to show a side menu which mimics the hamburger menu in W10M. The animation and app performance are great when the app first launches, but after navigating to some pages (say 3 or 4 pages) the app performance gets worst and worst. I don't have any code that is running in the background on the UI thread or any other thread.

Is there something about navigation in WinRT i am missing? It is really weird and i don't know what is causing it.

Upvotes: 0

Views: 73

Answers (1)

Jerry Nixon
Jerry Nixon

Reputation: 31831

Here are some considerations that impact performance in XAML.

  1. Depth of the visual tree. You can drag on two controls, but those controls represent several nested controls - things like borders, buttons, and panels. Running your app and looking at it with the Live XAML Tree viewer can give you a hint if a control is more complex than you want. Also, keep depth in mind when you build your UI. Favor simple controls like RelativePanel and standard, non-re-template control.

  2. Construction versus loaded logic. It's not uncommon for developers not yet familiar with XAML to implement complex logic in inappropriate places. For example, you might, in the constructor of a sub-classed control, tell it to go get some data or test some expensive condition. Ideally, you will use Loaded of a control, or OnNavigatedTo of a Page if you have this type of logic, and use async if you have the option.

  3. Data binding. Data binding is awesome but it is also expensive. You can use it in a few dozen places on your page an not likely to ever make a difference, but if you start to use it everywhere and for everything, it can be really expensive. The easiest remediation is to reduce the bindings in your page. Next, you can change your bindings from Mode=OneWay (which is the default) to Mode=OneTime wherever you can. Next, you can switch from {binding} to {x:bind} wherever possible. Remember, binding is not wrong, it's just expensive, so use it only when appropriate.

  4. Too many records. If you have a repeater like a ListView or GridView then you might have too many items appearing at one time. This is a big deal, especially on load. It's rare that the real cost is fetching the data, it's typically rendering the data. If your item data template is complex, then your visual tree depth may be multiplied several times with each record. Loading fewer records at load and then showing more over time is one approach. Using x:Phase is another great approach. Simplifying your item templates is another approach. Minimizing data binding in your item templates can help. But, the best you can do is to run the diagnostics tool and look to see what's causing it. It might not be your ListView at all.

  5. Unused Visual States. Developers are smart to use visual states. However, some states they define are for edge cases and show only in certain circumstances. The XAML for those views may never appear, so they mark their Visibility to Collapsed. This is okay. But if you go one more step and use x:DeferLoadingStrategy you can prevent the cost of that XAML parsing and rendering at startup. When the visual state reveals that XAML, it will automatically be realized by the platform. You're the winner, so is the user.

So, 5 helpful tips to help your pages load faster.

Odds are, your reason is going to be something else :)

ONE MORE THING

Are you allowing your pages to be removed from memory? Is it possible that in your implicit code in your code-behind you are subscribing to a static or global event? Maybe you need to unsubscribe in your OnNavigatedFrom override. Since the problem gets worse over time, it sounds like it might be a memory issue. Though, that is just a guess. It's a common C# slip up.

Best of luck

Upvotes: 2

Related Questions