1.簡述你對(duì)緩存的實(shí)現(xiàn)和管理

首先:介紹一片博客里面對(duì)iOS的緩存做了很詳細(xì)的說明:http://www.cnblogs.com/qiqibo/p/3520635.html

TCP和UDP

1.在通信協(xié)議中,TCP和UDP屬于傳輸層協(xié)議 ?socket只是一種連接模式

2.TCP和UDP和最基本通信協(xié)議,其他協(xié)議基本上是基于這兩個(gè)協(xié)議的,而用socket可以創(chuàng)建tcp和udp協(xié)議

3.tcp和udp 的主要區(qū)別是tcp可以提供可靠的數(shù)據(jù)選擇

4.TCP---傳輸控制協(xié)議,提供的是面向連接、可靠的字節(jié)流服務(wù)。當(dāng)客戶和服務(wù)器彼此交換數(shù)據(jù)前，必須先在雙方之間建立一個(gè)TCP連接，之后才能傳輸數(shù)據(jù)。TCP提供超時(shí)重發(fā)，丟棄重復(fù)數(shù)據(jù)，檢驗(yàn)數(shù)據(jù)，流量控制等功能，保證數(shù)據(jù)能從一端傳到另一端。

5.UDP---用戶數(shù)據(jù)報(bào)協(xié)議，是一個(gè)簡單的面向數(shù)據(jù)報(bào)的運(yùn)輸層協(xié)議。UDP不提供可靠性，它只是把應(yīng)用程序傳給IP層的數(shù)據(jù)報(bào)發(fā)送出去，但是并不能保證它們能到達(dá)目的地。由于UDP在傳輸數(shù)據(jù)報(bào)前不用在客戶和服務(wù)器之間建立一個(gè)連接，且沒有超時(shí)重發(fā)等機(jī)制，故而傳輸速度很快

Cookies 和 Session的區(qū)別和共同點(diǎn):

1.cookie和session的共同之處在于：cookie和session都是用來跟蹤瀏覽器用戶身份的會(huì)話方式。

2.cookie和session的區(qū)別是：

1)cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上

2)cookie不是很安全，別人可以分析存放在本地的cookie并進(jìn)行cookie欺騙,如果主要考慮到安全應(yīng)當(dāng)使用session

3)session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪問增多，會(huì)比較占用你服務(wù)器的性能，如果主要考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用cookie

4)單個(gè)cookie在客戶端的限制是3K，就是說一個(gè)站點(diǎn)在客戶端存放的COOKIE不能3K。

5)如何選擇：一般將登陸信息等重要信息存放為SESSION;其他信息如果需要保留，可以放在COOKIE中

手寫單例的實(shí)現(xiàn)

+(AccountManager *)sharedManager {

static AccountManager *sharedAccountManagerInstance = nil; static dispatch_once_t predicate;

dispatch_once(&predicate, ^{

sharedAccountManagerInstance = [[self alloc] init];

});

return sharedAccountManagerInstance;

}

問題一: 遇到APP閃退問題怎么處理?

1.可以通過第三方查看奔潰日志,定位奔潰位置;

2.查看客戶的測(cè)試環(huán)境和我們的測(cè)試環(huán)境差異,排除系統(tǒng)版本和軟件版本的差異

3.排除是否存在內(nèi)存溢出的問題,系統(tǒng)版本不匹配造成API使用不當(dāng)?shù)谋紳?/p>

4.自己重新測(cè)試復(fù)現(xiàn),打斷點(diǎn)查看,leak工具查看

問題二: 遠(yuǎn)程推送的原理步驟

原理: 公司服務(wù)器通過APNs服務(wù)器找到裝有我們APP的設(shè)備,并給設(shè)備上面的這個(gè)應(yīng)用推送消息; 我們需要配置推送證書獲得DeviceToken,推送證書需要知道我們的BundleID和UDID,還有服務(wù)器的UDID ? ?證書申請(qǐng)步驟(1.注冊(cè)一個(gè)蘋果遠(yuǎn)程通知證書,2.綁定BundleID和蘋果ID,并添加我們需要的服務(wù)3.配置推送證書;4.需要導(dǎo)入一個(gè)crs簽名文件;5,在鑰匙串中下載好crs文件,load進(jìn)行配置,配置好了就直接下載下來;6.雙擊進(jìn)行安裝,在代理方法中就可以獲得tokenID)

