基於定位的出發地異常問題治理詳情 - 前端,地圖哈囉技術博客

前言

哈囉作為一家出行互聯網公司，定位這種基礎能力是深度融入在各業務的核心鏈路中的，筆者所在的地圖團隊經常會收到定位相關的badcase，但苦於定位的複雜與較難回收出價值，一直沒有針對性去解決此類問題，那在各大互聯網廠商都在做下沉市場注重用户體驗的今天，我們重新撿起了這個話題。

問題梳理

無位置

由於APP啓動時未獲取到位置，會給用户提示並阻塞發單，用户需要使用POI搜索或拖動地圖的方式選擇出發地進行發單。

定位漂移

定位漂移是定位最影響訂單履約的問題。由於它不阻塞發單，問題的暴露節點往往在司機到達訂單出發地後等待乘客上車的環節，司機接不到乘客導致糟糕的用户體驗甚至取消訂單，嚴重影響品牌口碑。

舉個🌰：

經後台日誌查看，這筆訂單發單定位不準導致車主找不到用户，造成了訂單取消。用户於11:10:48.650時啓動APP ->11:10:50.417設備定位在東方康羅->11:10:51.241 這個時間定位恢復到現代物流大廈。

用户啓動後請求上車點時的經緯度是一個噪點，在用户定位恢復後並沒有重新刷新位置請求新的上車點，造成了使用漂移的定位為出發地最終影響訂單履約。而為什麼iOS設備經常出現首次定位不準會在下一章見詳解。

現狀概括

哈囉目前使用的高德的定位SDK，遇到問題要通過向高德提工單的方式解決，但由於定位的badcase有着較強的環境干預因素無法在高德的demo中復現，且高德本身對於定位SDK也沒有相關的日誌（數據量級過大且很難有價值），反饋的定位問題基本無法解決，最後只能一句“這是系統問題，沒辦法解決”而草草了事。

定位的複雜

由於定位的badcase五花八門，要搞清楚不同平台的手機定位原理和差異是首要問題，在與哈囉的使用現狀相結合，知己知彼後續才能制定出針對性的解決方案。要明確不準的原因有什麼？高德定位的機制是什麼？我們能做什麼？我在整理前也就只知道個大概，遮擋啊、信號差啊啥的，但沒有形成系統理論，接下來我會詳細整理定位這個大課題，為我們後續的優化提供一定的理論基礎。

定位原理

手機廠商的定位能力都是自己實現的，但是各自的規格都不一樣，使用高德SDK可以打平Android各廠商之間實現的差異，定位能力包括GNSS、DR（航跡推算）、MM（地圖匹配）、視覺定位和網絡定位等。

