OC零散小知识总结

1，循环引用

@interface ClassB ()
@property (nonatomic, strong) ClassA *classA;
@end

如代码，classA 是ClassB的一个属性，就是说ClassB拥有(也可说引用)classA, 表示为如图关系

jietu.png

理解了这层引用关系，对于delegate 为什么要用weak 修饰符，block可能会出现循环引用的解答就有帮助。

2，属性特质

1）原子性(atomic 和 nonatomic)

默认是atomic,原子的。两者的区别:具有atomic特质的获取方法会通过同步锁机制来确保其操作的原子性。比如，两条线程读写统一属性，如果用atomic，那么不论何时，总能看到有效的属性值。如果不加锁的话(使用nonatomic)，那么当其中一个线程正在改写某属性时，另外一个线程也许会突然闯入，把尚未修改好的属性值读取出来，这时，线程读到的属性值可能不对。但是，在iOS程序里，所有属性都是声明为nonatomic。原因：在iOS中使用同步锁的开销比较大，这会带来性能问题。还有“原子的”属性也并不能完全保证线程安全，若要实现线程安全的操作，还需要更为深层的锁定机制才行

2）内存管理语义

• assign 基本数据类型
• strong 表明该属性定义了一种"拥有关系"。为该属性设置新值时，设置方法里会保留新值，并释放旧值，然后再将新值设置上去
• weak 表明该属性定义了一种"非拥有关系"。为该属性设置新值时，设置方法里既不会保留新值，也不会释放旧值，同assign类似，只是使用weak，属性所指的对象遭到摧毁时，属性值会自动清空，置为nil。而assign则不会
• copy 所属关系与strong类似，只是设置方法里并不是保留新值，而是将新值"copy"一份。
• unsafe_unretained 与assign相同，但它适用于对象类型

3）读写权限

有readwrite 和 readonly 两种权限。默认是readwrite. 尽量使用不可变对象，即属性尽量用readonly修饰

4）方法名

getter = <name> setter=<name>(少用)

3，类簇与工厂模式

示例如下，EOCEmployee是基类，剩下的类都是其子类

typedef NS_ENUM(NSUInteger, EOCEmployeeType) {
    EOCEmployeeTypeDesigner,
    EOCEmployeeTypeDeveloper,
    EOCEmployeeTypeTester,
    EOCEmployeeTypeFinance
};
@interface EOCEmployee : NSObject
@property (nonatomic, copy) NSString *name;
@property (nonatomic, assign) NSUInteger salary;

+ (EOCEmployee *)employeeWithType:(EOCEmployeeType)type;
- (void)doADaysWork;
@end

@implementation EOCEmployee
+ (EOCEmployee *)employeeWithType:(EOCEmployeeType)type {
    switch (type) {
        case EOCEmployeeTypeDesigner:
            return [[EOCEmployeeDesigner alloc] init];
            break;
        case EOCEmployeeTypeDeveloper:
            return [[EOCEmployeeDeveloper alloc] init];
            break;
        case EOCEmployeeTypeTester:
            return [[EOCEmployeeTester alloc] init];
            break;            
        case EOCEmployeeTypeFinance:
            return [[EOCEmployeeFinance alloc] init];
            break;
    }
    
}
- (void)doADaysWork {
    //子类自己去实现。。。
}

@end

子类继承，实现父类方法

#import "EOCEmployee.h"
@interface EOCEmployeeDeveloper : EOCEmployee
@end
@implementation EOCEmployeeDeveloper

- (void)doADaysWork {
    NSLog(@"i am developer");
}
@end

#import "EOCEmployee.h"
@interface EOCEmployeeDesigner : EOCEmployee
@end

#import "EOCEmployeeDesigner.h"
@implementation EOCEmployeeDesigner
- (void)doADaysWork {
    NSLog(@"i am designer...");
}
@end

接下来test

#import "ViewController.h"
#import "EOCEmployee.h"

@interface ViewController ()
@end
@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    EOCEmployee *paEmployee = [EOCEmployee employeeWithType:EOCEmployeeTypeDeveloper];
    [paEmployee doADaysWork];
    // Do any additional setup after loading the view, typically from a nib.
}
@end

以上就是类簇的创建模式。类簇模式可以把实现细节隐藏在一套简单的公共接口后面。在系统框架中使用

4，runtime的一些基本知识

1）C语言使用的是"静态绑定"，即在编译器就能决定运行时所应调用的函数，而OC采用的是"动态绑定"，只有在运行时才能确定。在底层，对象收到消息后，究竟该调用哪个方法完全在运行期决定，甚至可以在程序运行时改变

5，发邮件 MFMailComposeViewController 使用注意

1. 需要导入MessageUI.framework库(实际上，ios10之后就无需手动导入了，为兼容低版本，最好手动导入)
   2）发邮件前，需要判断 MFMailComposeViewController 是否有发邮件的功能，否则可能会cresh. 报错 Application tried to present a nil modal view controller on target

MFMailComposeViewController *mc = [[MFMailComposeViewController alloc] init];
    if ([MFMailComposeViewController canSendMail]) {
        mc.mailComposeDelegate = self;
        [mc setSubject:emailTitle];
        [mc setMessageBody:messageBody isHTML:NO];
        [mc setToRecipients:toRecipents];
        
        //Present mail view controller on screen
        [self presentViewController:mc animated:YES completion:nil];
    }

6，用storyboard创建tableViewCell或者collectionViewCell 时，当在storyboard里使用了Identifier,并在代码里做了匹配时，如下两图，就不再需要用代码提前注册cell了，否则会出错。

屏幕快照 2017-03-14 16.37.09.png 屏幕快照 2017-03-14 16.37.52.png needDelete.png

7，哪些场景必须要使用@synthesize？

• 同时重写了 setter 和 getter 时
• 重写了只读属性的 getter 时
• 使用了 @dynamic 时
• 在 @protocol 中定义的所有属性
• 在 category 中定义的所有属性
• 重载的属性
  更多信息:http://stackoverflow.com/questions/19784454/when-should-i-use-synthesize-explicitly/19821816#19821816

8，通知NSNotificationCenter的一点认识

• 我们知道通知是一对多的关系，即一处发通知，多处可接收。假设有这个场景：A-->B-->C-->D, push关系，这4个控制器全部都在同一个栈里。当在C控制器里点击确定按钮push 到D时发送通知，并且在 A，B页面里都接收这个通知，在对应通知方法里做某些处理(比如请求数据，刷新当前页面...)
  之前的认知: C push 到D的时候 发送通知，A，B即使接收了该通知，也不会有相应的处理，因为当前response的页面是D，而不是它们
  经过测试验证，认知是错误的，只要它们在同一个栈里，有一处发通知，其他任何有监听这个通知的地方都会及时响应并处理，如果考虑性能，这点就不太合理，也就是push 到 D 时尽量避免给栈内的其他控制器发送通知。代理delegate 应该也有如此

9，iOS里通用的数据结构有三类:数组，字典，集合(Set)。

有时候脑袋不灵光，把最基本的忘记了，通过看书，把一些基本的知识点记下来。“好记性不如烂笔头”，经常翻翻以巩固记忆