CYLDeallocBlockExecutor【你好 block,再见 dealloc】
Hello block,byebye dealloc!一行代码代替 dealloc 完成自我管理
导航
与其他框架的区别
- | 特点 | 说明 |
---|---|---|
1 | 轻量级、无污染 | 基于 NSObject 分类,无污染,适用于任何 Objective-C 对象,比基于子类化、继承的框架更加轻量级 |
2 | 高性能 | 使用 runtime 的对象关联(或称为关联引用)技术,随着关联对象的 dealloc,对应的 block 自发执行,性能消耗极低。 |
3 | 简单,无学习成本 | 只需一行代码即可完成,只需用 cyl_willDeallocWithSelfCallback: 中的 block 替换 dealloc 即可。系统将自动检测对象释放时机并执行 block。 |
4 | 将分散的代码集中起来 | 你可以使用 CYLDeallocBlockExecutor 将 KVO 或 NSNotificationCenter 的 addObserver 和 removeObserver 操作集中在一起,使代码更直观,易于维护。demo 中也提供了相应的使用方法。 |
5 | 支持CocoaPods | 简单易集成 |
(学习交流群:523070828)
CYLDeallocBlockExecutor
使用三步完成:
第一步:使用CocoaPods导入CYLDeallocBlockExecutor
在 Podfile
中进行如下导入:
pod 'CYLDeallocBlockExecutor'
然后使用 cocoaPods
进行安装:
如果尚未安装 CocoaPods, 运行以下命令进行安装
gem install cocoapods
安装成功后就可以安装依赖了:
建议使用如下方式:
# 禁止升级CocoaPods的spec仓库,否则会卡在 Analyzing dependencies ,非常慢
pod update --verbose --no-repo-update
如果提示找不到库,则可去掉 --no-repo-update
pod update
第二步:导入头文件
导入头文件:
#import "CYLDeallocBlockExecutor.h"
使用方法:
一行代码代替 dealloc:
[foo cyl_willDeallocWithSelfCallback:^(__unsafe_unretained id owner, NSUInteger identifier) {
// do something
}];
注意:在 cyl_willDeallocWithSelfCallback
的参数 block 中不能使用 weak 修饰符修饰的 self,因为 weak 变量在 dealloc 中会被自动置为 nil。使用 cyl_willDeallocWithSelfCallback
需要遵循以下原则:
参数 block 中的内容可以完全放入 dealloc。
因为该 block 就是在 dealloc 执行时执行的!
[self cyl_willDeallocWithSelfCallback:^(__unsafe_unretained id owner, NSUInteger identifier) {
[[NSNotificationCenter defaultCenter] removeObserver:owner];
}];
第三步
没有第三步!
运行Demo
示例 Demo 展示了一个自动换皮肤的功能,
在 demo 中我们使用了 UIView 的一个分类来管理皮肤,并在分类中设置了皮肤主题属性,并使用通知进行换皮肤操作,所有的 addObserver
和 removeObserver
操作都在皮肤属性的 setter 方法中实现。
运行好 demo 后,请点击设备屏幕,会触发换主题(背景)的事件。
应用场景
管理KVO与NSNotificationCenter的removeObserver操作
在KVO、NSNotificationCenter在addObserver后,都需要在dealloc方法中进行removeObserver操作,一方面代码分散,不易维护,
另一方面如果想在分类中使用KVO、NSNotificationCenter,而你又想在dealloc中进行removeObserver操作,那应该怎么办?
答:你需要借助CYLDeallocBlockExecutor!
Demo中给出一个换皮肤的Demo,演示:
所有的操作全部都在Setter方法中进行,无需借助Dealloc方法。
- (void)setThemeMap:(NSDictionary *)themeMap {
objc_setAssociatedObject(self, &kUIView_ThemeMap, themeMap, OBJC_ASSOCIATION_COPY_NONATOMIC);
if (themeMap) {
// Need to removeObserver in dealloc
// NOTE: need to be __unsafe_unretained because __weak var will be reset to nil in dealloc
[self cyl_willDeallocWithSelfCallback:^(__unsafe_unretained id weakSelf, NSUInteger identifier) {
[[NSNotificationCenter defaultCenter] removeObserver:weakSelf];
}];
[[NSNotificationCenter defaultCenter] removeObserver:self
name:kThemeDidChangeNotification
object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(themeChanged:)
name:kThemeDidChangeNotification
object:nil
];
[self themeChangedWithDict:themeMap];
} else {
[[NSNotificationCenter defaultCenter] removeObserver:self
name:kThemeDidChangeNotification
object:nil];
}
}
对应的时序图如下所示:
直接从看图里的第8步骤开始看:CYLDeallocBlockExecutor所起作用的地方从第8步骤开始。
模拟weak修饰的property的生命周期
我曾经在我的一篇博文中使用过类似的策略:
下面做下简要叙述:
我们都知道@property的weak属性:
weak此特质表明该属性定义了一种“非拥有关系”(nonowning relationship)。为这种属性设置新值时,设置方法既不保留新值,也不释放旧值。此特质同assign类似,然而在属性所指的对象遭到摧毁时,属性值也会清空(nil out)。
那么如何让不使用weak修饰的@property,拥有weak的效果?
代码如下所示:
- (void)setObject:(NSObject *)object
{
objc_setAssociatedObject(self, "object", object, OBJC_ASSOCIATION_ASSIGN);
[object cyl_willDeallocWithSelfCallback:^(__unsafe_unretained id owner, NSUInteger identifier) {
owner = nil;
}];
}
这样就达到了当object为nil时,自动将self.object置nil的目的,从而就模拟了weak修饰的property的生命周期。
更加安全地在viewDidLoad里管理应用的生命周期
在我的一个框架CYLTabBarController中,有一个KVO注册与反注册的实现:
- (void)viewDidLoad {
[super viewDidLoad];
// 处理tabBar,使用自定义 tabBar 添加 发布按钮
[self setUpTabBar];
// KVO注册监听
if (!self.isObservingSwappableImageViewDefaultOffset) {
[self.tabBar addObserver:self forKeyPath:@"swappableImageViewDefaultOffset" options:NSKeyValueObservingOptionNew context:CYLSwappableImageViewDefaultOffsetContext];
self.observingSwappableImageViewDefaultOffset = YES;
}
self.delegate = self;
}
- (void)dealloc {
// KVO反注册
if (self.isObservingSwappableImageViewDefaultOffset) {
[self.tabBar removeObserver:self forKeyPath:@"swappableImageViewDefaultOffset"];
}
}
也许你会很奇怪为什么有一个flag在做判断,那是因为viewDidLoad在一些场景下没有被调用,但dealloc却被调用了。。。什么场景?当CYLTabBarController被作为StoryBoard的初始控制器,但是你又重写了下面的方法:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
if (!self.isUserLogin) {
LoginViewController *login = [[UIStoryboard storyboardWithName:@"Main" bundle:nil] instantiateViewControllerWithIdentifier:@"LoginViewController"];
self.window.rootViewController = login;
}
return YES;
}
Demo我已经放在仓库里,叫做CYLTabBarControllerTestDemo,CYLTabBarController版本1.5.5及之前的版本因为没有flag判断,直接会crash掉。这种场景下我这里采用了flag来规避,其实也可以用CYLDeallocBlockExecutor来达到目的。在viewDidLoad做dealloc该做的事,即使viewDidLoad没有被调用,也没有关系,block里的内容也不会被执行。
同时,如果用KVO监听iVar,如果由于不能确定iVar是否为nil,那么你就可以做出判断,只在有值时监听。同时,释放KVO的行为,就可以借助本库,放在这个是否有值的判断里。这样就达到了只在有值时监听,同时在self销毁时释放的效果。
(更多iOS开发干货,欢迎关注微博@iOS程序猿)
由微博@iOS程序猿发布
原创文章,版权声明:自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0