關于大型客戶端項目的思考

大型客戶端項目在使用過程中一般會面臨幾個問題:

a. 啟動慢b. 運行慢c. 穩(wěn)定性低基于以上問題進行一些思考,最終總結出該方案.

(資料圖)

解決方案

當項目過大時,需要加載的程序集也越多,對應程序需要啟動的時間也越長,如果在這個時候有一個啟動的過渡頁,從使用的角度看,能在啟動后快速看到程序反應,則在某種程度上加快了程序的啟動速度.

以VS2022為例,在啟動的時候并不是第一時間去加載整個IDE窗口,而是使用了一個過渡,先啟動一個啟動頁再過渡到導航窗口,來選擇要編輯的項目,再而去加載整個編輯界面.即:啟動窗口->導航窗口->編輯窗口在啟動窗口時,可以看到VS主進程并沒有真正啟動,而是到導航窗口時才啟動,這個時候也只是啟動了7個子進程,直到編輯窗口時,以我的設置為例子進程數(shù)運行到13個,達到真正使用的狀態(tài).那么退回來講,如果在啟動時,直接把這13個子進程的事情合并到一個主進程來做,可想而知,啟動速度會慢多少倍而這個情況正是我們在開發(fā)客戶端項目時使用的邏輯.所以以此為鑒,要做的就是拆分主進程.

從穩(wěn)定性來說,不管是VS還是CEFSharp,也都是采用多進程的方法,我在使用VS2022的時候遇到過某個模塊功能崩潰但不影響主功能使用的情況,而CEFSharp中的CefSharp.BrowserSubprocess進程更是為每個頁啟動一個進程來做渲染等工作,好處則是即使其中一個頁面崩潰,也不影響其他頁面.我在開發(fā)過程中集成過好多第三方SDK,不限于騰訊阿里,但都在使用過程中遇到各種問題導致SDK內部崩潰,使整個程序崩潰的情況,這些也并不能通過良好的代碼及經(jīng)驗來規(guī)避,只能等待SDK方去解決,但最終不管是體現(xiàn)在領導或用戶方,都是開發(fā)人員來背鍋,那么要怎么甩鍋,我認為依然是多進程.

那說了這么多,多進程真的那么好么?好是真的好,但也要從實際業(yè)務去考慮

優(yōu)點:

啟動快,安全性高,穩(wěn)定性高,且可以更好的利用CPU

缺點:

啟動進程成本高,進程間通訊成本高

所以并不能一味的去靠多進程,如果存在大的模塊或者第三方服務時,才應該去考慮多進程實現(xiàn).

多進程架構實現(xiàn)

說了這么說,那么以一個調用阿里播放器SDK的程序為例來進行一個實現(xiàn).

Shell進程:展示歡迎頁檢測版本更新當存在版本更新時,直接對主程序集進行更新[主進程也可增加反更新Shell邏輯],增加用戶體驗(傳統(tǒng)做法為,主進程啟動時進行版本檢測,如需要更新時再啟動更新進程)單例啟動控制傳統(tǒng)的單例啟動是控制主進程,一次主進程存在,二次主進程則把啟動參數(shù)拋給一次主進程.而先啟動Shell進程,要做的就是判斷主進程是否存在,如果存在直接把啟動參數(shù)拋給主進程并關閉自己Main進程:

程序的主要功能進程,被Shell進行調起,可接收Shell拋來的啟動參數(shù)集成播放器控件(該控件和播放器SDK完全解耦,負責渲染SDK回調的視頻數(shù)據(jù)和發(fā)送控制命令)

Player進程:

實例播放器SDK,并把SDK中的視頻數(shù)據(jù)回調給播放器控件

技術實現(xiàn)

關于進程間通訊,這里主要使用兩種通訊方式,管道和共享內存(C#中SharedMemoryManager庫)a. Shell和Main進程的通訊,可使用管道來實現(xiàn).b. Main(具體為播放器控件)和Player則使用管道和共享內存兩種方式播放器的控制邏輯使用管道來實現(xiàn),而視頻幀的數(shù)據(jù)回調則使用共享內存來實現(xiàn).

其他

該方案為在使用其他軟件時的觀察和思考,包括一些利用ChatGPT4.0得到的信息,僅為個人理解.軟件及庫不限于:VS2022,CEFSharp,網(wǎng)易云音樂,微信等.

關鍵詞：