數(shù)據(jù)存儲:

在 iOS 開發(fā)中數(shù)據(jù)的存儲可以歸納為兩類:一類是存儲為文件,另一類是存儲為數(shù)據(jù)庫.

存儲為文件:

Document 目錄:保存應(yīng)用程序運(yùn)行時生成的需要持久化的數(shù)據(jù).應(yīng)用自己的數(shù)據(jù)(比如:游戲進(jìn)度存檔,軟件的一些個人設(shè)置等).會備份,此目錄下保存的相對重要的數(shù)據(jù).

temp 目錄:程序運(yùn)行時所需的臨時數(shù)據(jù),不會備份,系統(tǒng)管理

Library/Cachas 目錄:保存從網(wǎng)絡(luò)下載的數(shù)據(jù)(聽歌,圖片的緩存),程序員管理清除數(shù)據(jù).不會備份,主要保存程序運(yùn)行時生成的需要持久化的數(shù)據(jù),一般存儲體積大,不需要備份的非重要數(shù)據(jù).

偏好設(shè)置: ?Library/Preference 目錄:保存通過"偏好設(shè)置"寫入的數(shù)據(jù). iOS 的 settings 應(yīng)用會在該目錄中查找應(yīng)用的設(shè)置信息,會備份,系統(tǒng)管理,通常用來儲存一些基本的軟件配置信息,比如記住密碼,自動登錄等.NSUserDefaults被設(shè)計(jì)用來存儲設(shè)備和應(yīng)用的配置信息，它通過一個工廠方法返回默認(rèn)的、也是最常用到的實(shí)例對象治专。這個對象中儲存了系統(tǒng)中用戶的配置信息旧烧，開發(fā)者可以通過這個實(shí)例對象對這些已有的信息進(jìn)行修改锥忿，也可以按照自己的需求創(chuàng)建新的配置項(xiàng)渔隶。用來保存應(yīng)用程序設(shè)置和屬性邀摆、用戶保存的數(shù)據(jù)纵顾。

NSKeyedArchiver(歸檔):把內(nèi)存數(shù)據(jù)轉(zhuǎn)移到閃存中進(jìn)行持久化的操作稱成為歸檔。內(nèi)存存儲是臨時的栋盹，運(yùn)行時有效的施逾，但效率高，而閃存則是一種持久化存儲例获，但產(chǎn)生I/O消耗汉额，效率相對低.NSKeyedArchiver：采用歸檔的形式來保存數(shù)據(jù)，該數(shù)據(jù)對象需要遵守NSCoding協(xié)議榨汤，并且該對象對應(yīng)的類必須提供encodeWithCoder:和initWithCoder:方法蠕搜。前一個方法告訴系統(tǒng)怎么對對象進(jìn)行編碼，而后一個方法則是告訴系統(tǒng)怎么對對象進(jìn)行解碼收壕。缺點(diǎn)：歸檔的形式來保存數(shù)據(jù)妓灌，只能一次性歸檔保存以及一次性解壓轨蛤。所以只能針對小量數(shù)據(jù)，而且對數(shù)據(jù)操作比較笨拙虫埂，即如果想改動數(shù)據(jù)的某一小部分俱萍，還是需要解壓整個數(shù)據(jù)或者歸檔整個數(shù)據(jù)。

存儲為數(shù)據(jù)庫:

SQLite3:iOS的SDK里預(yù)置了SQLite的庫告丢，開發(fā)者可以自建SQLite數(shù)據(jù)庫。SQLite每次寫入數(shù)據(jù)都會產(chǎn)生IO消耗损谦，把數(shù)據(jù)歸檔到相應(yīng)的文件岖免。

SQLite擅長處理的數(shù)據(jù)類型其實(shí)與NSUserDefaults差不多，也是基礎(chǔ)類型的小數(shù)據(jù)照捡，只是從組織形式上不同颅湘。開發(fā)者可以以關(guān)系型數(shù)據(jù)庫的方式組織數(shù)據(jù)，使用SQL DML來管理數(shù)據(jù)栗精。 一般來說應(yīng)用中的格式化的文本類數(shù)據(jù)可以存放在數(shù)據(jù)庫中闯参，尤其是類似聊天記錄、Timeline等這些具有條件查詢和排序需求的數(shù)據(jù)悲立。

