作者| 張旭海

現今的汽車與數年前的汽車相比，雖然作為載具的主要目的變化不大，但不論是駕乘體驗、智能化水平還是交互方式，都發生了質的飛躍。

為了能支撐新一代汽車所提供的這種智慧化服務水平，顯而易見：

需要將軟體平台與硬體平台相互分離並抽像以提升靈活性。

這種被稱為軟體定義汽車（Software Defined Vehicle，下文簡稱為SDV）的設計方法是基於更靈活和易於擴展的軟體作為汽車的核心，將傳統的汽車升級為擁有諸如智慧駕駛、深度娛樂、個人化人機互動能力的「第三空間」。

SDV 帶來了一系列汽車設計的革命性跨越，同時也引入了各種新的困難。諸如性能、可靠性、安全性、易用性等在軟體領域長期存在的跨領域、跨業務型挑戰，隨著SDV 被一併引入了汽車領域。

一、為什麼車企不容易做好軟體性能

「車機卡頓」故障常年在汽車投訴榜單上擁有一席之地，性能問題除了影響乘駕體驗，有些情況下甚至會造成危險，如導航系統的卡頓會嚴重干擾駕駛員的決策。

既然汽車產業和軟體產業都已發展多年，那為什麼在軟體定義汽車之後，車企不容易做好軟體效能呢？

1.無可避免的本質複雜性

軟體領域沒有新鮮事，從單體到分散式，從多任務到多實例，軟體領域所面臨的挑戰總是伴隨著業務形式和組織形式的發展。

一切問題源自於複雜性。就像冤家路窄的擴展性和效能，隨著軟體規模的擴大，擴展性差會降低研發效率，而擴展性要求的層層抽象卻會成為軟體效能設計的掣肘。

由於軟體本身的架構靈活性，其功能構造十分易於修改和擴展，這也使得在表面上看，軟體的規模似乎可以不受限制的擴大。但人類大腦的認知邊界限制導致了軟體規模的擴大同樣也意味著協作規模的擴大，這種大規模的軟體協作體系，讓軟體的複雜度倍增。

任何軟體在規模擴張的過程中都容易陷入兩類本質複雜性的泥淖：

• 晦澀性：軟體研發的過程可以看做是知識傳遞和轉換的過程，大規模軟體的領域知識不掌握在任何單一個體的腦中，更複雜的分工也造成了知識傳遞過程中的失真。若不加以治理，這種晦澀性最終會導致整個軟體系統無法被理解。
• 依賴性：大規模軟體通常都包含了十分複雜的層次結構，其模組和元件之間透過各種形式的介面耦合相互依賴從而形成整體。但這種依賴絕大多數時候是級聯的，一旦處理不好，某個邊緣組件的修改可能突然導致其他看似毫不相關的組件發生故障。

不出意外，為了實現各種高階智慧化特性，SDV 驅動的汽車軟體系統滿足了複雜軟體系統的一切特徵。

圖源：智慧網聯汽車電子電氣架構產業技術路線圖

以上圖所示的汽車軟體功能架構為例，汽車軟體的架構具有業務繁雜、技術堆疊深度、安全性要求高的特性。與其他產業如手機製造、網路平台等的軟硬體架構相比，汽車軟體在各架構層級中的標準化程度較低，研發客製化的場景也更多，而整個汽車產業鏈中的各類供應商更是層出不窮。

以上現況決定了汽車軟體研發過程中，業務互動複雜、架構設計複雜、團隊協作複雜。

2.效能是一種橫跨軟體全業務、全生命週期的架構特性

架構特性（Architecture Characteristics）是架構師在設計軟體時需要考慮的與領域或業務需求無關的軟體特性，如可審計性、效能、安全性、可擴展性、可靠性等等。在很多時候我們也會稱之為非功能性需求（Nonfunctional Requirements）或品質屬性（Quality Attributes）。

在ISO/IEC 25010:2011 中，效能效率是軟體品質模型中的關鍵架構特性，模型中將效能效率更具體的描述為軟體的「時間特性」、「資源利用率」和「容量」等。

顯然，軟體效能作為一種橫跨業務和軟體生命週期的通用架構特性，效能的優劣在許多關鍵業務場景下都決定著客戶的使用意願，而為了建構高效能的軟體系統，從軟體的設計之初就需要開始考慮性能。

當性能特性需要橫跨複雜的汽車軟體系統時，就會面臨跨技術領域、跨業務領域和跨團隊領域的三類挑戰。

以導航功能為例：導航作為車上非常關鍵的應用，如果出現遲滯、卡頓、退出等問題，會嚴重影響使用者的駕駛體驗。因此為了確保導航使用的流暢性，在運行時需要有更多的系統資源，以及更穩定的運作環境。

