對(duì)于大型的應(yīng)用軟件，特別是客戶端應(yīng)用軟件，應(yīng)用啟動(dòng)過(guò)程中，需要執(zhí)行大量的邏輯，包括各個(gè)模塊的初始化和注冊(cè)等等邏輯。大型應(yīng)用軟件的啟動(dòng)過(guò)程都是非常復(fù)雜的，而客戶端應(yīng)用軟件是對(duì)應(yīng)用的啟動(dòng)性能有所要求的，不同于服務(wù)端的應(yīng)用軟件。設(shè)想，用戶雙擊了桌面圖標(biāo)，然而等待幾分鐘，應(yīng)用才啟動(dòng)完畢，那用戶下一步會(huì)不會(huì)就是點(diǎn)擊卸載了。為了權(quán)衡大型應(yīng)用軟件在啟動(dòng)過(guò)程，既需要執(zhí)行復(fù)雜的啟動(dòng)邏輯，又需要關(guān)注啟動(dòng)性能，為此過(guò)程造一個(gè)框架是一個(gè)完全合理的事情。我所在的團(tuán)隊(duì)為啟動(dòng)過(guò)程造的庫(kù)，就是本文將要和大家介紹我所在團(tuán)隊(duì)開(kāi)源的 dotnetCampus.ApplicationStartupManager 啟動(dòng)流程框架的庫(kù)

背景

這個(gè)庫(kù)的起源是一次聽(tīng) VisualStudio 團(tuán)隊(duì)的分享，當(dāng)時(shí)大佬們告訴我，為了優(yōu)化 VisualStudio 的啟動(dòng)性能，他的團(tuán)隊(duì)制定了一個(gè)有趣的方向，那就是在應(yīng)用啟動(dòng)的時(shí)候?qū)?CPU 和內(nèi)存和磁盤跑滿。當(dāng)然，這是一個(gè)玩笑的話，本來(lái)的意思是，在 VisualStudio 應(yīng)用啟動(dòng)的時(shí)候，應(yīng)該充分壓榨計(jì)算機(jī)的性能。剛好，我所在的團(tuán)隊(duì)也有很多個(gè)大型的應(yīng)用，代碼的 MergeRequest 數(shù)都破萬(wàn)的應(yīng)用。這些應(yīng)用的邏輯復(fù)雜度都是非常高的，原本只能是采用單個(gè)線程執(zhí)行，從而減少模塊之間的依賴復(fù)雜度導(dǎo)致的坑。但在后續(xù)為了優(yōu)化應(yīng)用軟件的啟動(dòng)性能，考慮到進(jìn)行機(jī)器性能的壓榨策略，其中就包括了多線程的方式

然而在開(kāi)多線程的時(shí)候，自然就會(huì)遇到很多線程相關(guān)的問(wèn)題，最大的問(wèn)題就是如何處理各個(gè)啟動(dòng)模塊之間的依賴關(guān)系。如果沒(méi)有一個(gè)較好的框架來(lái)進(jìn)行處理，只靠開(kāi)發(fā)者的個(gè)人能力來(lái)處理，做此重構(gòu)是完全不靠譜的，或者說(shuō)這個(gè)事情是做不遠(yuǎn)的，也許這個(gè)版本能優(yōu)化，但下個(gè)版本呢

還有一點(diǎn)非常重要的是如何做啟動(dòng)性能的監(jiān)控，如分析各個(gè)啟動(dòng)項(xiàng)的耗時(shí)情況。在進(jìn)行逐個(gè)啟動(dòng)業(yè)務(wù)模塊的性能優(yōu)化之前，十分有必要進(jìn)行啟動(dòng)模塊的性能測(cè)量。而有趣的是，啟動(dòng)模塊是非常和妖魔的用戶環(huán)境相關(guān)的，也就是在實(shí)驗(yàn)室里測(cè)量的結(jié)果，和實(shí)際的用戶使用的結(jié)果是有很大的誤差的。這也就給啟動(dòng)流程框架提了一個(gè)重要的需求，那就是能支持方便的對(duì)各個(gè)啟動(dòng)模塊進(jìn)行性能測(cè)量監(jiān)控

由于有多個(gè)項(xiàng)目都期望接入啟動(dòng)流程框架，因此啟動(dòng)流程框架應(yīng)該做到足夠的抽象，最好不能有耦合單一項(xiàng)目的功能

經(jīng)過(guò)了大概一年的開(kāi)發(fā)時(shí)間，在 2019 年正式將啟動(dòng)流程框架投入使用。當(dāng)前在近千萬(wàn)臺(tái)設(shè)備上跑著啟動(dòng)流程框架的邏輯

當(dāng)前此啟動(dòng)流程框架的庫(kù)在 GitHub 上，基于最友好的 MIT 協(xié)議，也就是大家可以隨便用的協(xié)議進(jìn)行開(kāi)源，開(kāi)源地址：?https://github.com/dotnet-campus/dotnetCampus.ApplicationStartupManager

功能

我所在的團(tuán)隊(duì)開(kāi)源的?ApplicationStartupManager?啟動(dòng)流程框架的庫(kù)提供了如下的賣點(diǎn)

• 自動(dòng)構(gòu)建啟動(dòng)流程圖

• 支持高性能異步多線程的啟動(dòng)任務(wù)項(xiàng)執(zhí)行

• 支持 UI 線程自動(dòng)調(diào)度邏輯

• 動(dòng)態(tài)分配啟動(dòng)任務(wù)資源

• 支持接入預(yù)編譯框架

• 支持所有的 .NET 應(yīng)用

• 啟動(dòng)流程耗時(shí)監(jiān)控

啟動(dòng)流程圖

各個(gè)啟動(dòng)任務(wù)項(xiàng)之間，必然存在顯式或隱式依賴，如依賴某個(gè)邏輯或模塊初始化，或者依賴某個(gè)服務(wù)的注冊(cè)，或者有執(zhí)行時(shí)機(jī)的依賴。在開(kāi)發(fā)者梳理完成依賴之后，給各個(gè)啟動(dòng)任務(wù)項(xiàng)確定相互之間的依賴關(guān)系，即可根據(jù)此依賴關(guān)系構(gòu)建出啟動(dòng)流程圖

假設(shè)有以下幾個(gè)啟動(dòng)任務(wù)項(xiàng)，啟動(dòng)任務(wù)項(xiàng)之間有相互的依賴關(guān)系，如下圖，使用箭頭表示依賴關(guān)系

• 啟動(dòng)任務(wù)項(xiàng) A ：最先啟動(dòng)的啟動(dòng)任務(wù)項(xiàng)，如日志或容器的初始化啟動(dòng)任務(wù)項(xiàng)

• 啟動(dòng)任務(wù)項(xiàng) B ：一些基礎(chǔ)服務(wù)，但是需要依賴 A 啟動(dòng)任務(wù)項(xiàng)完成才能執(zhí)行

• 啟動(dòng)任務(wù)項(xiàng) C ：依賴 B 啟動(dòng)任務(wù)項(xiàng)的執(zhí)行完成

