關於iOS後台問題（ 一 ）(ios後台重新整理，後台定位，後台下載，真後台）

標籤：android   style   blog   http   color   io   os   使用   ar   

關於iOS的後台，以下引用一些文段進行一下腦補，請同學們大致看一下，有個基礎，原文出處

-----------------------------------------------------------------------------------------------

OS 7中，實際上APP擁有四種後台模式，無論是哪一種後台機制，均需要利用蘋果給予的相應後台介面實現。IOS7系統中，開發人員可以靈活利用多種後台介面（API）實現更加智能的應用操作。
一，無後台僅推送
第一種後台方式為傳統的無後台操作，僅有蘋果推送機制，這種方式出現在iOS 3.x以下的大部分系統版本上。這個方式下，應用在按下Home鍵後即會關閉退出，其資料通過蘋果搭建的推送伺服器傳輸，並不需要應用後台運行。這種方式 不太好的原因在於，每次推出後，重新進入均需要重新載入，雖然推送能夠統一解決資料和資訊的傳輸，但遇到需要頻繁進入應用（如聊天APP）的時候便會顯得 體驗不好。
二，墓碑式
第二種方式為墓碑式的後台機制，這在iOS 4後被大量採用，也就是人們所說的偽多任務。這方式相比較第一種改進的地方在於，按下Home鍵至主介面後，應用隨即進入後台，但其被凍結，並不能進行任何操作。
三，智能調度後台
第三種為系統智能調度的後台，iOS 7新增的background fetch，這個後台介面在蘋果WWDC 2013上有提及，其會根據使用者行為自動調整達到效率最優的後台模式，能夠處理不是很有時效性的資訊擷取。例如一些社交、新聞類的應用的後台資訊更 新，iOS系統便會根據應用啟動頻率、時間和當前網路和電量的狀況來智能分配每個應用的後台擷取頻率和啟動時間長度。
由於擁有該介面的應用的資料後台重新整理操作是統一調度的，因此系統可以在一個進程裡面獲得多個應用的資料，類似統一的推送機制，這樣就能夠最大限度地省電。 不過這個方式也有一個缺點，那便是開發人員不能設定資料具體什麼時候更新，因此這個後台方式只能應用在一些時效性和敏感度不高的地方。
四，真後台
 第四種方式便是真後台機制，但iOS的真後台與Android的後台機制是不一樣的，為了兼顧系統體驗和統一進程管理，iOS在這上面加入了眾多的限制。大致擁有以下幾個後台介面模式：
1、Background Audio，這是背景音頻，這個很早之前便有，也是iOS裝置中用得最多的後台應用，調用這個介面可以實現背景音樂播放。
2、Location Services，這是背景定位，系統會擁有統一頁面進行管理。
3、VoIP，後台Voice Messaging Service，類似Skype通話應用需要調用，可進行背景語音通話。
4、Newsstand，報刊雜誌後台自動下載更新，其能夠自動即時更新。
5、Background Task  Completion，這個介面早在iOS 4時候便擁有，其可以供任意類型的APP使用，不過在舊系統中，這個介面的後台限制已耗用時間僅為10分鐘，意味著當應用退至後台，其後台運行僅能持續10 分鐘便會轉至休眠狀態。iOS 7中對這個介面作出了改變，原來的為連續10分鐘，即不論你這10分鐘內使用者是否關閉螢幕進入休眠狀態，應用仍然會在後台等待10分鐘完結後推出，而新的 改進為假如遇到關閉螢幕休眠的情況，這後台啟動並執行10分鐘便會跟隨一同休眠，剩餘的後台時間將會留待使用者再一次喚醒裝置才計算。這樣後台啟動並執行時間仍然為 10分鐘，但並不連續，這樣做的優點為省電。
如現在有一些詞典應用帶有後台複製選詞功能，實際上其是利用了這個介面，如果使用者開啟詞典後並推出，即使螢幕關閉，但詞典仍然在後台運行，電量消耗還是比較大的，在iOS 7上，這個問題可以得到解決。
6、 Remote Notification，這是本次較大的一個改進介面，以往聊天類應用接受推送後點進去需要再收一次資訊，這情況在QQ、等應用上最為明顯。不過擁有了這個介面後，這情況將不複存在，以後推送將能夠直接啟動背景工作。值得注意的是remote notification支援silent notification（靜默推送），這樣dropbox這類同步應用可以在後台以最節能的模式即時靜默同步了，類似布卡漫畫這種也可以推送正在追的漫 畫的新章節並在後台靜默下載，待到下載好再給使用者發送一個本地推送，使用者點開即看無需再連網
7、Background Transfer Service，後台上傳下載。iOS最接近傳統多任務的後台介面，可供任意類型的app調用，無時間限制。應用情境包括後台上傳和下載資料，這使得遊戲後台更新資料包，後台上傳視頻等等都成為可能，但是正如其名字，它只能用於處理上傳下載這種傳輸類的任務，類似後台剪下板監控這種它就無能為力了。

 

 

--------------------------------------------------------------------------------------------------------------------------------

以下介紹一下實際操作

首先我們在工程中選擇Gapability,找到back ground mode，

我們拿location updates重新整理來舉例

當我們初始化CLLocationmanager之後，需要額外添加這樣一句代碼

self.manger.pausesLocationUpdatesAutomatically = NO; //該模式是抵抗ios在後台殺死程式設定，iOS會根據當前手機使用狀況會自動關閉某些應用程式的後台重新整理，該語句申明不能夠被暫停，但是不一定iOS系統在效能不佳的情況下強制結束應用重新整理

 

經過測試，CLLocationmanager協議方法能在後台一直被調用，此時App是比較耗電的，如果後台擁有其他處理和運算的需求，最好將位置更新觸發的操作進行多執行緒，最好是多線程排隊處理。還有一種方法就是在AppDelegate中的生命週期函數裡，在即將進入背景時候將CLLocationmanager的閥值降低，比方說原來監測的米層級，可以降低成千米層級

 

在 applicationDidEnterBackground 中加入

 

if ([CLLocationManager significantLocationChangeMonitoringAvailable])         {                    [[mapCenter manager] stopUpdatingLocation];            [[mapCenter manage ] startMonitoringSignificantLocationChanges];        }        else         {            NSLog(@"Significant location change monitoring is not available.");        }

 

 

在applicationDidBecomeActive 中加入 

     if ([CLLocationManager significantLocationChangeMonitoringAvailable])     {[[mapCenter manager] stopMonitoringSignificantLocationChanges];[[mapCenter manager] startUpdatingLocation];}else     {NSLog(@"Significant location change monitoring is not available.");}

 

 

關於iOS後台問題（ 一 ）(ios後台重新整理，後台定位，後台下載，真後台）