無論你采用系統(tǒng)自帶的還是用的SQLight第三方庫的數(shù)據(jù)存儲本質(zhì)都數(shù)據(jù)庫存儲鹿寨，沒必要再另外分類。數(shù)據(jù)存儲稍微麻煩薪夕，并且存儲的速度較慢脚草，只有真正需要用到的地方才采用這種方式，如：聊天記錄原献，地圖地理信息查詢馏慨。

Core Data(對 SQLite 的封裝):

一個支持持久化的，對象圖和生命周期的自動化管理方案姑隅。嚴(yán)格意義上說CoreData是一個管理方案写隶，他的持久化可以通過SQLite、XML或二進(jìn)制文件儲存讲仰。如官方定義所說慕趴，CoreData的作用遠(yuǎn)遠(yuǎn)不止儲存數(shù)據(jù)這么簡單，它可以把整個應(yīng)用中的對象建模并進(jìn)行自動化的管理叮盘。他和微軟的MFC::CArchive實(shí)現(xiàn)對象的持久化和反持久化一樣只能支持具有序列化的函數(shù)秩贰，把對象分解成基本數(shù)據(jù)類型的持久化，如字符串柔吼，整形數(shù)字毒费，浮點(diǎn)型數(shù)據(jù)，字符愈魏。由于持久化的對象數(shù)據(jù)都在一個對象中觅玻，所以他利于數(shù)據(jù)管理想际。所以采用CoreData存儲數(shù)據(jù)就不需要采用NSUserDefaults數(shù)據(jù)存儲數(shù)據(jù)了。

KVO 和 KVC

KVC:

Key-value coding,它是一種使用字符串標(biāo)識符溪厘，間接訪問對象屬性的機(jī)制,而不是直接調(diào)用getter 和 setter方法胡本。通常我們使用valueForKey 來替代getter 方法，setValue:forKey來代替setter方法畸悬。一般是用在 JSON 數(shù)據(jù)的序列化.字典轉(zhuǎn)模型.

KVO:(是基于 KVC 實(shí)現(xiàn)的)

即：Key-Value Observing侧甫，它提供一種機(jī)制，當(dāng)指定的對象的屬性被修改后蹋宦，則對象就會接受到通知披粟。簡單的說就是每次指定的被觀察的對象的屬性被修改后，KVO就會自動通知相應(yīng)的觀察者了冷冗。

使用方法:

系統(tǒng)框架已經(jīng)支持KVO守屉，所以程序員在使用的時候非常簡單。

1. 注冊蒿辙，指定被觀察者的屬性拇泛，

2. 實(shí)現(xiàn)回調(diào)方法

3. 移除觀察

MVC:

MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫思灌，一種軟件設(shè)計(jì)典范俺叭，用一種業(yè)務(wù)邏輯、數(shù)據(jù)习瑰、界面顯示分離的方法組織代碼绪颖，將業(yè)務(wù)邏輯聚集到一個部件里面，在改進(jìn)和個性化定制界面及用戶交互的同時甜奄，不需要重新編寫業(yè)務(wù)邏輯柠横。MVC被獨(dú)特的發(fā)展起來用于映射傳統(tǒng)的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結(jié)構(gòu)中课兄。

代理和通知:

代理：一般控件用的比較多牍氛，其實(shí)也可以用block實(shí)現(xiàn)，如果實(shí)現(xiàn)的接口比較多的話烟阐，建議用代理搬俊，代理是一對一,可以有返回值.

通知：這東西是全局的，而且是同步的蜒茄，如果你要全局發(fā)送消息唉擂，并且做的事情時間不長，不會阻塞線程的話檀葛，建議使用玩祟。可以一對多,多對多.

kvo: ?kvo是建立在kvc的基礎(chǔ)之上的屿聋，它通過 key path 觀察對象的值空扎，當(dāng)值發(fā)生變化的時候會收到通知藏鹊。比 如，你需要監(jiān)聽UITableview的contentoffset那么當(dāng)转锈，tableview滑動的時候盘寡，就會不停的收到contentoffset point值。你要監(jiān)聽某一對象的值的時候撮慨，建議使用竿痰。

實(shí)現(xiàn)單例的幾種方式:

單例模式：保證一個類中，有且只有一個實(shí)例存在并提供一個訪問點(diǎn)供全局訪問砌溺，該實(shí)例可以被所有的程序來訪問菇曲。

一般有在，在這種情況下用：

1抚吠、當(dāng)要用一個類時，又要用該類中的一個實(shí)例弟胀；

2楷力、new?來創(chuàng)建實(shí)例時會給程序造成資源的浪費(fèi)，而且實(shí)例越多也不好控制孵户。