問題三:kvc和kvo底層實(shí)現(xiàn)原理

kvc :鍵值編碼

kvo:鍵值監(jiān)聽

kvo是基于runtime實(shí)現(xiàn)的,也是kvc 關(guān)鍵技術(shù)之一,是一種觀察者模式,利用它可以很容易的實(shí)現(xiàn)視圖組件和數(shù)據(jù)模型的分離,當(dāng)數(shù)據(jù)模型的屬性值發(fā)生改變之后,監(jiān)聽器的視圖組件就會(huì)被激活,激發(fā)時(shí)回調(diào)監(jiān)聽器自身

kvc 設(shè)置屬性時(shí),會(huì)優(yōu)先調(diào)用set方法,如果沒有該方法,則優(yōu)先考慮搜索帶下劃線的變量,如果仍然沒有則搜索成員變量,如果也沒有,則會(huì)抵用undefinekey方法,如果沒有實(shí)現(xiàn)這個(gè)方法,則會(huì)直接奔潰

kvc 讀取屬性時(shí),會(huì)優(yōu)先調(diào)用getter方法,如果沒有則會(huì)優(yōu)先搜索帶下劃線的成員變量,如果沒有則會(huì)調(diào)用同名成員變量,最后還沒有搜索到的話,則會(huì)調(diào)用undefinekey這個(gè)方法,如果沒有實(shí)現(xiàn),就會(huì)奔潰

kvc 可以用來訪問系統(tǒng)的私有屬性 (列如 tabbar)

問題四:sqlite異步請(qǐng)求數(shù)據(jù) ???

1.直接在請(qǐng)求數(shù)據(jù)時(shí),開啟一個(gè)異步線程進(jìn)行數(shù)據(jù)請(qǐng)求,數(shù)據(jù)請(qǐng)求回來之后,通過線程間的通信回到主線程刷新UI

問題二:怎么樣對(duì)tableview進(jìn)行性能優(yōu)化

1.適當(dāng)?shù)膶?duì)cell進(jìn)行復(fù)用

2.正確的緩存,復(fù)用圖片和數(shù)據(jù)

3.在調(diào)用比較頻繁的方法中,盡量減少邏輯計(jì)算時(shí)間 (把一些計(jì)算屬性交給模型處理

,cell只負(fù)責(zé)展示數(shù)據(jù))

4.對(duì)cell的高度進(jìn)行緩存,不要重復(fù)計(jì)算(在模型中重寫cellHeight的getter方法)

5.盡量避免在cell上使用圖形特效 (圖形越多,cell上面的UI組件渲染越慢)

6.減少cell的層次結(jié)構(gòu),可以使用coreText進(jìn)行繪圖,cell的內(nèi)容為圖片顯示.

7.減少不必要的cell 顯示和網(wǎng)絡(luò)請(qǐng)求

問題七:SDWebImage的底層實(shí)現(xiàn)

SDWebImage開始下載任務(wù),先進(jìn)入SDWebImageManager-downloadWithURL:delegate:options:userinfo: ? 交給SDImageCache從緩存中查找圖片是否已經(jīng)下載,queryDiskCacheForKey:delegate:userinfo ;如果緩存中有圖片,就會(huì)通過代理回調(diào)給SDWebImage并通過UIImage+webCache等前端展示圖片; ?如果緩存中沒有,那么會(huì)生成NSInvocationOperation添加到隊(duì)列中開始去沙盒中查找,在沙盒中是根據(jù)圖片的URLKey進(jìn)行圖片的讀取的,這一步是在NSOperation子線程中進(jìn)行操作的,所以如果讀取到沙盒中有圖片,會(huì)回到主線程結(jié)束回調(diào) ;如果沙盒中讀取不到圖片,說明所有的緩存和沙盒中都沒有該圖片,需要下載圖片,接著回調(diào)imageCache:didNotFindImageForKey:userInfo; 并重新生成一個(gè)下載器SDWebImageDownloader開始下載圖片;圖片下載是由NSURLConnection來完成的,實(shí)現(xiàn)相關(guān)的delegate來判斷圖片下載狀態(tài)

