后臺(tái)定位上傳的代碼實(shí)踐.docx

后臺(tái)定位上傳的代碼實(shí)踐前言之前的文章說(shuō)過(guò) 我現(xiàn)在做的是LBS定位的社交APP 其中主要的一個(gè)功能就是能夠?qū)崟r(shí)定位社交圈中各個(gè)成員的位置后臺(tái)實(shí)時(shí)上傳位置則是非常重要的一個(gè)技術(shù)點(diǎn) 接下來(lái)就來(lái)說(shuō)說(shuō)我關(guān)于這方面的實(shí)踐經(jīng)驗(yàn)需求先來(lái)看看實(shí)現(xiàn)這個(gè)功能的具體需求是什么 由于我們是實(shí)時(shí)定位的生活類社交APP 所以我們需要做到一下幾點(diǎn)1. 如果用戶的位置在持續(xù)變化 則隔一段時(shí)間上報(bào)一次由于我們希望能夠?qū)崟r(shí)的將用戶的位置變化反饋在APP里 所以定時(shí)的上報(bào)是剛需2. 如果用戶的移動(dòng)速度很慢 則隔一段距離上報(bào)一次如果用戶是低速率的狀態(tài)(比如步行的移動(dòng)速度大概就是1m/s左右) 這個(gè)時(shí)候如果還按(1)中的方式來(lái)上報(bào)的話 由于變化太小 地圖上的點(diǎn)會(huì)非常的密集 這種數(shù)據(jù)的意義不大(而且如果要做軌跡服務(wù)的話 這些密集點(diǎn)都是必須有花掉的) 所以這時(shí)候我們按照距離間隔來(lái)上報(bào)3. 如果用戶的位置在到達(dá)某處后沒(méi)有變化 則不繼續(xù)上報(bào)我們只關(guān)心位置的變化 如果用戶的位置沒(méi)有變化或者變化很小 其實(shí)是不需要上報(bào)其位置的(比如進(jìn)入的公司 或者等一個(gè)很長(zhǎng)時(shí)間的紅燈) 這時(shí)候我們就不上報(bào)(以達(dá)到省電的目的)4. 切換到后臺(tái)也要能定位上報(bào)后臺(tái)上報(bào)是必須的 用戶不可能一直運(yùn)行著我們的APP (iOS4開(kāi)始就支持了)5. APP因各種原因終止運(yùn)行后(用戶主動(dòng)關(guān)閉, 系統(tǒng)殺掉) 也要能定位上報(bào)用戶主動(dòng)關(guān)閉APP的幾率不大 但是因系統(tǒng)調(diào)度被殺掉的情況是很普遍的 這個(gè)時(shí)候我們也要能夠上報(bào) (iOS7開(kāi)始已支持被殺掉后喚醒)分析完需求 接下來(lái)就開(kāi)始介紹如何實(shí)現(xiàn)準(zhǔn)備首先做一些準(zhǔn)備工作在target的Capabilities選項(xiàng)中打開(kāi)Background Modes并勾選Location updates然后在plist中添加NSLocationAlawaysUsageDescription的鍵 在value中隨便鍵入任何內(nèi)容完成這兩步 我們的前期工作就完成了Background Modes是iOS7帶入的新功能 而NSLocationAlawaysUsageDescription為了增強(qiáng)權(quán)限機(jī)制引入的提示描述 不添加這個(gè)的話 定位功能可是使用不了的代碼定位肯定要跟CLLocationManager打交道 所以我們先定義一個(gè)CLLocationManager的子類 并根據(jù)需求中的幾點(diǎn)定義三個(gè)變量interfaceMMLocationManager:CLLocationManager+(instancetype)sharedManager;property(nonatomic,assign)CGFloatminSpeed;/最小速度property(nonatomic,assign)CGFloatminFilter;/最小范圍property(nonatomic,assign)CGFloatminInteval;/更新間隔end這里解釋一下這幾個(gè)參數(shù)minSpeed如果當(dāng)前運(yùn)動(dòng)速度大于此值 則滿足需求(1) 以時(shí)間為更新依據(jù)(minFilter) 如果當(dāng)前運(yùn)動(dòng)速度小于此值 則滿足需求(2) 以范圍為更新依據(jù)(minInteval) minFilter最小的觸發(fā)范圍 用于需求(1) minInteval更新間隔 用于需求(2) 接下來(lái)是初始化函數(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;這里的默認(rèn)值可以根據(jù)需求來(lái)調(diào)整然后是位置更新后的處理邏輯 其實(shí)也非常的簡(jiǎn)單、-(void)locationManager:(CLLocationManager*)managerdidUpdateLocations:(NSArray*)locationsCLLocation*location=locations0;NSLog(%,location);/根據(jù)實(shí)際情況來(lái)調(diào)整觸發(fā)范圍selfadjustDistanceFilter:location;/上傳數(shù)據(jù)selfuploadLocation:location;而這個(gè)adjustDistanceFilter函數(shù) 就是整個(gè)代碼的核心 會(huì)根據(jù)當(dāng)前速度來(lái)動(dòng)態(tài)的調(diào)整distanceFilter這個(gè)參數(shù) 以滿足我們的需求/*規(guī)則:如果速度小于minSpeedm/s則把觸發(fā)范圍設(shè)定為50m*否則將觸發(fā)范圍設(shè)定為minSpeed*minInteval*此時(shí)若速度變化超過(guò)10%則更新當(dāng)前的觸發(fā)范圍(這里限制是因?yàn)椴荒懿煌５脑O(shè)置distanceFilter,*否則uploadLocation會(huì)不停被觸發(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é)果如下接下來(lái)我們會(huì)討論一下相關(guān)的幾個(gè)問(wèn)題討論為什么不用定時(shí)器來(lái)控制定位間隔網(wǎng)上有很多教程是用NSTimer來(lái)實(shí)現(xiàn)的 但是其實(shí)這樣不是很好 雖然定位的間隔是固定的 但是耗電的問(wèn)題無(wú)法解決 后臺(tái)會(huì)持續(xù)的更新定位 無(wú)論當(dāng)前的位置是否在更新 當(dāng)然 如果你的使用場(chǎng)景就是要每隔一段時(shí)間來(lái)上傳 就可以使用定時(shí)器來(lái)處理使用distanceFilter來(lái)處理 會(huì)有些什么問(wèn)題由于distanceFilter=currentSpeed*minInteval 那么間隔的時(shí)間因?yàn)樗俣鹊淖兓鴷?huì)有波動(dòng) 但是這個(gè)波動(dòng)是在可接受范圍的 如果速度加快或者變慢 那么下一次的更新時(shí)間則會(huì)相應(yīng)的縮短或者變長(zhǎng) 但是因?yàn)槲覀兪窃谡鎸?shí)生活環(huán)境中 速度的變化不可能那么快 所以這個(gè)誤差是可以接受的 另外我們對(duì)distanceFilter針對(duì)速度進(jìn)行矯正 因而總體來(lái)說(shuō) 間隔還是會(huì)保持在我們與其的范圍內(nèi)的為什么不使用allowDeferredLocationUpdatesUntilTraveled:timeout:allowDeferredLocationUpdatesUntilTraveled是iOS6推出的一個(gè)新的API 看名字我們可以知道這個(gè)函數(shù)的作用是延遲位置更新 直到移動(dòng)了xx米或者時(shí)間超過(guò)了xx秒 那么這個(gè)函數(shù)不正好滿足了我們的所有要求么? 可是萬(wàn)萬(wàn)沒(méi)想到 事情并不是這樣的 這個(gè)函數(shù)并不好用接下來(lái)是吐槽時(shí)間 ()為什么說(shuō)這個(gè)函數(shù)不好用呢? 首先 這個(gè)函數(shù)的要求很多 我們來(lái)看看要這個(gè)函數(shù)起作用要滿足哪些條件必須iPhone5以及之后的硬件設(shè)備才支持 desiredAccuracy必須設(shè)置為kCLLocationAccuracyBest或者kCLLocationAccuracyBestForNavigation distanceFilter必須設(shè)置為kCLDistanceFilterNone 只在APP運(yùn)行在后臺(tái)時(shí)生效 前臺(tái)運(yùn)行時(shí)是不會(huì)進(jìn)行延遲處理的 只有系統(tǒng)在低功耗(Low Power State)的時(shí)候才有可能生效 關(guān)于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ù)我簡(jiǎn)單的了解 這個(gè)*Low Power State”只有在黑屏的狀態(tài)下(不只是鎖屏)才有可能觸發(fā) 只要有任何電量屏幕的操作(就連推送也算) 都會(huì)使APP退出這個(gè)狀態(tài) 同時(shí) 如果在充電狀態(tài)下 也是無(wú)法進(jìn)入的我嘗試在真機(jī)和模擬器上使用這個(gè)API 但結(jié)果APP還是以1HZ的頻率在定位(設(shè)置了kCLDistanceFilterNone的原因)雖然locationManager:didFinishDeferredUpdatesWithError:在指定的時(shí)間后成功的回調(diào)了 但是結(jié)果還是沒(méi)有deffer 于是我查了一下 原來(lái)這個(gè)函數(shù)無(wú)法直接進(jìn)行調(diào)試的 因?yàn)?不支持模擬器deferredLocationUpdatesAvailable用于檢測(cè)設(shè)備是否支持 模擬器會(huì)返回NO 不支持真機(jī)調(diào)試 因?yàn)檎{(diào)試時(shí)Xcode會(huì)阻止程序休眠 導(dǎo)致程序無(wú)法進(jìn)入低功耗狀態(tài) 結(jié)論就是這個(gè)東西連調(diào)試都沒(méi)辦法 所以我也