總結關於iOS室內定位開發踩過的一些坑。。。

直接正題，沒得BB

首先說明一下室內定位從架構上嚴格來說分爲3步：

一、室內地圖以及室內地圖能相關的一些成熟API

二、以任意方式來獲取室內定位的座標

三、將室內定位的座標轉化成室內地圖的API或者一種能兼容二者的轉換方式

（可選）四、定位穩定性的濾波處理，試定位座標點不出現 跳點、卡頓、掉幀、北偏角指向性錯誤等影響用戶體驗的處理方案

 

目前市場中室內定位資源比較散亂，主要分爲地圖供應商和定位服務商兩種，也有將室內定位資源合併的企業，好比 某石科技

因此要是想對室內定位有研究的最好仍是須要多方瞭解提供商的SDK相關信息

最近咱們公司的室內定位項目立刻殺青了，纔有空寫個博客散散心，總結一下iOS開發中踩過的坑：

一、手機端地圖出現黑色無色模型，Web端出現透明模型。

二、路徑導航沒法規劃路線。

三、沒法繪製路徑/SDK的相關方法/對象不執行。

四、地圖對象建立後未銷燬，形成第二次地圖對象在規劃路徑的時候閃退、崩潰。

五、地圖圖標出現黑塊。

六、返回上一級界面後未執行dealloc方法。

七、路徑繞遠。

八、U型彎道或L型彎道在路網吸附的模式下路過會出現跳點。

九、地圖加載失敗。

十、地圖的繪製/解析慢。

========================分割線=========================

個人解決方案：

一、手機端地圖出現黑色無色模型，Web端出現透明模型。

緣由：這個是由於主題不兼容形成的，地圖在SDK解析過程當中根據資源包已經賦予其顏色屬性了，若是沒有相關資源包就默認爲黑色

我使用的是蜂鳥視圖，咱們地圖屬性和顯示是通過定製的，因此使用常規的主題就會形成黑塊模型的出現。

WEB端JS的SDK作過相關處理，因此展現只是透明的模型。

解決：與其相關開發人員溝通，從新更新一個定製的主題便可。

二、路徑導航沒法規劃路線。

緣由：由於沒有相關路網能抵達終點，路網的結構大體是這樣的：

黑色區域是可到達的路網，紅色是禁止掉的路網。明白了吧，若是終點的附近沒有黑色路網，那麼就表明這個點位是沒法到達的

具體附近是多少，請注意供應商的API文檔說明

解決：要和相關地圖供應商聯合解決這個問題，由於具體有那些點位可達/不可達，最好去實地勘探一下。

三、沒法繪製路徑/SDK的相關方法/對象不執行。

緣由：請覈對和官方的工程配置的作法是否有出入的地方，我出現這個緣由是由於Other Linker Flags 中有個-ObjC錯寫成-Objc了，

C必須是大寫，要麼XCode編譯器不會全編譯框架中的OC文件，編譯確實無錯，可是一旦調用相關API的時候，這個API會引發崩潰等風險。

解決：Other Linker Flags 中添加-ObjC，大小寫要分清

四、地圖對象建立後未銷燬，形成第二次地圖對象在規劃路徑的時候閃退、崩潰。

緣由：上一個地圖對象成爲了殭屍對象，在執行規劃路線/或者其餘操做的時候同時操做了殭屍對象，這個在崩潰的時候會有日誌：

「你操做了一個不可操做的對象/指針」

解決：無論怎麼使用地圖視圖對象，必定要在這個VC地圖界面推出棧的時候（我用的push方法）查看是否執行dealloc方法，

若是沒有，最好在點擊退出的一瞬間將所有View remove掉，包括地圖視圖和相關View對象，而後指針置空，必定保證執行了dealloc。

保證程序穩定的狀況下才能作更多事。

五、地圖圖標出現黑塊。

緣由：這個提及來很尷尬=。=  由於需求中有一個模擬導航，須要模擬這個定位點一點點移動在線路上，而且行走等事件。

是吧、、確定用到了NSTimer啊。。。因此這個緣由是由於在另外一種我沒想到的邏輯下退出界面，致使Timer沒被銷燬和暫停。