• 啟動(dòng)任務(wù)項(xiàng) D ：另一個(gè)獨(dú)立的模塊，和 B C E 啟動(dòng)任務(wù)項(xiàng)沒(méi)有聯(lián)系，但是也依賴 A 啟動(dòng)任務(wù)項(xiàng)的完成

• 啟動(dòng)任務(wù)項(xiàng) E ：同時(shí)依賴 B C 啟動(dòng)任務(wù)項(xiàng)的完成

• 啟動(dòng)任務(wù)項(xiàng) F ：同時(shí)依賴 A D 啟動(dòng)任務(wù)項(xiàng)的完成

以上的啟動(dòng)任務(wù)項(xiàng)可以構(gòu)成一個(gè)有向無(wú)環(huán)啟動(dòng)流程圖，每個(gè)啟動(dòng)任務(wù)項(xiàng)都可以有自己的前置或后置。那為什么需要是無(wú)環(huán)呢？要是有兩個(gè)啟動(dòng)任務(wù)項(xiàng)是相互等待依賴的，那就自然就無(wú)法成功啟動(dòng)了，如下圖，有三個(gè)啟動(dòng)任務(wù)項(xiàng)都在相互依賴，那也就是說(shuō)無(wú)論哪個(gè)啟動(dòng)任務(wù)項(xiàng)先啟動(dòng)，都是不符合預(yù)期的，因?yàn)橄葐?dòng)的啟動(dòng)任務(wù)項(xiàng)的前置沒(méi)有被滿足，啟動(dòng)過(guò)程中邏輯上是存在有前置依賴沒(méi)有執(zhí)行

為了更好的構(gòu)建啟動(dòng)流程圖，在邏輯上也加上了兩個(gè)虛擬的節(jié)點(diǎn)，那就是啟動(dòng)點(diǎn)和結(jié)束點(diǎn)，無(wú)論是哪個(gè)啟動(dòng)任務(wù)項(xiàng)，都會(huì)依賴虛擬的啟動(dòng)點(diǎn)，以及都會(huì)跟隨著結(jié)束點(diǎn)

另外，具體業(yè)務(wù)方也會(huì)定義自己的關(guān)聯(lián)啟動(dòng)過(guò)程，也就是預(yù)設(shè)的啟動(dòng)節(jié)點(diǎn)，關(guān)鍵啟動(dòng)過(guò)程點(diǎn)將被各個(gè)啟動(dòng)項(xiàng)所依賴，如此即可人為將啟動(dòng)過(guò)程分為多個(gè)階段

例如可以將啟動(dòng)過(guò)程分為如下階段

• 啟動(dòng)點(diǎn)：虛擬的節(jié)點(diǎn)，表示應(yīng)用啟動(dòng)，用于構(gòu)建啟動(dòng)流程圖

• 基礎(chǔ)設(shè)施：表示在此之前應(yīng)該做啟動(dòng)基礎(chǔ)服務(wù)的邏輯，例如初始化日志，初始化容器等等。其他啟動(dòng)任務(wù)項(xiàng)可以依賴基礎(chǔ)設(shè)施，從而認(rèn)為在基礎(chǔ)設(shè)施之后執(zhí)行的啟動(dòng)任務(wù)項(xiàng)，基礎(chǔ)設(shè)施已準(zhǔn)備完成

• 窗口啟動(dòng)：在客戶端程序的窗口初始化之前，需要完成 UI 的準(zhǔn)備邏輯，例如樣式資源和必要的數(shù)據(jù)準(zhǔn)備，或者 ViewModel 的注入等。在窗口啟動(dòng)之后，即可對(duì) UI 元素執(zhí)行邏輯，或者注冊(cè) UI 強(qiáng)相關(guān)邏輯?；蛘呤窃诖翱趩?dòng)之后，執(zhí)行那些不需要在主界面顯示之前執(zhí)行的啟動(dòng)任務(wù)項(xiàng)，從而提升主界面顯示性能

• 應(yīng)用啟動(dòng)：完成了啟動(dòng)的邏輯，在應(yīng)用啟動(dòng)之后的啟動(dòng)任務(wù)項(xiàng)都是屬于可以慢慢執(zhí)行的邏輯，例如觸發(fā)應(yīng)用的自動(dòng)更新，例如執(zhí)行一下日志文件清理等等

• 結(jié)束點(diǎn)：虛擬的節(jié)點(diǎn)，表示應(yīng)用啟動(dòng)過(guò)程完全完成，用于構(gòu)建啟動(dòng)流程圖

如圖，每個(gè)啟動(dòng)任務(wù)項(xiàng)可以選擇依賴的是具體的某個(gè)啟動(dòng)任務(wù)項(xiàng)，也可以選擇依賴的是關(guān)鍵啟動(dòng)過(guò)程點(diǎn)

通過(guò)此邏輯，可以為后續(xù)的優(yōu)化做準(zhǔn)備，也方便上層業(yè)務(wù)開(kāi)發(fā)者開(kāi)發(fā)業(yè)務(wù)層的啟動(dòng)任務(wù)項(xiàng)。讓上層業(yè)務(wù)開(kāi)發(fā)者可以比較清晰了解自己新寫的啟動(dòng)任務(wù)項(xiàng)應(yīng)該放在哪個(gè)地方，也可以提供了調(diào)試各個(gè)模塊的啟動(dòng)任務(wù)項(xiàng)的依賴情況，了解是否存在循環(huán)的依賴邏輯

高性能異步多線程的啟動(dòng)任務(wù)項(xiàng)執(zhí)行

為了更好的壓榨機(jī)器性能，進(jìn)行多線程啟動(dòng)是必要的。在完成了啟動(dòng)流程圖的構(gòu)建之后，即可將啟動(dòng)任務(wù)項(xiàng)畫成樹(shù)形，自然也就方便進(jìn)行多線程調(diào)度?；?.NET 的 Task 方式調(diào)度，可以實(shí)現(xiàn)多線程異步等待，解決多個(gè)啟動(dòng)任務(wù)項(xiàng)的依賴在多線程情況下的線程安全問(wèn)題

如使用線程池的 Task 調(diào)度，可以從邏輯上，將不同的啟動(dòng)任務(wù)項(xiàng)的啟動(dòng)任務(wù)鏈劃分為給不同的線程執(zhí)行。實(shí)際執(zhí)行的線程是依靠線程池調(diào)度，甚至實(shí)際執(zhí)行上，線程池只是用了兩個(gè)實(shí)際線程在執(zhí)行

