- 系統(tǒng)的UI事件傳遞機(jī)制是怎么樣的 ?
- 使UITableView滾動(dòng)更流暢的方案或思路都有哪些 ?
- 什么是離屏渲染 ?
- UIView和CALayer之間的關(guān)系是怎樣的 ?
如果不是很清楚浊竟，請(qǐng)往下看
會(huì)講解的內(nèi)容
- UITableView相關(guān)
- 事件傳遞&視圖響應(yīng) (一)
- 圖像顯示原理
- 卡頓&掉幀
- 繪制原理&異步繪制
- 離屏渲染 (二)
UITableView相關(guān)
- 重用機(jī)制
- 數(shù)據(jù)源同步
重用機(jī)制
這里A1到A7視為同一個(gè)標(biāo)識(shí)符绿聘，虛線是可視區(qū)域，當(dāng)A1滑出可視區(qū)域的時(shí)候會(huì)放入重用池A，A7根據(jù)標(biāo)識(shí)符從備用池取出一個(gè)可重用的cell，這樣就達(dá)到了重用的一個(gè)目的
數(shù)據(jù)源同步
如何解決tableView在多線程的情況下修改或者訪問(wèn)數(shù)據(jù)源的一個(gè)同步問(wèn)題?
-- 倆個(gè)解決方案
- 并發(fā)訪問(wèn) & 數(shù)據(jù)拷貝
- 串行訪問(wèn)
并發(fā)訪問(wèn) & 數(shù)據(jù)拷貝
上圖中,一般做數(shù)據(jù)拷貝在主線程當(dāng)中，拷貝之后會(huì)把拷貝的結(jié)果給子線程使用,同時(shí)在子線程中做新數(shù)據(jù)的網(wǎng)絡(luò)請(qǐng)求，數(shù)據(jù)解析。
主線程在子線程請(qǐng)求數(shù)據(jù)的時(shí)候刪除了一條數(shù)據(jù)更米，然后reloadUI
子線程在完成一系列操作之后，返回請(qǐng)求的結(jié)果毫痕，然后reloadUI征峦。
這個(gè)時(shí)候問(wèn)題就出現(xiàn)了，子線程的拷貝發(fā)生在主線程刪除一條數(shù)據(jù)之前消请，所以子線程在返回給主線程的數(shù)據(jù)源列表中還包括了主線程刪除的那條數(shù)據(jù)栏笆，導(dǎo)致數(shù)據(jù)異常.
怎么解決這種數(shù)據(jù)源的同步問(wèn)題呢? 往下看
我們可以在主線程進(jìn)行刪除操作的時(shí)候把它記錄下來(lái)，在子線程中將要返回?cái)?shù)據(jù)更新主線程UI的時(shí)候同步刪除操作臊泰。這就是并發(fā)訪問(wèn)的解決方案
串行隊(duì)列
串行訪問(wèn),這個(gè)時(shí)候要用到GCD中的串行隊(duì)列
子線程做網(wǎng)絡(luò)請(qǐng)求,數(shù)據(jù)解析后數(shù)據(jù)放到串行隊(duì)列中做預(yù)排版(都是在子線程當(dāng)中完成). 在這個(gè)過(guò)程中如果在主線程中刪除了一條數(shù)據(jù),需要以同步的方式在串行隊(duì)列中處理, 在上個(gè)任務(wù)數(shù)據(jù)排版完成之后再同步數(shù)據(jù)刪除蛉加，然后再回到主線程更新UI，這樣可以保證無(wú)論在主線程或者子線程都是在串行隊(duì)列上進(jìn)行操作的缸逃，避免數(shù)據(jù)源的錯(cuò)亂問(wèn)題针饥。
倆種方案各有利弊，具體視項(xiàng)目實(shí)際業(yè)務(wù)而定需频。
這里多提一下,隊(duì)列和線程的關(guān)系,在iOS 開發(fā)中除了一個(gè)特殊情況（主隊(duì)列和主線程的關(guān)系）丁眼，它二者之間是相互獨(dú)立的，其實(shí)只要記住一個(gè)要點(diǎn)就可以了昭殉，主隊(duì)列是一個(gè)特殊的隊(duì)列苞七，首先藐守，它是一個(gè)串行隊(duì)列，其次莽鸭，它自始至終占用一個(gè)特殊的線程--主線程吗伤，而主線程，自始至終僅被主隊(duì)列占用硫眨，其他任何隊(duì)列，不管并行還是串行巢块，都不能占用主線程礁阁，除去這個(gè)奇葩之外，任意隊(duì)列不管是系統(tǒng)的還是自建的族奢，不管是串行還是并行的姥闭，所有跑在這些隊(duì)列上的線程都是子線程，都不能用來(lái)刷新UI
事件傳遞&視圖響應(yīng)
CALayer 與 UIView 關(guān)系
UIView 為CALayer提供內(nèi)容越走，專門負(fù)責(zé)處理觸摸等時(shí)間棚品，參與響應(yīng)鏈
CALayer 全權(quán)負(fù)責(zé)顯示內(nèi)容 contents
這里用到了六大設(shè)計(jì)原則之中的單一職責(zé)原則，這就是為什么要區(qū)分UIView 和 CALayer 之間的工作分工.
事件傳遞機(jī)制
基本上是一個(gè)必考點(diǎn)廊敌，事件傳遞與倆個(gè)方法有關(guān)
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
//返回最終響應(yīng)的事件
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
//判斷點(diǎn)擊位置是否在當(dāng)前范圍內(nèi)
在看事件傳遞機(jī)制之前铜跑，先看一下 hitTest 的內(nèi)部方法實(shí)現(xiàn)，看下圖
首先判斷當(dāng)前視圖 !hidden &$ userInteractionEnable && alpha > 0.01 條件通過(guò)的時(shí)候骡澈，到下一步. 否則返回nil锅纺，找不到當(dāng)前視圖
通過(guò) pointInside 判斷點(diǎn)擊的點(diǎn)是否在當(dāng)前范圍內(nèi)，為YES直接下一步. 不在則直接返回nil肋殴。
倒序遍歷所有子視圖囤锉，同時(shí)調(diào)用 hitTest 方法，如果某一個(gè)子視圖返回了對(duì)應(yīng)的響應(yīng)視圖护锤，這個(gè)子視圖會(huì)直接作為最終的響應(yīng)視圖給響應(yīng)方官地，如果為 nil 則繼續(xù)遍歷下一個(gè)子視圖。如果全部遍歷結(jié)束都返回nil烙懦，那會(huì)返回當(dāng)前點(diǎn)擊位置在當(dāng)前的視圖范圍內(nèi)的視圖作為最終響應(yīng)視圖.......
當(dāng)我們點(diǎn)擊屏幕時(shí)候的事件傳遞
UIApplication -> UIWindow -> hitTest:withEvent:
深入了解驱入，做一個(gè)Demo，一個(gè)方形按鈕,控制只在點(diǎn)擊圓內(nèi)的時(shí)候才響應(yīng)點(diǎn)擊事件,源碼看這里(PPEventDemo)
視圖響應(yīng)鏈(注意和事件傳遞是倆概念)
看一下官方的一張圖修陡，一目了然
UIResponder 主要有三個(gè)方法
-(void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
-(void)touchesMoved:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
-(void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
提問(wèn),下圖中點(diǎn)擊空白圓點(diǎn)沧侥，視圖響應(yīng)順序是什么？如果最后傳遞到UIApplicationDelegate 依然沒(méi)有響應(yīng)魄鸦，會(huì)發(fā)生什么?
正確順序是 C2 -> B2 -> A
到 UIApplicationDelegate 依然沒(méi)有任何視圖處理該事件的時(shí)候宴杀，直接忽略此事件， 并不會(huì)崩潰拾因。
