【插件式框架探索系列】使用多UI线程提升性能

了解WPF线程模型的都知道,UI线程负责呈现和管理UI,而UI元素(派生自DispatcherObject)只能由创建该元素的线程来访问,这就导致了一些耗时的UI操作将影响到整个应用程序性能,未响应及漫长的等待有时会令人抓狂,而UI线程一度成为了不可越逾的鸿沟。

对于框架来说,一个插件的行为不应该影响到其它插件及整个平台的稳定性,后来在看了《Running WPF Application with Multiple UI Threads》和《DispatcherObject与WPF线程模型》两篇文章后,思维一下子就打开了,前一篇讲的是在WPF应用程序中使用多个UI线程,如果每个独立的插件都处于不同的UI线程,自然性能会有所提升,而后一篇则深入的分析了win32的消息循环和wpf的线程模型,非常透彻。

下面是创建新UI线程的方法

Thread thread = new Thread(() =>
{
     Window win = new Window { Title = string.Format("Thread id:{0}", Thread.CurrentThread.ManagedThreadId) };
     win.Show();
     Dispatcher.Run();
});
thread.IsBackground = true;
thread.SetApartmentState(ApartmentState.STA);
thread.Start();

如此Window将会在新的线程中运行,Dispatcher.Run()使当前线程进入消息循环,而设置线程的IsBackground为True是为了保证在程序退出时自动回收该线程,否则会出现进程驻留问题。

时间: 2024-12-30 15:41:39

【插件式框架探索系列】使用多UI线程提升性能的相关文章

【插件式框架探索系列】应用程序域(AppDomain)

应用程序域(AppDomain)已经不是一个新名词了,只要熟悉.net的都知道它的存在,不过我们还是先一起来重新认识下应用程序域吧,究竟它是何方神圣. 应用程序域 众所周知,进程是代码执行和资源分配的最小单元,每个进程都拥有独立的内存单元,而进程之间又是相互隔离的,自然而然,进程成为了代码执行的安全边界. 一个进程对应一个应用程序是一个普遍的认知,而.net却打破了这一惯例,因为它带来了应用程序域这一全新的概念,CLR可使用应用程序域来提供应用程序之间的隔离,而一个进程中可以运行多个应用程序域,

【插件式框架探索系列】建立基于委托的订阅发布机制

前些时候有个想法,想把自己感觉很有意思且方便平时开发的东西合起来,建立一个Framework,它会让开发变得更得心应手,可惜后来随着更多的东西被加入其中,越来越发觉这可能并不是一个开发者需要的东西,因为它太杂了,是的,作为一个Framework,还是单纯点的好,后来工作也忙了,就停滞了.这几天出差广州,夜来无事,便捡个模块来说道说道. Messenger 在平时的开发中,数据的传递.处理等可以通过事件机制来完成,但是事件机制会引入耦合,当然这种耦合很多时候是合理的,但是却有那么一些时候这种耦合却

插件式框架开发的优势劣势

问题描述 插件式开发的优势不用说了,楼主有个工业上位机的小项目基本做得差不多了,和下位机用串口和以太网通信.现在想把两种通信做成主程序的插件(看起来高端也有其他好处)但是众所周知,插件是根据主程序的接口来实现的,我想问下这样可移植性不就低了吗?假如别的部门需要我的串口通信插件,他们的主程序得弄个跟我插件一样的接口先,对吗?另外我们后面想用第三方控件重做UI,UI层能用插件来优化更新吗?就是插件改变UI的意思插件也是继承接口的类库编成dll文件给别人用,那直接写一个类变成dll文件,别人用里面的方

请问windows的.net平台下比较好的轻量级插件式框架,哪个比较好?

问题描述 请问windows的.net平台下比较好的轻量级插件式框架,哪个比较好? 请问.net平台下比较好的轻量级插件式框架,哪个比较好? 比如SCSF,MEF等 解决方案 FireBreath还不错,可以试试啊

即插即用插件式框架的程序集处理

摘要: 在多层架构中我们经常都会通过工厂模式来对数据库层的类进行初始化,有些会用抽象类作为基类,有些会用接口然后通过反射来对其进行初始化.而把需要初始化的类型和程序集通过字符串保存在配置文件中或数据库中等等,今天我将要介绍的是不需要保存配置文件而去BIN目录寻找你所要的抽象类或接口的子类并将其初始化后返回.这种方法可以用在其他方面,当然这会对应用程序的性能造成影响,所以我们应该适当的应用他. 检索程序集: 每一个写程序的人都知道,程序就是像建房子,首先要先规划设计然后一块砖一块砖的从地基开始建起

(1)从底层设计,探讨插件式GIS框架的实现

文章版权由作者李晓晖和博客园共有,若转载请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/.   研一时,听当时的师兄推荐,买了蒋波涛的一本关于GIS插件框架的书.当时一边看书一边将其中的例子完整的实现了一遍,收益匪浅.后来由于项目需要,也做过一个插件的C/S系统,用的是微软提供的MEF框架.在这个系统中,把蒋波涛在他的书中没有涉及到的插件和插件的通信完成了.不过,蒋波涛的那本书,涉及到了插件系统的很多底层内容,其中关于插件引擎的设计尤其值得学习.近来,我将自

从底层设计开始探讨插件式GIS框架的实现

三年前,听当时的师兄推荐,买了蒋波涛的一本关于GIS插件框架的书.当时一边看书一边将其中的例子完整的实现了一遍,收益匪浅.后来由于项目需要,也做过一个插件的C/S系统,用的是微软提供的MEF框架.在这个系统中,把蒋波涛在他的书中没有涉及到的插件和插件的通信完成了.不过,蒋波涛的那本书,涉及到了插件系统的很多底层内容,其中关于插件引擎的设计尤其值得学习.近来,我将自己当年实现的那个例子进行了一个总结,和大家一起分享. 1.插件式框架的组成 (1).框架分为宿主程序和插件对象两部分 (2).两部分交

我的插件式桌面软件框架类库(一)XFrmWork简介

一. 综述 工欲善其事,必先利其器.器可以来自他人,也可以自造.我进实验室的第一个项目便是开发一款行业软件,相比于真正的商业软件,它的系统本身真的很简单.但真是应了那句话,"大学不适合做软件",整个系统交互复杂,设计冗余,维护起来很困难.在项目结题之后,整个系统便存在硬盘里再也没有人问津.虽然我只开发了其中一个模块,但依旧心痛. 痛定思痛,我希望能有一个成熟简单的桌面框架,解决多数桌面开发遇到的问题:界面显示,数据库,插件式架构,调试输出,网络连接等.同时尽可能减少多个开发者之间的耦合

构建插件式的应用程序框架(一)----订立契约

问题描述 无论是用COM的方式,还是普通DLL,抑或.NET方式来实现插件框架,首先要面临的问题就是如何订立契约.如同我上一篇文章讲到的一样,契约是应用程序和插件之间进行交互的依据和凭证.应用程序必须声明我有什么样的功能可被插件使用,并且插件必须符合什么条件才能被我使用.反之,插件必须要知道应用程序提供什么样的功能,我才能将自己的功能融入到应用程序的体系中.本系列文章主要讲如何使用.NET实现插件式的应用程序框架,所以其它的方式我就不再提了.如何使用.NET订立契约呢?首先想到的Interfac