后臺定位上傳的代碼實踐.docx_第1頁
后臺定位上傳的代碼實踐.docx_第2頁
后臺定位上傳的代碼實踐.docx_第3頁
后臺定位上傳的代碼實踐.docx_第4頁
后臺定位上傳的代碼實踐.docx_第5頁
已閱讀5頁,還剩3頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

后臺定位上傳的代碼實踐前言之前的文章說過 我現(xiàn)在做的是LBS定位的社交APP 其中主要的一個功能就是能夠?qū)崟r定位社交圈中各個成員的位置后臺實時上傳位置則是非常重要的一個技術點 接下來就來說說我關于這方面的實踐經(jīng)驗需求先來看看實現(xiàn)這個功能的具體需求是什么 由于我們是實時定位的生活類社交APP 所以我們需要做到一下幾點1. 如果用戶的位置在持續(xù)變化 則隔一段時間上報一次由于我們希望能夠?qū)崟r的將用戶的位置變化反饋在APP里 所以定時的上報是剛需2. 如果用戶的移動速度很慢 則隔一段距離上報一次如果用戶是低速率的狀態(tài)(比如步行的移動速度大概就是1m/s左右) 這個時候如果還按(1)中的方式來上報的話 由于變化太小 地圖上的點會非常的密集 這種數(shù)據(jù)的意義不大(而且如果要做軌跡服務的話 這些密集點都是必須有花掉的) 所以這時候我們按照距離間隔來上報3. 如果用戶的位置在到達某處后沒有變化 則不繼續(xù)上報我們只關心位置的變化 如果用戶的位置沒有變化或者變化很小 其實是不需要上報其位置的(比如進入的公司 或者等一個很長時間的紅燈) 這時候我們就不上報(以達到省電的目的)4. 切換到后臺也要能定位上報后臺上報是必須的 用戶不可能一直運行著我們的APP (iOS4開始就支持了)5. APP因各種原因終止運行后(用戶主動關閉, 系統(tǒng)殺掉) 也要能定位上報用戶主動關閉APP的幾率不大 但是因系統(tǒng)調(diào)度被殺掉的情況是很普遍的 這個時候我們也要能夠上報 (iOS7開始已支持被殺掉后喚醒)分析完需求 接下來就開始介紹如何實現(xiàn)準備首先做一些準備工作在target的Capabilities選項中打開Background Modes并勾選Location updates然后在plist中添加NSLocationAlawaysUsageDescription的鍵 在value中隨便鍵入任何內(nèi)容完成這兩步 我們的前期工作就完成了Background Modes是iOS7帶入的新功能 而NSLocationAlawaysUsageDescription為了增強權(quán)限機制引入的提示描述 不添加這個的話 定位功能可是使用不了的代碼定位肯定要跟CLLocationManager打交道 所以我們先定義一個CLLocationManager的子類 并根據(jù)需求中的幾點定義三個變量interfaceMMLocationManager:CLLocationManager+(instancetype)sharedManager;property(nonatomic,assign)CGFloatminSpeed;/最小速度property(nonatomic,assign)CGFloatminFilter;/最小范圍property(nonatomic,assign)CGFloatminInteval;/更新間隔end這里解釋一下這幾個參數(shù)minSpeed如果當前運動速度大于此值 則滿足需求(1) 以時間為更新依據(jù)(minFilter) 如果當前運動速度小于此值 則滿足需求(2) 以范圍為更新依據(jù)(minInteval) minFilter最小的觸發(fā)范圍 用于需求(1) minInteval更新間隔 用于需求(2) 接下來是初始化函數(shù)-(instancetype)initself=superinit;if(self)self.minSpeed=3;self.minFilter=50;self.minInteval=10;self.delegate=self;self.distanceFilter=self.minFilter;self.desiredAccuracy=kCLLocationAccuracyBest;returnself;這里的默認值可以根據(jù)需求來調(diào)整然后是位置更新后的處理邏輯 其實也非常的簡單、-(void)locationManager:(CLLocationManager*)managerdidUpdateLocations:(NSArray*)locationsCLLocation*location=locations0;NSLog(%,location);/根據(jù)實際情況來調(diào)整觸發(fā)范圍selfadjustDistanceFilter:location;/上傳數(shù)據(jù)selfuploadLocation:location;而這個adjustDistanceFilter函數(shù) 就是整個代碼的核心 會根據(jù)當前速度來動態(tài)的調(diào)整distanceFilter這個參數(shù) 以滿足我們的需求/*規(guī)則:如果速度小于minSpeedm/s則把觸發(fā)范圍設定為50m*否則將觸發(fā)范圍設定為minSpeed*minInteval*此時若速度變化超過10%則更新當前的觸發(fā)范圍(這里限制是因為不能不停的設置distanceFilter,*否則uploadLocation會不停被觸發(fā))*/-(void)adjustDistanceFilter:(CLLocation*)location/NSLog(adjust:%f,location.speed);if(location.speed0.1f)self.distanceFilter=self.minFilter;elseCGFloatlastSpeed=self.distanceFilter/self.minInteval;if(fabs(lastSpeed-location.speed)/lastSpeed0.1f)|(lastSpeedLocation-Freeway Drive) 結(jié)果如下接下來我們會討論一下相關的幾個問題討論為什么不用定時器來控制定位間隔網(wǎng)上有很多教程是用NSTimer來實現(xiàn)的 但是其實這樣不是很好 雖然定位的間隔是固定的 但是耗電的問題無法解決 后臺會持續(xù)的更新定位 無論當前的位置是否在更新 當然 如果你的使用場景就是要每隔一段時間來上傳 就可以使用定時器來處理使用distanceFilter來處理 會有些什么問題由于distanceFilter=currentSpeed*minInteval 那么間隔的時間因為速度的變化而會有波動 但是這個波動是在可接受范圍的 如果速度加快或者變慢 那么下一次的更新時間則會相應的縮短或者變長 但是因為我們是在真實生活環(huán)境中 速度的變化不可能那么快 所以這個誤差是可以接受的 另外我們對distanceFilter針對速度進行矯正 因而總體來說 間隔還是會保持在我們與其的范圍內(nèi)的為什么不使用allowDeferredLocationUpdatesUntilTraveled:timeout:allowDeferredLocationUpdatesUntilTraveled是iOS6推出的一個新的API 看名字我們可以知道這個函數(shù)的作用是延遲位置更新 直到移動了xx米或者時間超過了xx秒 那么這個函數(shù)不正好滿足了我們的所有要求么? 可是萬萬沒想到 事情并不是這樣的 這個函數(shù)并不好用接下來是吐槽時間 ()為什么說這個函數(shù)不好用呢? 首先 這個函數(shù)的要求很多 我們來看看要這個函數(shù)起作用要滿足哪些條件必須iPhone5以及之后的硬件設備才支持 desiredAccuracy必須設置為kCLLocationAccuracyBest或者kCLLocationAccuracyBestForNavigation distanceFilter必須設置為kCLDistanceFilterNone 只在APP運行在后臺時生效 前臺運行時是不會進行延遲處理的 只有系統(tǒng)在低功耗(Low Power State)的時候才有可能生效 關于Low Power State在iOS中的描述 我只在蘋果官網(wǎng)的文檔中找到部分定義iOS is very good at getting a device into a low power state when its not being used. At idle, very little power is drawn and energy impact is low. When tasks are actively occurring, system resources are being used and those resources require energy. However, sporadic tasks can cause the device to enter an intermediate stateneither idle nor activewhen the device isnt doing anything. There may not be enough time during these intermediate states for the device to reach absolute idle before the next task executes. When this occurs, energy is wasted and the users battery drains faster.據(jù)我簡單的了解 這個*Low Power State”只有在黑屏的狀態(tài)下(不只是鎖屏)才有可能觸發(fā) 只要有任何電量屏幕的操作(就連推送也算) 都會使APP退出這個狀態(tài) 同時 如果在充電狀態(tài)下 也是無法進入的我嘗試在真機和模擬器上使用這個API 但結(jié)果APP還是以1HZ的頻率在定位(設置了kCLDistanceFilterNone的原因)雖然locationManager:didFinishDeferredUpdatesWithError:在指定的時間后成功的回調(diào)了 但是結(jié)果還是沒有deffer 于是我查了一下 原來這個函數(shù)無法直接進行調(diào)試的 因為:不支持模擬器deferredLocationUpdatesAvailable用于檢測設備是否支持 模擬器會返回NO 不支持真機調(diào)試 因為調(diào)試時Xcode會阻止程序休眠 導致程序無法進入低功耗狀態(tài) 結(jié)論就是這個東西連調(diào)試都沒辦法 所以我也

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論