為什麼糟糕的軟體會讓你感覺需要新硬體

為什麼糟糕的軟體會讓你感覺需要新硬體

使用現代計算機的體驗常常令人沮喪地自相矛盾。您可能會在高效能組件（先進的多核心處理器、尖端顯示卡和充足的 RAM）上投入大量資金，但發現自己卻在等待打開資料夾或進行搜尋等簡單任務。

根本問題通常不是硬體本身。即使是中檔系統也能夠相對輕鬆地管理日常操作。真正的罪魁禍首在於軟體。多年來，儘管運算能力和記憶體取得了顯著進步，但軟體變得越來越笨重和低效，忽略了優化資源使用。現代軟體並沒有有效地利用這種能力，而是常常表現得好像自己擁有無限的資源，從而導致效能令人失望。

硬體和軟體效能之間的差異

當今的電腦硬體與幾十年前相比有了顯著的飛躍。目前的 CPU 設計精巧，具有多個核心和大量緩存，可即時優化效能。值得注意的是，如今的智慧型手機擁有比 20 世紀 80 年代佔據整個房間的超級電腦更強大的運算能力。

圖形處理單元 (GPU) 取得了更顯著的進展。以NVIDIA的RTX系列為例。這些不僅專注於圖形，而且已經發展成為平行處理引擎，使用專門的核心處理與人工智慧和機器學習相關的任務——用於計算效率的 Tensor Core 和用於即時光線追蹤的 RT Core，實現每秒數萬億次計算。

有瞭如此強大的性能，人們可以期待在操作電腦時獲得無縫的用戶體驗。應用程式應該快速打開，介面在多任務處理期間應該保持流暢，並且任務之間的切換應該順暢。不幸的是，事實往往並非如此。

這種情況與早期的軟體開發形成了鮮明的對比。在創建 Windows NT 3.51 等作業系統期間，開發人員精心管理記憶體和處理能力。他們精心設計了適合環境的系統，其 RAM 比當今單一現代瀏覽器標籤所消耗的 RAM 少得多，從而實現了在當今開發範式中幾乎過時的效率水平：

探索 Windows 使用者體驗

效能滯後最突出的例子可以在現代作業系統中看到，尤其是 Windows。微軟頻繁的功能更新對增強 Windows 10 和 11 的核心介面響應能力幾乎沒有作用，導致用戶普遍感到沮喪。常見的抱怨包括右鍵單擊後上下文選單延遲或檔案總管視窗出現交錯渲染。

值得注意的是，開發人員Julio Merino幾年前進行的一項實驗強調了這些問題。他將在最小硬體上運行的舊作業系統與在高效能機器上運行的現代 Windows 進行了比較，揭示了響應能力的明顯差異。

在一次測試中，一台 2000 年的機器，配備 128MB RAM 和 600 MHz 處理器，立即啟動了執行 Windows NT 3.51 的應用程式。相較之下，一台更新、功能更強大的機器——配備 32GB RAM 的 6 核心 Mac Pro——卻出現了延遲，因為 UI 元素是分塊渲染的，這暴露了性能方面的脫節：

開發人員 Theo Browne 分享的另一個引人注目的例子也凸顯了這個問題。他描述了這樣一個場景：打開一個包含流記錄的資料夾（一個簡單的任務）卻花了令人惱火的八分鐘，並且在右鍵單擊時 Windows 資源管理器崩潰。罪魁禍首是 Windows 自動解析每個檔案的元資料所導致的延遲，這嚴重阻礙了效能。解決方案是停用自動資料夾類型發現，展示使用者如何輕鬆找到系統固有問題的修復方法。

即使是全新安裝，Windows 也常常陷入預先安裝的應用程式、遙測系統和耗費資源的後台程序。這種混亂導致執行日常任務的嚴重延遲，而且許多用戶依賴第三方「debloat腳本」 ，這使得情況更加複雜。此類腳本凸顯了用戶的不滿程度，因為用戶經常將 Windows 描述為“幾乎無法使用”，除非他們刪除不需要的附加功能。

搜尋功能也反映了這些令人沮喪的情況。當搜尋最近的文件時，您可能會發現 Windows 花了異常長的時間才顯示結果，而通常會提供一些不相關的網路搜尋。許多人希望擁有類似於“Everything”這樣的免費工具的即時搜尋功能，可以在用戶輸入時快速定位文件，這與最大的科技公司之一緩慢的內建搜尋功能形成了鮮明對比。

回歸品質標準？

人們越來越覺得，提供高品質軟體的基本原則已經被權宜之計所取代。那些記得過去的人會記得，軟體，特別是操作系統和主要應用程序，在發布之前要經過嚴格的內部測試，通常能達到“黃金”質量標準。此過程確保了發佈時的穩定性、完整性和準備就緒性。

考慮到 Windows NT 4.0 或 Windows 2000 等系統，這些版本有望表現出企業級穩定性，這要歸功於密集的品質保證週期，包括一種稱為「dogfooding」的實踐，即甚至要求微軟員工親自使用該軟體。傳統上，更新是結構良好的服務包，而不是如今源源不絕的快速補丁。

