接手過一個(gè)考古型維護(hù)任務(wù)一套運(yùn)行了近十年的內(nèi)部業(yè)務(wù)系統(tǒng)前端跑在Silverlight上。打開解決方案的那一刻我人有點(diǎn)懵——XAML、.xap、WCF調(diào)用、JS橋接這些詞像是從上一個(gè)技術(shù)時(shí)代寄來的明信片。更難受的是想查資料時(shí)發(fā)現(xiàn)官方文檔早已下線社區(qū)帖子大量沉底能搜到的博客不是404就是斷章取義。我不甘心對著反編譯工具一點(diǎn)點(diǎn)反推于是花了好幾個(gè)周末把所有能接觸到的Silverlight相關(guān)資料按技術(shù)維度做了系統(tǒng)梳理順手把過程中的經(jīng)驗(yàn)也匯總成了文檔。這篇文章算是那份匯總的公開版給同樣需要維護(hù)老系統(tǒng)、做技術(shù)考古或者單純想弄清楚瀏覽器插件時(shí)代的前端到底是怎么寫的的人。我會盡量用遇到了什么問題 - 為什么會出現(xiàn) - 怎么解決的脈絡(luò)來講這樣不管是新手還是老手都能直接拿里面的思路去用。文里會涉及一些代碼示例和配置文件寫法都是我實(shí)測過的路徑照著落地基本不會跑偏。1. Silverlight是什么瀏覽器插件時(shí)代的技術(shù)切片1.1 極其精簡的運(yùn)行時(shí)CoreCLR與XAMLSilverlight的本質(zhì)是瀏覽器里的一套輕量級運(yùn)行時(shí)。它搭載了一個(gè)經(jīng)過裁剪的.NET運(yùn)行時(shí)官方叫CoreCLR配合專用的XAML解析器、矢量圖形引擎和媒體管道讓開發(fā)者可以用C#在瀏覽器里寫富客戶端應(yīng)用。這句話拆開理解就是傳統(tǒng)網(wǎng)頁用HTMLCSSJS三件套Silverlight則是用XAML描述界面、用C#寫業(yè)務(wù)邏輯。XAML這套聲明式語言負(fù)責(zé)布局、樣式、動(dòng)畫和數(shù)據(jù)綁定C#負(fù)責(zé)事件處理、服務(wù)調(diào)用、數(shù)據(jù)加工。它的心智模型更接近桌面開發(fā)而不是Web開發(fā)。這里有個(gè)容易踩的認(rèn)知誤區(qū)Silverlight的XAML和WPF的XAML雖然長得幾乎一模一樣但兩者不是同一套東西。Silverlight的XAML做了大量裁剪沒有WPF里那些重量級框架組件控件的默認(rèn)樣式也更偏簡潔實(shí)用。如果你把WPF項(xiàng)目里的XAML整段粘過來會碰到一堆屬性不存在的編譯錯(cuò)誤。這個(gè)教訓(xùn)我在整理資料時(shí)遇到了不止一次后面會專門說排查方法。1.2 從風(fēng)光到退場為什么老系統(tǒng)還賴在Silverlight上Silverlight曾經(jīng)是微軟押注的瀏覽器插件方向之一定位是直接對標(biāo)當(dāng)時(shí)的Flash打的牌是瀏覽器里的.NET。在那個(gè)RIA富互聯(lián)網(wǎng)應(yīng)用概念最火的年代它被大量用在數(shù)據(jù)看板、在線播放器、復(fù)雜表單、企業(yè)內(nèi)部管理系統(tǒng)上。后來移動(dòng)互聯(lián)網(wǎng)崛起瀏覽器端HTML5標(biāo)準(zhǔn)逐漸成熟插件技術(shù)整體退場Silverlight在2021年10月正式停止支持官方文檔和下載渠道基本都關(guān)了。但現(xiàn)實(shí)是金融、工業(yè)控制、醫(yī)療信息、政企內(nèi)部辦公這些領(lǐng)域仍有一大批系統(tǒng)跑在Silverlight上。它們不是不想升級而是業(yè)務(wù)邏輯復(fù)雜、配套服務(wù)深、替換成本高。這些系統(tǒng)大多還能穩(wěn)定運(yùn)行只是維護(hù)它們的人越來越少資料也越來越難找。這份匯總的初衷就是把這些挺老但還沒死的技術(shù)經(jīng)驗(yàn)留下來。從技術(shù)演進(jìn)的角度看Silverlight現(xiàn)代意義其實(shí)超出它自身它把聲明式UI、數(shù)據(jù)驅(qū)動(dòng)界面、事件異步模型、瀏覽器與本地代碼的橋接這些理念帶進(jìn)了很多開發(fā)者的視野。那些后來在HTML5、Angular、Vue里面被反復(fù)驗(yàn)證的思路不少能在Silverlight時(shí)代找到影子。研究它不只是拆一臺技術(shù)化石更是在理解前端框架演進(jìn)中的幾條主線。1.3 同類技術(shù)橫評Silverlight、Flash、ActiveX與現(xiàn)代HTML5為了把Silverlight放在正確的坐標(biāo)里我整理過一個(gè)對比表格按運(yùn)行形態(tài)、語言、渲染方式、安全模型、現(xiàn)狀五個(gè)維度列了一遍技術(shù)運(yùn)行形態(tài)開發(fā)語言界面渲染安全模型現(xiàn)狀Silverlight瀏覽器插件ActiveX/NPAPI OOB桌面模式C#/VB.NET XAML基于XAML的矢量渲染自繪UI沙箱隔離可申請?zhí)嵘龣?quán)限已停止支持遺留系統(tǒng)仍在運(yùn)行Flash瀏覽器插件ActionScript MXML基于時(shí)間軸的矢量渲染沙箱隔離存在大量歷史漏洞已停止支持基本退出市場ActiveX瀏覽器插件僅IE系C/COM為主本地窗口/自繪權(quán)限極高風(fēng)險(xiǎn)大隨IE退役被Edge的IE模式替代現(xiàn)代HTML5瀏覽器原生功能HTMLCSSJS/TS瀏覽器標(biāo)準(zhǔn)渲染管線同源策略、權(quán)限API、CSP等當(dāng)前主流持續(xù)演進(jìn)這張表的核心信息是Silverlight的渲染方式與頁面其他部分是完全分離的它不是一個(gè)可以被CSS影響的DOM元素而是一塊插件畫布。這就決定了它和周邊頁面的交互必須靠橋接機(jī)制也決定了它在布局上有自己的坐標(biāo)系統(tǒng)。理解這一點(diǎn)后面看部署兼容性、遷移方案時(shí)才會順。提示Silverlight插件頁面上通常是一個(gè)object標(biāo)簽指定了xap包路徑。如果你在某個(gè)老系統(tǒng)里看到typeapplication/x-silverlight-2這樣的寫法基本可以確認(rèn)這塊區(qū)域就是插件畫布。2. 資料分類法把Silverlight文章按技術(shù)維度歸堆整理資料時(shí)我踩過一個(gè)坑一開始按項(xiàng)目A的資料項(xiàng)目B的文檔這樣歸檔結(jié)果發(fā)現(xiàn)同一個(gè)技術(shù)問題散落在十幾個(gè)文件夾里想查一個(gè)跨域策略配置得來回翻。后來我改成按技術(shù)維度分類所有資料圍繞界面層、業(yè)務(wù)邏輯層、通信層、橋接層四條主線歸堆找起來舒服多了。下面是我整理出來的四塊內(nèi)容重點(diǎn)。2.1 界面層XAML、控件模板與依賴屬性Silverlight界面開發(fā)的核心是XAML但它和WPF有一個(gè)重要區(qū)別Silverlight不強(qiáng)調(diào)完整的邏輯樹/視覺樹分離控件的自定義程度也相對保守。多數(shù)開發(fā)場景是直接用內(nèi)置控件拼頁面配合布局容器Grid、StackPanel、Canvas需要改樣式時(shí)再寫Style和ControlTemplate。實(shí)際寫起來幾個(gè)高頻關(guān)鍵詞是DataTemplate定義ListBox、DataGrid這類列表控件里單項(xiàng)數(shù)據(jù)長什么樣綁定上下文是當(dāng)前數(shù)據(jù)項(xiàng)。TemplateBinding在ControlTemplate里綁定到控件自身屬性的手段做自定義控件時(shí)必備。依賴屬性DependencyPropertySilverlight控件屬性體系的基礎(chǔ)。它支持綁定、樣式繼承和默認(rèn)值機(jī)制。但要注意Silverlight里依賴屬性系統(tǒng)是裁剪版的很多高級觸發(fā)行為如屬性觸發(fā)器并不支持。一段非常典型的XAML代碼像這樣Grid x:NameLayoutRoot ListBox x:NameUserList ListBox.ItemTemplate DataTemplate StackPanel OrientationHorizontal TextBlock Text{Binding UserName} FontWeightBold / TextBlock Text - / TextBlock Text{Binding Role} ForegroundGray / /StackPanel /DataTemplate /ListBox.ItemTemplate /ListBox /Grid這段代碼里最值得注意的地方是{Binding UserName}。Silverlight的數(shù)據(jù)綁定默認(rèn)情況下不會為開發(fā)者提供太顯眼的錯(cuò)誤提示如果綁定路徑寫錯(cuò)、或者數(shù)據(jù)上下文的某個(gè)屬性叫UserName而實(shí)際存在的是Username界面就靜默地什么都不顯示。這種事在Silverlight時(shí)代坑了無數(shù)人后面專門有一節(jié)講怎么讓綁定錯(cuò)誤浮出水面。2.2 業(yè)務(wù)邏輯層異步模型與事件驅(qū)動(dòng)的代碼形態(tài)Silverlight的C#層有一個(gè)人盡皆知的規(guī)矩不允許在UI線程上做同步阻塞等待。因?yàn)檫@個(gè)平臺的事件循環(huán)本質(zhì)上是異步的任何阻塞UI線程的操作都可能直接卡死整個(gè)插件。所以Silverlight時(shí)代的代碼風(fēng)格是強(qiáng)異步的用了大量的回調(diào)、事件和委托。舉個(gè)例子從服務(wù)器拉取一段文本的經(jīng)典寫法private void LoadTextButton_Click(object sender, RoutedEventArgs e) { var client new WebClient(); client.DownloadStringCompleted (s, args) { if (args.Error ! null) { ResultText.Text 加載失敗 args.Error.Message; return; } ResultText.Text args.Result; }; client.DownloadStringAsync(new Uri(http://example.com/data.txt, UriKind.Absolute)); }這段代碼放在當(dāng)時(shí)很標(biāo)準(zhǔn)但放在今天看嵌套回調(diào)的體驗(yàn)確實(shí)糟糕。Silverlight后來在.NET框架里也引入了async/await的支持但很多老項(xiàng)目因?yàn)檫\(yùn)行時(shí)版本和工具鏈的限制還停留在事件回調(diào)的模式。如果你在讀老代碼時(shí)看到大把的Completed lambda不用懷疑這就是那個(gè)時(shí)代的標(biāo)準(zhǔn)寫法。此外業(yè)務(wù)邏輯層還很愛用LINQ。原因很簡單Silverlight的客戶端拿到的大多是集合數(shù)據(jù)在內(nèi)存里做篩選、排序、分組用LINQ比寫循環(huán)干凈得多。這個(gè)習(xí)慣到了現(xiàn)代C#開發(fā)里也完全不過時(shí)。2.3 通信層WCF、REST與跨域那個(gè)著名文件Silverlight應(yīng)用和服務(wù)器通信的方式主要有三種第一種是WCF服務(wù)調(diào)用。這也是企業(yè)內(nèi)部系統(tǒng)的主流方式開發(fā)流程里通過添加服務(wù)引用自動(dòng)生成客戶端代理類然后調(diào)用方法。配置文件里要關(guān)注binding、timeout、maxReceivedMessageSize這些參數(shù)。經(jīng)常遇到的問題是取數(shù)量大一點(diǎn)就報(bào)通信異常多半是默認(rèn)的消息大小上限太小了。system.serviceModel bindings basicHttpBinding binding nameLargeDataBinding maxReceivedMessageSize5242880 receiveTimeout00:10:00 sendTimeout00:10:00 / /basicHttpBinding /bindings /system.serviceModel第二種是REST風(fēng)格調(diào)用。用WebClient或HttpWebRequest發(fā)請求靠JSON或XML交換數(shù)據(jù)。相比WCF更輕但需要自己處理序列化和錯(cuò)誤碼。第三種繞不開的就是跨域訪問。Silverlight在瀏覽器里運(yùn)行時(shí)受同源策略限制跨域請求需要服務(wù)器根目錄放一個(gè)clientaccesspolicy.xml。這個(gè)文件是Silverlight的跨域許可證當(dāng)年幾乎所有聯(lián)調(diào)問題都跟它有關(guān)。?xml version1.0 encodingutf-8? access-policy cross-domain-access policy allow-from http-request-headers* domain uri* / /allow-from grant-to resource path/ include-subpathstrue / /grant-to /policy /cross-domain-access /access-policy注意這個(gè)文件必須放在域名的根路徑下不是放在應(yīng)用子目錄。我見過太多團(tuán)隊(duì)把文件放錯(cuò)位置排查半天才意識到服務(wù)端根本沒返回這個(gè)策略。調(diào)試方法很簡單瀏覽器直接訪問http://目標(biāo)域名/clientaccesspolicy.xml能看到內(nèi)容且狀態(tài)碼200才算過關(guān)。2.4 瀏覽器橋接與OOB模式Silverlight與宿主環(huán)境的關(guān)系Silverlight不是封閉的孤島它可以和宿主網(wǎng)頁雙向通信從Silverlight調(diào)用JavaScript通過HtmlPage.Window.Invoke(methodName, args)。從JavaScript調(diào)用Silverlight方法先給C#方法加[ScriptableMember]特性再注冊HtmlPage.RegisterScriptableObject(bridge, this)頁面里就能以object.bridge.MethodName()的方式調(diào)用。[ScriptableMember] public string GetVersion() { return 1.0.0; } public Page() { InitializeComponent(); HtmlPage.RegisterScriptableObject(appBridge, this); }OOB模式Out-of-Browser則是一個(gè)容易被忽略的功能。它允許Silverlight應(yīng)用脫離瀏覽器窗口直接運(yùn)行變成一個(gè)類似桌面的應(yīng)用。這對內(nèi)部系統(tǒng)非常有用——用戶不用開瀏覽器直接雙擊圖標(biāo)就能進(jìn)入系統(tǒng)。OOB應(yīng)用還能請求更高的信任權(quán)限比如直接讀寫本地文件需要證書配合。代價(jià)是OOB部署時(shí)安裝流程、版本更新都要自己控制體驗(yàn)比Web模式笨重不少。整理橋接這塊資料時(shí)我最大的體會是Silverlight時(shí)代就有人在思考瀏覽器里跑的代碼和頁面其他部分怎么通信這個(gè)問題后來流行的WebView橋、JS Bridge這些方案本質(zhì)上都還是在解決同一件事。3. .xap打包與部署老系統(tǒng)能否安穩(wěn)運(yùn)行的細(xì)節(jié)庫如果說界面和邏輯是Silverlight的面子那打包和部署就是里子。這部分資料如果不整理清楚項(xiàng)目跑不起來時(shí)連從哪兒下手都不知道。3.1 .xap包的結(jié)構(gòu)與加載流程Silverlight項(xiàng)目的最終產(chǎn)物是一個(gè).xap文件本質(zhì)是一個(gè)zip壓縮包。里面的核心成員是AppManifest.xaml程序集清單、若干個(gè)編譯好的dll、一個(gè)可選的pdb調(diào)試文件以及嵌入的資源文件。瀏覽器加載Silverlight時(shí)插件事先拿到.xap解包后讀取AppManifest.xaml定位入口程序集和啟動(dòng)類型再去執(zhí)行應(yīng)用初始化。這個(gè)加載機(jī)制直接影響兩個(gè)運(yùn)維判斷一是體積問題。xap包每次更新都是全量下載所以包內(nèi)dll數(shù)量、資源體積都會影響首次加載速度。優(yōu)化手段通常是裁剪引用、把不常用的資源拆到按需加載的程序集。別小看這個(gè)一個(gè)20MB的xap和2MB的xap在老舊內(nèi)網(wǎng)里的體感差異是天壤之別。二是更新問題。Silverlight沒有像現(xiàn)代前端那樣方便的增量更新發(fā)布新版本時(shí)就是重新部署xap文件然后用戶刷新頁面讓瀏覽器重新拉取。如果用戶端有緩存還得配合服務(wù)器端設(shè)置或版本號策略來強(qiáng)制繞過。這里有個(gè)實(shí)操經(jīng)驗(yàn)在部署新版本后可以直接在服務(wù)器上修改xap文件的最后修改時(shí)間或者在引用地址后面加版本參數(shù)?v20250601大多數(shù)場景下能有效避免用戶加載舊包。3.2 瀏覽器兼容矩陣插件沒了怎么辦這是我在整理部署資料時(shí)最扎心的部分。Silverlight插件在IE里走ActiveX通道在Firefox、Chrome、Safari這些瀏覽器里走NPAPI通道。隨著Google Chrome逐步禁用NPAPI、Firefox跟進(jìn)、Edge直接不內(nèi)置支持Silverlight在現(xiàn)代瀏覽器里基本無處安放。那張兼容性結(jié)論并不復(fù)雜瀏覽器Silverlight支持情況替代訪問思路IE 8/9/10/11老環(huán)境完整支持ActiveX插件保留低版本瀏覽器環(huán)境EdgeChromium內(nèi)核不支持使用IE模式或獨(dú)立插件容器Chrome 43不支持NPAPI通過企業(yè)策略或老版本瀏覽器Firefox 52不支持NPAPI通過舊版或插件容器企業(yè)定制瀏覽器部分提供內(nèi)置模塊直接用對應(yīng)廠商方案實(shí)際運(yùn)維中我見過幾個(gè)相對穩(wěn)妥的落地做法第一保留一臺老版本W(wǎng)indows IE11 Silverlight插件的訪問機(jī)專供內(nèi)部系統(tǒng)使用第二用遠(yuǎn)程桌面或虛擬桌面方案把老系統(tǒng)運(yùn)行在服務(wù)器端的瀏覽器里用戶端只負(fù)責(zé)顯示桌面第三利用某些國產(chǎn)瀏覽器的兼容模式來跑ActiveX。這三種都不是長久之計(jì)但能撐住過渡期。這里必須提醒一句不要指望讓用戶裝第三方插件或改瀏覽器FLAG來破局一方面安全風(fēng)險(xiǎn)不可控另一方面隨著瀏覽器版本迭代這些土辦法一一失效的概率極高。早一點(diǎn)規(guī)劃遷移比什么都強(qiáng)。3.3 安全與信任提升權(quán)限、證書與混合內(nèi)容Silverlight部署中還有一類問題不算高頻但一旦碰到就是大事權(quán)限與證書。提升權(quán)限模式Silverlight應(yīng)用默認(rèn)在沙箱中運(yùn)行訪問本地文件、跨域敏感操作都會受限。如果需要提升權(quán)限必須在OOB模式下配合簽名的證書并且用戶安裝時(shí)要確認(rèn)信任關(guān)系。證書鏈問題內(nèi)部系統(tǒng)常用的自簽名證書在Silverlight里常常不被直接信任導(dǎo)致OOB安裝或請求HTTPS服務(wù)時(shí)失敗。解決路徑基本是把證書導(dǎo)入客戶端受信任根或者統(tǒng)一用企業(yè)CA簽發(fā)。混合內(nèi)容攔截HTTPS頁面里嵌了HTTP的Silverlight xap現(xiàn)代瀏覽器會直接攔截或提示不安全內(nèi)容導(dǎo)致插件完全無法加載。這個(gè)坑在老舊系統(tǒng)里特別常見因?yàn)楫?dāng)年部署時(shí)可能還沒有全站HTTPS的強(qiáng)制要求。整理安全這塊資料的收獲是Silverlight時(shí)代總結(jié)的沙箱、信任、混合內(nèi)容三件套到今天依然適用。現(xiàn)代Web的CSP、HTTPS-only、權(quán)限API本質(zhì)上都在講同一件事瀏覽器里的代碼不能想干嘛就干嘛。4. 高頻異常排查從踩坑記錄里提煉的檢查清單在整理同事的踩坑記錄、再加上自己動(dòng)手復(fù)現(xiàn)之后我發(fā)現(xiàn)Silverlight的高頻異常其實(shí)就那幾類。把它們整理成檢查清單排查效率能提高一個(gè)量級。4.1 調(diào)試工具鏈XAML綁定錯(cuò)誤怎么看見Silverlight項(xiàng)目在Visual Studio里可以斷點(diǎn)調(diào)試C#代碼但XAML層的綁定錯(cuò)誤不會以異常形式彈出只會吐到調(diào)試輸出窗口。默認(rèn)情況下你什么都看不到因?yàn)榻壎ㄒ娴腻e(cuò)誤輸出級別很低。想要看見綁定錯(cuò)誤有兩個(gè)手段第一種在調(diào)試時(shí)觀察輸出窗口里的System.Windows.Data Error消息。這類消息會標(biāo)明綁定路徑、目標(biāo)元素、數(shù)據(jù)上下文類型是定位綁定問題的最直接線索。第二種顯式開啟綁定跟蹤Binding binding new Binding(UserName); binding.Source this.DataContext; binding.TraceLevel BindingTraceLevel.High; binding.TraceDestination BindingTraceDestination.Console; targetTextBlock.SetBinding(TextBlock.TextProperty, binding);這樣可以把綁定解析過程輸出到控制臺。雖然寫法啰嗦但在查為什么這個(gè)字段沒顯示時(shí)非常管用。還有一個(gè)不得不提的基礎(chǔ)排查工具全局異常處理器。在App.xaml.cs中掛上Application_UnhandledException事件把異常詳情記錄到日志很多生產(chǎn)環(huán)境里看不見摸不著的崩潰就有跡可循了。private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e) { LogHelper.Write(e.ExceptionObject.ToString()); e.Handled true; }4.2 幾類經(jīng)典異常的完整排查鏈路我把高頻異常分成了四組每組給出建議的排查順序。第一組XamlParseException。這類異常大多出現(xiàn)在應(yīng)用啟動(dòng)階段常見原因是資源查找失敗、StaticResource引用了尚未定義的資源、或者在模板里寫了不存在的屬性。排查時(shí)先看內(nèi)部異常里面通常會指出具體的XAML行號和屬性名如果內(nèi)部信息不明確就用二分注釋法把XAML代碼里大段內(nèi)容注釋掉逐步縮小范圍。這個(gè)辦法聽著笨但在復(fù)雜頁面里比肉眼找有效率得多。第二組跨域通信異常。報(bào)錯(cuò)內(nèi)容里經(jīng)常出現(xiàn)AG_E_NETWORK或者SecurityException或者干脆是遠(yuǎn)程服務(wù)器返回錯(cuò)誤。排查順序應(yīng)該是先確認(rèn)服務(wù)端有沒有返回clientaccesspolicy.xml再確認(rèn)該文件內(nèi)容里的domain和resource配置是否覆蓋目標(biāo)地址最后確認(rèn)網(wǎng)絡(luò)層是否被防火墻或代理攔截。我見過最隱蔽的情況是CDN緩存了舊的策略文件導(dǎo)致策略改了不生效折騰了一整天。第三組通信超時(shí)和消息大小問題。這類報(bào)錯(cuò)一般是TimeoutException或CommunicationException。排查順序先看配置文件里binding的超時(shí)設(shè)置和消息大小上限再確認(rèn)服務(wù)端實(shí)際處理時(shí)間最后檢查服務(wù)器日志里有沒有線程池饑餓的跡象。老系統(tǒng)最常見的問題不是網(wǎng)絡(luò)不通而是某個(gè)方法處理時(shí)間偶爾超過默認(rèn)的10秒超時(shí)把超時(shí)調(diào)到合理范圍往往立竿見影。第四組內(nèi)存持續(xù)增長。Silverlight的生命周期管理很脆弱事件處理器掛接后沒有解除、靜態(tài)集合里持有控件引用、視覺樹移除但資源未釋放都會造成內(nèi)存只增不減。排查方式用Windbg或者Visual Studio的托管內(nèi)存分析工具抓快照比較兩個(gè)時(shí)間點(diǎn)的對象數(shù)量。常見的元兇包括CompositionTarget.Rendering事件每幀觸發(fā)不解除必然泄漏、DataContext未置空。4.3 性能和內(nèi)存老項(xiàng)目最容易被忽略的兩座山排查高發(fā)之外整理資料時(shí)我還專門歸納過性能優(yōu)化清單挑三個(gè)見效最快的說。第一列表控件的虛擬化。Silverlight的ListBox、DataGrid默認(rèn)支持UI虛擬化但前提是外層容器給它們足夠的高度約束而且沒有被人為設(shè)置成ScrollViewer嵌套結(jié)構(gòu)。如果發(fā)現(xiàn)頁面加載很慢且內(nèi)存暴漲先去看是不是列表項(xiàng)一次性全部生成了。第二圖片資源加載。Silverlight里如果直接綁定大圖原圖解碼開銷會非常夸張。最佳實(shí)踐是服務(wù)端處理成多尺寸版本客戶端只加載當(dāng)前展示需要的尺寸。這和現(xiàn)代前端里srcset、loadinglazy的思路完全一致。第三Layout抖動(dòng)。Silverlight布局是依賴屬性驅(qū)動(dòng)的任何依賴屬性變化都可能觸發(fā)重新布局。頻繁更新某個(gè)TextBlock的Text、或者大批量改變元素寬高都會導(dǎo)致Layout刷新的風(fēng)暴。解決辦法是合并UI更新類似現(xiàn)代框架的批處理機(jī)制或者使用Canvas在絕對坐標(biāo)模式下做局部更新避免觸發(fā)整樹重排。5. 遷移路線圖老系統(tǒng)搬家前要做的四件事整理Silverlight資料繞不開一個(gè)終極問題這套東西還能活多久幾乎所有維護(hù)者最后都會走到遷移這件事上。我的建議是遷移之前先把下面四件事做完否則很容易被現(xiàn)實(shí)吊打。5.1 盤點(diǎn)資產(chǎn)先列清單再談重構(gòu)很多人一提遷移就急著選新技術(shù)、畫架構(gòu)圖結(jié)果連系統(tǒng)到底有多少個(gè)功能點(diǎn)都沒數(shù)清楚。我建議先做四張清單清單類型要收集的內(nèi)容用途功能清單頁面/模塊/操作流/權(quán)限點(diǎn)確定遷移范圍與優(yōu)先級控件清單用到的Silverlight控件、自定義組件、第三方控件評估對應(yīng)現(xiàn)代替代品的匹配度接口清單服務(wù)方法、參數(shù)、消息結(jié)構(gòu)、鑒權(quán)方式?jīng)Q定服務(wù)端是否需要調(diào)整環(huán)境清單部署位置、域名、證書、瀏覽器要求、訪問方式規(guī)劃過渡期運(yùn)行方案資產(chǎn)盤點(diǎn)是最枯燥但最值錢的一步。做完它你對遷移量會有完全不同的體感——很多團(tuán)隊(duì)以為界面重寫是大頭實(shí)際上數(shù)據(jù)接口和權(quán)限邏輯往往更耗時(shí)。5.2 概念映射把Silverlight語言翻譯成現(xiàn)代語言為了方便討論遷移方案我做過一張概念映射表把Silverlight時(shí)代的核心概念翻譯到現(xiàn)代技術(shù)棧團(tuán)隊(duì)溝通起來順暢很多Silverlight概念現(xiàn)代對應(yīng)物說明XAML界面HTMLCSS / Blazor的Razor組件 / 其他前端框架模板聲明式UI理念一脈相承但語法完全不同依賴屬性Signal / 響應(yīng)式綁定機(jī)制數(shù)據(jù)驅(qū)動(dòng)UI的底層機(jī)制DataTemplate前端框架的列表模板 / Angular的ng-template定義數(shù)據(jù)項(xiàng)如何渲染App.xaml全局資源全局狀態(tài)管理 / 設(shè)計(jì)系統(tǒng)令牌統(tǒng)一管理主題、樣式、共享配置WCF服務(wù)引用REST API / gRPC客戶端通信方式從SOAP轉(zhuǎn)向輕量API事件回調(diào)異步模型async/await從回調(diào)地獄走向順序化代碼OOB模式桌面端架構(gòu) / PWA脫離瀏覽器運(yùn)行的思路延續(xù)這張表的價(jià)值在于它告訴團(tuán)隊(duì)老系統(tǒng)中的大部分設(shè)計(jì)思想是可以平移的遷移的難點(diǎn)在語法和工具鏈而不是重新發(fā)明架構(gòu)。5.3 三條路徑對等重寫、漸進(jìn)遷移與混合嵌入盤點(diǎn)完資產(chǎn)、做完概念映射接下來就是選路。我見過并參與過的路線基本有三條第一條是對等重寫。選一個(gè)現(xiàn)代前端框架或桌面框架把Silverlight應(yīng)用按模塊逐一重寫全部完成后切換。優(yōu)點(diǎn)是技術(shù)棧統(tǒng)一、邊界干凈缺點(diǎn)是周期長、期間系統(tǒng)要同時(shí)維護(hù)兩套團(tuán)隊(duì)需要具備完整的前端能力。第二條是漸進(jìn)遷移。保持老系統(tǒng)繼續(xù)運(yùn)行新功能用現(xiàn)代技術(shù)棧開發(fā)通過導(dǎo)航層或微前端方式把新舊模塊拼接在一起。優(yōu)點(diǎn)是每步都有交付成果、業(yè)務(wù)風(fēng)險(xiǎn)小缺點(diǎn)是需要設(shè)計(jì)好兩個(gè)技術(shù)棧之間的導(dǎo)航與身份會話共享復(fù)雜度不低。第三條是混合嵌入?，F(xiàn)代頁面為主老模塊通過iframe或?qū)Ｓ脼g覽器容器嵌入。這是過渡味道最濃的路線但也最省力適合先穩(wěn)住業(yè)務(wù)再慢慢替換的場景。需要注意的是嵌入意味著老模塊的登錄態(tài)、權(quán)限、交互邊界都要提前約定好不然用戶在兩個(gè)系統(tǒng)間跳來跳去會瘋掉。5.4 遷移中的隱形坑看起來能平移實(shí)際會翻車的地方最后提醒幾個(gè)我在遷移討論中反復(fù)遇到的坑。第一個(gè)坑是嘗試用工具自動(dòng)把XAML翻譯成HTML。市面上確實(shí)有轉(zhuǎn)換工具但產(chǎn)出物大多是能看不能用的靜態(tài)代碼離可用差著十萬八千里。界面重寫必須按交互設(shè)計(jì)重新來別指望機(jī)器翻譯。第二個(gè)坑是依賴屬性到綁定的平移。Silverlight的DependencyProperty支持樣式繼承和默認(rèn)值而現(xiàn)代框架的響應(yīng)式綁定通常需要顯式聲明。如果只是機(jī)械地把依賴屬性改成屬性很容易漏掉樣式依賴關(guān)系導(dǎo)致界面行為和原來不一致。第三個(gè)坑是異步模型轉(zhuǎn)換。老代碼里的回調(diào)嵌套在遷移到async/await后確實(shí)更清晰但回調(diào)里隱藏的錯(cuò)誤處理和資源釋放邏輯在重寫時(shí)最容易丟。建議逐方法比對別只看編譯通過就以為萬事大吉。第四個(gè)坑是數(shù)據(jù)上下文。Silverlight時(shí)代大家習(xí)慣把DataContext直接賦給根元素子控件自動(dòng)繼承。遷移到現(xiàn)代框架后如果仍然照搬全局狀態(tài)一頓傳的思路會出現(xiàn)大量無鏈接、難以追蹤的隱式依賴。正確的做法是顯式傳遞、顯式注入。提示遷移不是技術(shù)升級而是業(yè)務(wù)重寫。衡量標(biāo)準(zhǔn)應(yīng)該是功能等價(jià)、權(quán)限一致、性能不劣化、運(yùn)維可接管。別為了用新框架而強(qiáng)行引入不必要的復(fù)雜度。最后分享一個(gè)我整理資料時(shí)固定下來的習(xí)慣每個(gè)技術(shù)條目最終都套用五要素模板——功能描述、操作路徑、技術(shù)要點(diǎn)、常見故障、更新記錄。這個(gè)模板幫了我大忙半年后回看自己寫的文檔依然能三分鐘定位到知識點(diǎn)而不是在堆砌的文字里翻半天。另一個(gè)體會是Silverlight會過時(shí)但它踩過的數(shù)據(jù)綁定、異步通信、內(nèi)存泄漏、跨域限制這些坑在現(xiàn)代前端框架里換個(gè)名字照樣存在。整理老技術(shù)資料表面上是為舊系統(tǒng)續(xù)命實(shí)際上也是在幫自己建立一套問題類型的排查直覺——這套直覺放到哪個(gè)技術(shù)棧里都不會貶值。