ios網路請求發生在哪個線程

㈠ 在iOS開發為什麼使用多線程 多線程有哪些

1、概念性知識：iOS開發中有主線程（也可叫UI）線程和子線程（你自己通過方法開辟的線程）的概念，子線程和主線程的合稱可以稱為多線程。
2、為什麼用多線程開發：正常一個簡單的軟體，如果沒有比較消耗性能設時間的操作是無需開辟子線程的，我們去一條線程（主線程）上去添加UI、載入數據、刷新，很快，因為載入的數據其實是很小的。但是如果有了諸如圖片下載，視頻下載等需要花費比較多時間的操作就必須開辟子線程了，圖片、視頻比較大，下載浪費時間，如果主線程下載，那麼整個APP的界面就不動了，因為線程正在忙著下載呢，沒時間去刷新UI、響應用戶任務（如點擊手勢等）和載入數據給用戶看，APP在辛苦的下載工作，但是用戶一看，這軟體不動了，以為卡死了，就關了或者卸載了，這樣的體驗不是我們想要的，所以開辟子線程相當於喊來一個朋友，讓他去下載，你可以繼續做刷新UI、響應用戶任務（如點擊手勢等）和載入數據給用戶看等事情，互不影響，效率提高了，代價是多消耗了寫CPU。
3、常規使用多線程有哪些：NSThread ， NSOperation（NSOperationQueue） ， GCD主要3種，後兩種使用較多。蘋果推薦使用NSOperation，因為它是面向對象的，和oc一樣，換可以控制線程的開始，暫停，取消。GCD這樣是C語言函數，函數略生澀，使用很方便，可以實現延時，單次，調度組執行，具體實現網上有很多帖子。

㈡ ioshttp請求有必要在子線程嗎

會堵塞吧，比如說網路這會不好，你在主線程里做了同步的http的請求，在返回結果之前，你的主線程就會一直卡在這里，不響應用戶的任何操作請求。所以一般都是掛個非同步操作或者開個線程去進行http請求

㈢ iOS 網路請求有哪些方式

兩種請求方式GET,POST
兩種請求方式的比較
相同點:都能給伺服器傳輸數據

不同點:
1、給伺服器傳輸數據的方式:
GET:通過網址字元串。POST:通過data
2、傳輸數據的大小:GET:⽹址字元串最多255位元組。POST:使用NSData,容量超過1G
3、安全性:GET:所有傳輸給伺服器的數據,顯示在網址里,類似於密碼的明文輸入,直接可見。
POST:數據被轉成NSData(二進制數據),類似於密碼的密文輸⼊入,⽆無法直接讀取。
連接方式

同步:使用一個線程(主線程)完成所有的工作,效率低,當線程正在執行一個任務的時候無法執行另一個任務,所有如果使用同步進行網路數據的請求,那麼在該線程進行網路請求時,暫時無法響應用戶的點擊事件,用戶體驗極差
非同步:再開一個線程(子線程)去完成任務,此時,主線程依然可以監聽用戶的點擊事件,不會造成卡頓,用戶體驗較好

㈣ iOS中載入網路數據一定要開子線程嗎

不一定啊，想開就開，現在很多網路默認都是多線程

㈤ ios 開發 兩個線程怎麼通訊

