关于大型客户端项目的思考-Toy模板网

这篇具有很好参考价值的文章主要介绍了关于大型客户端项目的思考。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

大型客户端项目在使用过程中一般会面临几个问题:

a. 启动慢
b. 运行慢
c. 稳定性低
基于以上问题进行一些思考,最终总结出该方案.

解决方案

当项目过大时,需要加载的程序集也越多,对应程序需要启动的时间也越长,如果在这个时候有一个启动的过渡页,从使用的角度看,能在启动后快速看到程序反应,则在某种程度上加快了程序的启动速度.

以VS2022为例,在启动的时候并不是第一时间去加载整个IDE窗口,而是使用了一个过渡,先启动一个启动页再过渡到导航窗口,来选择要编辑的项目,再而去加载整个编辑界面.即:
启动窗口->导航窗口->编辑窗口
在启动窗口时,可以看到VS主进程并没有真正启动,而是到导航窗口时才启动,这个时候也只是启动了7个子进程,直到编辑窗口时,以我的设置为例子进程数运行到13个,达到真正使用的状态.
那么退回来讲,如果在启动时,直接把这13个子进程的事情合并到一个主进程来做,可想而知,启动速度会慢多少倍
而这个情况正是我们在开发客户端项目时使用的逻辑.所以以此为鉴,要做的就是拆分主进程.

从稳定性来说,不管是VS还是CEFSharp,也都是采用多进程的方法,我在使用VS2022的时候遇到过某个模块功能崩溃但不影响主功能使用的情况,而CEFSharp中的CefSharp.BrowserSubprocess进程更是为每个页启动一个进程来做渲染等工作,好处则是即使其中一个页面崩溃,也不影响其他页面.我在开发过程中集成过好多第三方SDK,不限于腾讯阿里,但都在使用过程中遇到各种问题导致SDK内部崩溃,使整个程序崩溃的情况,这些也并不能通过良好的代码及经验来规避,只能等待SDK方去解决,但最终不管是体现在领导或用户方,都是开发人员来背锅,那么要怎么甩锅,我认为依然是多进程.

那说了这么多,多进程真的那么好么?
好是真的好,但也要从实际业务去考虑

优点:

启动快,安全性高,稳定性高,且可以更好的利用CPU

缺点:

启动进程成本高,进程间通讯成本高

所以并不能一味的去靠多进程,如果存在大的模块或者第三方服务时,才应该去考虑多进程实现.

多进程架构实现

说了这么说,那么以一个调用阿里播放器SDK的程序为例来进行一个实现.

Shell进程:

展示欢迎页
检测版本更新
当存在版本更新时,直接对主程序集进行更新[主进程也可增加反更新Shell逻辑],增加用户体验(传统做法为,主进程启动时进行版本检测,如需要更新时再启动更新进程)
单例启动控制
传统的单例启动是控制主进程,一次主进程存在,二次主进程则把启动参数抛给一次主进程.
而先启动Shell进程,要做的就是判断主进程是否存在,如果存在直接把启动参数抛给主进程并关闭自己

Main进程:

程序的主要功能进程,被Shell进行调起,可接收Shell抛来的启动参数
集成播放器控件(该控件和播放器SDK完全解耦,负责渲染SDK回调的视频数据和发送控制命令)

Player进程:

实例播放器SDK,并把SDK中的视频数据回调给播放器控件

技术实现

关于进程间通讯,这里主要使用两种通讯方式,管道和共享内存(C#中SharedMemoryManager库)
a. Shell和Main进程的通讯,可使用管道来实现.
b. Main(具体为播放器控件)和Player则使用管道和共享内存两种方式
播放器的控制逻辑使用管道来实现,而视频帧的数据回调则使用共享内存来实现.