1. 程式人生 > >高德車載導航的差分更新優化實踐

高德車載導航的差分更新優化實踐

導讀
隨著車載裝置聯網化,越來越多的車載裝置從離線走到了線上。高德車載導航也早已從過去的離線安裝包更新演進到了線上迭代更新。但原車載裝置的Android硬體配置遠低於手機,主要表現在處理器主頻低、記憶體和儲存空間有限,導致車載導航在車機上會出現無法下載新版本資料包、更新過程耗時長導致卡頓的情況,對導航應用的效能提出了要求。

為提高使用者體驗,高德技術團隊立項解決了該問題。本文小結了高德車載導航在版本自更新演進過程中二進位制差分解決方案的效能優化實踐。

差分更新方案比較

對於應用程式的版本更新迭代,除了分發全量的安裝包,還有一種更低成本的方式是分發增量包,即通過下發前後兩個版本的差異部分(這個過程下面簡稱Diff),然後在客戶端對原版本進行補丁更新(這個過程下面簡稱Patch)。因此也叫差分更新。

業內比較流行的差分方案主要有: bsdiff、Xdelta3和Courgette。最後一個方案Courgette來自於谷歌,主要解決的是可執行檔案的差分,而導航更新資源不僅包含可執行檔案,還包含了圖片等各種資原始檔。所以,我們主要對比bsdiff和Xdelta3方案。

bsdiff和Xdelta3方案比較

下面是我們對選取的幾個檔案做的bsdiff和Xdelta3差分效能對比:

bsdiff的優勢是壓縮比高,生成的差分檔案非常小,但Patch過程耗時。而Xdelta3的優勢是Patch過程耗時極短,但記憶體消耗非常大。

相比高德車載導航自身執行記憶體開銷不足100MB的情況,Xdelta3的Patch記憶體消耗無法接受。因此我們選用了bsdiff作為自更新方案。

原生bsdiff方案缺陷與改進

原生bsdiff方案使得壓縮比問題得到解決,但在車載導航自更新中還存在下面兩個缺陷:

  • 記憶體消耗大,整個過程會佔用10~35MB左右的記憶體。
  • 耗時長,整個包更新時間在3分鐘左右。

在對bsdiff的優化探索中我們發現Chromium開源專案中存在一份基於bsdiff的優化版本。該版本將bsidff的預設sufsort演算法替換成了divsufsort演算法,在Patch時間上有了較大的提升。

 

使用Chromium版本的bsdiff, 高德車載導航的自更新效能如下:

  • 記憶體消耗在10~20MB。
  • 整個Patch過程耗時仍然長達25秒左右。

耗時依然很長。

由於Patch過程是一個CPU密集型的操作,且車載裝置CPU的效能普遍不足,這意味著在整個升級過程中使用者能明顯感受到導航的操作卡頓。同時,更新時間越長意味著遭遇斷電的可能性也越大。

基於以上分析,我們決定對Chromium版本的bsdiff進行CPU和記憶體上的效能優化。

bsdiff在車載自更新業務中的效能優化實踐

在車載自更新業務上,我們設定的目標是整體更新時間小於6秒,且記憶體開銷小於2MB。整個優化的過程就是圍繞時間和空間的取捨。

記憶體優化方案

經過對bsdiff原始碼的分析,其Patch記憶體主要開銷來自檔案內容在記憶體中的讀寫暫存和Bzip2的解壓開銷。通過調整Bzip2引數可以降低部分記憶體,但無法達到期望。而檔案讀寫的記憶體佔用主要來自於其在記憶體中的暫存。

基於bsdiff差分Patch包的檔案格式,我們增加了滑動視窗緩衝區的Patch特性,使其在檔案的流式處理上能夠有更好的記憶體消耗可控性。每次讀取和寫入指定的滑動視窗大小資料,使資料即來即走。

演算法優化方案

經過上述的優化後,Patch過程的主要效能瓶頸在於Bzip2的解壓演算法中,即使調整Bzip2引數也無法減少本身的計算量。

bsdiff差分演算法的一個特性就是差分出的Patch資料包含了大量連續的01冗餘資料,而Bzip2演算法的優點就是對這類資料可以做到高度的壓縮,這也是bsdiff壓縮比高的原因。不過現在是目前的瓶頸。

此外,我們會製作軟體整體的壓縮差分包(即生成tar.bz2或zip格式檔案),也就是說針對每個Bzip2壓縮後的差分檔案還要再經過一次壓縮歸檔。這也意味著在客戶段要進行兩次的解壓。

替換壓縮演算法