3萧朝、不同的線程調(diào)用時，可能會引起不同步的現(xiàn)象夏哭。

+ (AccountManager *)sharedManager {

static AccountManager *sharedAccountManagerInstance = nil;

static dispatch_once_t predicate;

dispatch_once(&predicate, ^{

sharedAccountManagerInstance = [[self alloc] init];

});

return sharedAccountManagerInstance;

}

runTime 和 runLoop

runLoop:基本作用：

保持程序的持續(xù)運(yùn)行

處理App中的各類事件（觸摸事件检柬、定時器事件、Selector事件）

節(jié)省CPU資源竖配，提高程序性能：沒有事件時就進(jìn)行睡眠狀態(tài)

內(nèi)部實(shí)現(xiàn)：

do-while循環(huán)何址，在這個循環(huán)內(nèi)部不斷地處理各種任務(wù)（Source\Timeer\Observer）

注意點(diǎn)：

一個線程對應(yīng)一個RunLoop（采用字典存儲，線程號為key进胯，RunLoop為value）

主線程的RunLoop默認(rèn)已經(jīng)啟動用爪，子線程的RunLoop需要手動啟動

RunLoop只能選擇一個Mode啟動，如果當(dāng)前Mode沒有任何Source胁镐、Timer偎血、Observer，那么就不會進(jìn)入RunLoop

RunLoop的主要函數(shù)調(diào)用順序?yàn)椋篊FRunLoopRun->CFRunLoopRunSpecific->__CFRunLoopRun

runTime:

Objective-C是基于C語言加入了面向?qū)ο筇匦?/b>和消息轉(zhuǎn)發(fā)機(jī)制的動態(tài)語言盯漂，這意味著它不僅需要一個編譯器颇玷，還需要Runtime系統(tǒng)來動態(tài)創(chuàng)建類和對象，進(jìn)行消息發(fā)送和轉(zhuǎn)發(fā)就缆。

內(nèi)存管理機(jī)制:

1>堆和棧的區(qū)別

管理方式：對于棧來講帖渠，是由編譯器自動管理，無需我們手工控制违崇；對于堆來說阿弃，釋放工作由程序員控制诊霹，容易產(chǎn)生memory leak。

申請大性尽：

棧是向低地址擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)脾还，是一塊連續(xù)的內(nèi)存的區(qū)域,棧頂?shù)牡刂泛蜅５淖畲笕萘渴窍到y(tǒng)預(yù)先規(guī)定好的，能從棧獲得的空間較小入愧。

堆是向高地址擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)鄙漏，是不連續(xù)的內(nèi)存區(qū)域,因?yàn)橄到y(tǒng)是用鏈表來存儲的空閑內(nèi)存地址的,自然是不連續(xù)的,而鏈表的遍歷方向是由低地址向高地址。堆的大小受限于計(jì)算機(jī)系統(tǒng)中有效的虛擬內(nèi)存,因此堆獲得的空間比較靈活,也比較大棺蛛。

碎片問題：

對于堆來講怔蚌，頻繁的new/delete勢必會造成內(nèi)存空間的不連續(xù)，從而造成大量的碎片旁赊，使程序效率降低桦踊。對于棧來講，則不會存在這個問題终畅，因?yàn)闂Ｊ窍冗M(jìn)后出的隊(duì)列籍胯，他們是如此的一一對應(yīng)，以至于永遠(yuǎn)都不可能有一個內(nèi)存塊從棧中間彈出

分配方式：

堆都是動態(tài)分配的离福，沒有靜態(tài)分配的堆杖狼。棧有2種分配方式：靜態(tài)分配和動態(tài)分配。靜態(tài)分配是編譯器完成的妖爷，比如局部變量的分配蝶涩。動態(tài)分配由alloca函數(shù)進(jìn)行分配，但是棧的動態(tài)分配和堆是不同的絮识，他的動態(tài)分配是由編譯器進(jìn)行釋放绿聘，無需我們手工實(shí)現(xiàn)。

分配效率：

棧是機(jī)器系統(tǒng)提供的數(shù)據(jù)結(jié)構(gòu)次舌，計(jì)算機(jī)會在底層對棧提供支持：分配專門的寄存器存放棧的地址斜友，壓棧出棧都有專門的指令執(zhí)行，這就決定了棧的效率比較高垃它。堆則是C/C++函數(shù)庫提供的鲜屏，它的機(jī)制是很復(fù)雜的。

