UITableView 手勢延遲導致subview無法完成兩次繪制

問題:
在UITableViewCell 中點擊自定義View 本來想在touchesBegan和touchesEnd中各觸發(fā)一次繪制來模擬點擊高亮的效果薄霜,但只要是快速點擊就無法觸發(fā)高亮效果,從而探究原因。

解釋:
UIScrollView 中默認情況下對TouchesBegan進行了延遲(150ms)用于判斷是否進行滑動如果滑動就不將事件傳遞給子view特恬;由于延遲導致如果點擊過快舆逃,這時候touchesBegan 和 touchesEnd就緊接著發(fā)生。
如果是在touchesBegan和touchesEnd里面都進行了 setNeedsDisplay 操作背捌,標記需要繪制毙籽;而兩次的間隔時間極小,導致Runloop 只執(zhí)行一次繪制毡庆。換句話說同時標記了兩次只有一次標記繪制生效坑赡。

iOS 的屏幕刷新為60FPS烙如,也就是最多每秒發(fā)生60次的繪制。 每一幀間隔就是 1000 ms / 60 = 16.66 ms 毅否,當兩次的繪制的間隔少于16.6毫秒時無法完成兩次繪制只會觸發(fā)一次繪制亚铁。

探究:
打印tableview默認手勢

 for(UIGestureRecognizer *gestureRecognizer in self.tableView.gestureRecognizers) {
      NSLog(@"%@",gestureRecognizer);
 }

如下:

2016-05-19 22:46:29.923 LabelTapDemo[64833:5081332] <UIScrollViewDelayedTouchesBeganGestureRecognizer: 0x7f94e37a2360; state = Possible; delaysTouchesBegan = YES; view = <MyTableView 0x7f94e5033200>; target= <(action=delayed:, target=<MyTableView 0x7f94e5033200>)>>
2016-05-19 22:46:29.924 LabelTapDemo[64833:5081332] <UIScrollViewPanGestureRecognizer: 0x7f94e3452160; state = Possible; delaysTouchesEnded = NO; view = <MyTableView 0x7f94e5033200>; target= <(action=handlePan:, target=<MyTableView 0x7f94e5033200>)>>

可以看到一個UIScrollViewDelayedTouchesBeganGestureRecognizer,這個是私有的手勢螟加,在UIKit庫中可以看到徘溢,查看一下頭文件定義
https://github.com/nst/iOS-Runtime-Headers/blob/master/Frameworks/UIKit.framework/UIScrollViewDelayedTouchesBeganGestureRecognizer.h

@interface UIScrollViewDelayedTouchesBeganGestureRecognizer : UIGestureRecognizer {
    struct CGPoint {
        float x;
        float y;
    } _startSceneReferenceLocation;
    UIDelayedAction *_touchDelay;
}

- (void).cxx_destruct;
- (void)_resetGestureRecognizer;
- (void)clearTimer;
- (void)dealloc;
- (void)sendDelayedTouches;
- (void)sendTouchesShouldBeginForDelayedTouches:(id)arg1;
- (void)sendTouchesShouldBeginForTouches:(id)arg1 withEvent:(id)arg2;
- (void)touchesBegan:(id)arg1 withEvent:(id)arg2;
- (void)touchesCancelled:(id)arg1 withEvent:(id)arg2;
- (void)touchesEnded:(id)arg1 withEvent:(id)arg2;
- (void)touchesMoved:(id)arg1 withEvent:(id)arg2;

@end

其中關于手勢延遲的處理UIDelayedAction 由這個類實現(是從名字猜想),再找這個UIDelayedAction 看看,在下面
https://github.com/nst/iOS-Runtime-Headers/blob/master/Frameworks/UIKit.framework/UIDelayedAction.h

@interface UIDelayedAction : NSObject {
    SEL m_action;
    BOOL m_canceled;
    double m_delay;
    NSString *m_runLoopMode;
    NSDate *m_startDate;
    id m_target;
    NSTimer *m_timer;
    id m_userInfo;
}

@property (readonly) BOOL _canceled;
@property (readonly) NSDate *_startDate;
@property (retain) id target;
@property (retain) id userInfo;