操作響應快要求導航進程的調度優先權更高，連續讀圖要求IO 排隊時間短，畫面渲染涉及如Unity3D 等的第三方庫以及GPU 資源，另外導航中的一些輔助功能如AI語音，畫面共享等則需要呼叫其他元件的能力。

因此對於導航這項關鍵功能，如果發現性能故障，其定位和優化的過程可能牽涉多個業務領域，以及包括應用層、中間件層和系統層等多個技術層，此外還可能會牽扯資訊安全、體驗一致性、系統可靠性等諸多問題。

二、性能持續提升的工程化方法

效能作為一種在複雜軟體環境下的跨領域架構特性，效能最佳化工作很容易陷入「效能不佳-> 問題拖延-> 間歇性最佳化-> 再次劣化」的循環。

我們期望透過一種工程化的方法，來管理和運作軟體效能，從而實現持續的效能守護和提升。

工程化方法一般指透過科學的方法和標準化的流程，來提升專案的效率和品質。因此對於「性能優化」 這樣的課題，可以透過以下五個方面的實踐來實現工程化，即性能工程。

• 系統方法論：效能最佳化的體系化方法，可參考如《性能之巔》等的效能分析與最佳化方法論。
• 標準化流程與規範：定義如效能建模以及自動化方法（如適應度函數）等的標準化流程，提升效率。
• 成熟的技術支援：需要的知識、技術能力和人才，其中領域專家、性能專家和工程專家這三類角色非常關鍵。
• 全生命週期管理：類似DevOps 的方式，對軟體全生命週期的效能最佳化活動進行定義。
• 持續改進：透過持續觀測、持續看護等手段將性能優化的實踐持續運作。

有關性能工程更多的細節，請參閱《什麼是性能工程》。

下文將從效能觀測、效能調優、效能團隊三個角度，介紹上述工程化方法的五個面向在SDV 研發中的落地實踐。

1.持續性能觀測

性能優化的前提是能夠對性能進行客觀的評估，透過建構對系統的觀測能力，我們能盡可能多的了解系統現狀，從而為之後的性能看護和優化提供評估依據。

(1) 建立評估模型

性能評估模型作為性能建模活動的產出之一，在系統建設之初就可以著手開展，同時，評估模型也需要隨著產品的不斷迭代，融入更多業務和技術指標，以準確的描述系統性能要求。

指標模型一般可分為業務指標，系統指標和資源指標。

• 業務指標更偏向黑盒指標，以最貼近用戶使用的角度描述產品性能特性。
• 系統指標則更貼近白盒指標，描述系統運作過程中的內部狀態，它們會間接影響到業務指標。
• 而資源指標是作為前兩種指標的補充，獨立評估資源指標沒有意義，但與其他指標結合後能夠更準確的描述系統狀況。

嘗試落地持續表現最佳化的過程中，最困難的部分就是建立評估模型，因為評估模型代表表現目標。 （關於評估模型的建立，請參考《智慧座艙軟體效能與可靠性的評估與改進》）

如果評估模型設計的偏差，很容易導致花了不少時間建立的模型，關鍵的效能點沒有納入其中。基於這種模型進行最佳化迭代，會讓團隊產生一種錯覺：花了大力氣建設的觀測系統，派不上用場，因為即使是觀測到指標在改善，系統的性能看起來似乎仍舊不佳。

這也反過來會讓團隊產生懷疑：效能觀測和效能優化到底有關係嗎？在這種自我懷疑中，性能團隊的工作就很容易陷入《性能之巔》中提到的一些反模式，如街燈訥方法或隨機變動訥方法。

(2) 客製化可擴展的觀測工具

為了有效地評估系統，觀測工具是不可或缺的。對於評估模型中的各類指標，大多數都可以透過現有的工具進行收集。而為了更好的發現問題，業界也存在著眾多可對系統進行剖析的追蹤工具。

因此建立觀測系統的主要目標是整合各類零散的觀測工具，形成完整且易用的系統性能觀測能力。除了傳統的工具整合，觀測系統的可客製化以及開銷也值得關注。

最簡單的觀測系統可分為裝置上的探針前端以及上位機或伺服器上的分析後端。由於直接運行在設備上，探針本身的開銷不容忽視，因此通常性能探針都包含細粒度的配置能力，在研發或測試階段，打開全部或大部分開關，而在生產運行階段只打開部分開銷低的資訊收集功能。