APP 主流框架的搭建:

用 UITabBarController管理 UINavigationController. ?然后 UINavigationController 再管理子控制器

GCD 和 NSOperation 多線程技術(shù):

GCD是純C語言的API国拇，NSOperationQueue是基于GCD的OC版本封裝

提供給 GCD 隊(duì)列的是代碼塊.

GCD 暫停 ? dispatch_suspend

dispatch_resume ? 恢復(fù)一個隊(duì)列

3.2> GCD僅僅支持FIFO(先進(jìn)先出)隊(duì)列洛史，只可以設(shè)置隊(duì)列的優(yōu)先級,而NSOperationQueue中的每一個任務(wù)都可以被重新設(shè)置優(yōu)先級(setQueuePriority:)，從而實(shí)現(xiàn)不同操作的執(zhí)行順序調(diào)整

3.3> GCD不支持異步操作之間的依賴關(guān)系設(shè)置酱吝。如果某個操作的依賴另一個操作的數(shù)據(jù)也殖，使用NSOperationQueue能夠設(shè)置依賴按照正確的順序執(zhí)行操作(addDependency:)。GCD則沒有內(nèi)建的依賴關(guān)系支持(只能通過Barrior和同步任務(wù)手動實(shí)現(xiàn))。

3.4> NSOperationQueue方便停止隊(duì)列中的任務(wù)(cancelAllOperations, suspended),GCD不方便停止隊(duì)列中的任務(wù).

3.5> NSOperationQueue支持KVO忆嗜，可以監(jiān)測operation是否正在執(zhí)行（isExecuted）己儒、是否結(jié)束（isFinished），是否取消（isCanceld）

3.6> GCD的執(zhí)行速度比NSOperationQueue快

3.7> NSOperationQueue可設(shè)置最大并發(fā)數(shù)量(節(jié)電),GCD具有dispatch_once(只執(zhí)行一次,單例)和dispatch_after(延遲執(zhí)行)功能

get/post 請求:

Get：

1>get一般是獲取服務(wù)器上的數(shù)據(jù)

2>get請求的數(shù)據(jù)一般在url中可以看到(用戶名和密碼)

3>請求的數(shù)據(jù)在URL上捆毫，不安全

4>get請求的數(shù)據(jù)能夠被服務(wù)器緩存

5>get請求的url一般不超過1kb

6>一般向服務(wù)器發(fā)送比較小的文件

POST:

1>post一般是往服務(wù)器提交數(shù)據(jù)闪湾，并獲取服務(wù)器返回的結(jié)果

2>post方式通過請求體傳輸數(shù)據(jù)，效率低

3>請求的數(shù)據(jù)用戶看不到绩卤，相對安全

4>post請求不能被瀏覽器緩存

5>post請求體沒有大小的限制途样！

6>一般向服務(wù)器發(fā)送比較大的數(shù)據(jù)(通過請求體向服務(wù)器發(fā)送數(shù)據(jù),沒有大小限制)

線程間通信:

線程間通信：在1個進(jìn)程中，線程往往不是孤立存在的濒憋，多個線程之間需要經(jīng)常進(jìn)行通信

線程間通信的體現(xiàn)

1個線程傳遞數(shù)據(jù)給另1個線程

在1個線程中執(zhí)行完特定任務(wù)后何暇，轉(zhuǎn)到另1個線程繼續(xù)執(zhí)行任務(wù)

線程間通信常用方法

-?(void)performSelectorOnMainThread:(SEL)aSelector?withObject:(id)arg?waitUntilDone:(BOOL)wait

-?(void)performSelector:(SEL)aSelector?onThread:(NSThread?*)thr?withObject:(id)arg?waitUntilDone:

(BOOL)wait;

線程間數(shù)據(jù)共享:

資源共享

1塊資源可能會被多個線程共享，也就是多個線程可能會訪問同一塊資源

比如多個線程訪問同一個對象凛驮、同一個變量裆站、同一個文件

當(dāng)多個線程訪問同一塊資源時，很容易引發(fā)數(shù)據(jù)錯亂和數(shù)據(jù)安全問題

互斥鎖的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：能有效防止因多線程搶奪資源造成的數(shù)據(jù)安全問題

缺點(diǎn)：需要消耗大量的CPU資源

互斥鎖的使用前提：多條線程搶奪同一塊資源

相關(guān)專業(yè)術(shù)語：線程同步,多條線程按順序地執(zhí)行任務(wù)

