这篇文章主要介绍了不可错过的iOS开发技巧有哪些，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。
专注于为中小企业提供成都网站设计、成都网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业民丰免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了上千余家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
主要记录了以下几个问题：
NSString属性什么时候用copy，什么时候用strong?
Foundation中的断言处理
IBOutletCollection
NSRecursiveLock递归锁的使用
NSHashTable
NSString属性什么时候用copy，什么时候用strong?
我们在声明一个NSString属性时，对于其内存相关特性，通常有两种选择(基于ARC环境)：strong与copy。那这两者有什么区别呢？什么时候该用strong，什么时候该用copy呢？让我们先来看个例子。
示例
我们定义一个类，并为其声明两个字符串属性，如下所示：
@interface TestStringClass ()
@property (nonatomic, strong) NSString *strongString;
@property (nonatomic, copy) NSString *copyedString;
@end
上面的代码声明了两个字符串属性，其中一个内存特性是strong，一个是copy。下面我们来看看它们的区别。
首先，我们用一个不可变字符串来为这两个属性赋值，
- (void)test {
NSString *string = [NSString stringWithFormat:@"abc"];
self.strongString = string;
self.copyedString = string;
NSLog(@"origin string: %p, %p", string, &string);
NSLog(@"strong string: %p, %p", _strongString, &_strongString);
NSLog(@"copy string: %p, %p", _copyedString, &_copyedString);
}
其输出结果是：
origin string: 0x7fe441592e20, 0x7fff57519a48 strong string: 0x7fe441592e20, 0x7fe44159e1f8 copy string: 0x7fe441592e20, 0x7fe44159e200
我们要以看到，这种情况下，不管是strong还是copy属性的对象，其指向的地址都是同一个，即为string指向的地址。如果我们换作MRC环境，打印string的引用计数的话，会看到其引用计数值是3，即strong操作和copy操作都使原字符串对象的引用计数值加了1。
接下来，我们把string由不可变改为可变对象，看看会是什么结果。即将下面这一句
NSString *string = [NSString stringWithFormat:@"abc"];
改成：
NSMutableString *string = [NSMutableString stringWithFormat:@"abc"];
其输出结果是：
origin string: 0x7ff5f2e33c90, 0x7fff59937a48 strong string: 0x7ff5f2e33c90, 0x7ff5f2e2aec8 copy string: 0x7ff5f2e2aee0, 0x7ff5f2e2aed0
可以发现，此时copy属性字符串已不再指向string字符串对象，而是深拷贝了string字符串，并让_copyedString对象指向这个字符串。在MRC环境下，打印两者的引用计数，可以看到string对象的引用计数是2，而_copyedString对象的引用计数是1。
此时，我们如果去修改string字符串的话，可以看到：因为_strongString与string是指向同一对象，所以_strongString的值也会跟随着改变(需要注意的是，此时_strongString的类型实际上是NSMutableString，而不是NSString)；而_copyedString是指向另一个对象的，所以并不会改变。
结论
由于NSMutableString是NSString的子类，所以一个NSString指针可以指向NSMutableString对象，让我们的strongString指针指向一个可变字符串是OK的。
而上面的例子可以看出，当源字符串是NSString时，由于字符串是不可变的，所以，不管是strong还是copy属性的对象，都是指向源对象，copy操作只是做了次浅拷贝。
当源字符串是NSMutableString时，strong属性只是增加了源字符串的引用计数，而copy属性则是对源字符串做了次深拷贝，产生一个新的对象，且copy属性对象指向这个新的对象。另外需要注意的是，这个copy属性对象的类型始终是NSString，而不是NSMutableString，因此其是不可变的。
这里还有一个性能问题，即在源字符串是NSMutableString，strong是单纯的增加对象的引用计数，而copy操作是执行了一次深拷贝，所以性能上会有所差异。而如果源字符串是NSString时，则没有这个问题。
所以，在声明NSString属性时，到底是选择strong还是copy，可以根据实际情况来定。不过，一般我们将对象声明为NSString时，都不希望它改变，所以大多数情况下，我们建议用copy，以免因可变字符串的修改导致的一些非预期问题。
关于字符串的内存管理，还有些有意思的东西，可以参考NSString特性分析学习。
参考
NSString copy not copying?
NSString特性分析学习
NSString什么时候用copy，什么时候用strong
Foundation中的断言处理
经常在看一些第三方库的代码时，或者自己在写一些基础类时，都会用到断言。所以在此总结一下Objective-C中关于断言的一些问题。
Foundation中定义了两组断言相关的宏，分别是：
NSAssert / NSCAssert NSParameterAssert / NSCParameterAssert
这两组宏主要在功能和语义上有所差别，这些区别主要有以下两点：
如果我们需要确保方法或函数的输入参数的正确性，则应该在方法(函数)的顶部使用NSParameterAssert / NSCParameterAssert；而在其它情况下，使用NSAssert / NSCAssert。
另一个不同是介于C和Objective-C之间。NSAssert / NSParameterAssert应该用于Objective-C的上下文(方法)中，而NSCAssert / NSCParameterAssert应该用于C的上下文(函数)中。
当断言失败时，通常是会抛出一个如下所示的异常：
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'true is not equal to false'
Foundation为了处理断言，专门定义了一个NSAssertionHandler来处理断言的失败情况。NSAssertionHandler对象是自动创建的，用于处理失败的断言。当断言失败时，会传递一个字符串给NSAssertionHandler对象来描述失败的原因。每个线程都有自己的NSAssertionHandler对象。当调用时，一个断言处理器会打印包含方法和类(或函数)的错误消息，并引发一个NSInternalInconsistencyException异常。就像上面所看到的一样。
我们很少直接去调用NSAssertionHandler的断言处理方法，通常都是自动调用的。
NSAssertionHandler提供的方法并不多，就三个，如下所示：
// 返回与当前线程的NSAssertionHandler对象。
// 如果当前线程没有相关的断言处理器，则该方法会创建一个并指定给当前线程
+ (NSAssertionHandler *)currentHandler
// 当NSCAssert或NSCParameterAssert断言失败时，会调用这个方法
- (void)handleFailureInFunction:(NSString *)functionName file:(NSString *)object lineNumber:(NSInteger)fileName description:(NSString *)line, format,...
// 当NSAssert或NSParameterAssert断言失败时，会调用这个方法
- (void)handleFailureInMethod:(SEL)selector object:(id)object file:(NSString *)fileName lineNumber:(NSInteger)line description:(NSString *)format, ...
另外，还定义了一个常量字符串，
NSString * const NSAssertionHandlerKey;
主要是用于在线程的threadDictionary字典中获取或设置断言处理器。
关于断言，还需要注意的一点是在Xcode 4.2以后，在release版本中断言是默认关闭的，这是由宏NS_BLOCK_ASSERTIONS来处理的。也就是说，当编译release版本时，所有的断言调用都是无效的。
我们可以自定义一个继承自NSAssertionHandler的断言处理类，来实现一些我们自己的需求。如Mattt Thompson的NSAssertionHandler实例一样：
@interface LoggingAssertionHandler : NSAssertionHandler
@end
@implementation LoggingAssertionHandler
- (void)handleFailureInMethod:(SEL)selector
object:(id)object
file:(NSString *)fileName
lineNumber:(NSInteger)line
description:(NSString *)format, ...
{
NSLog(@"NSAssert Failure: Method %@ for object %@ in %@#%i", NSStringFromSelector(selector), object, fileName, line);
}
- (void)handleFailureInFunction:(NSString *)functionName
file:(NSString *)fileName
lineNumber:(NSInteger)line
description:(NSString *)format, ...
{
NSLog(@"NSCAssert Failure: Function (%@) in %@#%i", functionName, fileName, line);
}
@end
上面说过，每个线程都有自己的断言处理器。我们可以通过为线程的threadDictionary字典中的NSAssertionHandlerKey指定一个新值，来改变线程的断言处理器。
如下代码所示：
- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
NSAssertionHandler *assertionHandler = [[LoggingAssertionHandler alloc] init];
[[[NSThread currentThread] threadDictionary] setValue:assertionHandler
forKey:NSAssertionHandlerKey];
// ...
return YES;
}
而什么时候应该使用断言呢？通常我们期望程序按照我们的预期去运行时，如调用的参数为空时流程就无法继续下去时，可以使用断言。但另一方面，我们也需要考虑，在这加断言确实是需要的么？我们是否可以通过更多的容错处理来使程序正常运行呢？
Mattt Thompson在NSAssertionHandler中的倒数第二段说得挺有意思，在此摘抄一下：
But if we look deeper into NSAssertionHandler—and indeed, into our own hearts, there are lessons to be learned about our capacity for kindness and compassion; about our ability to forgive others, and to recover from our own missteps. We can't be right all of the time. We all make mistakes. By accepting limitations in ourselves and others, only then are we able to grow as individuals.
参考
NSAssertionHandler
NSAssertionHandler Class Reference
IBOutletCollection
在IB与相关文件做连接时，我们经常会用到两个关键字：IBOutlet和IBAction。经常用xib或storyboard的童鞋应该用这两上关键字非常熟悉了。不过UIKit还提供了另一个伪关键字IBOutletCollection，我们使用这个关键字，可以将界面上一组相同的控件连接到同一个数组中。
我们先来看看这个伪关键字的定义，可以从UIKit.framework的头文件UINibDeclarations.h找到如下定义：
#ifndef IBOutletCollection #define IBOutletCollection(ClassName) #endif
另外，在Clang源码中，有更安全的定义方式，如下所示：
#define IBOutletCollection(ClassName) __attribute__((iboutletcollection(ClassName)))
从上面的定义可以看到，与IBOutlet不同的是，IBOutletCollection带有一个参数，该参数是一个类名。
通常情况下，我们使用一个IBOutletCollection属性时，属性必须是strong的，且类型是NSArray，如下所示：
@property (strong, nonatomic) IBOutletCollection(UIScrollView) NSArray *scrollViews;
假定我们的xib文件中有三个横向的scrollView，我们便可以将这三个scrollView都连接至scrollViews属性，然后在我们的代码中便可以做一些统一处理，如下所示：
重庆分公司
重庆分公司
- (void)setupScrollViewImages { for (UIScrollView *scrollView in self.scrollViews) { [self.imagesData enumerateObjectsUsingBlock:^(NSString *imageName, NSUInteger idx, BOOL *stop) { UIImageView *imageView = [[UIImageView alloc] initWithFrame:CGRectMake(CGRectGetWidth(scrollView.frame) * idx, 0, CGRectGetWidth(scrollView.frame), CGRectGetHeight(scrollView.frame))]; imageView.contentMode = UIViewContentModeScaleAspectFill; imageView.image = [UIImage imageNamed:imageName]; [scrollView addSubview:imageView]; }]; } }这段代码会影响到三个scrollView。这样做的好处是我们不需要手动通过addObject:方法将scrollView添加到scrollViews中。
不过在使用IBOutletCollection时，需要注意两点：
IBOutletCollection集合中对象的顺序是不确定的。我们通过调试方法可以看到集合中对象的顺序跟我们连接的顺序是一样的。但是这个顺序可能会因为不同版本的Xcode而有所不同。所以我们不应该试图在代码中去假定这种顺序。
不管IBOutletCollection(ClassName)中的控件是什么，属性的类型始终是NSArray。实际上，我们可以声明是任何类型，如NSSet，NSMutableArray，甚至可以是UIColor，但不管我们在此设置的是什么类，IBOutletCollection属性总是指向一个NSArray数组。
关于第二点，我们以上面的scrollViews为例，作如下修改：
@property (strong, nonatomic) IBOutletCollection(UIScrollView) NSSet *scrollViews;
实际上我们在控制台打印这个scrollViews时，结果如下所示：
