1、Hash方法與isEqual
1.1、== 運(yùn)算符判斷對(duì)象內(nèi)存地址是否相同
1.2毅贮、isequal判斷對(duì)象是否相同(自定義對(duì)象通常要重寫isEqual方法)
1.3、hash方法通過hash計(jì)算會(huì)返回一個(gè)hash值（最好是唯一）
???????? hash會(huì)在被添加到NSSet中調(diào)用：（要通過hash值查找新值是否已存在）
???????? hash會(huì)在被設(shè)置為NSDictionary的key時(shí)調(diào)用：（利用hash值提高key的查找效率）
2尘奏、SDWebimage
? ? 判斷當(dāng)前圖片類型：只判斷圖片二進(jìn)制數(shù)據(jù)的第一個(gè)字節(jié)
?緩存策略：默認(rèn)情況下既做內(nèi)存緩存又做磁盤緩存滩褥，下載圖片前先檢查內(nèi)存緩存，再檢查磁盤緩存
?緩存的實(shí)現(xiàn)方式：采用了蘋果推出的專門用來處理緩存的類NSCache
? 下載隊(duì)列中對(duì)多個(gè)圖片任務(wù)的處理方式：提供了FIFO和LIFO兩種方式铸题，默認(rèn)為FIFO
? 如何下載圖片：采用NSURLConnection發(fā)送網(wǎng)絡(luò)請(qǐng)求，在其代理方法中接收數(shù)據(jù)并處理進(jìn)度回調(diào)等工作
? 磁盤緩存圖片的命名：以該圖片的URL進(jìn)行MD5散列加密【echo -n “url” |MD5】
?緩存路徑：~/Library/Caches/default/com.hackemist.SDWebImageCache.default
3琢感、哈希
散列算法就是一種以較短的信息來保證文件唯一性的標(biāo)志丢间，這種標(biāo)志與文件的每一個(gè)字節(jié)都相關(guān)，而且難以找到逆向規(guī)律
4驹针、NSdictionary 烘挫、KVO等底層實(shí)現(xiàn)
5、Block使用在ARC下, 以下幾種情況, Block會(huì)自動(dòng)被從棧復(fù)制到堆（默認(rèn)情況下柬甥，block是存檔在棧中饮六，可能被隨時(shí)回收，通過copy操作可以使其在堆中保留一份, 相當(dāng)于一直強(qiáng)引用著）:
???? 1.被執(zhí)行copy方法
???? 2.作為 方法返回值
???? 3.將Block賦值給附有__strong修飾符的id類型的類或者Blcok類型成員變量時(shí)
???? 4.在方法名中含有usingBlock的Cocoa框架方法或者GDC的API中傳遞的時(shí)候.
6苛蒲、SEL和IMP區(qū)別Class
SEL : 類成員方法的指針卤橄，但不同于C語言中的函數(shù)指針，函數(shù)指針直接保存了方法的地址臂外，但SEL只是方法編號(hào)窟扑。
IMP:一個(gè)函數(shù)指針,保存了方法的地址
也就是說方法編號(hào)SEL最后還是要通過Dispatch table表尋找到對(duì)應(yīng)的IMP，IMP就是一個(gè)函數(shù)指針漏健，然后執(zhí)行這個(gè)方法
類在 Objective-C 也為我們準(zhǔn)備了類似的機(jī)制, Class 類型嚎货。當(dāng)一個(gè)類被正確的編譯過后,在這個(gè)編譯成功的類里面,存在一個(gè)變量用于保存這 個(gè)類的信息。我們可以通過一個(gè)普通的字符串取得 這個(gè) Class,也可以通過我們生成的對(duì)象取 得這個(gè) Class蔫浆。Class 被成功取得之后,我們可以把這個(gè) Class 當(dāng)作一個(gè)已經(jīng)定義好的類來使用 它殖属。這樣的機(jī)制允許我們?cè)诔绦驁?zhí)行的過程當(dāng)中,可以 Class 來得到對(duì)象的類,也可以在程序 執(zhí)行的階段動(dòng)態(tài)的生成一個(gè)在編譯階段無法確定的一個(gè)對(duì)象。
7瓦盛、GCD
實(shí)現(xiàn)A洗显，B異步執(zhí)行完后外潜，執(zhí)行C
方法一：
dispatch_barrier_async
在它前面的任務(wù)執(zhí)行結(jié)束后它才執(zhí)行，在它后面的任務(wù)等它執(zhí)行完成后才會(huì)執(zhí)行
-(void)barrier
{
// 這個(gè)隊(duì)列【不能】使用全局并發(fā)隊(duì)列
dispatch_queue_t queue = dispatch_queue_create("yanhooQueue", DISPATCH_QUEUE_CONCURRENT);
dispatch_async(queue, ^{
NSLog(@"----1-----%@", [NSThread currentThread]);
});
dispatch_async(queue, ^{
NSLog(@"----2-----%@", [NSThread currentThread]);
});
// 在它前面的任務(wù)執(zhí)行結(jié)束后它才執(zhí)行挠唆，在它后面的任務(wù)等它執(zhí)行完成后才會(huì)執(zhí)行
dispatch_barrier_async(queue, ^{
NSLog(@"----barrier-----%@", [NSThread currentThread]);
});
dispatch_async(queue, ^{
NSLog(@"----3-----%@", [NSThread currentThread]);
});
dispatch_async(queue, ^{
NSLog(@"----4-----%@", [NSThread currentThread]);
});
}
方法二：
// 創(chuàng)建隊(duì)列組
dispatch_group_t group =? dispatch_group_create();
// 獲取全局并發(fā)隊(duì)列
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
// 添加任務(wù)A到group
dispatch_group_async(group, queue, ^{
// 添加任務(wù)A到group
});
// 添加任務(wù)B到group
dispatch_group_async(group, queue, ^{
// 添加任務(wù)B到group
});
// 當(dāng)任務(wù)A和任務(wù)B都執(zhí)行完后到此來執(zhí)行任務(wù)C
dispatch_group_notify(group, queue, ^{
// 如果這里還有基于上面兩個(gè)任務(wù)的結(jié)果繼續(xù)執(zhí)行一些代碼橡卤，建議還是放到子線程中，等代碼執(zhí)行完畢后在回到主線程
// 回到主線程
dispatch_async(group, dispatch_get_main_queue(), ^{
// 執(zhí)行相關(guān)UI顯示代碼...
});
});
iOS中鎖
1损搬、@synchronized【性能較差】
只有當(dāng)標(biāo)識(shí)相同時(shí)碧库，才為滿足互斥，@synchronized指令實(shí)現(xiàn)鎖的優(yōu)點(diǎn)就是我們不需要在代碼中顯式的創(chuàng)建鎖對(duì)象巧勤，便可以實(shí)現(xiàn)鎖的機(jī)制嵌灰，但作為一種預(yù)防措施，@synchronized塊會(huì)隱式的添加一個(gè)異常處理例程來保護(hù)代碼颅悉，該處理例程會(huì)在異常拋出的時(shí)候自動(dòng)的釋放互斥鎖沽瞭。所以如果不想讓隱式的異常處理例程帶來額外的開銷，你可以考慮使用鎖對(duì)象剩瓶。
2驹溃、dispatch_semaphore
dispatch_semaphore_t signal = dispatch_semaphore_create(1);
dispatch_time_t overTime = dispatch_time(DISPATCH_TIME_NOW, 3 * NSEC_PER_SEC);
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
dispatch_semaphore_wait(signal, overTime);
NSLog(@"需要線程同步的操作1 開始");
sleep(2);
NSLog(@"需要線程同步的操作1 結(jié)束");
dispatch_semaphore_signal(signal);
});
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
sleep(1);
dispatch_semaphore_wait(signal, overTime);
NSLog(@"需要線程同步的操作2");
dispatch_semaphore_signal(signal);
})
dispatch_semaphore是GCD用來同步的一種方式，與他相關(guān)的共有三個(gè)函數(shù)延曙，分別是dispatch_semaphore_create豌鹤，dispatch_semaphore_signal，dispatch_semaphore_wait枝缔。
（1）dispatch_semaphore_create的聲明為：
dispatch_semaphore_t? dispatch_semaphore_create(long value);
傳入的參數(shù)為long布疙，輸出一個(gè)dispatch_semaphore_t類型且值為value的信號(hào)量。
值得注意的是愿卸，這里的傳入的參數(shù)value必須大于或等于0灵临，否則dispatch_semaphore_create會(huì)返回NULL。
（2）dispatch_semaphore_signal的聲明為：
long dispatch_semaphore_signal(dispatch_semaphore_t dsema)
這個(gè)函數(shù)會(huì)使傳入的信號(hào)量dsema的值加1趴荸；
(3) dispatch_semaphore_wait的聲明為：
long dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout)儒溉；
這個(gè)函數(shù)會(huì)使傳入的信號(hào)量dsema的值減1；這個(gè)函數(shù)的作用是這樣的发钝，如果dsema信號(hào)量的值大于0顿涣，該函數(shù)所處線程就繼續(xù)執(zhí)行下面的語句，并且將信號(hào)量的值減1笼平；如果desema的值為0园骆，那么這個(gè)函數(shù)就阻塞當(dāng)前線程等待timeout（注意timeout的類型為dispatch_time_t，不能直接傳入整形或float型數(shù)）寓调，如果等待的期間desema的值被dispatch_semaphore_signal函數(shù)加1了，且該函數(shù)（即dispatch_semaphore_wait）所處線程獲得了信號(hào)量锄码，那么就繼續(xù)向下執(zhí)行并將信號(hào)量減1夺英。如果等待期間沒有獲取到信號(hào)量或者信號(hào)量的值一直為0晌涕，那么等到timeout時(shí)，其所處線程自動(dòng)執(zhí)行其后語句痛悯。
dispatch_semaphore
是信號(hào)量余黎，但當(dāng)信號(hào)總量設(shè)為 1 時(shí)也可以當(dāng)作鎖來。在沒有等待情況出現(xiàn)時(shí)载萌，它的性能比 pthread_mutex
還要高惧财，但一旦有等待情況出現(xiàn)時(shí)，性能就會(huì)下降許多扭仁。相對(duì)于 OSSpinLock 來說垮衷，它的優(yōu)勢(shì)在于等待時(shí)不會(huì)消耗 CPU 資源。
如上的代碼乖坠，如果超時(shí)時(shí)間overTime設(shè)置成>2搀突，可完成同步操作。如果overTime<2的話熊泵，在線程1還沒有執(zhí)行完成的情況下仰迁，此時(shí)超時(shí)了，將自動(dòng)執(zhí)行下面的代碼顽分。
3徐许、NSLock
NSLock是Cocoa提供給我們最基本的鎖對(duì)象，這也是我們經(jīng)常所使用的卒蘸，除lock和unlock方法外绊寻，NSLock還提供了tryLock和lockBeforeDate:兩個(gè)方法，前一個(gè)方法會(huì)嘗試加鎖悬秉，如果鎖不可用(已經(jīng)被鎖住)澄步，剛并不會(huì)阻塞線程，并返回NO和泌。lockBeforeDate:方法會(huì)在所指定Date之前嘗試加鎖村缸，如果在指定時(shí)間之前都不能加鎖，則返回NO武氓。
4梯皿、NSRecursiveLock遞歸鎖
//NSLock *lock = [[NSLock alloc] init];
NSRecursiveLock *lock = [[NSRecursiveLock alloc] init];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
static void (^RecursiveMethod)(int);
RecursiveMethod = ^(int value) {
[lock lock];
if (value > 0) {
NSLog(@"value = %d", value);
sleep(1);
RecursiveMethod(value - 1);
}
[lock unlock];
};
RecursiveMethod(5);
});
NSRecursiveLock實(shí)際上定義的是一個(gè)遞歸鎖，這個(gè)鎖可以被同一線程多次請(qǐng)求县恕，而不會(huì)引起死鎖东羹。這主要是用在循環(huán)或遞歸操作中。
這段代碼是一個(gè)典型的死鎖情況忠烛。在我們的線程中属提，RecursiveMethod是遞歸調(diào)用的。所以每次進(jìn)入這個(gè)block時(shí)，都會(huì)去加一次鎖冤议，而從第二次開始斟薇，由于鎖已經(jīng)被使用了且沒有解鎖，所以它需要等待鎖被解除恕酸，這樣就導(dǎo)致了死鎖堪滨，線程被阻塞住了。
在這種情況下蕊温，我們就可以使用NSRecursiveLock袱箱。它可以允許同一線程多次加鎖，而不會(huì)造成死鎖义矛。如果我們將NSLock代替為NSRecursiveLock发笔，上面代碼則會(huì)正確執(zhí)行。
5症革、NSConditionLock條件鎖
當(dāng)我們?cè)谑褂枚嗑€程的時(shí)候筐咧，有時(shí)一把只會(huì)lock和unlock的鎖未必就能完全滿足我們的使用。因?yàn)槠胀ǖ逆i只能關(guān)心鎖與不鎖噪矛，而不在乎用什么鑰匙才能開鎖量蕊，而我們?cè)谔幚碣Y源共享的時(shí)候，多數(shù)情況是只有滿足一定條件的情況下才能打開這把鎖
6艇挨、OSSpinLock
OSSpinLock 自旋鎖残炮，性能最高的鎖。原理很簡單缩滨，就是一直 do while 忙等势就。它的缺點(diǎn)是當(dāng)?shù)却龝r(shí)會(huì)消耗大量 CPU 資源，所以它不適用于較長時(shí)間的任務(wù)脉漏。 不過最近YY大神在自己的博客不再安全的 OSSpinLock中說明了OSSpinLock已經(jīng)不再安全苞冯，請(qǐng)大家謹(jǐn)慎使用。
OSSpinLock和dispatch_semaphore的效率遠(yuǎn)遠(yuǎn)高于其他侧巨。
@synchronized和NSConditionLock效率較差舅锄。
Home push A 和Home present B，生命周期方法調(diào)用順序
Home push A：
2017-08-22 15:54:41.491812 test[69211:12624968] A-viewDidLoad
2017-08-22 15:54:41.505239 test[69211:12624968] Home-viewWillDisappear
2017-08-22 15:54:41.505423 test[69211:12624968] A-viewWillAppear
2017-08-22 15:54:42.028112 test[69211:12624968] Home-viewDidDisappear
2017-08-22 15:54:42.028310 test[69211:12624968] A-viewDidAppear
Home Present B
2017-08-22 15:57:13.000129 test[69211:12624968] B-viewDidLoad
2017-08-22 15:57:13.005573 test[69211:12624968] Home-viewWillDisappear
2017-08-22 15:57:13.005740 test[69211:12624968] B-viewWillAppear
2017-08-22 15:57:13.509749 test[69211:12624968] B-viewDidAppear
2017-08-22 15:57:13.509927 test[69211:12624968] Home-viewDidDisappear
