UWP發展歷程

通用Windows平臺(UWP)發展歷程

引言

通用Windows平臺(Universal Windows Platform, UWP)是微軟為實現"一次編寫,處處運行"的愿景而打造的現代應用程序平臺。作為微軟統一Windows生態系統的核心戰略組成部分,UWP代表了從傳統Win32應用向現代應用模型的演進。本文將詳細回顧UWP從概念提出到成熟發展的完整歷程,分析其技術特點、面臨的挑戰以及在微軟生態系統中的地位變化,并探討其未來發展前景。

起源與背景(2012-2014)

Windows 8與現代應用平臺的誕生

UWP的起源可以追溯到Windows 8時代。2012年10月,微軟發布了Windows 8操作系統,引入了全新的用戶界面和應用模型。這一版本的Windows帶來了兩個重要概念:

  1. Metro設計語言(后更名為Modern UI,再后來稱為Fluent Design):以排版為靈感的扁平化設計風格,強調簡潔、內容優先和響應式布局。

  2. Windows Runtime (WinRT):一個全新的應用程序架構,允許開發者使用多種編程語言(C++、C#、VB.NET和JavaScript)創建現代應用。

Windows 8時代的應用被稱為"Windows Store Apps"或"Metro Apps",它們擁有以下特點:

  • 全屏運行,專注于內容
  • 使用聲明式標記語言(XAML)定義用戶界面
  • 通過應用商店分發和更新
  • 運行在沙盒環境中,提高安全性
  • 使用新的異步編程模型
    Windows 8 Metro應用架構圖

然而,Windows 8的雙重界面(桌面模式和Metro模式)引起了用戶的困惑和不滿。市場反饋表明,盡管Metro應用概念創新,但其強制的全屏體驗和對觸摸優化的界面在傳統桌面電腦上使用體驗不佳。

Windows 8.1的改進

為了應對用戶反饋,微軟在2013年10月發布了Windows 8.1,對現代應用平臺進行了多項改進:

  • 允許現代應用窗口化運行
  • 改進了多屏幕支持
  • 增強了與桌面環境的集成
  • 擴展了WinRT API,提供更多功能

盡管這些改進使Windows 8.1的體驗有所提升,但其現代應用平臺仍未獲得廣泛采用。開發者對這一新平臺的投入有限,應用商店中的應用數量和質量均無法與iOS和Android平臺相比。

在這一階段,微軟意識到需要一個更加統一的平臺戰略,以消除Windows生態系統的碎片化問題。Windows Phone與Windows桌面版使用不同的應用模型和API,使開發者難以創建跨設備的應用程序。這一問題促使微軟開始構思一個真正統一的應用平臺。

UWP的誕生與Windows 10(2015)

"一個Windows"戰略

2015年7月,微軟發布了Windows 10,引入了通用Windows平臺(UWP)的概念。UWP是Windows 8/8.1的WinRT平臺的演進和擴展,目標是提供一個真正統一的應用平臺,允許開發者創建能在所有Windows 10設備上運行的應用程序。

Windows 10的"一個Windows"戰略包含以下關鍵要素:

  • 統一的核心操作系統
  • 統一的應用平臺(UWP)
  • 統一的Windows Store
  • 跨設備的用戶體驗和數據同步
  • 自適應設計,支持不同形態的設備

統一核心平臺

UWP的核心概念與技術特性

UWP的核心理念是提供一個通用的應用平臺,讓開發者能夠使用單一的代碼庫和項目,創建可在不同Windows 10設備上運行的應用程序。UWP應用具有以下技術特點:

  1. 自適應界面:UWP引入了自適應設計的概念,通過響應式布局、視覺狀態和設備特定視圖,使應用能夠自動適應不同屏幕尺寸和設備特性。

  2. 通用API:提供了一套統一的API,可以在所有Windows 10設備上使用。對于特定設備的獨特功能,UWP使用擴展SDK和條件編譯來處理。

  3. 單一應用包:UWP應用可以打包為單一的應用包(.appx,后來改為.msix),包含針對不同設備的必要資源和代碼,簡化了部署和管理。

  4. Windows應用商店分發:通過Windows Store分發應用,提供自動更新、許可管理和安全審核機制。

  5. 現代安全模型:UWP應用運行在沙盒環境中,使用聲明式權限模型,提供更好的安全性和隱私保護。

  6. 多種輸入支持:原生支持觸摸、筆、鍵盤、鼠標等多種輸入方式,使應用能夠適應不同設備的交互模式。

首個UWP版本的功能與限制

Windows 10首發版本中的UWP,相比Windows 8的WinRT平臺有了顯著改進,但仍存在一些限制:

特性類別改進與優勢限制與挑戰
應用模型支持窗口化運行,更好的桌面集成API相比Win32有限,無法完全替代傳統應用
用戶界面引入自適應設計,支持多種輸入早期控件套件和設計語言不夠成熟
開發工具Visual Studio 2015提供完整支持開發者學習曲線陡峭,文檔不夠完善
分發方式統一的Windows Store強制性商店分發限制了企業和專業應用場景
跨平臺能力可在Windows 10設備家族內跨平臺不支持非Windows平臺(如iOS、Android)

盡管如此,UWP的推出仍代表了微軟平臺戰略的重大轉變,為Windows應用開發提供了一條面向未來的新路徑。

成熟與發展(2016-2018)

持續的平臺改進

隨著Windows 10的多次更新,UWP平臺不斷得到增強和擴展:

Windows 10周年更新(1607,2016年8月)
  • 引入了Windows Ink平臺,強化了筆輸入支持
  • 改進了通知系統和Action Center
  • 增強了開發API和工具,如新的XAML控件和媒體功能
Windows 10創意者更新(1703,2017年4月)
  • 引入Compact Overlay模式,支持畫中畫功能
  • 改進的XAML設計器和工具
  • 添加了新的動畫和轉場效果
  • 增強了Xbox One上的UWP支持
Windows 10秋季創意者更新(1709,2017年10月)
  • 引入Fluent Design System,這是Metro/Modern UI的進化版
  • 新增了設計元素:亞克力材質、視差效果、光效、深度和動作
  • 改進了UWP的性能和穩定性
  • 增強了開發者工具和調試能力

Fluent Design System

Windows 10 April 2018 Update(1803,2018年4月)
  • 引入了Timeline(時間線)功能,增強了跨設備體驗
  • XAML島(XAML Islands),允許在Win32應用中嵌入UWP控件
  • 改進了Fluent Design實現,增加了更多視覺元素
  • 引入了自適應卡片(Adaptive Cards)
Windows 10 October 2018 Update(1809,2018年10月)
  • SwiftKey技術集成,改進了觸摸鍵盤體驗
  • 擴展了Fluent Design應用范圍
  • 改進了UWP性能和API功能
  • 增強了開發者工具集成

開發者體驗與工具鏈改進

為了提升開發者體驗,微軟在這一時期做了大量工作:

  1. Visual Studio改進:Visual Studio 2017提供了更好的UWP開發支持,包括改進的XAML編輯器、實時可視化樹和更好的調試工具。

  2. Windows開發者中心演進:提供了更簡化的應用提交和認證流程,以及更詳細的分析報告。

  3. 開源力度增加:微軟將越來越多的UWP組件開源,包括Windows社區工具包(Windows Community Toolkit)和控件庫。

  4. 橋接技術:推出了多個"橋接技術",幫助開發者將現有應用遷移到UWP:

    • Project Centennial(桌面應用轉換器),將Win32應用轉換為UWP
    • Project Westminster,將Web應用轉換為UWP
    • Project Islandwood,旨在幫助將iOS應用移植到UWP(后來停止開發)
    • Project Astoria,旨在將Android應用帶到UWP(已停止開發)

市場采用情況與挑戰

盡管微軟在UWP平臺上投入了大量資源,但其市場采用在2016-2018年期間仍面臨挑戰:

  1. 移動戰略調整:2017年微軟正式宣布放棄Windows Mobile/Phone平臺,這極大削弱了UWP的"通用"價值主張。沒有移動設備,UWP的跨設備能力大打折扣。

  2. 開發者生態系統:相比成熟的Win32生態系統以及iOS/Android移動生態,UWP應用數量和質量仍有差距。

  3. 企業采用障礙:企業對遷移到UWP持謹慎態度,主要受限于:

    • 現有Win32應用投資巨大
    • UWP早期的功能限制
    • 強制性Store分發模式不符合企業需求
  4. 平臺戰略不確定性:微軟頻繁調整平臺戰略,使開發者對長期投資UWP持觀望態度。

盡管如此,UWP在某些領域獲得了成功,特別是:

  • Xbox One游戲和應用
  • Surface設備上的觸屏優化應用
  • 教育市場的Windows設備應用
  • 企業內部的現代化應用

戰略調整與融合(2019-2021)

從"UWP優先"到"Windows應用"

2019年是UWP戰略的轉折點。微軟調整了其平臺戰略,從強調"UWP優先"轉變為更加包容的"Windows應用"概念。這一轉變體現在以下方面:

  1. XAML Islands技術成熟:允許Win32應用程序嵌入UWP控件和功能,創造混合應用體驗。

  2. Windows UI庫(WinUI):將UWP的UI框架解耦,使其可以在UWP和Win32應用中使用,為未來的UI框架統一鋪路。

  3. MSIX打包格式:擴展了UWP的應用包格式,支持打包和現代化分發各種Windows應用,而不僅限于UWP應用。

  4. Store政策調整:允許更多類型的應用通過Microsoft Store分發,不再強制要求純UWP應用。

  5. Project Reunion(后來演變為Windows App SDK):開始嘗試統一Win32和UWP開發模型。

Windows 10的后續更新中UWP的位置

在Windows 10的后續更新中,UWP繼續得到改進,但重點轉向與Win32平臺的整合:

Windows 10 May 2019 Update(1903,2019年5月)
  • 引入Windows Light主題
  • XAML Islands正式版發布
  • 改進的游戲模式和DirectX功能
Windows 10 November 2019 Update(1909,2019年11月)
  • 較小的功能更新,專注于穩定性和性能
  • 改進的通知管理和日歷集成
Windows 10 May 2020 Update(2004,2020年5月)
  • Windows Subsystem for Linux 2 (WSL2)
  • 更新的Cortana體驗(作為UWP應用)
  • 改進的開發者工具和診斷能力
Windows 10 October 2020 Update(20H2,2020年10月)
  • 開始菜單視覺刷新
  • 改進的通知體驗
  • 基于Chromium的新Edge瀏覽器集成

Windows開發的未來:Project Reunion/Windows App SDK

2020年5月,微軟在Build大會上宣布了Project Reunion(后更名為Windows App SDK)計劃,這是微軟平臺戰略的又一重大調整。Windows App SDK的目標是:

  1. 解耦Windows API與操作系統發布周期
  2. 統一Win32和UWP的API表面
  3. 提供現代化的Windows開發體驗,不再區分應用類型
  4. 允許漸進式采用,不要求完全重寫應用

這一舉措表明,微軟不再將UWP視為獨立的應用平臺,而是將其作為Windows應用生態系統的組成部分。UWP的許多技術和概念將被保留并整合到Windows App SDK中,但"純UWP應用"的概念開始淡化。

Windows 11時代的UWP(2021至今)

Windows 11與現代Windows應用

2021年6月,微軟發布了Windows 11操作系統,帶來了全新的視覺設計和用戶體驗。Windows 11對UWP和Windows應用開發的影響包括:

  1. 設計語言更新:Fluent Design得到進一步發展,引入了圓角設計、新的圖標和動畫系統。

  2. WinUI 3:正式發布,成為Windows 11的UI框架,支持UWP和Win32應用。

  3. Windows App SDK 1.0:取代Project Reunion,成為推薦的Windows開發方法。

  4. Microsoft Store改革

    • 允許未打包的Win32應用提交
    • 引入Android應用支持(通過Amazon應用商店)
    • 降低商店傭金,改善開發者收益
    • 提供新的搜索和發現機制
  5. UWP的定位變化:UWP不再作為單獨的平臺推廣,而是作為Windows App SDK的組成部分。

當前UWP的技術狀態與應用領域

截至2023年,UWP作為一項技術仍在Windows生態系統中存在,但其定位和使用場景發生了變化:

技術領域當前狀態
UI框架UWP XAML框架仍在使用,但逐漸被WinUI 3替代
應用模型被Windows App SDK統一的應用模型取代
應用商店Microsoft Store支持更多類型應用,UWP不再是唯一選擇
API訪問UWP API被整合到Windows App SDK中
設備支持繼續支持Xbox、HoloLens等特殊設備

UWP目前主要應用于以下領域:

  1. Xbox游戲和應用:Xbox仍然使用UWP作為其主要應用平臺
  2. HoloLens應用:混合現實應用開發
  3. 系統內置應用:Windows 11的一些內置應用仍基于UWP
  4. 特定行業應用:如教育、零售等領域的專用應用
  5. IoT設備應用:基于Windows IoT的設備應用

UWP與Windows App SDK的關系

Windows App SDK代表了微軟平臺戰略的最新發展,它與UWP的關系可以概括為:

UWP與Windows App SDK的關系

Windows App SDK采納了UWP的許多優勢部分,同時摒棄了其限制:

  1. 保留的UWP元素

    • XAML UI框架
    • 現代API設計
    • 自適應設計原則
    • 部分應用生命周期管理
  2. 超越UWP的方面

    • 不限于Store分發
    • 完整的Win32 API訪問
    • 向后兼容性更好
    • 可漸進式采用

UWP的技術評價與歷史意義

UWP的技術優勢與創新

回顧UWP的整個發展歷程,它在以下方面帶來了重要創新:

  1. 現代應用模型:引入了基于聲明式權限、安全沙盒和應用生命周期管理的現代應用模型。

  2. UI框架創新:XAML UI框架提供了強大的布局系統、數據綁定和樣式機制,影響了后續的多個UI框架。

  3. 設計語言革新:從Metro到Modern UI再到Fluent Design,推動了數字界面設計語言的發展。

  4. 自適應設計:早于移動行業引入了真正的響應式設計框架,支持多種設備和輸入模式。

  5. 應用打包與分發:APPX/MSIX包格式和相關技術簡化了應用分發和更新,提高了安全性。

UWP的局限與教訓

UWP的發展也暴露了一些平臺戰略和技術選擇的問題:

  1. 過于激進的平臺轉型:試圖一次性替代Win32生態系統,低估了平臺遷移的復雜性。

  2. 移動戰略失敗的影響:Windows Phone/Mobile戰略失敗極大削弱了UWP的價值主張。

  3. 封閉生態系統的挑戰:強制性Store分發模式限制了專業和企業應用場景。

  4. 平臺轉向頻繁:微軟多次調整平臺戰略,給開發者造成疲勞和困惑。

  5. 初期功能局限:早期版本功能不足,未能提供足夠的理由讓開發者遷移。

UWP在Windows發展中的歷史地位

UWP在Windows平臺發展歷史中占據重要位置:

  1. 過渡技術的角色:UWP實際上扮演了Windows從傳統桌面平臺向現代應用平臺過渡的橋梁角色。

  2. 技術實驗平臺:很多現代Windows技術首先在UWP中試驗,然后擴展到更廣泛的Windows生態系統。

  3. 設計語言的載體:UWP是微軟現代設計語言演進的主要載體,從Metro到Fluent Design。

  4. Windows as a Service模式的先驅:UWP應用模型率先采用了與操作系統解耦的API提供方式。

未來展望

UWP技術的繼承與發展

盡管"純UWP"作為獨立平臺的概念正在淡化,但UWP的許多技術元素將繼續在微軟生態系統中發展:

  1. Windows App SDK:將繼續整合UWP的優勢部分,為所有Windows應用提供現代化能力。

  2. WinUI:作為從UWP UI框架演進而來的技術,將成為Windows的主要UI框架。

  3. MSIX:源自UWP的現代包裝格式,將繼續服務于Windows應用分發。

  4. 跨平臺擴展:借助.NET MAUI,UWP的一些概念和設計模式將擴展到其他平臺。

Windows平臺統一的前景

微軟的平臺戰略現在明確轉向了Windows應用平臺的統一:

  1. API統一:通過Windows App SDK統一Win32和UWP API。

  2. UI框架統一:通過WinUI為所有Windows應用提供一致的UI框架。

  3. 設計語言統一:Fluent Design成為所有微軟產品的統一設計語言。

  4. 開發工具統一:Visual Studio和相關工具為各類Windows應用提供一致的開發體驗。

開發者生態系統的變化

Windows開發者生態系統正在經歷深刻變化:

  1. 從平臺分割到技術選擇:開發者不再面臨"Win32還是UWP"的二元選擇,而是可以根據需要混合使用技術。

  2. 漸進式現代化:允許現有應用逐步采用現代特性,而不是完全重寫。

  3. 開源與社區參與:微軟越來越多地通過開源和社區合作開發Windows平臺技術。

  4. 跨平臺思維:隨著微軟擁抱跨平臺戰略,Windows開發越來越多地考慮與其他平臺的互操作性。

結論

通用Windows平臺(UWP)的發展歷程反映了微軟在移動化和現代應用時代的平臺戰略演變。從Windows 8的Metro應用到Windows 10的UWP,再到如今的Windows App SDK,微軟一直在尋求平衡創新與兼容、現代化與穩定性之間的關系。

盡管UWP作為獨立平臺的重要性正在減弱,但它引入的許多技術創新和設計理念已經深刻影響了Windows生態系統,并將繼續通過Windows App SDK和WinUI等技術影響未來的Windows應用開發。

UWP的故事告訴我們,平臺演進是一個漸進的過程,需要尊重現有生態系統,并為開發者提供明確的價值和遷移路徑。微軟通過從UWP的經驗中學習,正在構建一個更加統一、開放和靈活的Windows開發平臺,這或許正是UWP最重要的遺產。

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/diannao/79455.shtml
繁體地址,請注明出處:http://hk.pswp.cn/diannao/79455.shtml
英文地址,請注明出處:http://en.pswp.cn/diannao/79455.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

git忽略已跟蹤的文件/指定文件

在項目開發中,有時候我們并不需要git跟蹤所有文件,而是需要忽略掉某些指定的文件或文件夾,怎么操作呢?我們分兩種情況討論: 1. 要忽略的文件之前并未被git跟蹤 這種情況常用的方法是在項目的根目錄下創建和編輯.gitig…

AI 組件庫是什么?如何影響UI的開發?

AI組件庫是基于人工智能技術構建的、面向用戶界面(UI)開發的預制模塊集合。它們結合了傳統UI組件(如按鈕、表單、圖表)與AI能力(如機器學習、自然語言處理、計算機視覺),旨在簡化開發流程并增強…

【Win】 cmd 執行curl命令時,輸出 ‘命令管道位置 1 的 cmdlet Invoke-WebRequest 請為以下參數提供值: Uri: ’ ?

1.原因: 有一個名為 Invoke-WebRequest 的 CmdLet,其別名為 curl。因此,當您執行此命令時,它會嘗試使用 Invoke-WebRequest,而不是使用 curl。 2.解決辦法 在cmd中輸入如下命令刪除這個curl別名: Remov…

UE5 UE循環體里怎么寫延遲

注:需要修改UE循環藍圖節點或者自己新建個藍圖宏庫把UE循環節點的原來代碼粘貼進去修改。 一、For Loop With Delay 二、For Each Loop With Delay 示例使用: 標注參考出處:分享UE5自制Loop with delay宏,在loop循環中添加執行…

IP檢測工具“ipjiance”

目錄 IP質量檢測 應用場景 對網絡安全的貢獻 對網絡管理的幫助 對用戶決策的輔助作用 IP質量檢測 檢測IP的網絡提供商:通過ASN(自治系統編號)識別IP地址所屬的網絡運營商,例如電信、移動、聯通等。 識別網絡類型&#xff1…

[工具]Java xml 轉 Json

[工具]Java xml 轉 Json 依賴 <!-- https://mvnrepository.com/artifact/cn.hutool/hutool-all --> <dependency><groupId>cn.hutool</groupId><artifactId>hutool-all</artifactId><version>5.8.37</version> </dependen…

vue3 傳參 傳入變量名

背景&#xff1a; 需求是&#xff1a;在vue框架中&#xff0c;接口傳參我們需要穿“變量名”&#xff0c;而不是字符串 通俗點說法是&#xff1a;在網絡接口請求的時候&#xff0c;要傳屬性名 效果展示&#xff1a; vue2核心代碼&#xff1a; this[_keyParam] vue3核心代碼&…

spring響應式編程系列:總體流程

目錄 示例 程序流程 just subscribe new LambdaMonoSubscriber ???????MonoJust.subscribe ???????new Operators.ScalarSubscription ???????onSubscribe ???????request ???????onNext 時序圖 類圖 數據發布者 MonoJust …

基于slimBOXtv 9.16 V2-晶晨S905L3A/ S905L3AB-Mod ATV-Android9.0-線刷通刷固件包

基于slimBOXtv 9.16 V2-晶晨S905L3A&#xff0f; S905L3AB-Mod ATV-Android9.0-線刷通刷固件包&#xff0c;基于SlimBOXtv 9 修改而來&#xff0c;貼近于原生ATV&#xff0c;僅支持晶晨S905L3A&#xff0f; S905L3AB芯片刷機。 適用型號&#xff1a;M401A、CM311-1a、CM311-1s…

使用droidrun庫實現AI控制安卓手機

使用droidrun庫實現AI控制安卓手機 介紹 DroidRun 是一個框架&#xff0c;通過LLM代理控制 Android 設備。它允許您使用自然語言命令自動化 Android 設備交互。 安裝環境 安裝源碼依賴 git clone https://github.com/droidrun/droidrun.git cd droidrun conda create --nam…

知識庫建設全流程指南(AI時代優化版)

知識庫建設全流程指南&#xff08;AI時代優化版&#xff09; ??一、知識庫建設的戰略定位?? ??核心價值錨點?? ??AI時代基建??&#xff1a;知識庫是GEO優化的核心載體&#xff0c;決定內容被AI引用的概率權重??動態護城河??&#xff1a;結構化知識體系可抵御算…

2025年03月中國電子學會青少年軟件編程(Python)等級考試試卷(五級)真題

青少年軟件編程&#xff08;Python&#xff09;等級考試試卷&#xff08;五級&#xff09; 分數&#xff1a;100 題數&#xff1a;38 答案解析&#xff1a;https://blog.csdn.net/qq_33897084/article/details/147341437 一、單選題(共25題&#xff0c;共50分) 1. 以下哪個選…

基于RRT的優化器:一種基于快速探索隨機樹算法的新型元啟發式算法

受機器人路徑規劃中常用的快速探索隨機樹&#xff08;RRT&#xff09;算法的搜索機制的啟發&#xff0c;我們提出了一種新穎的元啟發式算法&#xff0c;稱為基于RRT的優化器&#xff08;RRTO&#xff09;。這是首次將RRT算法的概念與元啟發式算法相結合。RRTO的關鍵創新是其三種…

進階篇|CAN FD 與性能優化

引言 1. CAN vs. CAN FD 對比 2. CAN FD 幀結構詳解

【隨身WiFi】隨身WiFi Debian系統優化教程

0.操作前必看 本教程基于Debian系統進行優化&#xff0c;有些操作對隨身WiFi來說可能會帶來負優化&#xff0c;根據需要選擇。 所有操作需要在root用戶環境下運行&#xff0c;否則都要加sudo 隨身wifi Debian系統&#xff0c;可以去某安的隨聲WiFi模塊自行搜索刷機 點贊&am…

【Pandas】pandas DataFrame where

Pandas2.2 DataFrame Indexing, iteration 方法描述DataFrame.head([n])用于返回 DataFrame 的前幾行DataFrame.at快速訪問和修改 DataFrame 中單個值的方法DataFrame.iat快速訪問和修改 DataFrame 中單個值的方法DataFrame.loc用于基于標簽&#xff08;行標簽和列標簽&#…

C++代碼優化

前段時間寫了一些代碼&#xff0c;但是在運算過程中發現有些代碼可以進行改進以提高運行效率&#xff0c;尤其是與PCL相關的部分&#xff0c;可以進行大幅度提高&#xff0e;特意在此進行記錄&#xff0c;分享給大家&#xff0c;也供自己查看&#xff0e; pcl::PointCloud< …

RAG-分塊策略

分塊策略在檢索增強生成&#xff08;RAG&#xff09;方法中起著至關重要的作用&#xff0c;它使文檔能夠被劃分為可管理的部分&#xff0c;同時保持上下文。每種方法都有其特定的優勢&#xff0c;適用于特定的用例。將大型數據文件拆分為更易于管理的段是提高LLM應用效率的最關…

Linux網絡編程 深入解析TFTP協議:基于UDP的文件傳輸實戰

知識點1【TFTP的概述】 學習通信的基本&#xff1a;通信協議&#xff08;具體發送上面樣的報文&#xff09;、通信流程&#xff08;按照什么步驟發送&#xff09; 1、TFTP的概述 tftp&#xff1a;簡單文件傳輸協議&#xff0c;**基于UDP&#xff0c;**不進行用戶有效性驗證 …

「數據可視化 D3系列」入門第十一章:力導向圖深度解析與實現

D3.js 力導向圖深度解析與實現 力導向圖核心概念 力導向圖是一種通過物理模擬來展示復雜關系網絡的圖表類型&#xff0c;特別適合表現社交網絡、知識圖譜、系統拓撲等關系型數據。其核心原理是通過模擬粒子間的物理作用力&#xff08;電荷斥力、彈簧引力等&#xff09;自動計…