神奇的 BlocksKit(1):源码分析(下)

私有类 _BKObserver

_BKObserver 是用来观测属性的对象,它在接口中定义了 4 个属性:

@property (nonatomic,readonly,unsafe_unretained) id observee;

@property (nonatomic,readonly) NSMutableArray *keyPaths;

@property (nonatomic,readonly) id task;

@property (nonatomic,readonly) BKObserverContext context;

上面四个属性的具体作用在这里不说了,上面的 bk_addObserverForKeyPaths:identifier:options:context: 方法中调用_BKObserver 的初始化方法 initWithObservee:keyPaths:context:task: 太简单了也不说了。

_BKObserver *observer = [[_BKObserver alloc] initWithObservee:self keyPaths:keyPaths context:context task:task];

[observer startObservingWithOptions:options];

上面的第一行代码生成一个 observer 实例之后立刻调用了 startObservingWithOptions: 方法开始观测对应的 keyPath:

- (void)startObservingWithOptions:(NSKeyValueObservingOptions)options

{

@synchronized(self) {

if (_isObserving) return;

#1:遍历 keyPaths 实现 KVO

_isObserving = YES;

}

}

startObservingWithOptions: 方法最重要的就是第 #1 部分:

[self.keyPaths bk_each:^(NSString *keyPath) {

[self.observee addObserver:self forKeyPath:keyPath options:options context:BKBlockObservationContext];

}];

遍历自己的 keyPaths 然后让 _BKObserver 作观察者观察自己,然后传入对应的 keyPath。

关于 _stopObservingLocked 方法的实现也十分的相似,这里就不说了。

[keyPaths bk_each:^(NSString *keyPath) {

[observee removeObserver:self forKeyPath:keyPath context:BKBlockObservationContext];

}];

到目前为止,我们还没有看到实现 KVO 所必须的方法 observeValueForKeyPath:ofObject:change:context,这个方法就是每次属性改变之后的回调:

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context

{

if (context != BKBlockObservationContext) return;

@synchronized(self) {

switch (self.context) {

case BKObserverContextKey: {

void (^task)(id) = self.task;

task(object);

break;

}

case BKObserverContextKeyWithChange: {

void (^task)(id,NSDictionary *) = self.task;

task(object,change);

break;

}

case BKObserverContextManyKeys: {

void (^task)(id,NSString *) = self.task;

task(object,keyPath);

break;

}

case BKObserverContextManyKeysWithChange: {

void (^task)(id,NSString *,NSDictionary *) = self.task;

task(object,keyPath,change);

break;

}

}

}

}

这个方法的实现也很简单,根据传入的 context 值,对 task 类型转换,并传入具体的值。

这个模块倒着就介绍完了,在下一节会介绍 BlocksKit 对 UIKit 组件一些简单的改造。

改造 UIKit

在这个小结会具体介绍 BlocksKit 是如何对一些简单的控件进行改造的,本节大约有两部分内容:

  • UIGestureRecongizer + UIBarButtonItem + UIControl
  • UIView

改造 UIGestureRecongizer,UIBarButtonItem 和 UIControl

先来看一个 UITapGestureRecognizer 使用的例子

UITapGestureRecognizer *singleTap = [UITapGestureRecognizer bk_recognizerWithHandler:^(id sender) {

NSLog(@"Single tap.");

} delay:0.18];

[self addGestureRecognizer:singleTap];

代码中的 bk_recognizerWithHandler:delay: 方法在最后都会调用初始化方法 bk_initWithHandler:delay: 生成一个UIGestureRecongizer 的实例

- (instancetype)bk_initWithHandler:(void (^)(UIGestureRecognizer *sender,UIGestureRecognizerState state,CGPoint location))block delay:(NSTimeInterval)delay

{

self = [self initWithTarget:self action:@selector(bk_handleAction:)];

if (!self) return nil;

self.bk_handler = block;

self.bk_handlerDelay = delay;

return self;

}

它会在这个方法中传入 target 和 selector。 其中 target 就是 self,而 selector 也会在这个分类中实现:

- (void)bk_handleAction:(UIGestureRecognizer *)recognizer

{

void (^handler)(UIGestureRecognizer *sender,UIGestureRecognizerState state,CGPoint location) = recognizer.bk_handler;

if (!handler) return;

NSTimeInterval delay = self.bk_handlerDelay;

#1: 封装 block 并控制 block 是否可以执行

self.bk_shouldHandleAction = YES;

[NSObject bk_performAfterDelay:delay usingBlock:block];

}