互斥鎖黔夭，就是使用了線程同步技術(shù)

原子和非原子屬性的選擇

nonatomic和atomic對比

atomic：線程安全遏插，需要消耗大量的資源

nonatomic：非線程安全，適合內(nèi)存小的移動設(shè)備

iOS開發(fā)的建議

所有屬性都聲明為nonatomic

盡量避免多線程搶奪同一塊資源

盡量將加鎖纠修、資源搶奪的業(yè)務(wù)邏輯交給服務(wù)器端處理，減小移動客戶端的壓力

AFNetWorking實(shí)現(xiàn)原理:

1>實(shí)現(xiàn)原理

AFN的直接操作對象AFHTTPClient不同于ASI厂僧，是一個實(shí)現(xiàn)了NSCoding和NSCopying協(xié)議的NSObject子類扣草。 AFHTTPClient是一個封裝了一系列操作方法的“工具類”，處理請求的操作類是一系列單獨(dú)的颜屠，基于NSOperation封裝 的辰妙，AFURLConnectionOperation的子類。AFN的示例代碼中通過一個靜態(tài)方法甫窟，使用dispatch_once()的方式創(chuàng)建 AFHTTPClient的共享實(shí)例密浑，這也是官方建議的使用方法。在創(chuàng)建AFHTTPClient的初始化方法中粗井，創(chuàng)建了OperationQueue并 設(shè)置一系列參數(shù)默認(rèn)值尔破。在getPath:parameters:success:failure方法中創(chuàng)建NSURLRequest，以 NSURLRequest對象實(shí)例作為參數(shù)浇衬，創(chuàng)建一個NSOperation懒构，并加入在初始化發(fā)方中創(chuàng)建的NSOperationQueue。以上操作都 是在主線程中完成的耘擂。在NSOperation的start方法中胆剧，以此前創(chuàng)建的NSURLRequest對象為參數(shù)創(chuàng)建NSURLConnection 并開啟連結(jié)。

SDWebImage 實(shí)現(xiàn)原理:

下載圖片,先判斷內(nèi)存中是否有圖片,有就直接返回.

如果沒有,根據(jù)資源定位符從沙盒中去找,有就將圖片保存在內(nèi)存中,以便下次讀取,因?yàn)閺膬?nèi)存中加載圖片的速度要比沙盒塊的多,然后將圖片返回.

如果沙盒中沒有圖片,此時就創(chuàng)建一個下載操作,發(fā)送get異步請求,如果下載成功,就將圖片的二進(jìn)制數(shù)據(jù)寫入沙盒,同時保存在內(nèi)存中,并且將下載操作保存在下載操作緩存池中,目的是為了避免用戶上下拉動屏幕再次顯示此圖片時因?yàn)榫W(wǎng)絡(luò)慢的緣故多次下載同一張圖片,所以要對下載操作做一個判斷,之后在返回圖片.

并且SDWebImage有專門的SDWebImageDecoder類處理圖片,根據(jù)圖片的16進(jìn)制判斷圖片的類型,然后進(jìn)行相應(yīng)的處理,還有一個類是用來讀取磁盤數(shù)據(jù)與將數(shù)據(jù)寫入磁盤的.加載磁盤數(shù)據(jù)與性能優(yōu)化做的都非常的好.

JSON 和 XML 解析:

1)解碼難度: json的解碼難度基本為零,xml需要考慮子節(jié)點(diǎn)和父節(jié)點(diǎn)

2)數(shù)據(jù)體積&傳輸速度: json相對于xml來講,數(shù)據(jù)體積小,json的速度遠(yuǎn)遠(yuǎn)快于xml

3)數(shù)據(jù)交互: json與JavaScript的交互更加方面,更容易解析處理,更好的數(shù)據(jù)交互

4)數(shù)據(jù)描述: xml對數(shù)據(jù)描述性比較好

TCP/UDP:

TCP 和 UDP都是傳輸層協(xié)議.

TCP(傳輸控制協(xié)議)

TCP協(xié)議提供的是一種可靠的醉冤、通過“三次握手”來連接的數(shù)據(jù)傳輸服務(wù),

"三次握手":

主機(jī)A向主機(jī)B發(fā)出連接請求數(shù)據(jù)包：“我想給你發(fā)數(shù)據(jù)秩霍，可以嗎篙悯？”，這是第一次對話铃绒；

