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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

成熟的技術(shù)支持：需要的知識(shí)、技術(shù)能力和人才,，其中領(lǐng)域?qū)＜?、性能專家和工程專家這三類角色非常關(guān)鍵。

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

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

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

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

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

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

(1) 建立評估模型

性能評估模型作為性能建?；顒?dòng)的產(chǎn)出物之一，在系統(tǒng)建設(shè)之初就可以著手開展,，同時(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)運(yùn)行過程中的內(nèi)部狀態(tài)，它們會(huì)間接影響到業(yè)務(wù)指標(biāo),。

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

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

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

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

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

為了有效地評估系統(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è)備上的探針前端以及上位機(jī)或服務(wù)器上的分析后端,。由于直接運(yùn)行在設(shè)備上,，探針自身的開銷不容忽視，因此通常性能探針都包含細(xì)粒度的配置能力,，在研發(fā)或測試階段,，打開全部或大部分開關(guān)，而在生產(chǎn)運(yùn)行階段只打開部分開銷低的信息收集功能,。

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

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

(3) 性能看護(hù)

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

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

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

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

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

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

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

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

(1) TopDown 分析與問題建模

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

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

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

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

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

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

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

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

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

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

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

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

3.性能工程團(tuán)隊(duì)

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

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

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

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

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

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

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

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

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

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

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

而當(dāng)構(gòu)建性能建模、性能觀測等平臺(tái)化能力時(shí),，性能工程團(tuán)隊(duì)又成為了平臺(tái)團(tuán)隊(duì),。

能有效承擔(dān)上述工作職責(zé)，與團(tuán)隊(duì)本身的成員構(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)驗(yàn)給出的,。領(lǐng)域?qū)＜也灰欢ㄩL期在性能工程團(tuán)隊(duì)工作，TA 可能是技術(shù)架構(gòu)師,，業(yè)務(wù)分析師或產(chǎn)品經(jīng)理,，但結(jié)合業(yè)務(wù)和性能的跨領(lǐng)域能力十分關(guān)鍵。

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

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

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

總結(jié)

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

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

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

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

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

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