因为在初始化方法 bk_initWithHandler:delay: 中保存了当前手势的 bk_handler,所以直接调用在 Block Execution 一节中提到过的 bk_performAfterDelay:usingBlock: 方法,将 block 派发到指定的队列中,最终完成对 block 的调用。

封装 block 并控制 block 是否可以执行

这部分代码和前面的部分有些相似,因为这里也用到了一个属性 bk_shouldHandleAction 来控制 block 是否会被执行:

CGPoint location = [self locationInView:self.view];

void (^block)(void) = ^{

if (!self.bk_shouldHandleAction) return;

handler(self,self.state,location);

};

同样 UIBarButtonItem 和 UIControl 也是用了几乎相同的机制,把 target 设置为 self,让后在分类的方法中调用指定的 block。

UIControlWrapper

稍微有些不同的是 UIControl。因为 UIControl 有多种 UIControlEvents,所以使用另一个类 BKControlWrapper 来封装handler 和 controlEvents

@property (nonatomic) UIControlEvents controlEvents;

@property (nonatomic,copy) void (^handler)(id sender);

其中 UIControlWrapper 对象以 {controlEvents,wrapper} 的形式作为 UIControl 的属性存入字典。

改造 UIView

因为在上面已经改造过了 UIGestureRecognizer,在这里改造 UIView 就变得很容易了:

- (void)bk_whenTouches:(NSUInteger)numberOfTouches tapped:(NSUInteger)numberOfTaps handler:(void (^)(void))block

{

if (!block) return;

UITapGestureRecognizer *gesture = [UITapGestureRecognizer bk_recognizerWithHandler:^(UIGestureRecognizer *sender,UIGestureRecognizerState state,CGPoint location) {

if (state == UIGestureRecognizerStateRecognized) block();

}];

gesture.numberOfTouchesRequired = numberOfTouches;

gesture.numberOfTapsRequired = numberOfTaps;

[self.gestureRecognizers enumerateObjectsUsingBlock:^(id obj,NSUInteger idx,BOOL *stop) {

if (![obj isKindOfClass:[UITapGestureRecognizer class]]) return;

UITapGestureRecognizer *tap = obj;

BOOL rightTouches = (tap.numberOfTouchesRequired == numberOfTouches);

BOOL rightTaps = (tap.numberOfTapsRequired == numberOfTaps);

if (rightTouches && rightTaps) {

[gesture requireGestureRecognizerToFail:tap];

}

}];

[self addGestureRecognizer:gesture];

}

UIView 分类只有这一个核心方法,其它的方法都是向这个方法传入不同的参数,这里需要注意的就是。它会遍历所有的gestureRecognizers,然后把对所有有冲突的手势调用 requireGestureRecognizerToFail: 方法,保证添加的手势能够正常的执行。

时间: 2024-11-05 19:44:40

神奇的 BlocksKit(1):源码分析(下)的相关文章

Hadoop-2.4.1学习之Map任务源码分析(下)

在Map任务源码分析(上)中,对MAP阶段的代码进行了学习,这篇文章文章将学习Map任务的SORT阶段.如果Reducer的数量不为0,则还需要进行SORT阶段,但从上面的学习中并未发现与MAP阶段执行完毕调用mapPhase.complete()类似的在SORT阶段执行完毕调用sortPhase.complete()的源码,那SORT阶段是在什么时候启动的?对于Map任务来说,有输入就有输出,输入由RecordReader负责,输出则由RecordWriter负责,当Reducer的数量不为0

知识小罐头09(tomcat8启动源码分析 下)

初始化已经完成,现在就是启动这些组件,Tomcat中的start方法就是用于启动的,其实start的原理还是和上一篇说的初始化几乎一样!这里我就大概说一下,看几个比较关键的地方就行了. 前面的步骤就大概截图看一下就ok了 ok,由于前面这些东西基本和初始化的流程一样,跳过,我们就从启动service开始看: 其实关键就是这三步,启动引擎,监听器和连接器,我们好好看看这三步其中的原理. 1.启动引擎 engine.start()方法其实就是到StandardEngine中startInternal

memcached学习笔记——存储命令源码分析上

