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

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

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

這種被稱為軟件定義汽車（Software Defined Vehicle，下文簡稱為SDV）的設計方法基于更加靈活和易于擴展的軟件作為汽車的核心，將傳統(tǒng)的汽車升級為擁有諸如智能駕駛、深度娛樂、個性化人機交互能力的 “第三空間”。

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

一、為什么車企不容易做好軟件性能

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

既然汽車行業(yè)和軟件行業(yè)都已發(fā)展多年，那為什么在軟件定義汽車之后，車企不容易做好軟件性能呢？

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

軟件領域沒有新鮮事，從單體到分布式，從多任務到多實例，軟件領域所面臨的挑戰(zhàn)總是伴隨著業(yè)務形式和組織形式的發(fā)展。

一切問題源于復雜性。就像冤家路窄的擴展性和性能，隨著軟件規(guī)模的擴大，擴展性差會降低研發(fā)效率，而擴展性要求的層層抽象卻會成為軟件性能設計的掣肘。

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

任何軟件在規(guī)模擴張的過程中都容易陷入兩類本質復雜性的泥潭：

晦澀性：軟件研發(fā)的過程可以看做是知識傳遞和轉換的過程，大規(guī)模軟件的領域知識不掌握在任何單一個體的腦中，更復雜的分工也造成了知識傳遞過程中的失真。若不加以治理，這種晦澀性最終會導致整個軟件系統(tǒng)無法被理解。

依賴性：大規(guī)模軟件通常都包含了十分復雜的層次結構，其模塊和組件之間通過各種形式的接口耦合相互依賴從而形成整體。但這種依賴性絕大多數時候是級聯的，一旦處理不好，某個邊緣組件的修改可能突然導致其他看似毫不相關的組件發(fā)生故障。

不出意外，為了實現各種高階智能化特性，SDV 驅動的汽車軟件系統(tǒng)滿足了復雜軟件系統(tǒng)的一切特征。

圖源：智能網聯汽車電子電氣架構產業(yè)技術路線圖

以上圖所示的汽車軟件功能架構為例，汽車軟件的架構具有業(yè)務繁雜、技術棧深、安全性要求高的特點。與其他行業(yè)如手機制造、互聯網平臺等的軟硬件架構相比，汽車軟件在各架構層級中的標準化程度更低，研發(fā)定制化的場景也更多，而整個汽車產業(yè)鏈中的各類供應商更是層出不窮。

以上現狀決定了汽車軟件研發(fā)過程中，業(yè)務交互復雜、架構設計復雜、團隊協作復雜。

2.性能是一種橫跨軟件全業(yè)務、全生命周期的架構特性

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

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

顯然，軟件性能作為一種橫跨業(yè)務和軟件生命周期的通用架構特性，性能的優(yōu)劣在許多關鍵業(yè)務場景下都決定著客戶的使用意愿，而為了構建高性能的軟件系統(tǒng)，從軟件的設計之初就需要開始考慮性能。

當性能特性需要橫跨復雜的汽車軟件系統(tǒng)時，就會面臨跨技術領域、跨業(yè)務領域和跨團隊領域的三類挑戰(zhàn)。

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

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

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

二、性能持續(xù)提升的工程化方法

性能作為一種在復雜軟件環(huán)境下的跨領域架構特性，性能優(yōu)化工作很容易陷入“性能不佳 -> 問題拖延 -> 間歇性優(yōu)化 -> 再次劣化”的循環(huán)。

我們期望通過一種工程化的方法，來管理和運營軟件性能，從而實現持續(xù)的性能守護和提升。

工程化方法一般指通過科學的方法和標準化的流程，來提升項目的效率和質量。因此對于 “性能優(yōu)化” 這樣的課題，可以通過如下五個方面的實踐來實現工程化，即性能工程。

系統(tǒng)方法論：性能優(yōu)化的體系化方法，可參照如《性能之巔》等的性能分析和優(yōu)化方法論。

標準化流程和規(guī)范：定義如性能建模以及自動化方法（如適應度函數）等的標準化流程，提升效率。

成熟的技術支持：需要的知識、技術能力和人才，其中領域專家、性能專家和工程專家這三類角色非常關鍵。

全生命周期管理：類似 DevOps 的方式，對軟件全生命周期的性能優(yōu)化活動進行定義。

持續(xù)改進：通過持續(xù)觀測、持續(xù)看護等手段將性能優(yōu)化的實踐持續(xù)運行。

