1.默認創建的工程，Application does not run in background默認爲NO(疑), 此時的application.backgroundTimeRemaining是10，其實是9.9.然後APP在PAD上面進入後臺後會掛起，然後從後臺切換到前臺後APP會重新激活。**********問題，既然是backgroundTimeRemaining是10，爲什麼在後臺沒有運行？要切換到前臺才運行？是不是因爲沒有添加後臺的處理代碼？
2.**info.plist裏面添加Application does not run in background字段，此時的默認值NO，此時的application.backgroundTimeRemaining還是10，現象還是和上面的一樣，進入後臺會掛起，從後臺切換到前臺會重新激活。
3.如果Application does not run in background設置爲YES，打印application.backgroundTimeRemaining還是10, 但是一切入後臺，XCODE調試的工程會馬上停止。
4.如果保持Application does not run in background字段的值爲NO，在添加UIBackgroundModes字段，是一個數組，在下面的一項string值裏面填入audio, location, voip, App processes Newsstand Kit downloads, App communicates with an accessory,CoreBluetooth任意一個。比如選audio,會自動轉換成對應的值App plays audio，如果填入location，會自動更正爲App registers for location updates，或者直接在右側的選擇框裏面進行選擇，這時候如果程序沒有做這方面的處理，還是不會後臺執行。我們再修改一下，填入voip，此時會自動更正爲App provides Voice over IP services，此時還是不會後臺執行。說明如果不在applicationDidEnterBackground加入__block UIBackgroundTaskIdentifier bgTask = [application beginBackgroundTaskWithExpirationHandler:，他是不會後臺執行的。
5.結合上面的分析，繼續保持Application does not run in background字段的值爲NO，同時在UIBackgroundModes字段中添加audio，location，voip，或者選擇App processes Newsstand Kit downloads，App communicates with an accessory，App communicates using CoreBluetooth，App shares data using CoreBluetooth，總共7個，都可以開始後臺執行，大概在594秒（即9.9分鐘）的時候停止，與加不加相應的調用代碼無關，空工程即可。
6.如果上面的代碼結合使用[[UIApplicationsharedApplication] setKeepAliveTimeout:600 handler:^{ [selfbackgroundHandler]; }];
BOOL backgroundAccepted = [[UIApplication sharedApplication] setKeepAliveTimeout:600 handler:^(void){
[self backgroundHandler];//如果此時不再調用beginBackgroundTaskWithExpirationHandler，則只有10秒鐘的後臺執行時間了。
}];
if (backgroundAccepted) {
NSLog(@"------------------------------Start new alive.");
}
[self backgroundHandler];
即在applicationDidEnterBackground加入上述代碼，如果此時UIBackgroundModes不是voip，Xcode控制檯會提示“Only VoIP apps can set KeepAliveTimeout”，會在9.9分鐘即594秒的時候停止，掛起5秒鐘左右的時間後，setKeepAliveTimeout起作用，繼續執行。如果將此類功能應用在企業級APP上面，就可以實現在後臺一直執行的APP。
打從這世界出現了操作系統以來，就沒有過所謂真正的“多任務”。所謂多任務，無非是CPU速度夠快而足以支撐極短時間內在多個進程內動作罷了。而所謂的“單任務”，無非是隻能讓當前任務獨享資源罷了。
簡單來說，iOS 4
app類型可以分爲三種：
1. 保存現場。按下Home鍵10秒內直接殺死進程，並釋放內存。
2. iOS支持的“多任務”。按下Home鍵轉入多任務狀態，保留在內存中，但只能系統允許的動作：比如GPS，比如VoIP，比如Streaming
Music等等。
3. 真正的桌面級別的多任務。只有Safari/Mail是，蘋果嫡系大都都不是。這個級別的app在後臺沒有任何限制動作。
無限制動作的程序，一會在用戶無察覺的情況下耗光電力，二會有安全上面的問題(君還記得那些個在後臺依舊默默發送你的個人消息程序嗎？)
順便提一句，後兩種佔用內存的app，也會在任意時間從內存中被砍掉，取決於你是否動用了其它app而導致內存不足。
真正不會被砍掉的後臺，只有蘋果那個通知系統。
其實可以回顧一下iOS是怎麼一步步引入現在這個機制的。
剛出生，什麼都沒有，單純的單任務。
iPhone OS 3.0，引入通知架構，當年全部機型可用；Android晚了一年，2.2纔有此功能，到這個時候相信纔有90%上下機器用上。
iOS 4.0，引入有限制的後臺多任務。
搞這麼複雜幹嘛？直接像Android一出生那樣所有app一個小虛擬機，無任何限制動作，讓根本沒有內存管理經驗和資源消耗概念的全世界最大民工羣Java程序員們寫的app任意地跑着吧！
答案只有兩個：電力，安全。安全不說，如何在保持多任務優勢的同時，避免消耗過多電力，蘋果花了很多心思；而不是像webOS/Android一樣，簡單粗暴桌面級的多任務。iPhone
4甚至在硬件上面也下了苦功，利用3D層疊技術組裝A4芯片，內部元件高度集成，並把天線移至體表，增加內部電池空間。結果就是iPhone 4 1420 vs. i9000 1500。
其實至iPhone OS 3，已經足夠應付大部分應用了。用戶根本無從知道app的實際運行狀態，保存現場讓app看起來不像是剛打開一樣，通知系統又可以在後臺默默推送消息。事實上，當前95% iOS app依舊只有保存現場 + 通知系統這樣的組合，比如很多twitter客戶端，大部分人根本不會注意到它不是真正意義上的“多任務”。很震撼的事實，但確實95%的應用場景根本不需要所謂真正的“多任務”。
但是時代在變。真正需要多任務的東西出現了：電臺要stream，IM要stream，GPS要stream，多任務必須提上日程。iOS 4加進了，WP7剛剛加進了，Android/webOS打一出生就有。從本質來說，iOS/WP7/Android/webOS跑在內存中的後臺程序，唯一的區別就是，iOS/WP7限制了它可以做的事(這就是爲什麼它們一出生都沒有多任務的原因，這個架構很複雜，不是幾百行中文字可以說明白的)，而Android/webOS沒有；從技術上面來說，iOS/WP7/webOS三者架構相當，Android獨立門戶。
於是很可笑，有無限制，成了真“多任務”和僞“多任務”的區別；而後者架構更復雜，可以套用一句“吃力不討好”。
爲什麼要做吃力不討好的事？答案依舊在上面，電力和安全。當然你可以說iPhone電力也沒好到哪裏去，安全也就一般般嘛。暫且拋掉這兩樣不談，實際看看iOS有限制後臺app，和Android完全無限制後臺app有什麼不同：
相信我，最終你會發現iOS上最令人詬病的app，是那些不支持標準協議的軟件平臺商們，比如騰訊。因爲iOS後臺允許的動作，已經覆蓋了全部大大小小的通信開源協議。
隨便提提騰訊的QQ協議：
大家都用過很多msn/gtalk客戶端，但是可能很多人都沒有用過非騰訊QQ客戶端(曾經有過，但是騰訊把他送進了監獄)。騰訊在QQ協議上面所做的事，一是不開放，二是隔兩三個月就換一次協議，三是封殺全部三方客戶端。
那麼最終多任務的對比無非是，擁抱標準 vs. 允許私有。蘋果作爲一個弱勢廠商，一直以來受夠了私有標準的苦。比如一直到現在都沒法用非IE支付的中國網銀們，正是微軟自己私有標準的後果，也是蘋果爲什麼要開做開源WebKit的原因。軟件可以封閉，硬件可以封閉，但是要擁抱標準，這是蘋果的理念。
結論很簡單：如果你要用一些私有協議的app(在中國我想大部分人都要用QQ的)，請別看別買別關注iPhone；如果你用的都是一些擁抱標準的app，那麼推薦你使用iPhone，因爲它更省電更安全。關於說iOS多任務有什麼用：除了不能支持私有協議外，和Android一樣
轉載自：http://blog.csdn.net/samuelltk/article/details/38517139