原创文章,转载请标明,谢谢. 上一篇分析过memcached的连接模型,了解memcached是如何高效处理客户端连接,这一篇分析memcached源码中的process_update_command函数,探究memcached客户端的set命令,解读memcached是如何解析客户端文本命令,剖析memcached的内存管理,LRU算法是如何工作等等. 解析客户端文本命令 客户端向memcached server发出set操作,memcached server读取客户端的命令,客户端的连接状态

Windows平台下源码分析工具

最近这段时间在阅读 RTKLIB的源代码,目前是将 pntpos.c文件的部分看完了,准备写一份文档记录下这些代码的用处.处理过程.理论公式来源.注意事项,自己还没有弄明白的地方.目前的想法是把每一个函数都做成一个名片,这个名片内则包含代码的功能说明.参数说明.函数调用关系图.整体处理过程.注意事项和自己的疑惑这几个部分.而在这个名片内出现的其他函数(包括在文字和调用关系图中出现的)则使用超链接链接到其他函数名片内.然而我并不想自己去手工绘制函数调用关系图,于是就百度了一下,这才发现关于接口文档

Hadoop之HDFS原理及文件上传下载源码分析(下)

上篇Hadoop之HDFS原理及文件上传下载源码分析(上)楼主主要介绍了hdfs原理及FileSystem的初始化源码解析, Client如何与NameNode建立RPC通信.本篇将继续介绍hdfs文件上传.下载源解析. 文件上传 先上文件上传的方法调用过程时序图: 其主要执行过程: FileSystem初始化,Client拿到NameNodeRpcServer代理对象,建立与NameNode的RPC通信(楼主上篇已经介绍过了) 调用FileSystem的create()方法,由于实现类为Dis

Android4.42-Setting源码分析之蓝牙模块Bluetooth(下)

接着上一篇Android4.42-Settings源码分析之蓝牙模块Bluetooth(上) 继续蓝牙模块源码的研究 THREE,蓝牙模块功能实现 switch的分析以及本机蓝牙重命名和可见性的分析见上一篇,接下来进行第三章第三部分的介绍:关于蓝牙远程设备列表的加载.如果没有看过,建议看看上一篇关第一章蓝牙的布局,有助于理解 3>,设备列表的加载 因为这部分代码很多,所以在介绍时先说一下思路,程序首先通过底层的BluetoothAdapter的getBondedDevices()方法获取到已配对

Tomcat源码分析——请求原理分析(下)

前言 本文继续讲解TOMCAT的请求原理分析,建议朋友们阅读本文时首先阅读过<TOMCAT源码分析——请求原理分析(上)>和<TOMCAT源码分析——请求原理分析(中)>.在<TOMCAT源码分析——请求原理分析(中)>一文我简单讲到了Pipeline,但并未完全展开,本文将从Pipeline开始讲解请求原理的剩余内容. 管道 在Tomcat中管道Pipeline是一个接口,定义了使得一组阀门Valve按照顺序执行的规范,Pipeline中定义的接口如下: getBas

Android中将xml布局文件转化为View树的过程分析(下)-- LayoutInflater源码分析

在Android开发中为了inflate一个布局文件,大体有2种方式,如下所示: // 1. get a instance of LayoutInflater, then do whatever you want LayoutInflater inflater = (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE); // 2. you're in some View class, then jus

SURF算法与源码分析、下

上一篇文章 SURF算法与源码分析.上 中主要分析的是SURF特征点定位的算法原理与相关OpenCV中的源码分析,这篇文章接着上篇文章对已经定位到的SURF特征点进行特征描述.这一步至关重要,这是SURF特征点匹配的基础.总体来说算法思路和SIFT相似,只是每一步都做了不同程度的近似与简化,提高了效率. 1. SURF特征点方向分配 为了保证特征矢量具有旋转不变性,与SIFT特征一样,需要对每个特征点分配一个主方向.为些,我们需要以特征点为中心,以$6s$($s = 1.2 *L /9$为特征点

Docker源码分析(八):Docker Container网络(下)

1.Docker Client配置容器网络模式 Docker目前支持4种网络模式,分别是bridge.host.container.none,Docker开发者可以根据自己的需求来确定最适合自己应用场景的网络模式. 从Docker Container网络创建流程图中可以看到,创建流程第一个涉及的Docker模块即为Docker Client.当然,这也十分好理解,毕竟Docker Container网络环境的创建需要由用户发起,用户根据自身对容器的需求,选择网络模式,并将其通过Docker Cl