有關性能工程更多的細節(jié)，請見《什么是性能工程》。

下文將從性能觀測、性能調優(yōu)、性能團隊三個角度，介紹上述工程化方法的五個方面在 SDV 研發(fā)中的落地實踐。

1.持續(xù)性能觀測

性能優(yōu)化的前提是能夠對性能進行客觀的評估，通過構建對系統(tǒng)的觀測能力，我們能盡可能多的了解系統(tǒng)現狀，從而為之后的性能看護和優(yōu)化提供評估依據。

(1) 建立評估模型

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

指標模型一般可分為業(yè)務指標，系統(tǒng)指標和資源指標。

業(yè)務指標更偏向于黑盒指標，以最貼近用戶使用的角度描述產品性能特性。

系統(tǒng)指標則更多地貼近白盒指標，描述系統(tǒng)運行過程中的內部狀態(tài)，它們會間接影響到業(yè)務指標。

而資源指標是作為前兩種指標的補充，獨立評估資源指標沒有意義，但與其他指標相結合后能夠更準確的描述系統(tǒng)狀況。

嘗試落地持續(xù)性能優(yōu)化的過程中，最困難的部分就是建立評估模型，因為評估模型代表性能目標。（關于評估模型的建立，請參考《智能座艙軟件性能與可靠性的評估和改進》）

如果評估模型設計的有偏差，很容易導致花了不少時間建立的模型，關鍵的性能點沒有納入其中?；谶@種模型進行優(yōu)化迭代，會讓團隊產生一種錯覺：花了大力氣建設的觀測系統(tǒng)，派不上用場，因為即使是觀測到指標在改善，系統(tǒng)的性能看上去似乎仍舊不佳。

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

(2) 定制可擴展的觀測工具

為了有效地評估系統(tǒng)，觀測工具是必不可少的。對于評估模型中的各類指標，大多數都可以通過既有的工具進行收集。而為了更好的發(fā)現問題，業(yè)內也存在眾多可對系統(tǒng)進行剖析的追蹤工具。

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

最簡單的觀測系統(tǒng)可分為設備上的探針前端以及上位機或服務器上的分析后端。由于直接運行在設備上，探針自身的開銷不容忽視，因此通常性能探針都包含細粒度的配置能力，在研發(fā)或測試階段，打開全部或大部分開關，而在生產運行階段只打開部分開銷低的信息收集功能。

為了擴展探針的系統(tǒng)級觀測能力，通過 eBPF 對內核行為進行觀測是一種安全且高效的方式，基于 eBPF，可以方便的對調度、內存、IO和網絡進行定制化觀測。

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

(3) 性能看護

擁有了評估模型后，通過模型建立系統(tǒng)的性能基線，就能夠在系統(tǒng)迭代過程中不斷地評估系統(tǒng)的性能是優(yōu)化還是劣化。

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

不論是建立性能基線，還是基于兩組不同的指標向量進行性能看護，都應采用一些基礎的統(tǒng)計學方法來使評估和看護更客觀。

首先，需要對采集到的指標樣本進行正態(tài)性檢驗。如果指標樣本不符合正態(tài)分布，則需要對樣本進行數據矯正，或是調研采樣過程是否存在偏斜。符合正態(tài)分布的樣本是進一步統(tǒng)計學對比的前提。

其次，由于指標眾多，加之優(yōu)化或劣化可能僅體現在某些指標上。因此在性能測試樣本與性能基線的對比過程中，可通過諸如 t 檢驗的一類方法，計算每個指標變化的顯著性水平，來客觀的評價指標值是否發(fā)生了顯著的變化。

最后，考慮到優(yōu)化成本和實際的收效，系統(tǒng)略微的劣化，可能不值得進行大刀闊斧的優(yōu)化活動。因此除了顯著性水平的判斷，還可通過計算效應量來判斷實際發(fā)生的劣化/優(yōu)化是否明顯對系統(tǒng)產生了影響，進而幫助工程師進行決策。

2.持續(xù)性能改進

在發(fā)現性能問題后，如何改進且持續(xù)的改進性能就變成了第一要務。

(1) TopDown 分析與問題建模

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

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