- (void).cxx_destruct;
- (BOOL)_canceled;
- (id)_startDate;
- (void)cancel;
- (void)dealloc;
- (double)delay;
- (id)init;
- (id)initWithTarget:(id)arg1 action:(SEL)arg2 userInfo:(id)arg3 delay:(double)arg4;
- (id)initWithTarget:(id)arg1 action:(SEL)arg2 userInfo:(id)arg3 delay:(double)arg4 mode:(id)arg5;
- (BOOL)scheduled;
- (void)setTarget:(id)arg1;
- (void)setUserInfo:(id)arg1;
- (id)target;
- (void)timerFired:(id)arg1;
- (void)touch;
- (void)touchWithDelay:(double)arg1;
- (void)unschedule;
- (id)userInfo;

@end

看到有個NSTimer蚓再,估計就是通過這個Timer來計時蜓陌,然后再延遲傳遞事件∈┟郏看到它的初始化方法有delay:(double)arg4 應該就是延遲多少時間了吧。
為了驗證這個猜想雌隅,想辦法hook 一下這兩個函數中的其中一個才行翻默。

@interface UIDelayedActionHook : NSObject

+ (void)hook;

- (id)hook_initWithTarget:(id)arg1 action:(SEL)arg2 userInfo:(id)arg3 delay:(double)arg4 mode:(id)arg5;

@end

@implementation UIDelayedActionHook
+ (void)hook {
    Class aClass = objc_getClass("UIDelayedAction");
    SEL sel = @selector(hook_initWithTarget:action:userInfo:delay:mode:);
    // 為UIDelayedAction增加函數
    class_addMethod(aClass, sel, class_getMethodImplementation([self class], sel), "v@:@@");
    // 交換實現
    exchangeMethod(aClass, @selector(initWithTarget:action:userInfo:delay:mode:), sel);
}

- (id)hook_initWithTarget:(id)arg1 action:(SEL)arg2 userInfo:(id)arg3 delay:(double)arg4 mode:(id)arg5 {
    return [self hook_initWithTarget:arg1 action:arg2 userInfo:arg3 delay:arg4 mode:arg5];
}

void exchangeMethod(Class aClass, SEL oldSEL, SEL newSEL) {
    Method oldMethod = class_getInstanceMethod(aClass, oldSEL);
    assert(oldMethod);
    Method newMethod = class_getInstanceMethod(aClass, newSEL);
    assert(newMethod);
    method_exchangeImplementations(oldMethod, newMethod);
}

用以上代碼在啟動應用時調用 [UIDelayedActionHook hook] ; 運行。
發(fā)現會調用兩次:

QQ20160519-2.png

第一次調用不知道是干啥的恰起,長按手勢消失時間修械?

QQ20160519-4.png

第二次才是我們想要的,確實是和手勢
UIScrollViewDelayedTouchesBeganGestureRecognizer 相關的检盼;延遲時間是0.149秒肯污,也就是上面提到的150毫秒,看來確實是這樣吨枉。

我在進一步測試蹦渣,我在自定義的view(次view就是放在UITableViewCell上的)上打印touchesBegan 和 touchesEnded 的間隔時間

- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    NSLog(@"%s",__func__);
    begin = CACurrentMediaTime();
}

- (void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    NSLog(@"%s",__func__);
    end = CACurrentMediaTime();
    time = end - begin;
    printf("time: %8.2f ms\n", time * 1000);
}
QQ20160519-5.png

發(fā)現才間隔0.31ms,離16.7 ms 還差很遠呢貌亭,所以快速點擊時永遠都不會觸發(fā)兩次繪制柬唯。
也就是因為UIScrollViewDelayedTouchesBeganGestureRecognizer 把事件延遲(150ms)傳遞給自定義view,而這個時候手指都快要離開屏幕了圃庭,隨后馬上就觸發(fā)touchesEnded锄奢,所以導致間隔時間很短,無法完成兩次繪制剧腻。

自定義view放在普通View上時拘央,touchesBegan 和 touchesEnded的時間間隔:

8E3932E4-39D8-411D-9102-65624A01D75C.png

解決辦法:
1.關閉UITableview的手勢延遲,(但這種做法不怎么好书在,因為這樣對滑動手勢有影響)
2.在自定義的view中延遲執(zhí)行繪制灰伟,相關的條件也要延遲獲取(比如:touchesEnded 中獲取點擊的point等)儒旬。

- (void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    UITouch *touch = [touches anyObject];
    double delayInSeconds = .2;
    dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(delayInSeconds * NSEC_PER_SEC));
    dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
        _endPoint = [touch locationInView:self];
        _touchPhase = touch.phase;
        [self setNeedsDisplay];
    });
}

