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

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

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

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

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

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

“車機卡頓”故障常年在汽車投訴榜單上擁有一席之地,，性能問題除了影響乘駕體驗,，有些情況下甚至?xí)斐晌ｋU，如導(dǎo)航系統(tǒng)的卡頓會嚴(yán)重干擾駕駛員的決策,。

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

1.無可避免的本質(zhì)復(fù)雜性

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

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

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

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

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

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

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

圖源：智能網(wǎng)聯(lián)汽車電子電氣架構(gòu)產(chǎn)業(yè)技術(shù)路線圖

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

以上現(xiàn)狀決定了汽車軟件研發(fā)過程中,，業(yè)務(wù)交互復(fù)雜,、架構(gòu)設(shè)計復(fù)雜、團隊協(xié)作復(fù)雜,。

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

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

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

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

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

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

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

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

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

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

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

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

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

標(biāo)準(zhǔn)化流程和規(guī)范：定義如性能建模以及自動化方法（如適應(yīng)度函數(shù)）等的標(biāo)準(zhǔn)化流程,，提升效率。

成熟的技術(shù)支持：需要的知識,、技術(shù)能力和人才,，其中領(lǐng)域?qū)＜摇⑿阅軐＜液凸こ虒＜疫@三類角色非常關(guān)鍵,。

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

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

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

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

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

性能優(yōu)化的前提是能夠?qū)π阅苓M(jìn)行客觀的評估，通過構(gòu)建對系統(tǒng)的觀測能力,，我們能盡可能多的了解系統(tǒng)現(xiàn)狀,，從而為之后的性能看護和優(yōu)化提供評估依據(jù)。

(1) 建立評估模型

性能評估模型作為性能建?；顒拥漠a(chǎn)出物之一,，在系統(tǒng)建設(shè)之初就可以著手開展,，同時,，評估模型也需要隨著產(chǎn)品的不斷迭代，融入更多業(yè)務(wù)和技術(shù)指標(biāo),，以準(zhǔn)確的描述系統(tǒng)性能要求,。

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

業(yè)務(wù)指標(biāo)更偏向于黑盒指標(biāo),，以最貼近用戶使用的角度描述產(chǎn)品性能特性。

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

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

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

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

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

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

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

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

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

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

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

(3) 性能看護

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

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

不論是建立性能基線,，還是基于兩組不同的指標(biāo)向量進(jìn)行性能看護,，都應(yīng)采用一些基礎(chǔ)的統(tǒng)計學(xué)方法來使評估和看護更客觀。

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

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

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

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

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

(1) TopDown 分析與問題建模

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

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

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

(2) 構(gòu)建微基準(zhǔn)測試

對性能問題進(jìn)行建模之后,，可能的優(yōu)化路徑也許已經(jīng)逐漸清晰,，但在著手嘗試實施優(yōu)化之前,，設(shè)計相關(guān)的微基準(zhǔn)測試也是十分必要的。相比于浮現(xiàn)出性能問題的業(yè)務(wù)現(xiàn)象或黑盒指標(biāo),，微基準(zhǔn)測試能從更細(xì)粒度的方向?qū)ο到y(tǒng)進(jìn)行測試,，它排除了不相干的噪聲干擾，可以專注于對性能優(yōu)化點所影響的指標(biāo)進(jìn)行測試,。

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

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

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

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

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

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

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

3.性能工程團隊

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

對于構(gòu)建性能工程，需要組建一個分別包含了領(lǐng)域?qū)＜?、性能專家和工程專家的專業(yè)化團隊,。

在 Matthew Skelton 和 Manuel Pais 的《團隊拓?fù)洹分校枋隽怂姆N基本的團隊類型：

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

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

賦能團隊：特定技術(shù)領(lǐng)域或產(chǎn)品領(lǐng)域的專家,，為業(yè)務(wù)流團隊賦能。

復(fù)雜子系統(tǒng)團隊：構(gòu)建和維護系統(tǒng)中嚴(yán)重依賴專業(yè)領(lǐng)域知識的子系統(tǒng),。

平臺團隊：為產(chǎn)品導(dǎo)向團隊構(gòu)建能提供自服務(wù)的各項基礎(chǔ)能力,。

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

當(dāng)負(fù)責(zé)協(xié)助業(yè)務(wù)流團隊對具體的產(chǎn)品或組件進(jìn)行性能診斷和優(yōu)化時，性能工程團隊是賦能團隊,；

當(dāng)對系統(tǒng)層面實施性能優(yōu)化時,，性能工程團隊變?yōu)閺?fù)雜子系統(tǒng)團隊；

而當(dāng)構(gòu)建性能建模,、性能觀測等平臺化能力時,，性能工程團隊又成為了平臺團隊。

能有效承擔(dān)上述工作職責(zé),，與團隊本身的成員構(gòu)成密不可分,。

在 SDV 的語境下，領(lǐng)域?qū)＜倚枰煜ぼ囕d系統(tǒng)在不同場景下的業(yè)務(wù)構(gòu)成及其性能要求,，性能評估模型中的業(yè)務(wù)指標(biāo),，也大都是由領(lǐng)域?qū)＜一跇I(yè)務(wù)經(jīng)驗給出的,。領(lǐng)域?qū)＜也灰欢ㄩL期在性能工程團隊工作，TA 可能是技術(shù)架構(gòu)師,，業(yè)務(wù)分析師或產(chǎn)品經(jīng)理,，但結(jié)合業(yè)務(wù)和性能的跨領(lǐng)域能力十分關(guān)鍵。

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

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

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

總結(jié)

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

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

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

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

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

對軟件性能工程這件事，我們?nèi)栽诔掷m(xù)不斷地探索和實踐,，希望本文能對您產(chǎn)生幫助,。