對(duì)應(yīng)用的啟動(dòng)過(guò)程中，在不明白 .NET 線程池調(diào)度機(jī)制的情況下，將在開(kāi)啟多線程問(wèn)題上稍微有一點(diǎn)爭(zhēng)議。核心爭(zhēng)議的就是如果一個(gè)應(yīng)用啟動(dòng)過(guò)程中，占滿了 CPU 資源，是否就讓用戶電腦卡的不能動(dòng)了。其實(shí)上面這個(gè)問(wèn)題不好回答，如果大家有此疑惑，那就請(qǐng)聽(tīng)我細(xì)細(xì)分析一下。首先一點(diǎn)就是問(wèn)題本身，先問(wèn) 問(wèn)題 本身一個(gè)問(wèn)題，如果只是開(kāi)一個(gè)線程啟動(dòng)，會(huì)不會(huì)也讓用戶的電腦卡的不能動(dòng)了？答案是 是的，完全取決于用戶電腦，包括電腦配置以及電腦的妖魔環(huán)境，例如一個(gè)渣配的設(shè)備配合國(guó)產(chǎn)的好幾個(gè)殺毒軟件一起，那么在應(yīng)用啟動(dòng)的瞬間，就有大量的殺毒工作在執(zhí)行，自然就卡的不能動(dòng)了。而且，電腦卡的不能動(dòng)了，是不是和 CPU 被占滿是必然關(guān)系？答案是 完全不是，應(yīng)用啟動(dòng)過(guò)程中，一定會(huì)存在 DLL 加載的過(guò)程，特別是應(yīng)用的冷啟動(dòng)過(guò)程，大量的文件讀寫，對(duì)于一些機(jī)械盤來(lái)說(shuō)，將會(huì)占滿磁盤的讀寫，自然也就能讓電腦卡的不能動(dòng)了，這個(gè)過(guò)程和是否開(kāi)啟多線程，其實(shí)關(guān)系很小，畢竟機(jī)械盤和 CPU 之間的性能擺在這。第二個(gè)是卡的時(shí)間是否重要，例如應(yīng)用開(kāi)了多線程就卡了 500 毫秒，而如果應(yīng)用啟動(dòng)只用單線程則需要 4 x 500ms = 2s 的耗時(shí)，那是否此時(shí)開(kāi)多線程劃得來(lái)呢？這個(gè)是需要權(quán)衡的，不同的應(yīng)用邏輯自然不同，例如生產(chǎn)力工具，我本來(lái)開(kāi)機(jī)就是為了用此工具，例如寫代碼用的 VisualStudio 工具，我打開(kāi)了這個(gè)應(yīng)用，過(guò)程中自然沒(méi)有其他同步使用的需求，卡了就卡了咯。最后一個(gè)問(wèn)題就是，開(kāi)啟 .NET 的多線程完全不等于占滿了 CPU 資源，別忘了 IO 異步哦

當(dāng)然了，會(huì)接入應(yīng)用流程的開(kāi)發(fā)者肯定不屬于新手，相信對(duì)于線程方面知識(shí)已有所了解，會(huì)自己選擇合適的方式執(zhí)行啟動(dòng)任務(wù)項(xiàng)。這也側(cè)面告訴大家，本啟動(dòng)流程框架的庫(kù)接入是有一定的門檻的

支持 UI 線程自動(dòng)調(diào)度邏輯

對(duì)于客戶端應(yīng)用，自然有一個(gè)特殊的線程是 UI 線程，啟動(dòng)過(guò)程，有很多邏輯是需要在 UI 線程執(zhí)行的。由于 .NET 系的各個(gè)應(yīng)用框架的 UI 線程調(diào)度都不咋相同，因此需要啟動(dòng)流程框架執(zhí)行一定量的適配

在具體的啟動(dòng)任務(wù)項(xiàng)上標(biāo)記當(dāng)前的啟動(dòng)任務(wù)項(xiàng)需要在 UI 線程執(zhí)行即可，框架層將會(huì)自動(dòng)調(diào)度啟動(dòng)任務(wù)項(xiàng)到 UI 線程執(zhí)行

設(shè)計(jì)上，默認(rèn)將會(huì)調(diào)度啟動(dòng)任務(wù)項(xiàng)到非 UI 線程執(zhí)行

動(dòng)態(tài)分配啟動(dòng)任務(wù)資源

在用戶端的各個(gè)啟動(dòng)任務(wù)項(xiàng)的耗時(shí)和在實(shí)驗(yàn)室里測(cè)試的結(jié)果，無(wú)論是開(kāi)發(fā)機(jī)還是測(cè)試機(jī)，大多數(shù)時(shí)候都是有很大的差值的。如果按照固定的順序去執(zhí)行啟動(dòng)任務(wù)項(xiàng)，自然有很多啟動(dòng)時(shí)間都在空白的等待上。本啟動(dòng)流程框架庫(kù)支持在啟動(dòng)過(guò)程中，自動(dòng)根據(jù)各個(gè)啟動(dòng)任務(wù)項(xiàng)的耗時(shí)，動(dòng)態(tài)進(jìn)行調(diào)度

核心方法就是構(gòu)建出來(lái)的啟動(dòng)流程圖，支持各個(gè)任務(wù)的等待邏輯，基于 Task 等待機(jī)制，即可進(jìn)行動(dòng)態(tài)調(diào)度等待邏輯，從而實(shí)現(xiàn)動(dòng)態(tài)編排啟動(dòng)任務(wù)項(xiàng)，在緊湊的時(shí)間內(nèi)讓多條線程排滿啟動(dòng)任務(wù)的執(zhí)行。如果對(duì)應(yīng)的上層業(yè)務(wù)開(kāi)發(fā)者能正確使用 Task 機(jī)制，例如正確使用異步等待，可以實(shí)現(xiàn)在啟動(dòng)過(guò)程中極大隱藏

支持接入預(yù)編譯框架

啟動(dòng)過(guò)程是屬于性能敏感的部分，各個(gè)模塊的啟動(dòng)任務(wù)項(xiàng)如何收集是一個(gè)很大的問(wèn)題。啟動(dòng)部分屬于性能敏感部分，不合適采用反射的機(jī)制。好在?dotnet campus?里面有技術(shù)儲(chǔ)備，在 2018 年的時(shí)候就開(kāi)源了?SourceFusion?預(yù)編譯框架，后面在 2020 年時(shí)吸取了原有?SourceFusion?的挖坑經(jīng)驗(yàn)，重新開(kāi)源了?dotnetCampus.Telescope?預(yù)編譯框架，新開(kāi)源的?dotnetCampus.Telescope?也放在?SourceFusion?倉(cāng)庫(kù)中

在?ApplicationStartupManager?啟動(dòng)流程框架開(kāi)發(fā)之初就考慮了對(duì)接預(yù)編譯框架，通過(guò)預(yù)編譯提供了無(wú)須反射即可完成啟動(dòng)任務(wù)項(xiàng)收集的能力，可以極大減少因?yàn)閱?dòng)過(guò)程中反射程序集的性能損耗

對(duì)接了預(yù)編譯框架，相當(dāng)于原本需要在用戶端執(zhí)行的邏輯的時(shí)間，搬到開(kāi)發(fā)者編譯時(shí)，在開(kāi)發(fā)者編譯時(shí)執(zhí)行了原本需要在用戶端執(zhí)行的邏輯。如此可以減少用戶端的執(zhí)行邏輯的時(shí)間

接入了預(yù)編譯框架，可以實(shí)現(xiàn)在開(kāi)發(fā)者編譯時(shí)，將所有項(xiàng)目的啟動(dòng)任務(wù)項(xiàng)收集起來(lái)，包括啟動(dòng)任務(wù)項(xiàng)類型和委托創(chuàng)建啟動(dòng)任務(wù)項(xiàng)，以及啟動(dòng)任務(wù)項(xiàng)的 Attribute 特性