為了擴展探針的系統級觀測能力，透過eBPF 對核心行為進行觀測是一種安全且高效的方式，基於eBPF，可以方便的對調度、記憶體、IO和網路進行客製化觀測。

除了開銷，在生產運作階段，還需要考慮資料的隱私合規性以及網路流量等方面的限制。因此資料脫敏、加密和壓縮也應作為重要的設計考量。

(3) 性能看護

擁有了評估模型後，透過模型建立系統的性能基線，就能夠在系統迭代過程中不斷評估系統的性能是最佳化還是劣化。

從前文可知，評估模型包含了一組用來描述不同系統特徵的指標，因此實際建立的效能基準就是一組指標向量。顯然，性能指標基線的建立，需要反覆地、大量的對系統進行性能測試，之後取統計值作為基線，才具有評估價值。

不論是建立表現基線，還是基於兩組不同的指標向量進行表現看護，都應採用一些基礎的統計學方法來使評估和看護更客觀。

首先，需要對採集到的指標樣本進行常態性檢定。如果指標樣本不符合常態分佈，則需要對樣本進行資料矯正，或是研究採樣過程是否有偏斜。符合常態分佈的樣本是進一步統計比較的前提。

其次，由于指标众多，加之优化或劣化可能仅体现在某些指标上。因此在性能测试样本与性能基线的对比过程中，可通过诸如 t 检验的一类方法，计算每个指标变化的显著性水平，来客观的评价指标值是否发生了显著的变化。

最后，考虑到优化成本和实际的收效，系统略微的劣化，可能不值得进行大刀阔斧的优化活动。因此除了显著性水平的判断，还可通过计算效应量来判断实际发生的劣化/优化是否明显对系统产生了影响，进而帮助工程师进行决策。

2.持續性能改進

在發現效能問題後，如何改進且持續的改進效能就變成了第一要務。

(1) TopDown 分析與問題建模

一般情況下，性能問題都是由業務現像或是黑盒指標異常所產生的，這類問題的特徵就在於表象之下深層的原因往往被各種紛繁複雜的噪音所掩蓋。而遇到這類問題最先冒出來的想法都是隨機試錯，這時我們會極度相信大腦所冒出的第一個可能原因，並有強烈的試一試看看的衝動。

然而隨機試誤法不僅是片面的，也是低效率的。更科學的分析方法是對問題建模，從負載和資源的角度更準確的定義問題，之後基於被測系統的架構進行自頂向下的分析，作出假設後採用客觀的測試方法進行驗證。

這裡舉一個問題建模的簡單例子。系統被測試使用者認為使用流暢度不佳。在分析問題之前，首先需要定義清楚問題：系統發生不流暢時，負載是怎樣的？幀率是一種能夠描述系統渲染負載的黑盒指標，如果低於正常值表示渲染過程存在高負載，否則就需要進一步調查各業務階段的完成時間。此外，系統發生不流暢時，資源是怎麼樣的？對硬體資源（CPU、記憶體、磁碟）以及軟體資源（鎖、執行緒、連線）的爭用情況進行分析，能夠對系統所處狀態做出進一步描述。

(2) 建構微基準測試

在對效能問題進行建模之後，可能的最佳化路徑也許已經逐漸清晰，但在著手嘗試實施最佳化之前，設計相關的微基準測試也是十分必要的。相較於浮現出效能問題的業務現像或黑盒子指標，微基準測試能從更細粒度的方向對系統進行測試，它排除了不相干的雜訊幹擾，可以專注於對效能最佳化點所影響的指標進行測試。

例如在對前台應用卡頓問題進行最佳化的時候，經過建模和分析，我們假設卡頓的原因可能是由於在系統負載較高時，渲染線程難以及時被調度到CPU 上，導致渲染不及時。那麼對於這個假設，我們就需要建構一組基準測試，包括一個負載產生器，能夠為系統施加一定程度的負載，使其達到測試條件。也包含一個能夠探測並記錄應用調度延遲的工具。之後通過一個測試腳本，一邊產生負載，一邊運行被測應用，測試完成後能夠列印過程中的調度延遲變化。基於這樣一組微基準測試，就能夠相對獨立的測試對前台應用調度延遲的最佳化程度。

(3) 優化驅動模型迭代

在效能優化工作中，必須認識到軟體的迭代性，隨著軟體的不斷迭代更新，原本可用的優化手段其效果可能會慢慢變差甚至失效。因此對優化本身的看護也很關鍵。

舉例說明，IO 預讀是一種縮短系統啟動時間的方法，透過將啟動過程中少量多次的IO 操作進行合併以減少總體開銷，從而達到縮短時間的目的。但預讀優化要求能事先獲悉啟動過程中所有程式碼實際讀寫的文件，這種資訊勢必會跟隨軟體迭代而變化，那麼預讀的內容也需要一起更新才能確保有效。

