Does Avalonia not have the pack URI feature for WPF?

[nczsl]

Having this feature is very important, as it allows navigation through different "pages" using only data and styles. As far as I know, Avalonia compiles XAML into C # instead of WPF BAML, which is a file and not always stored in memory. True navigation is based on this feature, where it is only in memory when resources are loaded and cleared from memory when resources are unloaded. Therefore, I believe that Avalonia needs a mechanism and functionality similar to pack URI, which is clearly indispensable.

[nczsl]

Now it has been successfully compiled, and I found through ilspy that even if it is an Ava resource, it is still not an embedded resource file after compilation, but a C # file that is a C # object! This indicates that the processing methods of Ava and WPF are completely different. They do not have real embedded resources, so they do not have real navigation based on embedded resources. Therefore, it is impossible to achieve unmanaged, data styled dynamic page cutting navigation, at least not currently. Not having this feature means that there will be a lot of GC pressure when navigating multiple pages, and it may lead to excessive memory consumption

[maxkatz6]

it is still not an embedded resource file after compilation, but a C # file that is a C # object! This indicates that the processing methods of Ava and WPF are completely different. They do not have real embedded resources,

If you speak about XAML files, then yes - these are compiled into IL. Other Avalonia assets are kept embedded.

Not having this feature means that there will be a lot of GC pressure when navigating multiple pages, and it may lead to excessive memory consumption

BAML still requires a lot of runtime processing and reflection, which is efficiently avoided in Avalonia by generating IL code directly. Additionally, IL code can undergo JIT optimizations like any other C# code (for example), not to mention highly recommended AOT compilation eliminates JIT time as well.

They do not have real embedded resources

If you wish, you can store Avalonia XAML as a text files, and parse in runtime. But I would not recommend that, as it's the worst of both worlds.

Therefore, it is impossible to achieve unmanaged, data styled dynamic page cutting navigation, at least not currently

It might not be possible in the same way as you are used in WPF, with URL and reflection which WPF used a lot.
But it's not an issue with dynamic navigation in Avalonia otherwise.

[Gillibald]

What makes you think loaded baml isn't ending up as objects that are producing any memory pressure?

[nczsl]

The demand scenario is as follows: there are many "pages". The page I am referring to here mainly means "xaml style+data". The WPF navigation+pack URI scheme theoretically does not go through GC, which means that when you need to load the page, you get the xaml from BAML, which is equivalent to the style. Then you pass data to it, such as data from a database. After combining these two, it will be assembled into a part of your page; When you uninstall this page, it will (I think it can be done) immediately disappear from memory because the BAML embedded resource is still a file, so it is an unmanaged resource; It's just that these files are packaged into DLL files; This method is more like loading and unloading web pages; If there is no such mechanism, theoretically, converting all resources into C # form and storing them in memory at once would result in a larger memory footprint? If the form of "new Page();" is used to attach value to a certain part of the page, it will go through "GC", which will bring additional GC pressure. When you have many pages navigating back and forth, won't it cause memory fragmentation? So in short, I think new non web UI frameworks should learn from the approach of the web; considering the popular single page (SPA) design, from the web perspective, it can easily wrap and place it in a certain position on the page every time it receives CSS style+data, thus achieving the same goal as multi page navigation page switching. Think about how this feature can stabilize with the same performance and memory usage on WPF and Avalon. Is it achievable? I think that's a question.