啟動(dòng)流程耗時(shí)監(jiān)控

對(duì)于大型應(yīng)用來(lái)說(shuō)，很重要的一點(diǎn)就是關(guān)注在用戶端的運(yùn)行效果。啟動(dòng)過(guò)程中，監(jiān)控是十分重要的。監(jiān)控最大的意義在于：

第一，可以了解到在用戶設(shè)備上，各個(gè)啟動(dòng)任務(wù)項(xiàng)的實(shí)際執(zhí)行耗時(shí)情況，從而在后續(xù)版本進(jìn)行性能優(yōu)化的時(shí)候，有數(shù)據(jù)支撐。否則憑借在開(kāi)發(fā)或測(cè)試端有限的設(shè)備上，很難跑出真正的性能瓶頸。如不僅關(guān)注在用戶設(shè)備上的 95 線啟動(dòng)分布，所謂 95 線就是在百分之九十五的用戶上的啟動(dòng)耗時(shí)分布，也可以關(guān)注關(guān)注 95 線到 99 線中間的用戶的啟動(dòng)分布，了解一些比較特殊的設(shè)備的環(huán)境，從而做特別的優(yōu)化

第二，可以做版本對(duì)比，做預(yù)警。對(duì)于大型應(yīng)用，基本都有灰發(fā)和預(yù)發(fā)機(jī)制，通過(guò)在灰發(fā)過(guò)程中監(jiān)控啟動(dòng)耗時(shí)，可以對(duì)接預(yù)警機(jī)制，在某個(gè)啟動(dòng)任務(wù)項(xiàng)耗時(shí)上升時(shí)告訴開(kāi)發(fā)者。如此可以有利項(xiàng)目的長(zhǎng)遠(yuǎn)開(kāi)發(fā)

最后一點(diǎn)，是可以告訴用戶，啟動(dòng)的慢，是慢在哪一步。這個(gè)機(jī)制集中在提供了開(kāi)放性上，例如 Visual Studio 將會(huì)不斷告訴你，啟動(dòng)慢是哪個(gè)插件導(dǎo)致的

使用方法

在抽離了各個(gè)項(xiàng)目的定制化需求之后，啟動(dòng)流程框架的庫(kù)只有核心的邏輯，這也就意味著在使用的時(shí)候，還需要具體的業(yè)務(wù)方自己加入初始化邏輯和適配業(yè)務(wù)的具體邏輯。換句話說(shuō)是，接入啟動(dòng)流程框架不是簡(jiǎn)單安裝一下庫(kù)，然后調(diào)用 API 即可，而是需要根據(jù)應(yīng)用的業(yè)務(wù)需求，進(jìn)行一部分對(duì)接的工作。好在啟動(dòng)流程框架只有在大型項(xiàng)目或者預(yù)期能做到大型的項(xiàng)目才適用，相比于大型應(yīng)用的其他邏輯，對(duì)接啟動(dòng)流程框架的代碼量基本可以忽略。對(duì)于小型項(xiàng)目或非多人協(xié)作的項(xiàng)目，自然是不合適的

整個(gè)?ApplicationStartupManager?啟動(dòng)流程框架設(shè)計(jì)上是高性能的，減少各個(gè)部分的性能內(nèi)損。但是在上啟動(dòng)流程框架本身就存在一定的框架性能損耗，如果對(duì)應(yīng)的只是小項(xiàng)目或非多人協(xié)作的項(xiàng)目，假設(shè)可以自己編排啟動(dòng)任務(wù)項(xiàng)，那自然自己編排啟動(dòng)任務(wù)項(xiàng)如此做是能達(dá)到性能最高的

應(yīng)用?ApplicationStartupManager?啟動(dòng)流程框架能解決的矛盾點(diǎn)在于項(xiàng)目的復(fù)雜度加上多人協(xié)作的溝通，與啟動(dòng)性能之間的矛盾。接入啟動(dòng)流程框架可以讓上層業(yè)務(wù)開(kāi)發(fā)者屏蔽對(duì)啟動(dòng)過(guò)程細(xì)節(jié)的干擾，方便上層業(yè)務(wù)開(kāi)發(fā)者根據(jù)業(yè)務(wù)需求加入啟動(dòng)任務(wù)項(xiàng)，方便啟動(dòng)模塊維護(hù)者定位和處理啟動(dòng)任務(wù)項(xiàng)的性能

按照慣例，在使用 .NET 的某個(gè)庫(kù)的第一步就是通過(guò) NuGet 安裝庫(kù)

第一步使用 NuGet 安裝?ApplicationStartupManager?庫(kù)。如果項(xiàng)目使用 SDK 風(fēng)格的項(xiàng)目文件格式，可以在 csproj 項(xiàng)目文件上添加如下的代碼進(jìn)行安裝

<ItemGroup><PackageReference Include="dotnetCampus.ApplicationStartupManager" Version="0.0.1-alpha01" /></ItemGroup>

為了方便讓大家看到?ApplicationStartupManager?啟動(dòng)流程框架庫(kù)的效果，我采用了放在?https://github.com/dotnet-campus/dotnetCampus.ApplicationStartupManager?里的例子代碼來(lái)作為例子

新建三個(gè)項(xiàng)目，分別如下

• WPFDemo.Lib1：代表底層的各個(gè)組件庫(kù)，特別指業(yè)務(wù)組件

• WPFDemo.Api：應(yīng)用的 API 層的程序集，將在這里部署啟動(dòng)流程的框架邏輯

• WPFDemo.App：應(yīng)用的頂層，也就是 Main 函數(shù)所在的程序集，在這里觸發(fā)啟動(dòng)的邏輯

大概的抽象之后的應(yīng)用的模型架構(gòu)如下，不過(guò)為了演示方便，就將 Business 層和 App 層合一，將眾多的 Lib 組件合為一個(gè) Lib1 項(xiàng)目

新建完成項(xiàng)目，也安裝完成 NuGet 包，現(xiàn)在就是開(kāi)始在 API 層搭建應(yīng)用相關(guān)聯(lián)的啟動(dòng)框架邏輯。為什么在安裝完成了 NuGet 包之后，還需要 API 做額外的邏輯？每個(gè)應(yīng)用都有自己獨(dú)特的邏輯，每個(gè)應(yīng)用的啟動(dòng)任務(wù)項(xiàng)所需的參數(shù)是不相同的，每個(gè)應(yīng)用的日志記錄方式也可以是不相同的，不同類型的應(yīng)用的啟動(dòng)節(jié)點(diǎn)也是不相同的，如此這些都是需要做應(yīng)用相關(guān)的定制的

先定義應(yīng)用相關(guān)的預(yù)設(shè)的啟動(dòng)節(jié)點(diǎn)