類似的冗餘壓縮演算法有RLE(Run-length encoding),這個演算法也是Bzip2演算法的第一步。簡單來說RLE演算法就是針對連續多個冗餘位元組去掉其冗餘位元組,僅保留冗餘的長度資訊。這個演算法相對更簡單。

因此,我們將Bzip2壓縮演算法替換成了RLE演算法,實際結果發現生成的Patch檔案很大, 壓縮比很低。但是可以通過再次壓縮歸檔製作一次差分包,就可以達到和Bzip2幾乎相同的壓縮比效果。唯一的不足就是在客戶端解壓後會佔用多一些磁碟空間, 而這個代價相對廉價多了。

優化效能對比

經過上述整體優化後,效能對比如下:

經過記憶體優化後的方案空間複雜度將為了O(1)。

上面的耗時差異在ARM車機會更明顯:

最終優化收益:記憶體消耗控制在2MB以內,整體Patch更新耗時3~5秒。

小結
通過對bsdiff的優化,高德車載導航在自更新效能上取得了較大收益。大幅縮短了使用者下載和更新時間,降低了對ARM車機的硬體資源要求。為推動車載導航OTA更新提供了技術基礎,對未來高德車載導航在分發新功能、新業務上鋪平了道路。

相關推薦

車載導航更新優化實踐

導讀隨著車載裝置聯網化,越來越多的車載裝置從離線走到了線上。高德車載導航也早已從過去的離線安裝包更新演進到了線上迭代更新。但原車載裝置的Android硬體配置遠低於手機,主要表現在處理器主頻低、記憶體和儲存空間有限,導致車載導航在車機上會出現無法下載新版本資料包、更新過程耗時長導致卡頓的情況,對導航應用的效能

車載導航自研圖片格式的探索和實踐

背景隨著近年來車內多媒體裝置從無屏向有屏的發展,市場上出現了各種形狀、尺寸和解析度的車機螢幕,其豐富程度遠遠超過Android適配的手機螢幕。 高德車載導航過去採用的多套UI 圖片資源,通過拉伸、縮小來適應各種車機螢幕以便減少內部UI資源開發和管理成本的方式受到越來越大的挑戰:軟體包的Size不斷增加,對安裝

機器學習在搜尋建議中的應用優化實踐

本文將主要介紹機器學習在高德搜尋建議的具體應用,尤其是在模型優化方面進行的一些嘗試,這些探索和實踐都已歷經驗證,取得了不錯的效果,並且為後來幾年個性化、深度學習、向量索引的應用奠定了基礎。 對搜尋排序模組做重構 搜尋建議(suggest服務)是指:使用者在輸入框輸入query的過程中,為使用者自動補全

APP啟動耗時剖析與優化實踐(iOS篇)

前言最近高德地圖APP完成了一次啟動優化專項,超預期將雙端啟動的耗時都降低了65%以上,iOS在iPhone7上速度達到了400毫秒以內。就像產品們用後說的,快到不習慣。算一下每天為使用者省下的時間,還是蠻有成就感的,本文做個小結。 (文中配圖均為多才多藝的技術哥哥手繪)   啟動階段效能多維度

C# JavaScrpt地圖航跡-實時更新

一、既然是地圖,當然先在工具欄裡,新增WebBrowser控制元件,由於還需要選單,所以在屬性裡面設定為:None,然後新增好選單,再在WebBrowser上,選擇 在父容器中停靠。 再加上一些程式碼。地圖的效果就出來了。 這裡還要說明一下。地圖是JavaScrpt的高

Android的增量更新,更新--伺服器端&客戶端

前言 隨著應用越來越大,應用更新耗時間和流量的問題,就顯得格外突出. 目前原生app的更新分為兩種:重新下載原始檔,還有一種就是差分包更新,也叫增量更新. 在有些應用市場,例如google play,會對安裝包進行拆分和合並,來達到差分更新的目的. 首先

iOS呼叫地圖導航

    在iOS開發地圖模組中,有需要用到導航的功能,尤其類似一些送快遞、外賣等軟體,除了需要展示路線到地圖中,還需要有一個導航按鈕。一般導航功能分兩類:一類是在本APP內部呼叫高德API的導航頁面,即在APP內部整合導航模組,此類導航頁面可以自己定製介面,但基本功能都是呼叫

IOS 地圖導航

引言 高德地圖導航包還是淺顯易懂,筆者在這裡做點總結,實際操作一遍。 導航分為模擬導航和實時導航兩種,兩種導航都包括語音提示、停止導航、暫停或繼續導航功能。通過模擬導航,使用者可預先了解出行路線,直觀掌握沿途每一個特別路口的交通狀況,讓出行更從容。 算路成