1.衞星定位
衞星定位系統的英文是Global Navigation Satellite System(GNSS），雖然直接翻譯過來是導航衞星系統，但它真正提供的能力是定位，能定位後，導航就變得相對簡單了。衞星定位的原理，是利用衞星播發時間信號，當設備接收到後，可以根據信號發射時間和本地時間，計算出信號傳輸時間，再結合光速獲得衞星-設備距離。

有了多顆衞星的信號，可以列出一組方程，求解4個未知數：設備的三維座標x/y/z，以及本地時間與GNSS系統的時間差。式中的代表衞星j的三維座標，這個座標可以通過衞星星曆計算獲得。

星曆是描述衞星運行軌道的一組參數，衞星軌道是一個橢圓，通過幾個參數和時間，可以唯一確定衞星的準確位置。

星曆的獲取有兩種方式，一種是衞星直接播發，這種方式的好處是定位過程不依賴衞星信號以外的任何輸入，即使沒有網絡也可以定位成功，但問題是衞星鏈路帶寬很小，要下載完整星曆，需要30秒左右的時間，早期的手機和一些車載設備定位過程很慢，就是由於這個原因。

另一種方式，是通過互聯網播發，這種方式叫A-GNSS，具體的傳輸協議叫SUPL(Secure User Plane Location)，這種數據一般不對應用層透出，在手機上操作系統會在底層定時請求SUPL數據，然後將獲得的星曆注入GNSS芯片。有了A-GNSS，設備就可以在秒級獲得定位，不需要任何等待過程，目前所有的手機都支持這種方式。A-GNSS的服務提供商，主要是通信運營商，以及一些定位服務商，比如谷歌、千尋等。

衞星不間斷的向地面廣播信號，這個信號主要包括以下信息：

衞星編號：用於從星曆中查找衞星軌道，再結合時間戳獲得當前衞星位置
當前時間戳：用於獲得衞星位置，另一方面計算偽距。偽距是(本地時間-信號發射時間)*光速，之所以叫偽距，是因為本地時間與衞星時間不同步，所以這個距離並不是真正的設備-衞星距離。
星曆數據：用於計算衞星位置。

像其他所有的通信技術一樣，這些信息也是以報文的形式發送的，以GPS為例，衞星會每隔6秒發出一個包，而這個包會分解為數據位-CA碼序列-載波波形，通過天線發射到地面。地面設備持續鎖定衞星，在解算時，計算每顆衞星當前時刻的時間戳（用最近一次收到的時間戳加上報文偏移量），然後進行位置解算。

載波的頻率是1.5G左右，波長20釐米左右，比移動通信的波長稍長一些，所以信號的穿透性還是比較好的（波長越長，越容易繞開障礙物），可以穿透比較薄的牆壁或屋頂，所以在一些情況下即使無法直接看到天空，也是能定位的。但是衞星信號是從上往下，在室內很難穿越多層建築。

定位誤差來源與精度提升

衞星定位雖然已經很準確了，但是在某些場景下，還是無法滿足需求，比如，打車的時候定位點離車輛有一定距離、步導的時候難以區分方向甚至會定位到馬路對面、靜止的時候定位點總數飄來飄去、室內的時候定位點亂飄。這需要從衞星信號的發射、傳輸、接收過程來解釋。

衞星信號從發射到被設備接收，需要經過大氣層，其中，大氣電離層有數千公里厚，這部分大氣非常稀薄，但是存在大量被電離的電子，這部分電子會讓電磁波變慢一點，從而產生延遲。在對流層，也會產生一定的延遲。在地表附近，由於各種建築、山體、水面的影響，衞星信號可能被反射或折射（多徑效應），產生延遲。

在衞星信號發射側和接收側，也有很多系統相關的誤差，比如時鐘偏差、處理延遲等，這些延遲加上傳輸延遲，使得衞星信號的傳輸時間，並不是準確的等於物理距離/光速，另一方面，衞星的星曆也有誤差，衞星位置和真實位置存在偏差，最終造成了定位結果產生偏差。

雙頻GNSS：不同頻率的電磁波通過電離層時會有不同的延遲，人們發現，對兩個或多個頻率的觀測值進行線性組合，可以消除電離層誤差，從而能提升精度。這就是雙頻GNSS定位的原理。小米8是業界第一款支持雙頻GNSS定位的手機，後續各大廠商均進行了跟進，一些高端手機均採用雙頻定位。消除電離層誤差後，定位精度可以提升到5米以內。iPhone 14 Pro 和 iPhone 14 Pro Max 才支持雙頻 GPS 定位。

設備差異
iOS設備
iOS設備的定位能力是完全封閉的，對外只透出定位結果，外部基本無法拿到任何定位相關的原始觀測量，比如衞星數量、類型等。好消息是，iPhone12終於開始支持北斗了。從蘋果的API上，外界甚至無法區分定位結果到底是來自衞星定位還是網絡定位（目前僅能通過速度的符號來判斷，但蘋果對此沒有任何承諾）。所以，基於iOS設備高德基本無法做出優化，iOS設備上高德地圖的定位點都是iOS底層直接提供的。

Android設備

Android設備比iOS設備開放的多，在定位能力方面提供了一系列API：

可以單獨獲取衞星定位結果或網絡定位結果，也可以同時進行兩種定位。
提供了NMEA格式（一種衞星定位結果的規範化表達）的結果數據，可以獲取每顆衞星的ID、類型、信號強度，以及xDOP等細粒度的誤差描述。
提供了GnssStatus來描述每顆衞星的狀態，內容比NMEA更全面。
提供了GnssMeasurement來描述原始觀測量，包括偽距測量值、載波相位測量值、衞星鎖定狀態等。
提供了GnssClock描述本地時鐘的狀態。
提供了GnssNavigation透出最原始的未解碼報文。

2.網絡定位

網絡定位是通過客户端掃描到的WiFi和基站信息來進行定位的一種定位方式。網絡定位能力是GNSS定位的有力補充，在GNSS無法定位或者定位較慢的時候（例如地鐵、高架、室內等場景），網絡定位都可以快速給出位置。網絡定位能力也是高德能夠深植於各類手機廠商（提供系統級網絡定位能力）和APP（出行、社交、O2O、P2P、旅遊、新聞、天氣等諸多領域）的原因之一。

注：高德網絡定位只存在於Android平台上，在iOS上由於蘋果公司未開放任何定位相關的指紋數據（WiFi、基站列表等），定位結果全部來自於iOS自身。

高德Android設備優化

網絡定位分為離線訓練和在線定位兩個過程：

離線訓練：是在用户有GPS位置時採集周邊的WiFi和基站（以下統稱為AP）信息，通過對採集數據進行聚類和關聯，得到兩類數據產品：AP庫和指紋庫;
在線定位：與離線訓練的過程正好相反，當用户沒有GPS定位時，可以通過掃描到的周邊WiFi和基站信號，結合離線訓練出的AP庫和指紋庫來進行實時定位。

AP庫和指紋庫這兩類數據產品中：

AP庫：以WiFi的mac地址或者基站的ID（gsm基站為mcc_mnc_lac_cid，cdma基站為mcc_sid _bsid_nid ）為主鍵，以WiFi或者基站的物理座標信息（經緯度或者地理柵格座標信息）為內容。
指紋庫：以物理座標位置對應的特徵指紋信息為內容，這些特徵指紋信息可以包括掃描到的WiFi或者基站的信號強度分佈，採集點頻次等統計信息，也可以是通過神經網絡提取出的特徵信息。

典型的AP庫數據只包含挖掘出的物理座標信息和覆蓋半徑，這種“點圓模型”是對AP發射信號的一種理想化，沒有考慮任何實際場景中的信號遮擋、反射等情況，所以AP庫大多用來進行粗略定位（WiFi覆蓋半徑50-100米基站 1km-10km ）。而指紋庫直接與位置相關，可以刻畫比“點圓模型”更細緻的分佈信息，所以指紋庫可以用來進行精細定位，不同場景算法不同，室內室外、場站高架。高德的指紋庫主要包括特有的室內指紋和全場景指紋信息兩種。

網絡定位問題
網絡定位的基本思路類似聚類，假設用户手機掃描到的AP列表中的AP的位置均比較固定，則我們可以以這些AP位置為錨點，來確定用户位置。現實世界中，錨點（即AP庫中的AP）的位置通過大數據來進行挖掘，並不一定完全準確，甚至出現嚴重錯誤，大多數網絡定位問題都發生在聚簇中，由於定位依據不足，WiFi少、信號弱等。

針對WiFi而言，移動WiFi、克隆WiFi、搬家WiFi等都可能造成AP位置的錯誤。移動WiFi包含手機熱點，4g移動路由器，公交車/地鐵/高鐵上的WiFi熱點等，這些WiFi的移動屬性較強，位置頻繁變化，如下圖所示。

如果以移動WiFi作為錨點，因為這些錨點的位置不固定，極可能會導致用户的定位出現極大誤差。克隆WiFi指不同的WiFi設備使用了同一個mac地址，國內的騰達和斐訊等路由器廠商製造了大量這樣的WiFi設備（例如大部分mac前綴為“c8:3a:35”的即為騰達的克隆WiFi），克隆WiFi導致AP庫中同一個mac地址對應的錨點位置有多個。搬家WiFi指某些因為搬家而發生位置變化的WiFi，數據挖掘存在一定的滯後性，搬家後AP庫中的位置未及時更新，也會造成定位錯誤。以下為定位點散佈的實例。

高德通過訓練分類模型的形式將這些非固定WiFi的屬性在AP庫中標記出來，以“移動WiFi識別”為例，由於AP庫中的WiFi數量十分龐大，高德根據人工規則的判定結果提取了一批確定性較高的樣本，使用人工強特徵訓練第一版模型，之後將第一版模型的預測結果與線上人工規則的結果進行全量比較，提取出模糊樣本進行人工標註。在標註樣本的過程中發現問題，持續特徵工程，不斷迭代模型。這部分距離我們比較遙遠不再展開了，感興趣的同學可以閲讀參考文獻。
蘋果iOS設備優化

無網基站定位

傳統的基站定位需要連接雲端服務器，產生網絡流量，iOS 4對其進行了優化，可以在沒有網絡連接時支持無網定位，因為蘋果預先已經將一些重要基站（幾十公里選一個）提前存儲在iOS系統中，在無網情況下，不用上網也能通過這些本地基站信息定位到用户位置，但這個誤差範圍更大，在10公里到50公里。

注意：您的手機能接受到內置在手機中的那些“重要基站”的信號，不一定是您手機所屬運營商，只要能收到信號就可以了。

無網WiFi定位
傳統的WiFi定位需要網絡，但是iOS對其進行了優化，可以實現無網WiFi定位。原理是iOS設備在您有網絡連接時，會大致定位出您的位置，並自動下載您所在地區周圍（幾個街區寬度或者更多）所有的WiFi熱點的信息到本地。之後，當您在周圍行走並WiFi定位的時候，即使沒有網絡，iOS照樣可以利用之前下載的WiFi熱點信息定位出您的位置。關於自動下載的熱點個數和範圍，這個是蘋果根據當地熱點的密度動態決定的，當地熱點很多時（如市中心），可能只下載幾條街道範圍的所有熱點，當地熱點密度很小時（例如海濱城市），可能會下載整個城市的所有熱點。

注意：無網WiFi定位的前提是您在這個區域附近曾經成功上過網，如果初次到一個陌生的地方，是無法定位的。

常見問題：

1.為什麼iPhone當前定位誤差有幾百或者上千米?
iPhone初始定位都是用基站或者無網基站定位，誤差幾百或幾公里。之後，如果無法搜索到WiFi信號，或者無法搜索到衞星信號，就會一直是這個精度。
您可以打開WiFi功能（不用連上，只需要打開即可），或者到窗户邊，或者户外以便收到衞星信號;
解決方法: 多等一會兒，開啓數據流量（定位之後即可關閉），或者到户外去。

2.為什麼我的位置總是變來變去?
iOS根據當前網絡環境，會不斷調整和修正定位方式，可能您所處地區基站和WiFi信號太複雜或者太微弱，比如一會兒連上這個基站，一會兒連上另一個基站，導致iOS計算位置的時候不穩定。
解決方法: 打開WiFi功能，開啓數據流量（定位之後即可關閉），或者到户外去。

3.無手機信號可以定位嗎？無數據流量可以定位嗎?
情況1：【沒有手機信號，沒有WiFi信號，沒有上網】則定位只能在户外利用GPS進行，初次定位時間可能很長，可能需要數分鐘，之後定位正常。
情況2：【沒有手機信號，有WiFi信號，沒有上網】如果之前在周圍上過網，下載了附近的熱點，則利用無網WiFi定位可以找到位置，否則，和情況1一樣。
情況3：【沒有手機信號，有WiFi信號，可以上網】利用WiFi定位找到位置，並且在定位時還會下載大量的周圍很大一個區域的所有WiFi熱點信息，用於今後無網WiFi定位。
情況4：【有手機信號，沒有WiFi信號，沒有上網】如果能收到iOS內置的“重要基站”的信號，則使用這些基站進行無望基站定位，否則，無法定位。
情況5：【有手機信號，沒有WiFi信號，可以上網】使用基站定位聯網查詢進行定位，同時可能會更新本地“重要基站”信息。

打開WiFi開關是一個提升定位的好方法，以前都沒注意過。我看網上還有説“為了提高iPhone上的GPS精度，您需要允許設備根據您的時區自動設置日期和時間。這樣，智能手機就可以瞭解您的身處，並確定可以連接的GPS衞星。”這種方法的。

關鍵提煉

定位結果由衞星定位或網絡定位返回，兩者互為補充且各有些原因導致其準確性降低
高德的網絡定位只適用於Android設備，iOS設備使用的是系統的定位，所以Android的國內定位效果要好一些
iOS設備定位會初始一個精度較差的值（iPhone初始定位都是用基站或者無網基站定位，誤差幾百或幾公里），然後不斷地更新精度（如更新不到則一直保持此精度）
Android設備能獲取到更為豐富的信息如衞星編號，WiFi列表等，而iOS設備能獲取到的額外信息幾乎沒有
打開WiFi開關是一個提升定位的好方法，可以讓設備使用到網絡定位

對症下藥

基於以上原理分析，我們制定了一系列的優化方案，重點解決無定位與定位漂移的問題。

構建監控體系

做任何優化工作的第一步永遠都是補齊埋點、建立口徑、摸清現狀，也方便後續回收效果，用數據説話。由於定位相關的埋點量級過大，全量埋點對服務器的壓力很大，而且定位異常只是小概率事件，絕大多數的數據全是無用數據，因此我們選擇對關鍵節點進行監控，對首次獲取和用當前定位作為出發地的訂單進行監控並能量化出異常定位對普惠訂單的影響。

無定位優化

在上述定位原理章節我們瞭解到提示用户打開WiFi可以幫助用户使用網絡定位，能高效提升用户室內定位的準確性，此外在與高德同學的排查溝通中，我們瞭解到當我們設置的定位閾值設置過精時，如果當時達不到設置的精度要求可能不會返回位置。基於以上兩點，我們落地兩個產品邏輯，無定位WiFi開關打開提示和無定位時降低精度閾值重新請求的兜底邏輯。

定位漂移優化

從最終結果看定位漂移實際反饋到交易體感上的影響就是由設備定位位置到用户真實位置的誤差反饋到訂單起點與用户真實位置的誤差，基於此我們發起了通過程序主動與被動的方式解決用户基於定位的出發地發單異常識別與修復專題，整體方案邏輯如下：

出發地遠距離提示
在識別到用户出發地位置與用户真實位置距離較遠時，在UI層面給予用户提示，幫助用户主動確認出發地是否符合預期，而在用户發單的節點會對用户的當前位置與出發地進行二次確認邏輯，如過遠會對用户進行彈窗提示，完成最終把關。

為何在發單環節還要進行阻塞干預？

講一個有趣的小故事，筆者在聽抖音關於直播間技術的分享時有一個問題是講抖音是如何識別監控直播間卡頓的？這無疑是個非常複雜的問題，是個例還是共性？是主播發送鏈路還是家人們的接收鏈路？是移動端還是服務端問題？相信不同角色的工程師對於這個問題都會在各自的領域內給出一個專業的答案，如客户端工程師會關注手機播放器的性能、網絡工程師會關注上下行的流量、後端工程師會檢測自己服務的性能等等，哪種方案都無法完全覆蓋直播間卡頓這個超複雜問題，而抖音給出的解決方案確實讓我眼前一亮：通過監測直播間的彈幕如卡了、不動了等關鍵字。這個方案太妙了，妙在它是一種思維方式的轉變，像抖音直播間是否流暢播放明顯是一個端到端解決方案，他們在整個端到端的終態也就是給用户呈現的層面進行監控，可以覆蓋整個端到端鏈路，同理像用户從選擇起點到發單也是一個端到端場景，中間涉及到用户使用定位、拖拽地圖、選擇POI、推薦上車點的召回、用户線下的不確定性動作等等行為，而在發單節點進行校驗是一個端到端尾節點的干預邏輯，更能影響最終結果，在我們分析的時候確實是有一部分用户在選完出發地後自己又走了一段距離後忘了更新出發地直接發單了導致訂單出發地離用户真實位置較遠的badcase。

噪點識別與糾偏

我們通過定位&IMU(Inertial measurementunit 慣性測量單元)&算法實現了一套軟件+硬件相結合的解決方案，識別出噪點並進行糾偏干預。

糾偏為何放到端上去做？

在端上部署糾偏算法更適用於出行這種網絡與定位環境複雜，在無或弱網絡信號和定位信號的場景進行補救的場景，節省持續大量計算數據傳輸到後端運算後在傳回端上的耗時操作，在無網絡成本的情況下更好的賦能出行業務，且我們的算法對性能消耗的較少不會產生性能問題。

PDR

PDR (Pedestrian Dead Reckoning 行人航位推算) 是一種定位技術，用於在室內或無 GPS 信號的環境中跟蹤行人的位置。它通過使用傳感器數據（如加速度計、陀螺儀和磁力計）來估計行人的步長、方向和位置變化。PDR 技術在室內導航、室內定位和增強現實等應用中具有重要的作用，特別是在缺乏 GPS 信號或需要高精度定位的環境中。然而，PDR 技術也存在一些挑戰，如傳感器誤差累積、行人步行模式的變化和環境干擾等，需要採取適當的算法和校準方法來解決這些問題。

步長估計：PDR 的第一步是通過加速度計來估計行人的步長。加速度計可以測量行人每一步的加速度變化。通過檢測加速度的峯值和谷值，並結合行人的身高和步行模式，可以估計出平均步長。這個步長估計可能會受到行人的個體差異和步行環境的影響。
步頻估計：除了步長，PDR 還需要估計行人的步頻，即每分鐘的步數。通過使用加速度計和濾波算法，可以檢測步行的週期性模式，並估計出步頻。
方向估計：PDR 需要估計行人的方向變化。這可以通過使用陀螺儀和磁力計來實現。陀螺儀可以測量設備的旋轉速度，而磁力計可以提供地磁信息。通過結合這些傳感器的數據，可以估計出行人的方向變化。
位置計算：基於步長、步頻和方向的估計，PDR 可以計算行人的位置變化。初始位置通常是通過其他定位技術（如起始位置的 GPS 或 Wi-Fi 定位）獲得的。通過累積每一步的位移和方向變化，可以計算出行人的當前位置。
誤差校正：PDR 的實現中需要進行誤差校正，以提高準確性和穩定性。這包括校準傳感器的誤差、校準步長和步頻的變化、校準方向的漂移等。常見的校準方法包括使用濾波算法、定位校準算法和環境校準算法。
結合其他定位技術：為了提高定位的準確性和穩定性，PDR 可以與其他定位技術結合使用。例如，可以使用地磁定位來校準方向數據，使用 WiFi 定位來校正位置漂移，並使用慣性導航系統來補償傳感器的誤差。

卡爾曼濾波：簡單地説就是可以根據gps糾正傳感器數據推算產生的偏差，並在定位發生漂移時使用傳感器推算出的點以減少漂移對位置產生的影響。

卡爾曼濾波尤其適用於動態系統，這種方法對於內存要求極低而運算速度快，且能夠保持較好的計算精度，這使得這種方法非常適合解決實時問題和應用於嵌入式系統，也就是説，卡爾曼濾波天然的適用於解決艦艇指控系統的航跡推算問題。

優點：內存佔用小、運行快
缺點：要先離線跑出基準值

IMU

包括陀螺儀和加速度計。陀螺儀測量物體三軸的角速率，用於計算載體姿態；加速度計測量物體三軸的線加速度，可用於計算載體速度和位置。

優點：不要求通視，定位範圍為全場景；
缺點：定位精度不高，且誤差隨時間發散。

導致定位漂移直接原因是GPS定位精度差。GPS定位精度由觀測環境決定，難以改善。通過對當前GPS精準度、短期內的歷史點集分佈、IMU慣性傳感器（加速計+陀螺儀）與路網數據分析，排除漂移位置，減少因為定位漂移導致的出發地異常問題。

加速度計

加速度計是慣性導航和慣性制導系統的基本測量元件之一，加速度計本質上是一個振盪系統，安裝於運動載體的內部，可以用來測量載體的運動加速度。

採集數據中重力加速計在手機停放在桌面（左圖）與手握手機步行狀態（右圖）時加速計的情況，可以看出步行狀態下手機加速計的變化是有較明顯的週期性的，其週期與步行狀態可對應上。

** 顏色説明：x\y\z\a分別為紅、綠、藍、黃

陀螺儀

手機裏的陀螺儀芯片內部包括有一塊微型磁性體，能夠在手機進行旋轉運動時發生的科里奧力效果下向X，Y，Z三個方向發生位移，運用這個原理便能夠測出手機的運動方向。

在採集數據中，不僅包含偏航（Yaw）、翻滾（Roll）、俯仰（Pitch）等直接角度指標，同時也包含四元數、旋轉速率等中間指標，甚至包含北向偏角（heading）指標，詳細採集數據可見附件鏈接。但最終發現北向偏角與實際差值在30度左右，且容易受拿取手機的姿勢影響，所以陀螺儀數據最終在方案中僅作為參考方向；

計算位置

由於手機是非固定設備（如反拿、搖晃、揣兜晃動等）導致方向的不確定性，我們採用定位的數據為主，傳感器數據為輔測算最遠距離半徑的形式，推算出他所能運動的最遠距離與算法擬合的新位置，在定位精度低於信任值的情況下判斷距離是否超過最遠距離，判斷是否使用擬合點。

算法落地

整個流程分為數據的離線採集確定用户行為與算法超參的基準值產出初版算法，數據的在線採集與離線訓練，算法的線上部署三個流程。

離線採集

基於上述理論支撐，我們需要對一些標準行為與真實的異常定位場景進行數據採集，分析其中數據轉換關係定義基準值，完成算法的初版，並可通過離線數據還原出用户發單前的定位情況。

定位與IMU數據採集（採用iPhone8設備，定位精度設置為最高）

線上採集

整個採集流程需注意以下幾個問題：

灰度放量：未防止性能與網絡消耗（1條傳感器數據目前2k 可接受，傳感器採集頻率設置為3s消耗很低，可忽略不計）與穩定性要小步放量
對APP啓動流程的影響：為減少對啓動的影響，整個採集開啓定在APP啓動3s後，APP啓動期間會有多條定位數據更新（本地查看為7條），由於前序的定位數據對整個算法的初始值設置非常重要，so決定將啓動期間的定位數據保存到內存中，3s後在補報
按時關閉：原定義的流程為採集到用户發單為止，但由於灰度用户未必為普惠用户且未必有發單訴求，需要額外機制關閉採集，否則會一直採集浪費性能，參考目前平均發單時長進行手動關閉
多線程問題：上鎖（手動狗頭）

綜上，整個採集邏輯如下: