作者 | 張旭海

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

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

需要將軟件平臺與硬件平臺相互分離和抽象以提升靈活性。

這種被稱為軟件定義汽車（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、測試工具開發等研發相關的能力也不可或缺。

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

總結

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

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

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

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