IT之家 4 月 13 日消息，戴夫 · 普盧默是 Windows 諸多標(biāo)志性功能（如 ZIP 壓縮文件支持）背后的工程師，他分享了自己是如何將任務(wù)管理器打造得如此高效的。據(jù)他在 YouTube 視頻中介紹，如今的 Windows 任務(wù)管理器體積約 4MB，而他最初編寫的版本僅有 80KB。
普盧默開發(fā)這款 Windows 工具時(shí)，核心考量是當(dāng)時(shí)硬件條件極為有限。即便系統(tǒng)其他部分全部卡死，這款用于在系統(tǒng)徹底崩潰后恢復(fù)電腦的工具，也必須保持流暢、響應(yīng)迅速。
普盧默表示：“每一行代碼都有代價(jià)，每一次內(nèi)存分配都會(huì)留下痕跡。每一項(xiàng)依賴都像一個(gè)白吃白住、從不交房租的室友。因此，我編寫任務(wù)管理器時(shí)，并沒有按照現(xiàn)代工具的開發(fā)思路 —— 先搭框架，再疊加九層易用性設(shè)計(jì)、六層前瞻性兼容，最后在這個(gè)工具占用 800MB 內(nèi)存、還得靠額外優(yōu)化才能顯示幾個(gè)數(shù)字時(shí)大驚小怪?！?/p>
IT之家注意到，任務(wù)管理器中普盧默最滿意的設(shè)計(jì)之一，是它的啟動(dòng)邏輯。其他應(yīng)用只會(huì)檢查自身是否已運(yùn)行，若存在實(shí)例則將其激活，而這款 Windows 工具更進(jìn)一步：它會(huì)向已存在的任務(wù)管理器實(shí)例（若有）發(fā)送私有消息并等待回復(fù)，以此判斷該實(shí)例是否未卡死。若收到正?；貞?yīng)，說明原有實(shí)例運(yùn)行正常；若毫無反饋，則判定該實(shí)例已失效，隨即啟動(dòng)新的任務(wù)管理器幫用戶擺脫困境。
這位工程師還做了另一項(xiàng)優(yōu)化：將高頻使用的字符串一次性加載為全局變量，而非反復(fù)調(diào)?。欢褚瞥龜U(kuò)展塢連接電腦這類低頻功能，僅在需要時(shí)才加載。進(jìn)程樹模塊也能節(jié)省資源 —— 它直接向系統(tǒng)內(nèi)核請求完整進(jìn)程表，而非逐個(gè)查詢程序，這減少了大量 API 調(diào)用。若緩沖區(qū)空間不足，它會(huì)自動(dòng)調(diào)整大小后重試。普盧默還分享了諸多設(shè)計(jì)技巧，確保 Windows 任務(wù)管理器不會(huì)過度占用資源，即便在當(dāng)時(shí)算力有限、甚至已出現(xiàn)故障的設(shè)備上也能流暢運(yùn)行。
90 年代電腦的處理與資源限制，迫使普盧默將 Windows 任務(wù)管理器做得盡可能精簡。他說：“任務(wù)管理器的設(shè)計(jì)理念截然不同。在那個(gè)時(shí)代，一次頁面缺頁中斷都能被明顯感知，內(nèi)存不足時(shí)會(huì)出現(xiàn)詭異的卡頓，若是讓不該頻繁刷新的界面反復(fù)重繪，你幾乎能聽到辦公室里同事的抱怨。我當(dāng)然不想再用當(dāng)年的老舊硬件，但真心希望我們能保留更多當(dāng)年的設(shè)計(jì)精髓，不是那段艱苦的開發(fā)經(jīng)歷，而是那種本能：批量處理任務(wù)、合理緩存數(shù)據(jù)、跳過無意義的操作、重繪前先對比差異、只向內(nèi)核請求一次而非上百次、低頻數(shù)據(jù)僅按需加載，對那些會(huì)消耗用戶資源的便捷性功能保持警惕。”
