关于线程和应用软件UI的那些事儿

时隔上次投稿到现在约1个月，虽然比较短暂，但经历了239薄壁转体项目的初次洗礼后，小小的收获便是对应用软件UI的线程认识有了新的提升，所以就此与各位同仁分享。

通常规模的项目，配置数据和动态数据量都不大，在软件运行过程中，无论从初始化读数据还是从保存数据至数据库或其他文件都显得电脑内存操控起来游刃有余。但当数据上升到30000单位，且每个单位数据关联3D模型时，一切都显得不那么自如了，如果说由于显卡配置低造成3D显示卡顿是个“硬伤”还有情可原的话，那么在主线程中已有UI界面显示情况下，另开新线程，将另一个UI放入新开线程就显得更加艰难了。可以直白的说，一般情况下，后台是不支持这样做的。因为在新线程新开界面，意味着新界面的控件的后台要与主界面的后台通信，但界面生成的本质是通过高频重绘得到界面图像的，虽然是“高频重绘”，却远远赶不上“纯”后台程序通信的频率，难么假设主界面程序支持新线程新开界面，就意味着界面对象所提供的通信机制必须可以做到和“纯”后台模块通信机制一样的速率，显然这是不可能的，所以可以说：任何界面程序，就界面角度说，不是线程安全的。

那难道无法实现不同线程，不同界面的后台通信么，当然可以实现，只不过“各种官方”实例不会提供这种效果的实现方法，更多实现来自广大无私的码工进阶和共享，实现的方法五花八门，但通常都是1个模式，找到界面显示中利用栈空间运行的方法，当栈空间释放后，在定时器中重启界面的重绘，并将事件注册到相关集合中。然后通常这样的做法并不保证一定解决卡顿的问题，如果让无法奏效，建议有三个思路。其一是将程序模块分散到可以串行执行的各个类中，根据流程尽量让任务顺序执行。其二是采取分布式缓存，提高性能。其三是提高本地相关硬件配置。后两种方法会提高固资成本，但当软件系统足够大，处理数据足够多时，后两种方法反而节约成本。