iOS提供的API
socket 方式
IOS 提供的socket 方式的網(wǎng)絡(luò)編程接口為CFSocket辞州。CFSocket是BSD sockets的抽象和封裝，CFSocket提供BSD sockets幾乎所有的功能谣辞，并與run loop集成，用來實(shí)現(xiàn)多線程網(wǎng)絡(luò)編程和網(wǎng)絡(luò)事件監(jiān)聽秋泳×氏校基于 CFSocket可以實(shí)現(xiàn)各種類型的 socket編程攒菠，包括stream-based 的sockets(如TCP)和packet-based 的sockets(如UDP)迫皱。
常用第三方庫:
robbiehanson/CocoaAsyncSocket
robbiehanson/XMPPFramework
一般要用到socket的地方就是需要長連接的地方，TCP居多辖众，做IM的時(shí)候需要用到卓起。其他情況，用到的情況不多凹炸。
stream方式
iOS 為stream編程模式提供的api編程接口包括兩大類戏阅，一類是Core Foundation框架層用C語言實(shí)現(xiàn)的CFStream API（包括CFStream、 CFReadStream 啤它、CFWriteStream等）,一類是基于其上的在Foundation框架層用Objective-C語言實(shí)現(xiàn)的NSStream API（包括NSStream奕筐、NSInputStream NSOutputStream等）舱痘。
這些接口用的地方也不是很多。
URL 方式
url 編程模式通過URL 的方式來實(shí)現(xiàn)網(wǎng)絡(luò)編程离赫，任何要存取的網(wǎng)絡(luò)資源（包括局域網(wǎng)和廣域網(wǎng)）都可以用一個(gè)URL來表示和存取芭逝，并支持設(shè)備間的資源共享。url 編程模式系統(tǒng)提供http, https, file, ftp, data等五種協(xié)議支持渊胸，并允許用戶自己開發(fā)和登記相關(guān)類來支持另外的應(yīng)用層網(wǎng)絡(luò)協(xié)議旬盯，進(jìn)行協(xié)議的擴(kuò)展。
url 編程模式在IOS系統(tǒng)可以使用兩種編程接口：NSURLSession 和NSURLConnection翎猛。
對于iOS 7 以后的最新系統(tǒng)推薦使用NSURLSession API胖翰，對于老版本由于不支持NSURLSession，因此必須使用NSURLConnection API切厘。
第三方庫：
AFNetworking/AFNetworking
yuantiku/YTKNetwork
在iOS開發(fā)中萨咳，這是用得最多的，需要重點(diǎn)掌握
AFNetworking3.0使用簡介
AFNetworking
- 直接用3.0版疫稿，基于NSURLSession某弦，比較好用
- HTTP數(shù)據(jù)業(yè)務(wù)用AFHTTPSessionManager
- 上傳和下載用AFURLSessionManager
- 證書用AFSecurityPolicy
- 判斷網(wǎng)絡(luò)狀況用AFNetworkReachabilityManager
- request用AFJSONRequestSerializer，僅限于HTTP數(shù)據(jù)業(yè)務(wù)
- response用AFJSONResponseSerializer而克，僅限于HTTP數(shù)據(jù)業(yè)務(wù)
- AFMultipartFormData不推薦使用靶壮，image和業(yè)務(wù)數(shù)據(jù)混合的方式不好
- 圖片可以考慮用上傳和下載業(yè)務(wù)AFURLSessionManager
AFNetworking/AFNetworking
AFNetworking文檔
YTKNetwork
- 主要還是通過繼承基類的方式來使用
- 使用了AFNetworking，是以源代碼的方式繼承员萍，沒有用Pods
- 對外暴露url腾降，request等概念，不是非常好
- 繼承方式改為協(xié)議方式碎绎，面向接口方式比較好
- 還可以封裝得更徹底一點(diǎn)
- YTKBatchRequest 類和YTKChainRequest 類作用不是很大
yuantiku/YTKNetwork
YTKNetwork基礎(chǔ)教程
YTKNetwork 使用高級(jí)教程
自己的思考
- 底層用AFNetworking螃壤，版本3.0，用源代碼整合的方式筋帖，對外輸出framework
- 數(shù)據(jù)業(yè)務(wù)奸晴，上傳業(yè)務(wù)，下載業(yè)務(wù)分開考慮
- image上傳下載提供專門的接口日麸，方便使用
- 使用者使用代理寄啼，簡化使用方式
- Block是趨勢，不過其主要作用是代碼聚合代箭，不利于模塊分割墩划；這里是要把具體業(yè)務(wù)和網(wǎng)絡(luò)模塊分割，讓不同的部門負(fù)責(zé)嗡综。所以乙帮，Block這種聚合的使用方式，在這里并不是最佳
- Notification是1對多的關(guān)系极景，在這里會(huì)帶來復(fù)雜性察净。并且全局的消息名字驾茴，并不能解耦
- 代理的1對1的溝通方式，比較合適
- protocol氢卡，使用者沟涨，實(shí)現(xiàn)者三者分離的模式，適合模塊劃分的隱含需求
- 可以做的像tableView那樣方便使用（協(xié)議和使用由底層模塊負(fù)責(zé)异吻，上層使用者比較方便）
- 容易和Android的思維方式達(dá)成統(tǒng)一
- Swift面向接口編程裹赴，也方便今后的進(jìn)化
- delegate的方式都可以改為Block，這個(gè)是一一對應(yīng)的诀浪，沒有問題棋返。這里選擇代理，只是更強(qiáng)調(diào)使用者和代理這種強(qiáng)烈的區(qū)分意味雷猪，讓使用者用起來更簡單睛竣。代碼是否在一個(gè)地方匯聚，不是這里的最重要需求求摇。這里更強(qiáng)調(diào)隔離射沟，讓業(yè)務(wù)使用者和框架實(shí)現(xiàn)者各司其職。這里的核心需求和Block的最重要特色是相反的与境。tableView從設(shè)計(jì)思路上是很值得參考的一個(gè)案例验夯。