/// <summary>/// 包含預(yù)設(shè)的啟動(dòng)節(jié)點(diǎn)。/// </summary>public class StartupNodes{/// <summary>/// 基礎(chǔ)服務(wù)（日志、異常處理、容器、生命周期管理等）請(qǐng)?jiān)诖斯?jié)點(diǎn)之前啟動(dòng)，其他業(yè)務(wù)請(qǐng)?jiān)诖酥髥?dòng)。/// </summary>public const string Foundation = "Foundation";/// <summary>/// 需要在任何一個(gè) Window 創(chuàng)建之前啟動(dòng)的任務(wù)請(qǐng)?jiān)诖斯?jié)點(diǎn)之前。/// 此節(jié)點(diǎn)之后將開(kāi)始啟動(dòng) UI。/// </summary>public const string CoreUI = "CoreUI";/// <summary>/// 需要在主 <see cref="Window"/> 創(chuàng)建之后啟動(dòng)的任務(wù)請(qǐng)?jiān)诖斯?jié)點(diǎn)之后。/// 此節(jié)點(diǎn)完成則代表主要 UI 已經(jīng)初始化完畢（但不一定已顯示）。/// </summary>public const string UI = "UI";/// <summary>/// 應(yīng)用程序已完成啟動(dòng)。如果應(yīng)該顯示一個(gè)窗口，則此窗口已布局、渲染完畢，對(duì)用戶完全可見(jiàn)，可開(kāi)始交互。/// 不被其他業(yè)務(wù)依賴的模塊可在此節(jié)點(diǎn)之后啟動(dòng)。/// </summary>public const string AppReady = "AppReady";/// <summary>/// 任何不關(guān)心何時(shí)啟動(dòng)的啟動(dòng)任務(wù)應(yīng)該設(shè)定為在此節(jié)點(diǎn)之前完成。/// </summary>public const string StartupCompleted = "StartupCompleted";}

定義完成之后，即可通過(guò)此將啟動(dòng)過(guò)程分為如下階段

再定義一個(gè)和應(yīng)用業(yè)務(wù)方相關(guān)的日志類型，不同的應(yīng)用記錄日志的方式大部分都是不相同的，所使用的底層日志記錄也都是不相同的

/// <summary>/// 和項(xiàng)目關(guān)聯(lián)的日志/// </summary>public class StartupLogger : StartupLoggerBase{public void LogInfo(string message){Debug.WriteLine(message);}public override void ReportResult(IReadOnlyList<IStartupTaskWrapper> wrappers){var stringBuilder = new StringBuilder();foreach (var keyValuePair in MilestoneDictionary){stringBuilder.AppendLine($"{keyValuePair.Key} - [{keyValuePair.Value.threadName}] Start:{keyValuePair.Value.start} Elapsed:{keyValuePair.Value.elapsed}");}Debug.WriteLine(stringBuilder.ToString());}}

如例子上的日志就是記錄到?Debug.WriteLine?輸出，同時(shí)日志里也添加了 LogInfo 方法

繼續(xù)定制應(yīng)用業(yè)務(wù)相關(guān)的啟動(dòng)任務(wù)項(xiàng)的參數(shù)，如例子代碼的項(xiàng)目就用到了?dotnetCampus.CommandLine?提供的命令行參數(shù)解析，各個(gè)啟動(dòng)任務(wù)項(xiàng)也許會(huì)用到命令行參數(shù)，因此也就需要帶入到啟動(dòng)任務(wù)項(xiàng)的參數(shù)里面，作為一個(gè)屬性。例子代碼的項(xiàng)目也用到了?dotnetCampus.Configurations 高性能配置文件庫(kù)?提供的應(yīng)用軟件配置功能，也是各個(gè)啟動(dòng)任務(wù)項(xiàng)所需要的，放入到啟動(dòng)任務(wù)項(xiàng)的參數(shù)

加上和應(yīng)用業(yè)務(wù)相關(guān)的屬性之后的啟動(dòng)任務(wù)項(xiàng)的參數(shù)定義如下

public class StartupContext : IStartupContext{public StartupContext(IStartupContext startupContext, CommandLine commandLine, StartupLogger logger, FileConfigurationRepo configuration, IAppConfigurator configs){_startupContext = startupContext;Logger = logger;Configuration = configuration;Configs = configs;CommandLine = commandLine;CommandLineOptions = CommandLine.As<Options>();}public StartupLogger Logger { get; }public CommandLine CommandLine { get; }public Options CommandLineOptions { get; }public FileConfigurationRepo Configuration { get; }public IAppConfigurator Configs { get; }public Task<string> ReadCacheAsync(string key, string @default = ""){return Configuration.TryReadAsync(key, @default);}private readonly IStartupContext _startupContext;public Task WaitStartupTaskAsync(string startupKey){return _startupContext.WaitStartupTaskAsync(startupKey);}}

為了繼續(xù)承接 WaitStartupTaskAsync 的功能，于是構(gòu)造函數(shù)依然帶上 IStartupContext 用于獲取框架里默認(rèn)提供的啟動(dòng)任務(wù)項(xiàng)的參數(shù)。上面代碼的?Configuration?和?Configs?兩個(gè)屬性都是?dotnetCampus.Configurations 高性能配置文件庫(kù)提供的功能，可以使用 COIN 格式進(jìn)行配置文件的讀寫

完成了啟動(dòng)任務(wù)項(xiàng)的參數(shù)的定義，就可以來(lái)定制具體應(yīng)用的啟動(dòng)任務(wù)項(xiàng)的基類型了。因?yàn)閱?dòng)任務(wù)項(xiàng)的基類型一定是和啟動(dòng)任務(wù)項(xiàng)的參數(shù)相關(guān)，而啟動(dòng)任務(wù)項(xiàng)的參數(shù)每個(gè)應(yīng)用都有所不同，因此啟動(dòng)任務(wù)項(xiàng)的基類型也就不同。即使不同的程度只有啟動(dòng)任務(wù)項(xiàng)的參數(shù)，代碼層面可以使用泛形來(lái)解決，但也會(huì)因?yàn)榉盒蔚膶?huì)讓業(yè)務(wù)層的代碼量較多，不如在應(yīng)用上再定義

/// <summary>/// 表示一個(gè)和當(dāng)前業(yè)務(wù)強(qiáng)相關(guān)的啟動(dòng)任務(wù)/// </summary>public class StartupTask : StartupTaskBase{protected sealed override Task RunAsync(IStartupContext context){return RunAsync((StartupContext) context);}protected virtual Task RunAsync(StartupContext context){return CompletedTask;}}

如上代碼，所有的應(yīng)用的業(yè)務(wù)端都應(yīng)該繼承 StartupTask 作為啟動(dòng)任務(wù)項(xiàng)的基類。繼承之后，依然是重寫 RunAsync 方法，在此方法里面執(zhí)行業(yè)務(wù)邏輯

這里設(shè)計(jì)上讓 RunAsync 作為一個(gè)虛方法而不是一個(gè)抽象方法是因?yàn)橛幸恍?yīng)用業(yè)務(wù)上需要一點(diǎn)占坑用的啟動(dòng)任務(wù)項(xiàng)，這些啟動(dòng)任務(wù)項(xiàng)沒(méi)有實(shí)際邏輯功能，只是為了優(yōu)化啟動(dòng)流程的編排而添加。另外重要的一點(diǎn)在于可以讓上層業(yè)務(wù)開(kāi)發(fā)者在編寫到一些只有同步的邏輯時(shí)，解決不知道如何返回 RunAsync 的 Task 的問(wèn)題，可以讓上層業(yè)務(wù)開(kāi)發(fā)者自然返回 base.RunAsync 方法的結(jié)果，從而減少了各個(gè)詭異的返回 Task 的方法