主機(jī)B向主機(jī)A發(fā)送同意連接和要求同步（同步就是兩臺主機(jī)一個在發(fā)送鸽照，一個在接收，協(xié)調(diào)工作）的數(shù)據(jù)包：“可以匿垄，你什么時候發(fā)移宅？”，這是第二次對話椿疗；

主機(jī)A再發(fā)出一個數(shù)據(jù)包確認(rèn)主機(jī)B的要求同步：“我現(xiàn)在就發(fā)漏峰，你接著吧！”届榄，這是第三次對話浅乔。

通過"四次拜拜"來斷開連接.

TCP需要建立連接,一對一,適用于大量數(shù)據(jù)的傳輸,速度比較慢.

UDP(用戶數(shù)據(jù)報(bào)協(xié)議)

UDP協(xié)議提供的則是一種相對來說不可靠的傳輸協(xié)議、無連接的數(shù)據(jù)傳輸服務(wù)铝条，可以一對多

UDP協(xié)議適用于傳輸少量的數(shù)據(jù),速度快.

SVN 和 git 第三方源代碼管理工具:

之前公司使用的是 SVN:

檢出checkout(co)

svn co ${url}

更新update(up)

svn up

提交commit(ci)

svn ci -m " 修改xxx 問題"

查看當(dāng)前目錄最近5 次提交記錄

svn log -l 5

查看當(dāng)前工作拷貝信息

svn info

查看當(dāng)前未提交的文件status(st)

svn st

這個命令輸出每個添加靖苇、修改、刪除過的目錄和文件班缰，前面的C 表示沖突贤壁，要特別注意。linux 下也可以用svn st | grep ^C 來查看沖突項(xiàng)埠忘。

查看當(dāng)前修改內(nèi)容

svn diff

撤銷當(dāng)前修改脾拆，覆蓋為資源庫最新版本

svn revert path/filename

遞歸撤銷當(dāng)前目錄修改，覆蓋為資源庫最新版本莹妒。注意新加的文件不會被刪除名船，這時也可以刪除工作拷貝，重新checkout

svn revert . --recursive

合并

SVN merge

視頻類技術(shù)點(diǎn):

系統(tǒng)自帶:

MPMoviePlayerController:

在iOS中播放視頻可以使用MPMoviePlayerController類來完成旨怠，具備一般的播放器控制功能渠驼，例如播放、暫停鉴腻、停止等迷扇。但是MPMediaPlayerController自身并不是一個完整的視圖控制器，如果要在UI中展示視頻需要將view屬性添加到界面中.

MPMoviePlayerController繼承于UIViewController爽哎，默認(rèn)是全屏模式展示谋梭、彈出后自動播放、作為模態(tài)窗口展示時如果點(diǎn)擊“Done”按鈕會自動退出模態(tài)窗口等

AVPlayer:

MPMoviePlayerController足夠強(qiáng)大和復(fù)倦青。自定義播放器的樣式瓮床，使用MPMoviePlayerController就不合適了，只能用AVPlayer.

AVPlayer本身并不能顯示視頻，而且它也不像MPMoviePlayerController有一個view屬性隘庄。如果AVPlayer要顯示必須創(chuàng)建一個播放器層AVPlayerLayer用于展示踢步，播放器層繼承于CALayer，有了AVPlayerLayer之添加到控制器視圖的layer中即可丑掺。

一般點(diǎn)播使用 HTTP; 直播使用RTMP 或私有協(xié)議,原因是延遲比較小,RTMP 本身也是為直播設(shè)計(jì). (視頻流傳輸協(xié)議)

第三方分享获印、登錄:

蘋果自帶的分享:

支持的分享軟件比較少, 所以一般使用第三方 SDK.

集成友盟社會化組件流程:

注冊友盟賬號.

申請第三方賬號.

是否通過審核.

友盟后臺綁定的第三方賬號.

下載 SDK

集成 SDK

集成 SDK 要注意的問題:

使用第三方登錄的時候需要進(jìn)行簽名打包，不然在新浪SSO授權(quán)街州、微信分享會出現(xiàn)異常兼丰。

微信登錄需要在微信開放平臺申請開發(fā)者認(rèn)證獲取登錄權(quán)限，不然無法完成授權(quán)

集成支付寶:(集成過程中遇到的一些坑)

下載支付寶 SDK . 現(xiàn)在改名為"移動支付集成開發(fā)包".

?向支付寶申請,與支付寶簽約唆缴，獲得商戶ID（partner）和賬號ID（seller）

?下載相應(yīng)的公鑰私鑰文件（加密簽名用）