跳轉到地圖或百度地圖或網頁導航

最近做一個新專案,需要用到導航,專案集成了高德的SDK,所以本來想直接用SDK內的導航方法,但是發現高德最新版的導航改版了,如果SDK內加上導航模組會使得整個專案大十幾二十M,所以決定棄用SDK內的導航,最終決定,採用以下方案: 1.當手機內有高德地圖app時

深度學習在駕車導航歷史速度預測中的探索與實踐

導讀 駕車導航服務是數字地圖提供的核心功能。通常而言,使用者在發起導航之前會對比高德前端展示的三條路線(如下圖),以決定按照哪條路線行駛。     而預估到達時間是使用者參考的最為重要的指標之一。給定一條路線,對應的預估到達時間的計算需要兩組資訊輸入,分別是實時路況資訊和

併發降溫,美團高效能、可靠四層負載均衡MGW優化實踐

負載均衡的作用及分類 網際網路初期階段,業務邏輯簡單、流量不大,單臺伺服器就可滿足日常需求。隨著網際網路的發展,業務不僅會流量爆發、邏輯越來越複雜且對可靠性的需求也逐步遞增。 這時,就需要多臺伺服器來應對單臺伺服器在效能、單點等方面凸顯出來的問題,進行效能的水平擴充套件和災備。但客戶端的流量要如何順利訪問到

機器學習在起點抓路中的應用實踐

導讀:高德地圖作為中國領先的出行領域解決方案提供商,導航是其核心使用者場景。路線規劃作為導航的前提,是根據起點、終點以及路徑策略設定,為使用者量身定製出行方案。   起點抓路,作為路線規劃的初始必備環節,其準確率對於路線規劃質量及使用者體驗至關重要。本文將介紹高德地圖針對起點抓路準確率的提升,尤

機器學習在使用者反饋資訊處理中的實踐

1.背景作為國內領先的出行大資料公司,高德地圖擁有眾多的使用者和合作廠商,這為高德帶來了海量的出行資料,同時通過各個渠道,這些使用者也在主動地為我們提供大量的反饋資訊,這些資訊是需要我們深入挖掘並作用於產品的,是高德地圖不斷進步和持續提升服務質量的重要手段。 本文將主要介紹針對使用者反饋的文字情報,如何利用機

衛星影像識別技術在資料建設中的探索與實踐

導讀對於地圖服務而言,地圖資料的準確率和覆蓋率是服務質量的關鍵因素,而地圖資料的更新,依賴於多種資訊源,如軌跡熱力,實採影象,衛星影像等。近年來,由於遙感衛星數量的增多及高解析度光譜相機的出現,以及衛星影像圖自身覆蓋廣、視角好、資訊豐富的特點,衛星影像作為地圖資料更新的資訊源起到了越來越重要的作用。 對於衛星

地圖駕車導航記憶體優化原理與實戰

​背景 根據Apple官方WWDC的回答,減少記憶體可以讓使用者體驗到更快的啟動速度,不會因為記憶體過大而導致Crash,可以讓APP存活的更久。 對於高德地圖來說,根據線上資料的分析,記憶體過高會導致導航過程中系統強殺OOM。尤其區別於其他APP的地方是,一般APP只需要關注前臺記憶體過高的系統強殺FOOM

Android 仿微信調用第三方應用導航(百度,、騰訊)

detail decorview fcm onclick api 描述 log def repr 實現目標 先來一張微信功能截圖看看要做什麽 其實就是有一個目的地,點擊目的地的時候彈出可選擇的應用進行導航。 大腦動一下,要實現這個功能應該大體分成兩步: 底部彈出可選的地

17款奇駿智能互聯連接成功--導航

2017 17款 17款奇駿 奇駿 智能互聯 環境:17款奇駿舒適2.0,原裝車載大屏、小米5s plus、系統版本miui 9 穩定版互聯軟件下載地址:http://www.dongfeng-nissan.com/Nissan/download/app/MobileAppXF想說的話:本

Codeforces 479E Riding in a Lift:前綴和/優化dp

spa -s ios cin sin lin 做的 codeforce 當前 題目鏈接:http://codeforces.com/problemset/problem/479/E 題意:   有一棟n層的房子。   還有一個無聊的人在玩電梯,每次玩電梯都會從某一層坐

QGIS在ANDRIOD上利用API實現道路導航功能

qgisQGIS在ANDRIOD上利用高德API實現道路導航功能

ionic3 應用內開啟第三方地圖導航 百度

1.安裝檢測第三方APP是否存在的外掛  cordova plugin add cordova-plugin-appavailability --save    npm install --save @ionic-native/app-availability &n