前言
分享iOS开发中遇到的问题,和相关的一些思考,本次内容包括:Extension、iOS9Crash、Pod库和CFDictionary相关。
正文
一、OC的Extensions特性
先看下图,这是一段Category中的代码:(SSPageControllManager+Report.h文件中)
关于蓝色框内的代码,有几个疑问:
1、是否可以放在SSPageControllManager+Report.h文件中运行并且访问声明的属性?
2、如果放在SSPageControllManager+Report.m文件呢?
3、这部分代码和SSPageControllManager.h的中的extension有什么区别?
在回复上面的疑问之前,我们先回顾下创建Extension的过程:通过Xcode的command+N新建文件,选择Objective-C File,再选择Extension;
如上,新建的是一个SSPageControllManager+Property.h文件,并且没有生成.m文件。
@interface SSPageControllManager ()
@end
对于疑问1----是否可以在SSPageControllManager+Report.h中写Extension(蓝色框的代码)并且运行时去访问声明的属性?答案是可以的,因为SSPageControllManager+Report.h是一个头文件,在头文件写Extension就是标准生成的Extension(上面的代码块);
对于疑问2----如果想在SSPageControllManager+Report.m中使用Extension,则需要手动实现getter和setter,否则实现时会因为访问不到_xx的属性而crash;
对于疑问3----Extension写在哪里的位置并不重要,核心是在于SSPageControllManager.m中要能引导到这个文件,以便于编译时SSPageControllManager.m能够自动添加对应的_xx属性。
因此,如果我们使用xx+Property.h的Extension来管理属性时,则一定要xx.m的文件中include这个头文件,否则属性无法正常初始化。比如说xx.m不引入xx+Property.h,然后在xx+report.m中去引用xx+Property.h中的属性,则会出现异常。
Extension和Category一个核心的区别,就在于能否在xx.m中去引用对应的头文件。
那么问题来了,如果我在Category的@interface代码块中声明属性,然后在.m引用对应的头文件,是否能够访问testCategoryStr
这个属性?
@interface SSPageControllManager (Report)
@property (nonatomic, strong) NSString *testCategoryStr;
@end
很遗憾,并不能。只有Extension的声明方式,并且在.m文件中引用,编译器才会自动添加_xx的属性。
不过,getter和setter还是会正常创建,所以可以通过下面的方式来“动态添加”属性。
SSPageControllManager.h如下:
@interface SSPageControllManager (SSUtil)
@property (nonatomic, strong) NSDate *ssStoreDate;
@end
SSPageControllManager.m如下:
@implementation SSPageControllManager (SSUtil)
- (NSDate *)ssStoreDate {
return objc_getAssociatedObject(self, _cmd);
}
- (void)setSsStoreDate:(NSDate *)storeDate {
objc_setAssociatedObject(self, @selector(ssStoreDate), storeDate, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}
@end
二、 iOS 9: Caught "CALayerInvalidGeometry", "sublayer with non-finite position [inf inf]"
该问题发生在对view进行截图时,截图的代码如下:
- (UIImage *)captureView:(UIView *)view {
CGRect rect = view.bounds;
UIGraphicsBeginImageContextWithOptions(rect.size, YES, 0.0f);
CGContextRef context = UIGraphicsGetCurrentContext();
CGAffineTransform transform = CGAffineTransformMake(-1.0, 0.0, 0.0, 1.0, rect.size.width, 0.0);
CGContextConcatCTM(context,transform);
[view.layer renderInContext:context];
UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return image;
}
仅在iOS9的时候,会发生CALayerInvalidGeometry
的crash。
在复现的过程发现将width设置为0,并不会触发该问题,需要view的rect为 CGRectNull
时才会触发。
self.timeLabel.frame = CGRectNull;
这行代码可以复现,且iOS12不会crash,仅在iOS9会crash;
问题修复:
问题的触发是因为在render时,存在某些view的rect为 CGRectNull
;那么可以尝试通过遍历视图树,检查是否存在异常view。
CGRectNull
判断方法:CGRectIsNull(view.frame)
。注意不是CGRectIsNull(view.bounds)
,通过frame的值来看,可以判断出来:frame = (inf inf; 0 0);
从这里可以看出,为什么前面仅仅设置width=0没有触发crash。
CGRectNull与CGRectZero不同,上面的frame可以看出。
最终修复方案是增加判断方法checkNullRect
:(如果业务需要一定返回图片,那么可以返回空,也可以将其frame设置为CGRectZero但是不合理,可能影响其他业务逻辑)
- (BOOL)checkNullRect:(UIView *)view {
BOOL ret = CGRectIsNull(view.frame);
for (UIView *subView in view.subviews) {
ret = ret || [self checkNullRect:subView];
}
if (ret) {
SSLOG_ERROR(@"zero frame, view:%@", view);
}
return ret;
}
- (UIImage *)captureView:(UIView *)view {
if ([self checkNullRect:view]) {
return nil;
}
CGRect rect = view.bounds;
UIGraphicsBeginImageContextWithOptions(rect.size, YES, 0.0f);
CGContextRef context = UIGraphicsGetCurrentContext();
CGAffineTransform transform = CGAffineTransformMake(-1.0, 0.0, 0.0, 1.0, rect.size.width, 0.0);
CGContextConcatCTM(context,transform);
[view.layer renderInContext:context];
UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return image;
}
三、Pod库相关
配置Podfile,执行pod install
之后,工程一切正常。
但是当我把LYTest.project的Build Active Architecture Only
属性设置为No之后,就出现了异常:
Target 'Pods-LYTest' of project 'Pods' was rejected as an implicit dependency for 'libPods-LYTest.a' because its architectures 'x86_64' didn't contain all required architectures 'i386x86_64'
尝试重新pod install,问题仍存在。
通过检查pod库的设置,发现是因为pod库的Build Active Architecture Only
属性在debug默认为Yes; 而LYTest.project的设置为No,所以libPods-LYTest.a中缺少了i386的architecture。
手动将pod库的Build Active Architecture Only
属性设置为No,问题可以解决。
但是在每次pod install
之后,仍需要手动修改Pod库的工程设置,总感觉应该可以通过脚本完成这个过程。
最后在StackOverflow中得到启发:
post_install do |installer_representation|
installer_representation.project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'
end
end
end
但是上面的代码插入podfile之后,会出现下面的问题:
分析代码逻辑和上面的error提示,可以发现这里的installer_representation.project修改的应该是project的设置,将其改为installer_representation.pods_project,问题得到解决。
post_install do |installer_representation|
installer_representation.pods_project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings['ONLY_ACTIVE_ARCH'] = 'NO'
end
end
end
四、CFDictionary的创建
最近对一段CFDictionary的创建代码产生好奇:
CFDictionaryCreateMutable(CFAllocatorGetDefault(), 0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
kCFTypeDictionaryKeyCallBacks
和kCFTypeDictionaryValueCallBacks
是什么?
于是展开来看,kCFTypeDictionaryKeyCallBacks
是5个callback加1个version组成。
typedef struct {
CFIndex version;
CFDictionaryRetainCallBack retain;
CFDictionaryReleaseCallBack release;
CFDictionaryCopyDescriptionCallBack copyDescription;
CFDictionaryEqualCallBack equal;
CFDictionaryHashCallBack hash;
} CFDictionaryKeyCallBacks;
其中的retain,对应的类是CFDictionaryRetainCallBack;
typedef const void * (*CFDictionaryRetainCallBack)(CFAllocatorRef allocator, const void *value);
到这里,我们能明白这5个方法分别是对key做retain、release、copy,判断等于,hash时会用到的方法,并且我们可以知道如果需要对key被retain时做额外处理,可以按照如下实现:
void *keyRetainCallBack(CFAllocatorRef allocator, const void * value)
{
id obj = (id)value;
[obj retain];
// do something
return obj;
}
CF是内存是手动管理,而CFDictionary作为容器类,需要知道当key、value被添加到容器时,应该如何处理key、value的引用,所以需要两个参数kCFTypeDictionaryKeyCallBacks
和kCFTypeDictionaryValueCallBacks
。默认的实现就是在添加时进行CFRetain,在移除时进行CFRelease。
总结
关于Extension已经学习过很久,但是这次的尝试让我重新回顾脑海中对Extension的了解;相比之下,Category是大家注意的重点,甚至连源码层面如何实现的Category都有相关文章。
保持刨坑问底的习惯,遇到问题时尽量去探究更深一层的原因,这样自己的知识层便会慢慢扩展。或许一开始了解的都是很简单的问题,但是随着简单的问题一一解决,对于更难的问题就可以综合已经学会的基础知识作为支撑尝试解决,久而久之就能触类旁通。