1、Hash方法與isEqual
1.1、== 運(yùn)算符判斷對(duì)象內(nèi)存地址是否相同
1.2、isequal判斷對(duì)象是否相同(自定義對(duì)象通常要重寫(xiě)isEqual方法)
1.3、hash方法通過(guò)hash計(jì)算會(huì)返回一個(gè)hash值（最好是唯一）
???????? hash會(huì)在被添加到NSSet中調(diào)用：（要通過(guò)hash值查找新值是否已存在）
???????? hash會(huì)在被設(shè)置為NSDictionary的key時(shí)調(diào)用：（利用hash值提高key的查找效率）
2、SDWebimage
? ? 判斷當(dāng)前圖片類(lèi)型：只判斷圖片二進(jìn)制數(shù)據(jù)的第一個(gè)字節(jié)
?緩存策略：默認(rèn)情況下既做內(nèi)存緩存又做磁盤(pán)緩存，下載圖片前先檢查內(nèi)存緩存，再檢查磁盤(pán)緩存
?緩存的實(shí)現(xiàn)方式：采用了蘋(píng)果推出的專(zhuān)門(mén)用來(lái)處理緩存的類(lèi)NSCache
? 下載隊(duì)列中對(duì)多個(gè)圖片任務(wù)的處理方式：提供了FIFO和LIFO兩種方式，默認(rèn)為FIFO
? 如何下載圖片：采用NSURLConnection發(fā)送網(wǎng)絡(luò)請(qǐng)求，在其代理方法中接收數(shù)據(jù)并處理進(jìn)度回調(diào)等工作
? 磁盤(pán)緩存圖片的命名：以該圖片的URL進(jìn)行MD5散列加密【echo -n “url” |MD5】
?緩存路徑：~/Library/Caches/default/com.hackemist.SDWebImageCache.default
3、哈希
散列算法就是一種以較短的信息來(lái)保證文件唯一性的標(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í)回收，通過(guò)copy操作可以使其在堆中保留一份, 相當(dāng)于一直強(qiáng)引用著）:
???? 1.被執(zhí)行copy方法
???? 2.作為 方法返回值
???? 3.將Block賦值給附有__strong修飾符的id類(lèi)型的類(lèi)或者Blcok類(lèi)型成員變量時(shí)
???? 4.在方法名中含有usingBlock的Cocoa框架方法或者GDC的API中傳遞的時(shí)候.
6、SEL和IMP區(qū)別Class
SEL : 類(lèi)成員方法的指針，但不同于C語(yǔ)言中的函數(shù)指針，函數(shù)指針直接保存了方法的地址，但SEL只是方法編號(hào)。
IMP:一個(gè)函數(shù)指針,保存了方法的地址
也就是說(shuō)方法編號(hào)SEL最后還是要通過(guò)Dispatch table表尋找到對(duì)應(yīng)的IMP，IMP就是一個(gè)函數(shù)指針，然后執(zhí)行這個(gè)方法
類(lèi)在 Objective-C 也為我們準(zhǔn)備了類(lèi)似的機(jī)制, Class 類(lèi)型。當(dāng)一個(gè)類(lèi)被正確的編譯過(guò)后,在這個(gè)編譯成功的類(lèi)里面,存在一個(gè)變量用于保存這 個(gè)類(lèi)的信息。我們可以通過(guò)一個(gè)普通的字符串取得 這個(gè) Class,也可以通過(guò)我們生成的對(duì)象取 得這個(gè) Class。Class 被成功取得之后,我們可以把這個(gè) Class 當(dāng)作一個(gè)已經(jīng)定義好的類(lèi)來(lái)使用 它。這樣的機(jī)制允許我們?cè)诔绦驁?zhí)行的過(guò)程當(dāng)中,可以 Class 來(lái)得到對(duì)象的類(lèi),也可以在程序 執(zhí)行的階段動(dòng)態(tài)的生成一個(gè)在編譯階段無(wú)法確定的一個(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í)行完后到此來(lái)執(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è)異常處理例程來(lái)保護(hù)代碼，該處理例程會(huì)在異常拋出的時(shí)候自動(dòng)的釋放互斥鎖。所以如果不想讓隱式的異常處理例程帶來(lái)額外的開(kāi)銷(xiāo)，你可以考慮使用鎖對(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 開(kāi)始");
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用來(lái)同步的一種方式，與他相關(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類(lèi)型且值為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í)行下面的語(yǔ)句，并且將信號(hào)量的值減1；如果desema的值為0，那么這個(gè)函數(shù)就阻塞當(dāng)前線程等待timeout（注意timeout的類(lèi)型為dispatch_time_t，不能直接傳入整形或float型數(shù)），如果等待的期間desema的值被dispatch_semaphore_signal函數(shù)加1了，且該函數(shù)（即dispatch_semaphore_wait）所處線程獲得了信號(hào)量，那么就繼續(xù)向下執(zhí)行并將信號(hào)量減1。如果等待期間沒(méi)有獲取到信號(hào)量或者信號(hào)量的值一直為0，那么等到timeout時(shí)，其所處線程自動(dòng)執(zhí)行其后語(yǔ)句。
dispatch_semaphore
是信號(hào)量，但當(dāng)信號(hào)總量設(shè)為 1 時(shí)也可以當(dāng)作鎖來(lái)。在沒(méi)有等待情況出現(xiàn)時(shí)，它的性能比 pthread_mutex
還要高，但一旦有等待情況出現(xiàn)時(shí)，性能就會(huì)下降許多。相對(duì)于 OSSpinLock 來(lái)說(shuō)，它的優(yōu)勢(shì)在于等待時(shí)不會(huì)消耗 CPU 資源。
如上的代碼，如果超時(shí)時(shí)間overTime設(shè)置成>2，可完成同步操作。如果overTime<2的話，在線程1還沒(méi)有執(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ì)去加一次鎖，而從第二次開(kāi)始，由于鎖已經(jīng)被使用了且沒(méi)有解鎖，所以它需要等待鎖被解除，這樣就導(dǎo)致了死鎖，線程被阻塞住了。
在這種情況下，我們就可以使用NSRecursiveLock。它可以允許同一線程多次加鎖，而不會(huì)造成死鎖。如果我們將NSLock代替為NSRecursiveLock，上面代碼則會(huì)正確執(zhí)行。
5、NSConditionLock條件鎖
當(dāng)我們?cè)谑褂枚嗑€程的時(shí)候，有時(shí)一把只會(huì)lock和unlock的鎖未必就能完全滿足我們的使用。因?yàn)槠胀ǖ逆i只能關(guān)心鎖與不鎖，而不在乎用什么鑰匙才能開(kāi)鎖，而我們?cè)谔幚碣Y源共享的時(shí)候，多數(shù)情況是只有滿足一定條件的情況下才能打開(kāi)這把鎖
6、OSSpinLock
OSSpinLock 自旋鎖，性能最高的鎖。原理很簡(jiǎn)單，就是一直 do while 忙等。它的缺點(diǎn)是當(dāng)?shù)却龝r(shí)會(huì)消耗大量 CPU 資源，所以它不適用于較長(zhǎng)時(shí)間的任務(wù)。 不過(guò)最近YY大神在自己的博客不再安全的 OSSpinLock中說(shuō)明了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