在完成了定制啟動(dòng)任務(wù)基類型之后，就需要編寫基于 StartupManagerBase 的和應(yīng)用業(yè)務(wù)相關(guān)的 StartupManager 類型，在這里的邏輯需要包含如何啟動(dòng)具體的啟動(dòng)任務(wù)項(xiàng)的邏輯，代碼如下

/// <summary>/// 和項(xiàng)目關(guān)聯(lián)的啟動(dòng)管理器，用來(lái)注入業(yè)務(wù)相關(guān)的邏輯/// </summary>public class StartupManager : StartupManagerBase{public StartupManager(CommandLine commandLine, FileConfigurationRepo configuration, Func<Exception, Task> fastFailAction, IMainThreadDispatcher mainThreadDispatcher) : base(new StartupLogger(), fastFailAction, mainThreadDispatcher){var appConfigurator = configuration.CreateAppConfigurator();Context = new StartupContext(StartupContext, commandLine, (StartupLogger) Logger, configuration, appConfigurator);}private StartupContext Context { get; }protected override Task<string> ExecuteStartupTaskAsync(StartupTaskBase startupTask, IStartupContext context, bool uiOnly){return base.ExecuteStartupTaskAsync(startupTask, Context, uiOnly);}}

以上代碼通過(guò)重寫 ExecuteStartupTaskAsync 方法實(shí)現(xiàn)在調(diào)用具體的啟動(dòng)任務(wù)項(xiàng)傳入業(yè)務(wù)相關(guān)的 StartupContext 參數(shù)

如果應(yīng)用有更多的需求，可以重寫 StartupManagerBase 更多方法，包括導(dǎo)出所有的啟動(dòng)項(xiàng)的 ExportStartupTasks 方法，重寫此方法可以讓應(yīng)用定義如何導(dǎo)出所有的啟動(dòng)任務(wù)項(xiàng)。重寫 AddStartupTaskMetadataCollector 方法可以讓應(yīng)用定義如何加入被管理的程序集中的啟動(dòng)信息等

以上幾步完成之后，還有一項(xiàng)需要完成的是，剛才新建的 WPFDemo.Api 項(xiàng)目其實(shí)沒(méi)有加上 WPF 的依賴，而在應(yīng)用里面，是有啟動(dòng)任務(wù)項(xiàng)需要依賴在 UI 線程執(zhí)行，于是就在加上 WPF 的依賴的 WPFDemo.App 上完成定義

class MainThreadDispatcher : IMainThreadDispatcher{public async Task InvokeAsync(Action action){await Application.Current.Dispatcher.InvokeAsync(action);}}

以上的基礎(chǔ)完成之后，就可以在 Program.cs 的主函數(shù)將啟動(dòng)框架跑起來(lái)，進(jìn)入到 WPFDemo.App 項(xiàng)目的 Program 類型，在主函數(shù)里面先解析命令行，然后再創(chuàng)建 App 再跑起啟動(dòng)框架