?下載支付寶SDK

?生成訂單信息,簽名加密

?調(diào)用支付寶客戶端鳍征，由支付寶客戶端跟支付寶安全服務(wù)器打交道

?支付完畢后,支付寶客戶端會自動跳回到原來的應(yīng)用程序

?在原來的應(yīng)用程序中顯示支付結(jié)果給用戶看

集成支付寶可能遇到的一些問題:

1.要設(shè)置好協(xié)議頭,因?yàn)榧芍Ц秾?發(fā)送支付請求的時候需要用到.

2.可能會找不到頭文件.在需要的類中導(dǎo)入頭文件

3.導(dǎo)入支付寶依賴的系統(tǒng)框架.

推送:

上圖可以分為三個階段：

第一階段：應(yīng)用程序的服務(wù)器端把要發(fā)送的消息、目的iPhone的標(biāo)識打包面徽，發(fā)給APNS艳丛。

第二階段：APNS在自身的已注冊Push服務(wù)的iPhone列表中，查找有相應(yīng)標(biāo)識的iPhone趟紊，并把消息發(fā)送到iPhone氮双。

第三階段：iPhone把發(fā)來的消息傳遞給相應(yīng)的應(yīng)用程序，并且按照設(shè)定彈出Push通知霎匈。

極光推送.

XMPP(即時通訊):

XMPP的環(huán)境配置非常的麻煩,首先要給電腦配置一個java的環(huán)境,配置玩java環(huán)境之后,還要安裝數(shù)據(jù)庫,一般用的是關(guān)系數(shù)據(jù)庫,MYSQL?數(shù)據(jù)庫安裝完之后安裝服務(wù)器openfire.這些裝完之后還沒完,還要建立數(shù)據(jù)庫與openfire的連接.這些都配置完之后,在使用XMPP的時候要下載XMPPFramework.如果手動導(dǎo)入framework非常麻煩,比如其中拖入點(diǎn)a文件的時候要設(shè)置點(diǎn)a文件的路徑為required.這樣將項(xiàng)目換臺電腦的時候不會因?yàn)檎也坏近c(diǎn)a文件而報(bào)錯.一般最簡單的方式就是直接用cocoaspod從終端直接下載.?就會省略很多復(fù)雜的步驟.?在使用XMPP時先在application中建立長連接,因?yàn)閄MPP本身就是一種協(xié)議,所以要創(chuàng)建一個XMPP流,用來進(jìn)行實(shí)時通訊.同時把流的代理設(shè)置成application并將主機(jī)域與JID發(fā)送給服務(wù)器,在代理中驗(yàn)證用戶密碼是否正確,也在驗(yàn)證密碼正確或者是錯誤的代理中處理事情.??在程序注銷激活狀態(tài)的時候還要斷開連接,因?yàn)殚L連接特別的耗服務(wù)器資源,在程序激活的時候再重新建立連接.

消息推送:

設(shè)置注冊的通知類型

請求授權(quán)

注冊授權(quán)請求

注冊遠(yuǎn)程通知

在didRegisterForRemoteNotificationForDeviceToken將deviceToken發(fā)送給服務(wù)器

在didReceiveRemotaNotification中接收遠(yuǎn)程推送的消息沒有圖片,此時就創(chuàng)建一個下載操作,發(fā)送get異步請求,如果下載成功,就將圖片的二進(jìn)制數(shù)據(jù)寫入沙盒,同時保存在內(nèi)存中,并且將下載操作保存在下載操作緩存池中,目的是為了避免用戶上下拉動頻幕再次顯示此圖片時因?yàn)榫W(wǎng)絡(luò)慢的緣故多次下載同一張圖片,所以要對下載操作做一個判斷,之后在返回圖片.并且SDWebImage有專門的SDWebImageDecoder類處理圖片,根據(jù)圖片的16進(jìn)制判斷圖片的類型,然后進(jìn)行相應(yīng)的處理,還有一個類是用來讀取磁盤數(shù)據(jù)與將數(shù)據(jù)寫入磁盤的.加載磁盤數(shù)據(jù)與性能優(yōu)化做的都非常的好.

訪問蘋果健康數(shù)據(jù):

導(dǎo)入 healthKit 框架;

XMPP:

即時通訊技術(shù)-->支持用戶在線實(shí)時交談.

它是通訊協(xié)議-->用來說明數(shù)據(jù)在網(wǎng)絡(luò)中如何傳輸.