為了能及時發現最佳化效果減弱的情況，基於最佳化本身可以提取出與之相關的檢測項，可作為白盒指標納入評估模型，最好能透過對應的適應度函數來自動化評估。仍舊回到預讀的例子，為了能讓預讀的內容跟得上軟體本身的變化，可以建構一個自動化的適應度函數：

在每個新版本發布後，自動執行一次，獲取啟動過程的讀寫文件列表，與實施優化的文件列表（這就是基線）進行對比，當發現差異度大於30% 時報警。

透過這樣的方式，就能持續確保優化的有效性，一旦建立後就不再需要人工幹預。

3.性能工程團隊

對於前文提到的性能工程方法，如果沒有一個專業化團隊來負責推進，是難以最終在組織中落地生根的。就像在工程化五大實踐中提到的，成熟的技術支援不可或缺。

對於建置效能工程，需要組建一個分別包含了領域專家、效能專家和工程專家的專業團隊。

在Matthew Skelton 和Manuel Pais 的《團隊拓樸》中，描述了四種基本的團隊類型：

圖片來自：Organizing Agile Teams and ARTs: Team Topologies at Scale

• 業務流程團隊：搭配業務領域和組織能力的端到端交付團隊。
• 賦能團隊：特定技術領域或產品領域的專家，為業務流團隊賦能。
• 複雜子系統團隊：建構和維護系統中嚴重依賴專業領域知識的子系統。
• 平台團隊：為產品導向團隊建立能提供自服務的各項基礎能力。

有趣的是，我們在性能工程的實踐過程中，發現性能工程團隊是一個融合了包括「賦能」、「複雜子系統」和「平台」三種類型的團隊：

• 當負責協助業務流程團隊對具體的產品或組件進行效能診斷與最佳化時，效能工程團隊就是賦能團隊；
• 當對系統層面實施效能最佳化時，效能工程團隊變成複雜子系統團隊；
• 而當建構效能建模、效能觀測等平台化能力時，效能工程團隊又成為了平台團隊。

能有效承擔上述工作職責，與團隊本身的成員構成密不可分。

在SDV 的脈絡下，領域專家需要熟悉車載系統在不同場景下的業務組成及其性能要求，性能評估模型中的業務指標，也大都是由領域專家基於業務經驗給出的。領域專家不一定長期在效能工程團隊工作，TA 可能是技術架構師，業務分析師或產品經理，但結合業務和效能的跨領域能力十分關鍵。

性能專家深諳性能觀測和性能優化的各種原理，方法和實踐，同時也需要熟悉整個系統架構。在整車軟體架構中，因不同功能域對即時性需求的不同，通常會採用虛擬化技術在同一硬體平台上運行多套系統。虛擬化產生的資源抽象化和隔離會對效能最佳化產生很大的影響。例如，若效能專家不了解虛擬化層對運算資源的抽象，在Guest 系統中盲目進行大小核、調頻等最佳化，不僅不一定有效，還可能導致出現未知的行為。

工程專家則主要參與優化的落地，平台的建置以及對業務團隊賦能等任務。工程專家是經驗豐富的工程師，排查業務團隊的效能故障要求TA 熟悉Android、Linux 或AUTOSAR 的開發；搭建觀測系統以及平台能力要求TA 熟悉資料工程、網路通訊、雲端原生服務等；而包含編譯工具鏈、DevOps、測試工具開發等研發相關的能力也不可或缺。

當然一步到位的組建出這樣的「六邊形」團隊不是件容易的事，但組織只要嘗試開始構建性能工程，相信最初不勝任的團隊，其能力也會隨著性能工程成熟度的不斷提升，而最終成為勝任的團隊。

總結

最後總結一下，由於智慧網聯汽車與傳統汽車在功能上的巨大差異，為了靈活性和迭代速度，軟體定義汽車的概念勢在必行。然而軟體的兩種本質複雜性，晦澀性和依賴性，疊加性能本身的跨領域特性，導致車企不容易做好軟體性能。

我們嘗試透過工程化的手段持續提升汽車軟體的性能，其中包含了一些實踐：

• 建構系統觀測能力，了解系統現狀，為性能看護和優化提供評估依據。
• 透過分析建模、測試驗證、迭代優化的方式持續優化軟體系統的效能。
• 組成性能工程團隊，專業化解決效能問題、賦能業務團隊並建立平台。

對軟體效能工程這件事，我們仍在持續探索和實踐，希望本文能對您產生幫助。