這里舉一個問題建模的簡單例子。系統(tǒng)被測試用戶認為使用流暢度不佳。在分析該問題之前，首先需要定義清楚問題：系統(tǒng)發(fā)生不流暢時，負載是怎樣的？幀率是一種能夠描述系統(tǒng)渲染負載的黑盒指標，如果低于正常值表明渲染過程存在高負載，否則就需要進一步調查各業(yè)務階段的完成時間。此外，系統(tǒng)發(fā)生不流暢時，資源是怎樣的？對硬件資源（CPU、內存、磁盤）以及軟件資源（鎖、線程、連接）的爭用情況進行分析，能夠對系統(tǒng)所處狀態(tài)做出進一步描述。

(2) 構建微基準測試

對性能問題進行建模之后，可能的優(yōu)化路徑也許已經逐漸清晰，但在著手嘗試實施優(yōu)化之前，設計相關的微基準測試也是十分必要的。相比于浮現出性能問題的業(yè)務現象或黑盒指標，微基準測試能從更細粒度的方向對系統(tǒng)進行測試，它排除了不相干的噪聲干擾，可以專注于對性能優(yōu)化點所影響的指標進行測試。

例如在對前臺應用卡頓問題進行優(yōu)化的時候，經過建模和分析，我們假設卡頓的原因可能是由于在系統(tǒng)負載較高時，渲染線程難以及時被調度到 CPU 上，導致渲染不及時。那么對于這種假設，我們就需要構建一組基準測試，包括一個負載生成器，能夠為系統(tǒng)施加一定程度的負載，使之達到測試條件。也包含一個能夠探測并記錄應用調度延遲的工具。之后通過一個測試腳本，一邊生成負載，一邊運行被測應用，測試完成后能夠打印過程中的調度延遲變化?；谶@樣一組微基準測試，就能夠相對獨立的測試對前臺應用調度延遲的優(yōu)化程度。

(3) 優(yōu)化驅動模型迭代

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

舉例說明，IO 預讀是一種縮短系統(tǒng)啟動時間的方法，通過將啟動過程中少量多次的 IO 操作進行合并以減少總體開銷，從而達到縮短時間的目的。但預讀優(yōu)化要求能提前獲悉啟動過程中所有代碼實際讀寫的文件，這種信息勢必會跟隨軟件迭代而變化，那么預讀的內容也需要一起更新才能確保有效。

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

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

通過這樣的方式，就能持續(xù)確保優(yōu)化的有效性，且一旦建立后就不再需要人工干預。

3.性能工程團隊

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

對于構建性能工程，需要組建一個分別包含了領域專家、性能專家和工程專家的專業(yè)化團隊。

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

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

業(yè)務流團隊：匹配業(yè)務領域和組織能力的端到端交付團隊。

賦能團隊：特定技術領域或產品領域的專家，為業(yè)務流團隊賦能。

復雜子系統(tǒng)團隊：構建和維護系統(tǒng)中嚴重依賴專業(yè)領域知識的子系統(tǒng)。

平臺團隊：為產品導向團隊構建能提供自服務的各項基礎能力。

有趣的是，我們在性能工程的實踐過程中，發(fā)現性能工程團隊是一個融合了包括 “賦能”、“復雜子系統(tǒng)”和“平臺”三種類型的團隊：

當負責協助業(yè)務流團隊對具體的產品或組件進行性能診斷和優(yōu)化時，性能工程團隊是賦能團隊；

當對系統(tǒng)層面實施性能優(yōu)化時，性能工程團隊變?yōu)閺碗s子系統(tǒng)團隊；

而當構建性能建模、性能觀測等平臺化能力時，性能工程團隊又成為了平臺團隊。

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

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

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

工程專家則主要參與優(yōu)化的落地，平臺的搭建以及對業(yè)務團隊賦能等任務。工程專家是經驗豐富的工程師，排查業(yè)務團隊的性能故障要求 TA 熟悉 Android、Linux 或 AUTOSAR 的開發(fā)；搭建觀測系統(tǒng)以及平臺能力要求 TA 熟悉數據工程、網絡通信、云原生服務等；而包括編譯工具鏈、DevOps、測試工具開發(fā)等研發(fā)相關的能力也不可或缺。

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

總結

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

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

構建系統(tǒng)觀測能力，了解系統(tǒng)現狀，為性能看護和優(yōu)化提供評估依據。

通過分析建模、測試驗證、迭代優(yōu)化的方式持續(xù)地優(yōu)化軟件系統(tǒng)的性能。

組建性能工程團隊，專業(yè)化解決性能問題、賦能業(yè)務團隊并搭建平臺。

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