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

(資料圖)

當(dāng)項(xiàng)目過大時(shí),需要加載的程序集也越多,對(duì)應(yīng)程序需要啟動(dòng)的時(shí)間也越長,如果在這個(gè)時(shí)候有一個(gè)啟動(dòng)的過渡頁,從使用的角度看,能在啟動(dòng)后快速看到程序反應(yīng),則在某種程度上加快了程序的啟動(dòng)速度.

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

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

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

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

啟動(dòng)進(jìn)程成本高,進(jìn)程間通訊成本高

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

說了這么說,那么以一個(gè)調(diào)用阿里播放器SDK的程序?yàn)槔齺磉M(jìn)行一個(gè)實(shí)現(xiàn).

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

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

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

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

關(guān)鍵詞：