參考資料:
http://pinka.cn/2015/06/uiwebview的scrollview和渲染機制探究/

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末袱箱,一起剝皮案震驚了整個濱河市遏乔,隨后出現的幾起案子,更是在濱河造成了極大的恐慌发笔,老刑警劉巖盟萨,帶你破解...
    沈念sama閱讀 206,013評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現場離奇詭異了讨,居然都是意外死亡捻激,警方通過查閱死者的電腦和手機,發(fā)現死者居然都...
    沈念sama閱讀 88,205評論 2 382
  • 文/潘曉璐 我一進店門前计,熙熙樓的掌柜王于貴愁眉苦臉地迎上來胞谭,“玉大人,你說我怎么就攤上這事男杈≌梢伲” “怎么了?”我有些...
    開封第一講書人閱讀 152,370評論 0 342
  • 文/不壞的土叔 我叫張陵伶棒,是天一觀的道長旺垒。 經常有香客問我,道長肤无,這世上最難降的妖魔是什么先蒋? 我笑而不...
    開封第一講書人閱讀 55,168評論 1 278
  • 正文 為了忘掉前任,我火速辦了婚禮宛渐,結果婚禮上竞漾,老公的妹妹穿的比我還像新娘。我一直安慰自己窥翩,他們只是感情好业岁,可當我...
    茶點故事閱讀 64,153評論 5 371
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著寇蚊,像睡著了一般笔时。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上幔荒,一...
    開封第一講書人閱讀 48,954評論 1 283
  • 那天,我揣著相機與錄音梳玫,去河邊找鬼爹梁。 笑死,一個胖子當著我的面吹牛提澎,可吹牛的內容都是我干的姚垃。 我是一名探鬼主播,決...
    沈念sama閱讀 38,271評論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼盼忌,長吁一口氣:“原來是場噩夢啊……” “哼积糯!你這毒婦竟也來了掂墓?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 36,916評論 0 259
  • 序言:老撾萬榮一對情侶失蹤看成,失蹤者是張志新(化名)和其女友劉穎君编,沒想到半個月后,有當地人在樹林里發(fā)現了一具尸體川慌,經...
    沈念sama閱讀 43,382評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡吃嘿,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 35,877評論 2 323
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現自己被綠了梦重。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片兑燥。...
    茶點故事閱讀 37,989評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖琴拧,靈堂內的尸體忽然破棺而出降瞳,到底是詐尸還是另有隱情,我是刑警寧澤蚓胸,帶...
    沈念sama閱讀 33,624評論 4 322
  • 正文 年R本政府宣布挣饥,位于F島的核電站,受9級特大地震影響赢织,放射性物質發(fā)生泄漏亮靴。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,209評論 3 307
  • 文/蒙蒙 一于置、第九天 我趴在偏房一處隱蔽的房頂上張望茧吊。 院中可真熱鬧,春花似錦八毯、人聲如沸搓侄。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,199評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽讶踪。三九已至,卻和暖如春泊交,著一層夾襖步出監(jiān)牢的瞬間乳讥,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,418評論 1 260
  • 我被黑心中介騙來泰國打工廓俭, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留云石,地道東北人。 一個月前我還...
    沈念sama閱讀 45,401評論 2 352
  • 正文 我出身青樓研乒,卻偏偏與公主長得像汹忠,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 42,700評論 2 345

推薦閱讀更多精彩內容

  • 好奇觸摸事件是如何從屏幕轉移到APP內的宽菜?困惑于Cell怎么突然不能點擊了谣膳?糾結于如何實現這個奇葩響應需求?亦或是...
    Lotheve閱讀 56,659評論 51 597
  • 在iOS開發(fā)中經常會涉及到觸摸事件铅乡。本想自己總結一下继谚,但是遇到了這篇文章,感覺總結的已經很到位隆判,特此轉載犬庇。作者:L...
    WQ_UESTC閱讀 5,988評論 4 26
  • 在開發(fā)過程中,大家或多或少的都會碰到令人頭疼的手勢沖突問題侨嘀,正好前兩天碰到一個類似的bug臭挽,于是借著這個機會了解了...
    閆仕偉閱讀 5,294評論 2 23
  • 手勢識別器是附加到視圖的對象,將低級別事件處理代碼轉換為更高級別的操作咬腕,它允許視圖以控件執(zhí)行的方式響應操作欢峰。 手勢...
    坤坤同學閱讀 4,062評論 0 9
  • 在iOS中隨處都可以看到絢麗的動畫效果,實現這些動畫的過程并不復雜涨共,今天將帶大家一窺iOS動畫全貌纽帖。在這里你可以看...
    F麥子閱讀 5,094評論 5 13