基于XML且開放的可擴(kuò)展通訊和表示協(xié)議（XMPP）協(xié)議

XMPP 的核心在網(wǎng)絡(luò)上分片段發(fā)送XML的流協(xié)議.這個流協(xié)議是XMPP的即時通訊指令的傳遞基礎(chǔ)戴差，也是一個非常重要的可以被進(jìn)一步利用的網(wǎng)絡(luò)基礎(chǔ)協(xié)議，可以說XMPP用TCP傳的是XML流

XMPP 的基本結(jié)構(gòu):典型的 C/S 架構(gòu) ?客戶端-->服務(wù)器<--客戶端.這種方式是簡化客戶端,把大多數(shù)工作都放到服務(wù)器端進(jìn)行.

ImageName:與 imageWithContentsOfFile: 區(qū)別

imageName: 會把圖片緩存到內(nèi)存中, 方便下次調(diào)用,適合比較小的圖片,

imageContentsOfFile: 不會緩存圖片,一般用在文件加載次數(shù)比較少,圖片本身比較大的情況.

加密:

數(shù)據(jù)安全包括(連接通道加密) 和 (上傳數(shù)據(jù)加密,算法加密, 對稱加密, 非對稱加密 )

1.對稱性加密算法铛嘱，信息接收雙方都需事先知道密匙和加解密算法且其密匙是相同的暖释，之后便是對數(shù)據(jù)進(jìn)行 加解密了。2.非對稱算法與之不同弄痹，發(fā)送雙方A,B事先均生成一對密匙，然后A將自己的公有密匙發(fā)送給B嵌器，B將自己的公有密匙發(fā)送給A肛真，3.如果A要給B發(fā)送消息，則先需要用B的公有密匙進(jìn)行消息加密爽航，然后發(fā)送給B端蚓让，此時B端再用自己的私有密匙進(jìn)行消息解密，

B向A發(fā)送消息時為同樣的道理讥珍±總而言之：公鑰與私鑰的作用是：用公鑰加密的內(nèi)容只能用私鑰解密，用私鑰加密的內(nèi)容只能 用公鑰解密衷佃。

MD5:加密后不可逆(只能加密不可解密)趟卸，我們用于加密用戶的登錄密碼

DES:對稱加密(服務(wù)器和客戶端公用同一個秘鑰)，缺點(diǎn)：一旦被抓包破解了秘鑰，就能破解所有的傳遞信息

RSA:非對稱加密（會生成一對秘鑰(公鑰和私鑰)), 通過MAC終端生成兩個.pem文件锄列，再用vim打開文件图云，獲取里面的字符串(也就是秘鑰)，

MD5

由于MD5加密算法具有較好的安全性邻邮，而且免費(fèi)竣况，因此該加密算法被廣泛使用

主要運(yùn)用在數(shù)字簽名、文件完整性驗(yàn)證以及口令加密等方面

現(xiàn)在的MD5已不再是絕對安全筒严，對此丹泉，可以對MD5稍作改進(jìn)，以增加解密的難度

加鹽（Salt）：在明文的固定位置插入隨機(jī)串鸭蛙，然后再進(jìn)行MD5

先加密摹恨，后亂序：先對明文進(jìn)行MD5，然后對加密得到的MD5串的字符進(jìn)行亂序

總之宗旨就是：黑客就算攻破了數(shù)據(jù)庫规惰，也無法解密出正確的明文

RSA

iOS中的Security.framework提供了對RSA算法的支持.這種方式需要對密匙對進(jìn)行處理, 根據(jù)public key生成證書, 通過private key生成p12格式的密匙.

除了Secruty.framework, 也可以將openssl庫編譯到iOS工程中, 這可以提供更靈活的使用方式.

base64

在代碼中使用 base64加解密, ?封裝方法.

網(wǎng)絡(luò)層,傳輸層,應(yīng)用層

IP 網(wǎng)絡(luò)層, TCP/UDP應(yīng)用于傳輸層, HTTP/HTTPS 應(yīng)用于應(yīng)用層. 從本質(zhì)上來講,三者沒有可比性,因?yàn)閼?yīng)用于不用的層面

socket則是對TCP/IP協(xié)議的封裝和應(yīng)用(程序員層面上)睬塌。

也可以說，TPC/IP協(xié)議是傳輸層協(xié)議歇万，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸揩晴，

HTTP 是應(yīng)用層協(xié)議,主要解決如何包裝數(shù)據(jù).

HTTPS 是對連接通道的加密.