而後呢，地圖又是OpenGL繪製的。。在下一次進入地圖界面的時候，Timer佔用了一個子線程，致使OpenGL一直沒時間去繪製圖標

致使地圖一些元素顯示成了黑塊。。

解決：必定要統計有幾種退出界面的方法，而後封裝一個安全的方法（就是在不釋放空對象的前提下能kill掉Timer），

在每種狀況下退出界面都要執行這個能安全的kill掉Timer的方法，最後必定要監督dealloc方法的執行與否。

六、返回上一級界面後未執行dealloc方法。

緣由：以前也提過不少了，主要是SDK中一些對象與主控制器的強引用形成的，這種很常見，要養成隨時查看dealloc的習慣。

有些人會想了：如今不都ARC了麼？誰還會關心這些啊？

這樣想很不對，ARC能夠爲開發者節省不少代碼，使用ARC之後不再須要關心何時retain，何時release，

可是這並不意味你能夠不思考內存管理，你可能須要常常性地問本身這個問題：誰持有這個對象？

解決：注意哪些是Strong引用的對象再被操做，何時把他置nil，保證能下降一個內存開銷，性能上也是有很大的提高。

七、路徑繞遠。

緣由：由於路網稀疏，致使想到達一個終點必須按照路網的規劃來走，有興趣的能夠研究一下dijstra算法，

這個是大部分主流地圖/導航的一個解決方案。

路網稀疏，只能這麼走：

路網緣由繞的遠，不怪你不怪SDK，只怪地圖路網沒設計好。

解決：固然是與供應商溝通咯=。=。。程序又作不了什麼。。。。

八、U型彎道或L型彎道在路網吸附的模式下路過會出現跳點。

緣由：由於路徑吸附的原理是判斷你的定位點在路徑周邊大概多少米以內，將點位強制吸附到路徑上

遇到U型彎道/L型彎道就會出現兩個斷定，，說白了就是兩條路吸附範圍發生重疊形成的斷定混亂。。懂了吧 =。=

解決：仍是溝通咯。。只能讓他們把路網規劃的更密一些，減小U型彎道的產生，至於L型麼。。。小跳而已

誰也不會全程盯着手機看吧。。室內導航。。擡擡頭就能知道該咋走了，，我就跳跳 =。=

九、地圖加載失敗。以及 十、地圖的繪製/解析慢。

緣由：由於整個地圖文件是通過混淆的，並且解析引擎是C++（蜂鳥視圖），解析完後再OpenGL繪製。。

聽着都繁瑣=。=。。固然慢了。。並且整個SDK流程是必須先通過認證後才能得到解析權限。。固然慢咯。。

解決：沒辦法。。可是能夠把解析和UI操做分開來作：

咱們但願多個任務同時（在多個線程裏）執行，再他們都完成以後，再執行其餘的任務，

因而能夠創建一個分組，讓多個任務造成一個組，下面的代碼在組中多個任務都執行完畢以後再執行後續的任務：

先解析地圖，而後頁面隨便展現一個 HUB或者Toast或者小菊花等等。。表示咱們正在瘋狂的畫地圖。。。

而後設置兩個回調，一個地圖成功和失敗：

這個BOOL是在地圖解析完後，準備執行下一個操做的時候的限制判斷

若是解析成功則執行UI的建立和添加等等。。。若是失敗則顯示一個加載失敗的圖片。

注意，最後我是將全部操做所有回調到了主線程來執行的。。

這樣就能夠不卡死主線程的狀況下先推出界面，同時進行解析、解析完成後再將地圖添加到視圖，失敗了就展現失敗的頁面就好。

若是把解析（就是地圖的構造方法）放在ViewDidLoad中，會卡死主線程1~8秒不等。。。這樣確定行不通的，比較平滑的處理先暫時只能這樣。。

養成註釋的習慣最好=。=  維護和二次開發的時候會很方便 =。= 

 

曬一張個人一個主繼承對象的h文件=。=

被人吐槽成把項目當SDK作。。

最後=。=  Axc大法好。。。。