先來看看官方的文檔，是這樣寫的： In a multithreaded application, notifications are always delivered in the thread in which the notification was posted, which may not be the same thread in which an observer registered itself. 翻譯過來是： 在多線程應用中，Notification在哪個線程中post，就在哪個線程中被轉發，而不一定是在注冊觀察者的那個線程中。 也就是說，Notification的發送與接收處理都是在同一個線程中。為了說明這一點，我們先來看一個示例： 代碼清單1：Notification的發送與處理 @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; NSLog(@"current thread = %@", [NSThread currentThread]); [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil]; dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ [[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil userInfo:nil]; }); } - (void)handleNotification:(NSNotification *)notification { NSLog(@"current thread = %@", [NSThread currentThread]); NSLog(@"test notification"); } @end 其輸出結果如下： 2015-03-11 22:05:12.856 test[865:45102] current thread = {number = 1, name = main} 2015-03-11 22:05:12.857 test[865:45174] current thread = {number = 2, name = (null)} 2015-03-11 22:05:12.857 test[865:45174] test notification 可以看到，雖然我們在主線程中注冊了通知的觀察者，但在全局隊列中post的Notification，並不是在主線程處理的。所以，這時候就需要注意，如果我們想在回調中處理與UI相關的操作，需要確保是在主線程中執行回調。 這時，就有一個問題了，如果我們的Notification是在二級線程中post的，如何能在主線程中對這個Notification進行處理呢?或者換個提法，如果我們希望一個Notification的post線程與轉發線程不是同一個線程，應該怎麼辦呢?我們看看官方文檔是怎麼說的： For example, if an object running in a background thread is listening for notifications from the user interface, such as a window closing, you would like to receive the notifications in the background thread instead of the main thread. In these cases, you must capture the notifications as they are delivered on the default thread and redirect them to the appropriate thread. 這里講到了“重定向”，就是我們在Notification所在的默認線程中捕獲這些分發的通知，然後將其重定向到指定的線程中。 一種重定向的實現思路是自定義一個通知隊列(注意，不是NSNotificationQueue對象，而是一個數組)，讓這個隊列去維護那些我們需要重定向的Notification。我們仍然是像平常一樣去注冊一個通知的觀察者，當Notification來了時，先看看post這個Notification的線程是不是我們所期望的線程，如果不是，則將這個Notification存儲到我們的隊列中，並發送一個信號(signal)到期望的線程中，來告訴這個線程需要處理一個Notification。指定的線程在收到信號後，將Notification從隊列中移除，並進行處理。 官方文檔已經給出了示例代碼，在此借用一下，以測試實際結果： 代碼清單2：在不同線程中post和轉發一個Notification @interface ViewController () @property (nonatomic) NSMutableArray *notifications; // 通知隊列 @property (nonatomic) NSThread *notificationThread; // 期望線程 @property (nonatomic) NSLock *notificationLock; // 用於對通知隊列加鎖的鎖對象，避免線程沖突 @property (nonatomic) NSMachPort *notificationPort; // 用於向期望線程發送信號的通信埠 @end @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; NSLog(@"current thread = %@", [NSThread currentThread]); // 初始化 self.notifications = [[NSMutableArray alloc] init]; self.notificationLock = [[NSLock alloc] init]; self.notificationThread = [NSThread currentThread]; self.notificationPort = [[NSMachPort alloc] init]; self.notificationPort.delegate = self; // 往當前線程的run loop添加埠源 // 當Mach消息到達而接收線程的run loop沒有運行時，則內核會保存這條消息，直到下一次進入run loop [[NSRunLoop currentRunLoop] addPort:self.notificationPort forMode:(__bridge NSString *)kCFRunLoopCommonModes]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(processNotification:) name:@"TestNotification" object:nil]; dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ [[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil userInfo:nil]; }); } - (void)handleMachMessage:(void *)msg { [self.notificationLock lock]; while ([self.notifications count]) { NSNotification *notification = [self.notifications objectAtIndex:0]; [self.notifications removeObjectAtIndex:0]; [self.notificationLock unlock]; [self processNotification:notification]; [self.notificationLock lock]; }; [self.notificationLock unlock]; } - (void)processNotification:(NSNotification *)notification { if ([NSThread currentThread] != _notificationThread) { // Forward the notification to the correct thread. [self.notificationLock lock]; [self.notifications addObject:notification]; [self.notificationLock unlock]; [self.notificationPort sendBeforeDate:[NSDate date] components:nil from:nil reserved:0]; } else { // Process the notification here; NSLog(@"current thread = %@", [NSThread currentThread]); NSLog(@"process notification"); } } @end 運行後，其輸出如下： 2015-03-11 23:38:31.637 test[1474:92483] current thread = {number = 1, name = main} 2015-03-11 23:38:31.663 test[1474:92483] current thread = {number = 1, name = main} 2015-03-11 23:38:31.663 test[1474:92483] process notification 可以看到，我們在全局dispatch隊列中拋出的Notification，如願地在主線程中接收到了。 這種實現方式的具體解析及其局限性大家可以參考官方文檔Delivering Notifications To Particular Threads，在此不多做解釋。當然，更好的方法可能是我們自己去子類化一個NSNotificationCenter，或者單獨寫一個類來處理這種轉發。 NSNotificationCenter的線程安全性 蘋果之所以採取通知中心在同一個線程中post和轉發同一消息這一策略，應該是出於線程安全的角度來考量的。官方文檔告訴我們，NSNotificationCenter是一個線程安全類，我們可以在多線程環境下使用同一個NSNotificationCenter對象而不需要加鎖。原文在Threading Programming Guide中，具體如下： The following classes and functions are generally considered to be thread-safe. You can use the same instance from multiple threads without first acquiring a lock. NSArray ... NSNotification NSNotificationCenter 我們可以在任何線程中添加/刪除通知的觀察者，也可以在任何線程中post一個通知。 NSNotificationCenter在線程安全性方面已經做了不少工作了，那是否意味著我們可以高枕無憂了呢?再回過頭來看看第一個例子，我們稍微改造一下，一點一點來： 代碼清單3：NSNotificationCenter的通用模式 @interface Observer : NSObject @end @implementation Observer - (instancetype)init { self = [super init]; if (self) { _poster = [[Poster alloc] init]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil] } return self; } - (void)handleNotification:(NSNotification *)notification { NSLog(@"handle notification "); } - (void)dealloc { [[NSNotificationCenter defaultCenter] removeObserver:self]; } @end // 其它地方 [[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil]; 上面的代碼就是我們通常所做的事情：添加一個通知監聽者，定義一個回調，並在所屬對象釋放時移除監聽者;然後在程序的某個地方post一個通知。簡單明了，如果這一切都是發生在一個線程裡面，或者至少dealloc方法是在-postNotificationName:的線程中運行的(注意：NSNotification的post和轉發是同步的)，那麼都OK，沒有線程安全問題。但如果dealloc方法和-postNotificationName:方法不在同一個線程中運行時，會出現什麼問題呢? 我們再改造一下上面的代碼： 代碼清單4：NSNotificationCenter引發的線程安全問題 #pragma mark - Poster @interface Poster : NSObject @end @implementation Poster - (instancetype)init { self = [super init]; if (self) { [self performSelectorInBackground:@selector(postNotification) withObject:nil]; } return self; } - (void)postNotification { [[NSNotificationCenter defaultCenter] postNotificationName:TEST_NOTIFICATION object:nil]; } @end #pragma mark - Observer @interface Observer : NSObject { Poster *_poster; } @property (nonatomic, assign) NSInteger i; @end @implementation Observer - (instancetype)init { self = [super init]; if (self) { _poster = [[Poster alloc] init]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:TEST_NOTIFICATION object:nil]; } return self; } - (void)handleNotification:(NSNotification *)notification { NSLog(@"handle notification begin"); sleep(1); NSLog(@"handle notification end"); self.i = 10; } - (void)dealloc { [[NSNotificationCenter defaultCenter] removeObserver:self]; NSLog(@"Observer dealloc"); } @end #pragma mark - ViewController @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; __autoreleasing Observer *observer = [[Observer alloc] init]; } @end 這段代碼是在主線程添加了一個TEST_NOTIFICATION通知的監聽者，並在主線程中將其移除，而我們的NSNotification是在後台線程中post的。在通知處理函數中，我們讓回調所在的線程睡眠1秒鍾，然後再去設置屬性i值。這時會發生什麼呢?我們先來看看輸出結果： 2015-03-14 00:31:41.286 SKTest[932:88791] handle notification begin 2015-03-14 00:31:41.291 SKTest[932:88713] Observer dealloc 2015-03-14 00:31:42.361 SKTest[932:88791] handle notification end (lldb) // 程序在self.i = 10處拋出了"Thread 6: EXC_BAD_ACCESS(code=EXC_I386_GPFLT)" 經典的內存錯誤，程序崩潰了。其實從輸出結果中，我們就可以看到到底是發生了什麼事。我們簡要描述一下： 當我們注冊一個觀察者是，通知中心會持有觀察者的一個弱引用，來確保觀察者是可用的。 主線程調用dealloc操作會讓Observer對象的引用計數減為0，這時對象會被釋放掉。 後台線程發送一個通知，如果此時Observer還未被釋放，則會向其轉發消息，並執行回調方法。而如果在回調執行的過程中對象被釋放了，就會出現上面的問題。 當然，上面這個例子是故意而為之，但不排除在實際編碼中會遇到類似的問題。雖然NSNotificationCenter是線程安全的，但並不意味著我們在使用時就可以保證線程安全的，如果稍不注意，還是會出現線程問題。 那我們該怎麼做呢?這里有一些好的建議： 盡量在一個線程中處理通知相關的操作，大部分情況下，這樣做都能確保通知的正常工作。不過，我們無法確定到底會在哪個線程中調用dealloc方法，所以這一點還是比較困難。 注冊監聽都時，使用基於block的API。這樣我們在block還要繼續調用self的屬性或方法，就可以通過weak-strong的方式來處理。具體大家可以改造下上面的代碼試試是什麼效果。 使用帶有安全生命周期的對象，這一點對象單例對象來說再合適不過了，在應用的整個生命周期都不會被釋放。 使用代理。