當今的模型通常被稱為“ Windows 即服務”，但往往讓人感覺混亂。 Windows Insider 計畫似乎將測試外包給了數百萬無償參與者，而不是品質控制的延伸。用戶經常抱怨主要版本有缺陷、功能損壞以及整體性能下降，未發布、未完成的產品只有在公眾強烈抗議後才會得到修補，這是一個反覆的循環。這種做法不僅限於作業系統；許多遊戲都表現出這種令人不安的趨勢，《Cyber​​punk 2077》的災難性發布就是一個典型例子。

這種持續的「先發布，後修復」的做法讓許多用戶對各大工作室的開發理念產生了質疑。推遲《GTA 6》的決定可能反映出 Rockstar 意識到倉促發布的潛在風險。

同樣的「從未真正完成」的心態也體現在對控制面板等舊系統進行緩慢改造以支援新設定應用程式的過程中，這一過程始於 2012 年的 Windows 8，但十三年後仍在繼續。

Web 效能挑戰

現代軟體的效能問題不僅限於桌面作業系統；它們也出現在網路平台上。儘管連接性和設備功能有所改進，但使用者仍經常遇到過於緩慢且資源密集的網路體驗。與以前的網站相比，網站通常載入速度較慢，反應速度較慢。

這種滯後源於 Web 應用程式日益複雜以及重型 JavaScript 框架的廣泛使用。雖然 React 和 Next.js 等工具顯著增強了功能，但它們在較簡單的網站上的應用可能會導致程式碼大小膨脹和載入時間延遲。諷刺的是，這通常是出於便利驅動的開發偏好，而不是真正的專案需求。

使用 Web 技術創建的用於桌面的應用程式（例如基於 Electron 的工具 Slack）也經常受到「膨脹」的影響。每個應用程式都捆綁一個版本的網頁瀏覽器，從而增加了開銷，減慢了啟動時間並增加了資源消耗。

儘管如此，仍然存在一些例外情況，表明績效可以透過不同的發展重點而提升。值得注意的是，麥克馬斯特-卡爾的網站因其快速的加載時間而受到關注，與使用更先進技術構建的現代、視覺上更具吸引力的網站形成了鮮明對比。

McMaster-Carr 透過採用諸如強大的伺服器端渲染、積極的預取策略、多層快取方法和嚴格的資產優化等基本技術實現了這一目標。他們對速度和可用性的承諾勝過了現代框架的吸引力，展示了必要性仍然可以決定設計。

https://www.youtube.com/watch?v=-Ln-8QM8KhQ

Linux 選項：好壞參半

為了尋求更流暢的運算體驗，許多用戶考慮切換到 Linux 等替代作業系統。許多發行版，特別是那些使用 XFCE 或 LXQt 等輕量級桌面環境的發行版，可以顯著提高舊硬體的性能，由於比 Windows 等更全面的解決方案開銷更低，使系統感覺更敏捷。

然而，過渡到 Linux 對許多用戶來說帶來了相容性挑戰，尤其是在流行的專業工具方面。許多必備應用程式（例如 Adob​​e Creative Cloud 和 Microsoft Office）都缺少原生 Linux 版本，這造成了一些障礙，導致用戶在返回 Windows 之前經常會短暫嘗試 Linux。

軟體膨脹和遲緩背後的原因

有了這些先進的硬體和可證明的軟體和網路效能優化策略，人們不禁要問，為什麼當代應用程式往往顯得如此遲緩和臃腫。答案可能很複雜，但有幾個關鍵因素引人注目：

  1. 「消費者作為 Beta 測試員」模式：大型軟體公司經常將其品質保證工作從徹底的內部審查轉變為公開 Beta 測試，依靠用戶回饋來最終確定即時環境中的功能。這與先前嚴格審查的“黃金”版本標準截然不同。
  2. 注重速度而非品質：目前與快速發布功能相關的壓力往往優先考慮權宜之計而不是精心的工藝，從而允許臃腫的框架佔據主導地位而不是進行詳細的性能優化。
  3. 過度抽象：使用多層抽象雖然可以簡化開發，但如果不仔細最佳化，可能會帶來不必要的效能開銷。
  4. 開發人員技能和重點：與更容易學習的整合技術和最新框架相比，記憶體管理和高效演算法等最佳化技能在開發人員中變得不那麼普遍了。
  5. 商業模式：當今許多軟體解決方案都嵌入了為廣告、遙測和用戶參與而設計的功能，增加了不必要的複雜性，從而削弱了核心功能。
  6. 日益複雜：對安全性、互聯網連接和處理高級圖形的需求不斷增加，帶來了固有的挑戰和可擴展性問題。

最後的想法：硬體並不總是罪魁禍首

下次您的電腦在執行日常任務時顯得很慢時，請暫停一下，然後再考慮升級新硬體。您目前的系統可能擁有一些功能，儘管與歷史標準相比令人印象深刻，但卻因效率低下和臃腫的軟體而陷入困境。

迫切需要的是效能、穩定性和品質再次成為軟體開發的優先考慮因素。至關重要的是，開發文化要轉向改善效能和使用者體驗，同時尊重使用者的時間和資源限制。為了真正提供滿足用戶需求的軟體，必須將重點放在提供強大且高效的解決方案上。

在這種轉變出現之前，用戶將繼續與最強大的機器的緩慢性能作鬥爭，這常常導致他們認為升級是唯一的辦法。

來源和圖片

相關文章:

為什麼大多數 Windows 11 使用者可以跳過防毒軟體
Winhance：您的必備 Windows 最佳化應用程式

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *