问题描述
我有更多的功能被加到其被越来越慢到负载的.NET WPF应用程序。我的客户想要增加了更多的功能。目前，它需要花费一分钟到负载。
时可以分离编码包含在组件称之为“销售订单”，这样它仅加载如果用户导航到该视觉状态和负荷的观点和相关联的viewmodels在于组件？
如果它是，我有数据和文件IO类的一些常见组件。它们可以在开始时被装载和由每个应用程序域共享，或我需要在每个应用程序域组件加载的本地副本OIF此。
假定这是可能的，那会像应用程序的启动编码的样子，我将如何导航到其需要它的可视状态在组装之前加载一个？
理想我要加载下10秒我的应用到初始菜单并且当它们加载应用程序的不同部分，我不介意进一步5〜10第二延迟。
我只是不知道这是否可能，如何去了解它。
解决方法
我不确定多个 AppDomain 是否适合 WPF（IMO 绝对不是！）。如果您有复杂的功能，并且有很多功能，我建议您尝试执行某种用例分析，并对较小的部分进行拆分/分解并实施“延迟加载”。
当然，根据应用程序的类型，可能会发生在单用户会话期间（用户启动应用程序 > 执行他的任务/工作 > 使用关闭应用程序），如果您有例如100 个功能，用户可能会使用其中的 10 个。因此，在启动时，对剩余的 90 个功能（加载、初始化视图、视图模型、数据等毫无意义）做任何事情都毫无意义。
其他词：
-
识别应用程序的功能并将它们表示为组件。我可以建议你看看这里： https://www.qube7.com/guides/controller-overview.html
在上述解决方案中，控制器可能代表单个特征并封装该特征运行所需的一切。
-
确定用户在其会话期间极有可能需要的功能，然后在启动时触发/运行代表这些功能的控制器。
-
其余功能视为按需：仅在用户明确请求时初始化、加载和运行代表控制器。
PS：您可以使用性能分析器（例如 ANTS）来查看您的瓶颈在哪里，但我敢打赌，程序集加载不会受到最大影响（程序集加载肯定不会花费 60 秒）:)
,另一个好主意，您可以在加载 UI 后立即将阴影加载端程序集（在不同的线程中）实现到第二个 AppDomain，这对用户来说会更舒适，因为他们可以在应用程序完全加载后立即访问他们的功能。 但是让我们看看您的应用程序。加载一个程序集需要时间，大约 300 毫秒，您还有多少个程序集？你有没有用特殊的追踪工具追踪过它？加载时究竟需要这么长时间？一分钟对于仅加载程序集来说听起来太长了，可能还有其他逻辑需要吗？
,我最终发现我可以通过使用反射动态加载与所选菜单选项相关的特定用户控件来显着加快加载时间。这将加载时间从 60 秒减少到 3
App Domains 是一个红鲱鱼