㈥ ios如果1個方法里有多個網路請求 怎麼依次施行

.新建一個網路請求工具類，負責整個項目中所有的Http網路請求

㈦ ios 多次請求多線程怎麼處理

如何處理多個網路請求的並發的情況
一、概念
1.並發 當有多個線程在操作時,如果系統只有一個CPU,則它根本不可能真正同時進行一個以上的線程，它只能把CPU運行時間劃分成若干個時間段,再將時間 段分配給各個線程執行，在一個時間段的線程代碼運行時，其它線程處於掛起狀。.這種方式我們稱之為並發(Concurrent)。
2.並行 當系統有一個以上CPU時,則線程的操作有可能非並發。當一個CPU執行一個線程時，另一個CPU可以執行另一個線程，兩個線程互不搶佔CPU資源，可以同時進行，這種方式我們稱之為並行(Parallel)。
3.區別 並發和並行是即相似又有區別的兩個概念，並行是指兩個或者多個事件在同一時刻發生；而並發是指兩個或多個事件在同一時間間隔內發生。
舉個栗子
1).並發 一個送外賣的A需要把兩份外賣分別送到兩個客戶B和C手裡。 A必須先送完B外賣才能接著送C的。這就是並發
2).並行 客戶C 分別從餓了么和美團訂了一共兩份外賣。那麼外賣員A和外賣員B需要把外賣一同送到客戶C手裡。 這就是並行
在iOS中，經常可以看見有這樣的需求，就是一個方法要等另外一個方法執行完畢再做相對應的處理，比如說一些網路請求，需要根據上一個請求的返回值做相對應的處理再執行第二個請求，所以我們不能讓兩個請求同時去請求網路。下面就記錄以下通過GCD和NSOperationQueue來控制並發。
二、代碼部分（GCD）
dispatch_semaphore 信號量

㈧ iOS開發中網路請求的代碼放到哪兒比較好

一般網路請求的代碼都封裝到一個工具類中。MVC的話就放到model層中

㈨ ios進行網路請求是開辟子線程嗎

是的。因為直接在主線程里進行網路請求會阻塞主線程，所有開辟子線程進行網路請求，請求完成後返回主線程刷新UI

㈩ ios 非同步網路請求 算是多線程嗎

換成我們伺服器的介面 查看原帖>>