[STAThread]static void Main(string[] args){var commandLine = CommandLine.Parse(args);var app = new App();//開(kāi)始啟動(dòng)任務(wù)StartStartupTasks(commandLine);app.Run();}

在 StartStartupTasks 方法里面使用 Task.Run 的方式在后臺(tái)線程跑起來(lái)啟動(dòng)框架，如此可以讓主線程也就是此應(yīng)用的 UI 線程開(kāi)始跑起來(lái)界面相關(guān)邏輯

private static void StartStartupTasks(CommandLine commandLine){Task.Run(() =>{// 1. 讀取應(yīng)用配置// 應(yīng)用將會(huì)根據(jù)配置決定啟動(dòng)的行為var configFilePath = "App.coin";var repo = ConfigurationFactory.FromFile(configFilePath);// 2. 對(duì)接預(yù)編譯模塊，獲取啟動(dòng)任務(wù)項(xiàng)var assemblyMetadataExporter = new AssemblyMetadataExporter(BuildStartupAssemblies());// 3. 創(chuàng)建啟動(dòng)框架和跑起來(lái)var startupManager = new StartupManager(commandLine, repo, HandleShutdownError, new MainThreadDispatcher())// 3.1 導(dǎo)入預(yù)設(shè)的應(yīng)用啟動(dòng)節(jié)點(diǎn)，這是必要的步驟，業(yè)務(wù)方的各個(gè)啟動(dòng)任務(wù)項(xiàng)將會(huì)根據(jù)此決定啟動(dòng)順序.UseCriticalNodes(StartupNodes.Foundation,StartupNodes.CoreUI,StartupNodes.UI,StartupNodes.AppReady,StartupNodes.StartupCompleted)// 3.2 導(dǎo)出程序集的啟動(dòng)項(xiàng).AddStartupTaskMetadataCollector(() =>// 這是預(yù)編譯模塊收集的應(yīng)用的所有的啟動(dòng)任務(wù)項(xiàng)assemblyMetadataExporter.ExportStartupTasks());startupManager.Run();});}

以上的例子應(yīng)用里面，有業(yè)務(wù)是需要根據(jù)配置決定啟動(dòng)過(guò)程，因此需要先讀取應(yīng)用配置。應(yīng)用配置選取?dotnetCampus.Configurations 高性能配置文件庫(kù)?可以極大減少因?yàn)樽x取配置而占用太多啟動(dòng)時(shí)間。以上的例子里，還對(duì)接了預(yù)編譯模塊。預(yù)編譯模塊的功能是收集應(yīng)用里的所有啟動(dòng)任務(wù)項(xiàng)，如此可以極大提升收集啟動(dòng)任務(wù)項(xiàng)的耗時(shí)，也不需要讓上層業(yè)務(wù)開(kāi)發(fā)者需要手工注冊(cè)啟動(dòng)任務(wù)項(xiàng)

以上代碼即可實(shí)現(xiàn)在 Main 函數(shù)啟動(dòng)之后，跑起來(lái)啟動(dòng)框架。不過(guò)上面代碼編譯還不能通過(guò)，因?yàn)檫€沒(méi)有完成 AssemblyMetadataExporter 的邏輯，這個(gè)預(yù)編譯模塊相關(guān)邏輯

這不等價(jià)于這套啟動(dòng)框架強(qiáng)依賴于預(yù)編譯模塊，而是說(shuō)可選接入預(yù)編譯模塊。只需要有任何的邏輯，能對(duì)接 AddStartupTaskMetadataCollector 方法，在此方法里面能傳入獲取應(yīng)用所需的啟動(dòng)任務(wù)項(xiàng)即可。無(wú)論使用任何的方式，包括反射等都是可以的。接入預(yù)編譯模塊只是為了優(yōu)化性能，減少收集啟動(dòng)任務(wù)項(xiàng)的耗時(shí)

接下來(lái)就是預(yù)編譯模塊的接入邏輯，本文不涉及 Telescope 預(yù)編譯模塊的原理部分，只包含如何接入的方法

和 .NET 的其他庫(kù)一樣，為了接入預(yù)編譯模塊，就需要先安裝 NuGet 庫(kù)。通過(guò) NuGet 安裝?dotnetCampus.Telescope?庫(kù)，如果是新 SDK 風(fēng)格的項(xiàng)目文件，可以編輯 csproj 項(xiàng)目文件，添加如下代碼安裝

<ItemGroup><PackageReference Include="dotnetCampus.TelescopeSource" Version="1.0.0-alpha02" /></ItemGroup>

不同于其他的庫(kù)，由于?dotnetCampus.Telescope?預(yù)編譯框架是對(duì)項(xiàng)目代碼本身進(jìn)行處理的，需要每個(gè)用到預(yù)編譯都安裝此庫(kù)，因此需要為以上三個(gè)項(xiàng)目都安裝，而不能靠引用依賴自動(dòng)安裝

安裝完成之后，在項(xiàng)目上新建一個(gè) AssemblyInfo.cs 的文件，給程序集添加特性。按照約定，需要將 AssemblyInfo.cs 文件放入到 Properties 文件夾里面。這個(gè) Properties 文件夾算是一個(gè)特別的文件夾，在 Visual Studio 里新建就可以看到此文件夾的圖標(biāo)和其他文件夾不相同

在 AssemblyInfo.cs 文件里面添加如下代碼

[assembly: dotnetCampus.Telescope.MarkExport(typeof(WPFDemo.Api.StartupTaskFramework.StartupTask), typeof(dotnetCampus.ApplicationStartupManager.StartupTaskAttribute))]

以上就是對(duì)接預(yù)編譯框架的代碼，十分簡(jiǎn)單。通過(guò)給程序集加上?dotnetCampus.Telescope.MarkExportAttribute?可以標(biāo)記程序集的導(dǎo)出預(yù)編譯的類型，傳入的兩個(gè)參數(shù)分別是導(dǎo)出的類型的基類型以及所繼承的特性

以上代碼表示導(dǎo)出所有繼承?WPFDemo.Api.StartupTaskFramework.StartupTask?類型，且標(biāo)記了?otnetCampus.ApplicationStartupManager.StartupTaskAttribute?特性的類型

標(biāo)記之后，重新構(gòu)建代碼，將會(huì)在 obj 文件夾找到 AttributedTypesExport.g.cs 生成文件，如在本文的例子項(xiàng)目里面，生成文件的路徑如下

C:\lindexi\Code\ApplicationStartupManager\demo\WPFDemo\WPFDemo.Api\obj\Debug\net6.0\TelescopeSource.GeneratedCodes\AttributedTypesExport.g.cs

假設(shè)有一個(gè)叫 Foo1Startup 的啟動(dòng)任務(wù)項(xiàng)定義如下

[StartupTask(BeforeTasks = StartupNodes.CoreUI, AfterTasks = StartupNodes.Foundation)]public class Foo1Startup : StartupTask{protected override Task RunAsync(StartupContext context){context.Logger.LogInfo("Foo1 Startup");return base.RunAsync(context);}}

那么生成的 AttributedTypesExport.g.cs 將包含以下代碼

using dotnetCampus.ApplicationStartupManager; using dotnetCampus.Telescope; using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using WPFDemo.Api.StartupTaskFramework;namespace dotnetCampus.Telescope {public partial class __AttributedTypesExport__ : ICompileTimeAttributedTypesExporter<StartupTask, StartupTaskAttribute>{AttributedTypeMetadata<StartupTask, StartupTaskAttribute>[] ICompileTimeAttributedTypesExporter<StartupTask, StartupTaskAttribute>.ExportAttributeTypes(){return new AttributedTypeMetadata<StartupTask, StartupTaskAttribute>[]{new AttributedTypeMetadata<StartupTask, StartupTaskAttribute>(typeof(WPFDemo.Api.Startup.Foo1Startup),new StartupTaskAttribute(){BeforeTasks = StartupNodes.CoreUI,AfterTasks = StartupNodes.Foundation},() => new WPFDemo.Api.Startup.Foo1Startup()),};}} }

也就是自動(dòng)收集了程序集里面的啟動(dòng)項(xiàng)，生成收集的代碼

可以在啟動(dòng)框架模塊里面，新建一個(gè)叫 AssemblyMetadataExporter 的類型來(lái)從 AttributedTypesExport.g.cs 拿到收集的類型。從 Telescope 拿到?__AttributedTypesExport__?生成類型的方法是調(diào)用 AttributedTypes 的 FromAssembly 方法，代碼如下

IEnumerable<AttributedTypeMetadata<StartupTask, StartupTaskAttribute>> collection = AttributedTypes.FromAssembly<StartupTask, StartupTaskAttribute>(_assemblies);

以上代碼傳入的?_assemblies?參數(shù)就是需要獲取收集的啟動(dòng)任務(wù)項(xiàng)程序集列表，調(diào)用以上代碼，將會(huì)從傳入的各個(gè)程序集里獲取預(yù)編譯收集的類型

將此收集的返回值封裝為 StartupTaskMetadata 即可返回給啟動(dòng)框架

using System.Reflection;using dotnetCampus.ApplicationStartupManager; using dotnetCampus.Telescope;namespace WPFDemo.Api.StartupTaskFramework {public class AssemblyMetadataExporter{public AssemblyMetadataExporter(Assembly[] assemblies){_assemblies = assemblies;}public IEnumerable<StartupTaskMetadata> ExportStartupTasks(){var collection = Export<StartupTask, StartupTaskAttribute>();return collection.Select(x => new StartupTaskMetadata(x.RealType.Name.Replace("Startup", ""), x.CreateInstance){Scheduler = x.Attribute.Scheduler,BeforeTasks = x.Attribute.BeforeTasks,AfterTasks = x.Attribute.AfterTasks,//Categories = x.Attribute.Categories,CriticalLevel = x.Attribute.CriticalLevel,});}public IEnumerable<AttributedTypeMetadata<TBaseClassOrInterface, TAttribute>> Export<TBaseClassOrInterface, TAttribute>() where TAttribute : Attribute{return AttributedTypes.FromAssembly<TBaseClassOrInterface, TAttribute>(_assemblies);}private readonly Assembly[] _assemblies;} }

回到 Program.cs 里面，新建一個(gè) BuildStartupAssemblies 方法，此方法里面，寫明需要收集啟動(dòng)任務(wù)項(xiàng)的程序集列表，交給 AssemblyMetadataExporter 去獲取

class Program{private static void StartStartupTasks(CommandLine commandLine){Task.Run(() =>{var assemblyMetadataExporter = new AssemblyMetadataExporter(BuildStartupAssemblies());// 忽略其他邏輯});}private static Assembly[] BuildStartupAssemblies(){// 初始化預(yù)編譯收集的所有模塊。return new Assembly[]{// WPFDemo.Apptypeof(Program).Assembly,// WPFDemo.Lib1typeof(Foo2Startup).Assembly,// WPFDemo.Apitypeof(Foo1Startup).Assembly,};}}

通過(guò) StartupManager 的 AddStartupTaskMetadataCollector 即可將導(dǎo)出的啟動(dòng)任務(wù)項(xiàng)加入到啟動(dòng)框架

var assemblyMetadataExporter = new AssemblyMetadataExporter(BuildStartupAssemblies());var startupManager = new StartupManager(/*忽略代碼*/)// 導(dǎo)出程序集的啟動(dòng)項(xiàng).AddStartupTaskMetadataCollector(() => assemblyMetadataExporter.ExportStartupTasks());startupManager.Run();

如此即可完成所有的應(yīng)用的啟動(dòng)框架配置邏輯，接下來(lái)就是各個(gè)業(yè)務(wù)模塊編寫啟動(dòng)邏輯

通過(guò)添加各個(gè)業(yè)務(wù)模塊的啟動(dòng)任務(wù)項(xiàng)演示啟動(dòng)框架的使用方法

在 WPFDemo.App 添加 MainWindowStartup 用來(lái)做主窗口的啟動(dòng)，代碼如下

using System.Threading.Tasks;using dotnetCampus.ApplicationStartupManager;using WPFDemo.Api.StartupTaskFramework;namespace WPFDemo.App.Startup {[StartupTask(BeforeTasks = StartupNodes.AppReady, AfterTasks = StartupNodes.UI, Scheduler = StartupScheduler.UIOnly)]internal class MainWindowStartup : StartupTask{protected override Task RunAsync(StartupContext context){var mainWindow = new MainWindow();mainWindow.Show();return CompletedTask;}} }

以上代碼通過(guò) StartupTask 特性標(biāo)記了啟動(dòng)任務(wù)項(xiàng)需要在 AppReady 之前執(zhí)行完成，需要在 UI 之后執(zhí)行，要求調(diào)度到主線程執(zhí)行。對(duì)于主窗口顯示，自然是需要等待其他的 UI 相關(guān)邏輯執(zhí)行完成，如 ViewModel 注冊(cè)和樣式字典初始化等才能顯示的。而只有在主窗口準(zhǔn)備完成之后，才能算 AppReady 應(yīng)用完成，因此可以如此編排啟動(dòng)任務(wù)項(xiàng)

接下來(lái)再添加一個(gè)和業(yè)務(wù)相關(guān)的啟動(dòng)任務(wù)項(xiàng)，添加 BusinessStartup 實(shí)現(xiàn)業(yè)務(wù)，業(yè)務(wù)要求在主界面添加一個(gè)按鈕。因此如需求，需要讓 BusinessStartup 在 MainWindowStartup 執(zhí)行完成之后才能啟動(dòng)，代碼如下

[StartupTask(BeforeTasks = StartupNodes.AppReady, AfterTasks = "MainWindowStartup", Scheduler = StartupScheduler.UIOnly)]internal class BusinessStartup : StartupTask{protected override Task RunAsync(StartupContext context){if (Application.Current.MainWindow.Content is Grid grid){grid.Children.Add(new Button(){HorizontalAlignment = HorizontalAlignment.Center,VerticalAlignment = VerticalAlignment.Bottom,Margin = new Thickness(10, 10, 10, 10),Content = "Click"});}return CompletedTask;}}

可以看到，在 BusinessStartup 里，通過(guò) AfterTasks 設(shè)置了?MainWindowStartup?字符串，也就表示了需要在 MainWindowStartup 執(zhí)行完成之后才能執(zhí)行

此外，依賴關(guān)系是可以跨多個(gè)項(xiàng)目的，例如在基礎(chǔ)設(shè)施里面有 WPFDemo.Lib1 程序集的 LibStartup 表示某個(gè)組件的初始化，這個(gè)組件屬于基礎(chǔ)設(shè)施，通過(guò) BeforeTasks 指定要在 Foundation 預(yù)設(shè)啟動(dòng)節(jié)點(diǎn)啟動(dòng)

[StartupTask(BeforeTasks = StartupNodes.Foundation)]class LibStartup : StartupTask{protected override Task RunAsync(StartupContext context){context.Logger.LogInfo("Lib Startup");return base.RunAsync(context);}}

如上可以看到，在此框架設(shè)計(jì)上，給了 StartupTask 類型的 RunAsync 作為虛方法，方便業(yè)務(wù)對(duì)接時(shí)，做同步邏輯，可以通過(guò)調(diào)用基類方法返回 Task 對(duì)象

以上代碼只是標(biāo)記了 BeforeTasks 而沒(méi)有標(biāo)記 AfterTasks 那么將會(huì)默認(rèn)給 AfterTasks 賦值為虛擬的啟動(dòng)點(diǎn)，也就是不需要等待其他啟動(dòng)項(xiàng)

在 WPFDemo.Api 程序集里面有一個(gè) OptionStartup 表示根據(jù)命令行決定執(zhí)行的邏輯，這個(gè)也屬于基礎(chǔ)設(shè)施，但是依賴于 LibStartup 的執(zhí)行完成，代碼如下

[StartupTask(BeforeTasks = StartupNodes.Foundation, AfterTasks = "LibStartup")]class OptionStartup : StartupTask{protected override Task RunAsync(StartupContext context){context.Logger.LogInfo("Command " + context.CommandLineOptions.Name);return CompletedTask;}}

如此即可實(shí)現(xiàn)讓 OptionStartup 在 LibStartup 之后執(zhí)行，且在 Foundation 之前執(zhí)行

以上的代碼的啟動(dòng)圖如下，其中 LibStartup 和 OptionStartup 沒(méi)有要求一定要在 UI 線程，默認(rèn)是調(diào)度到線程池里執(zhí)行

在 BeforeTasks 和 AfterTasks 都是可以傳入多個(gè)不同的啟動(dòng)項(xiàng)列表，多個(gè)之間使用分號(hào)分割。也可以換成使用 BeforeTaskList 和 AfterTaskList 使用數(shù)組的方式，例如有 WPFDemo.Api 程序集的 Foo1Startup 和在 WPFDemo.Lib1 的 Foo2Startup 和 Foo3Startup 啟動(dòng)任務(wù)項(xiàng)，其中 Foo3Startup 需要依賴 Foo1Startup 和 Foo2Startup 的執(zhí)行完成，可以使用如下代碼

[StartupTask(BeforeTasks = StartupNodes.CoreUI, AfterTaskList = new[] { nameof(WPFDemo.Lib1.Startup.Foo2Startup), "Foo1Startup" })]public class Foo3Startup : StartupTask{protected override Task RunAsync(StartupContext context){context.Logger.LogInfo("Foo3 Startup");return base.RunAsync(context);}}

以上就是應(yīng)用接入?ApplicationStartupManager?啟動(dòng)流程框架的方法，以及業(yè)務(wù)方編寫啟動(dòng)任務(wù)項(xiàng)的例子。以上的代碼放在?https://github.com/dotnet-campus/dotnetCampus.ApplicationStartupManager?的例子項(xiàng)目

總結(jié)

以上是生活随笔為你收集整理的.NET 为大型应用接入 ApplicationStartupManager 启动流程框架的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。