問題八:AFNetworking的底層實(shí)現(xiàn)

首先,AFNetworking這個(gè)庫是在NSURLSession和NSURLConnection的基礎(chǔ)上進(jìn)行封裝的,邏輯簡單清楚,設(shè)計(jì)思想也比較好;，

NSURLConnection是蘋果IOS2.0之后推出的用于加載URL資源的API,使用比較簡單,分為同步和異步請(qǐng)求,同步請(qǐng)求和異步請(qǐng)求的底層實(shí)現(xiàn)都是一樣的,都是告訴系統(tǒng)請(qǐng)求一個(gè)URL資源,系統(tǒng)會(huì)有自己的私有線程去load資源,在load完成之后告訴調(diào)用者.唯一的不同是,同步會(huì)阻塞線程,然后程序一直等待,直到load完成,一般不會(huì)再主線程中調(diào)用同步方法,這樣會(huì)阻塞用戶的交互. ?而異步方法,在程序調(diào)用完成之后就不用管了.程序還會(huì)繼續(xù)往下執(zhí)行,在load 完成之后會(huì)通知調(diào)用者,通知調(diào)用者的方式有兩種,一種是通過代理,系統(tǒng)會(huì)在connection的調(diào)用線程中通知代理,第二種是queue方式,系統(tǒng)會(huì)在指定的queue中通知調(diào)用者

AFNetworking是利用異步加載數(shù)據(jù)的方法,通過代理方式放回給調(diào)用者;首先請(qǐng)求調(diào)用必須有一個(gè)線程來執(zhí)行.那么我們必須要處理這個(gè)請(qǐng)求在哪個(gè)線程中執(zhí)行,因此AFNetworking就包含有connection和nsoperation;當(dāng)然只滿足于這兩點(diǎn)顯然是不夠的,線程的并發(fā)數(shù)難以控制,這樣就得引入NSOperationQueue來管理線程并發(fā),然而在數(shù)據(jù)量比較大,線程比較多的情況下,線程之間的load速度不一樣,一個(gè)線程的load任務(wù)完成之后,就只能等待其他線程的執(zhí)行,比較浪費(fèi)時(shí)間,因此可以讓NSOperation去通知一個(gè)共同的線程去執(zhí)行NSOperation的load方法;最后AF的模型為 NSConnection+NSOperation+NSOperationQueue+CommentNSTread

我的理解：

AFNetworking內(nèi)部由NSURLSession實(shí)現(xiàn)，AFHTTPSessionManager的接口GET／POST，其內(nèi)部實(shí)現(xiàn)如下：

1、調(diào)用AFURLRequestSerialization的接口，對(duì)參數(shù)進(jìn)行處理

2、拿到參數(shù)已經(jīng)處理好的NSURLRequest，調(diào)用父類AFURLSessionManager的接口，創(chuàng)建任務(wù)

3、resume

注：在執(zhí)行resume方法時(shí)，此處用到Swizzling Method，詳情見AFURLSessionManager.m文件中的_AFURLSessionTaskSwizzling類

其中第2步的父類接口內(nèi)部實(shí)現(xiàn)如下：

1、直接拿到NSURLSession執(zhí)行task（在AFURLSessionManager的構(gòu)造方法中，給它設(shè)置了NSURLSession屬性，并且設(shè)置了NSOperationQueue且最大并發(fā)數(shù)為1，設(shè)置為NSURLSession的代理）

2、將NSURLSession與AFURLSessionManagerTaskDelegate相關(guān)聯(lián)（通過NSProgress關(guān)聯(lián)），進(jìn)行上傳／下載進(jìn)度回調(diào)

3、當(dāng)NSURLSession任務(wù)執(zhí)行完畢后，AFURLSessionManager將代理任務(wù)下發(fā)給AFURLSessionManagerTaskDelegate，TaskDelegate調(diào)用AFURLResponseSerialization的接口進(jìn)行JSON解析，進(jìn)行失敗／成功回調(diào)

其中AFURLResponseSerialization的接口內(nèi)部由NSXMLParser／NSJSONSerialization實(shí)現(xiàn)，根據(jù)我們服務(wù)器數(shù)據(jù)的不同進(jìn)行不同解析。