1、提高可维护性。解决了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。

2、简化测试。因为同步逻辑是交由Binder做的，View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。大大减少了对View同步更新的测试。

缺点

1、过于简单的图形界面不适用，或说牛刀杀鸡。

2、对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。

3、数据绑定的声明是指令式地写在View的模版当中的，这些内容是没办法去打断点debug的。

三 为什么代理要用weak？代理的delegate和dataSource有什么区别？block和代理的区别?

weak 其实是一个hash(哈希)表 key是所指对象的地址，Value是weak指针的地址(当weak指针所指的对象销毁的时候，这个表根据这个对象地址(key),找到所有的只想他的Value(weak指针)，并把这些指针置nil),我们都知道weak的作用:所引用的对象的计数器不会加一，并在引用对象被释放的时候自动置为nil。通常用于解决循环引用.

weak 实现原理概括

RunTime维护了一个weak表，用于存储指向某个对象的所有weak指针。weak表其实是一个hash（哈希）表，Key是所指对象的地址，Value是weak指针的地址（这个地址的值是所指对象的地址）数组。

weak的实现原理可以概括为三步

(1)初始化时:runtime会调用objc_initWeak函数，初始化一个新的weak指针指向对象的地址。

(2)添加引用时 objc_initWeak函数会调用objc_storeWeak()函数，objc_storeWeak()的作用时更新指针的指向。创建对应的弱引用表

(3)释放时，调用clearDeallocating函数首先根据对象地址获取所有weak指针地址的数组，然后遍历这个数组把其中的数据设为nil，最后把这个entry从weak表中删除，最后清理对象的记录。

代理使用weak指针,其实就是为了解决循环引用的问题,假如一个A对象引用了另一个B对象并遵循了它的代理 如果不使用weak 就会造成 A引用了B B持有delegate delegate持有A 造城循环引用。而如果食用了weak delegate就不会持有A 打破循环引用，释放内存.

在代理中经常会看到DataSource和Delegate

DataSource 偏重于数据的回调，View里有什么东西 属性都是什么。例如UITableviewDatasource； delegate偏重于与用户交互的回调，有那些方法可以供我使用，例如UITableviewDelegate

Block和代理的区别

block和代理是iOS开发中实现回调的两种方式，大多数情况下是用哪个都可以 具体可以参考这里 https://www.jianshu.com/p/6bba9b4a25d5

四 属性的实质是什么?包括哪几个部分？属性默认的关键字有哪些？@dynamic关键字和@synthesize关键字是用来做什么的？

属性的本质也就是说@property的本质是什么

其实就是 @property = ivar + getter + setter (实例变量 + get方法 + set方法) https://www.jianshu.com/p/7ddefcfba3cb

atomic

原子操作(原子性是指事务的一个完整操作，操作成功就提交，反之就回滚。原子操作就是指具有原子性的操作),在OC属性设置中，默认的就是atomic,意思就是Setter/getter函数是一个原子操作，如果多线程同时调用setter时，不会出现某一个线程完成setter所有的语句之前，另一个线程就开始执行setter。相当于函数加了锁。这样的话，并发访问性能会比较低.

nonatomic

非原子操作属性 一般不需要多线程支持的时候就用它，这样在并发访问的时候效率会比较高,在OC中通常对象类型都应该声明为非原子性的。iOS中程序启动时系统会自动生成一个单一的主线程。程序在执行的时候一般情况下都是在同一个线程里面进行操作。如果在程序中 我们确定某一个属性会在多线程中被使用，并且需要做数据同步，就必须设置成原子性的，但也可以设置成非原子性的，然后自己在程序中用加锁之类的来做数据同步

@synthesize 和 @dynamic

如果没有实现setter和getter方法，编译将会自动生成setter和getter 如果@synthesize和@dynamic都没写 默认时@synthesize

@dynamic 属性的setter和getter方法由用户自己实现，不能自动生成 (当然对于 readonly 的属性只需提供 getter 即可)

readwrite

如果没有声明成 readonly ，那就 默认是 readwrite 。可以用来赋值，也可以被赋值

readonly

不可以被赋值 只可以调用

assgin 不会使引用计数加1 直接饮用对象 对象释放 会指向一个空地址 不安全

weak   见上面

retain strong

在ARC打开的情况下 才使用strong 引用计数加1

copy 建立一个索引计数为1的对象，在赋值时会使用传入值的一份拷贝.

综上所述，如果在声明属性的时候 没写关键字 如果是基本对象会默认 assign readwrite atomic OC对象默认  strong readwrite atomic

五 NSString为什么要用copy关键字，如果用strong会有什么问题？（注意：这里没有说用strong就一定不行。使用copy和strong是看情况而定的）

@interface ViewController ()

@property (nonatomic,strong) NSString *strongStr;

@property (nonatomic,copy) NSString * copyedStr;

@end

@implementation ViewController

- (void)viewDidLoad {

    [super viewDidLoad];

    NSString *string = [NSString stringWithFormat:@"abc"];

    self.strongStr = string;

    self.copyedStr = string;

    NSLog(@"origin string: %p, %p", string, &string);

    NSLog(@"strong string: %p, %p", _strongStr, &_strongStr);

    NSLog(@"copy string: %p, %p", _copyedStr, &_copyedStr);

}

-- ::55.804861+ StrCopyAndStrong[:] origin string: 0xa000000006362613, 0x7fff558b0c68

-- ::55.805013+ StrCopyAndStrong[:] strong string: 0xa000000006362613, 0x7f8ecce058a0

-- ::55.805123+ StrCopyAndStrong[:] copy string: 0xa000000006362613, 0x7f8ecce058a8

我们可以看到 这种情况下 不管是Strong还是copy属性的对象，其指向的地址都是同一个，即为string指向的地址。如果我们换作MRC环境，打印string的引用计数的话，会看到其引用计数值是3，即strong操作和copy操作都使原字符串对象的引用计数值加了1。

接下来 我们把string由不可变改为可变对象

NSString *string = [NSString stringWithFormat:@"abc"];

变为

NSMutableString *string = [NSMutableString stringWithString:@"abc"];

打印结果变为

-- ::04.404233+ StrCopyAndStrong[:] origin string: 0x60400005bff0, 0x7fff557d2c68

-- ::04.404412+ StrCopyAndStrong[:] strong string: 0x60400005bff0, 0x7fc8d3c08ac0

-- ::04.404522+ StrCopyAndStrong[:] copy string: 0xa000000006362613, 0x7fc8d3c08ac8

此时 可以看到copy属性的字符串已经不在指向string字符串对象，而是深拷贝了string字符串，并让_copyedStr指向这个字符串。

我们在声明一个NSString属性时，对于其内存相关特性，通常会有两种选择(基于ARC环境):strong和copy。在MRC环境下，打印两者的引用计数，可以看到string对象的引用计数是2，而_copyedString对象的引用计数是1。

此时，我们如果去修改string字符串的话，可以看到：因为_strongStr与string是指向同一对象，所以_strongStr的值也会跟随着改变(需要注意的是，此时_strongStr的类型实际上是NSMutableString，而不是NSString)；而_copyedStr是指向另一个对象的，所以并不会改变。

由于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，以免因可变字符串的修改导致的一些非预期问题。http://www.cocoachina.com/ios/20150512/11805.html

六 如何令自己所写的对象具有拷贝功能

若想令自己所写的对象具有拷贝功能,则需要实现NSCopying协议。如果自定义的对象氛围可变版本和不可变版本，那么需要同时实现NSCopying／NSMutableCopying协议。

具体步骤:

需要声明该类遵守NSCopying协议

实现NSCopying协议，该协议只有一个方法

- (id)copyWithZone:(NSZone *)zone;

注意：一提到让自己的类用 copy 修饰符，我们总是想覆写copy方法，其实真正需要实现的却是 “copyWithZone” 方法。

至于如何重写带copy关键字的setter方法这个问题

- (void)setName:(NSString *)name {

    //[_name release];

    _name = [name copy];

}

另外对于实现了NSCopying和NSMutableCopying协议的类来说，对他们的对象发送 copy 和 mutableCopy 也会有不同的效果.

copy 对于不可变对象 是浅拷贝(拷贝对象的指针，指向的是同一块内存地址<内存地址中的内容没被拷贝>) 对可变对象进行copy操作 是深拷贝(拷贝出来一个新的对象指向一个拷贝出来的新的内存地址<原内存地址中的内容也被拷贝>)  但是拷贝出来的都是不可变对象

需要注意的是集合对象的内容复制仅限于对象本身，对象元素仍然是指针复制

mutableCopy 拷贝出来的都是可变对象 而且进行的是深拷贝 这篇文章讲的很具体 https://www.jianshu.com/p/e98e6e30ebda

七 为什么IBOutlet修饰的UIView也适用weak关键字

因为当我们将控件拖到Storyboard上，相当于新创建了一个对象，而这个对象是加到视图控制器的view上，view有一个subViews属性，这个属性是一个数组，里面是这个view的所有子view，而我们加的控件就位于这个数组中，那么说明，实际上我们的控件对象是属于view的，也就是说view对加到它上面的控件是强引用。当我们使用Outlet属性的时候，我们是在viewController里面使用，而这个Outlet属性是有view来进行强引用的，我们在viewController里面仅仅是对其使用，并没有必要拥有它，所以是weak的。

如果将weak改为strong，也是没有问题的，并不会造成强引用循环。当viewController的指针指向其他对象或者为nil，这个viewController销毁，那么对控件就少了一个强引用指针。然后它的view也随之销毁，那么subViews也不存在了，那么控件就又少了一个强引用指针，如果没有其他强引用，那么这个控件也会随之销毁。

不过，既然没有必将Outlet属性设置为strong，那么用weak就好了

八 nonatomic和atomic的区别？atomic是绝对的线程安全么？为什么？如果不是，那应该如何实现？

在默认情况下，由编译器所合成的方法会通过锁定机制确保其原子性(atomicity)。如果属性具备nonatomic特质，则不需要同步锁。

具备atomic特质的获取方法会通过锁定机制来确保其操作的原子性。也就是说，如果两个线程同时读取一个属性，那么不论何时，总能看到有效的属性值。

如果不加锁的话（或者说使用nonatomic语义），那么当其中一个线程正在改写某属性值的时候，另外一个线程也许会突然闯入，把尚未修改好的属性值读取出来。发证这种情况时，线程读取道德属性值肯能不对。

一般iOS程序中，所有属性都声明为nonatomic。这样做的原因是：
在iOS中使用同步锁的开销比较大， 这会带来性能问题。一般情况下并不要求属性必须是“原子的”，因为这并不能保证“线程安全”(thread safety)，若要实现“线程安全”的操作，还需采用更为深层的锁定机制才行。

例如：一个线程在连续多次读取某个属性值的过程中有别的线程在同时改写该值，那么即便将属性声明为atomic，也还是会读取到不同的属性值。

因此，iOS程序一般都会使用nonatomic属性。但是在Mac OS X程序时， 使用atomic属性通常都不会有性能瓶颈;

然而atomic一定是线程安全的么，回答是NO ：

nonatomic的内存管理语义是非原子性的，非原子性的操作本来就是线程不安全，而atomic的操作是原子性的，但并不意味着他就是线程安全的，它会增加正确的几率，能够更好的避免线程错误，但仍旧是不安全的。

为了说atomic与nonatomic的本质区别其实也就是在setter方法上的操作不同：

nonatomic的实现:

- (void)setCurrentImage:(UIImage *)currentImage

{

    if (_currentImage != currentImage) {

        [_currentImage release];

        _currentImage = [currentImage retain];

        // do something

    }

}

- (UIImage *)currentImage

{

    return _currentImage;

}

atomic的实现:

- (void)setCurrentImage:(UIImage *)currentImage

{

    @synchronized(self) {

        if (_currentImage != currentImage) {

            [_currentImage release];

            _currentImage = [currentImage retain];

            // do something

        }

    }

}

- (UIImage *)currentImage

{

    @synchronized(self) {

        return _currentImage;

    }

}

当使用atomic时，虽然对属性的读和写是原子性的，但是仍然可能出现线程错误：当线程A进行写操作，这时其他线程的读或者写操作会因为等该操作而等待。当A线程的写操作结束后，B线程进行写操作，所有这些不同线程上的操作都将依次顺序执行——也就是说，如果一个线程正在执行 getter/setter，其他线程就得等待。如果有线程C在A线程读操作之前release了该属性，那么还会导致程序崩溃。所以仅仅使用atomic并不会使得线程安全，我们还要为线程添加lock来确保线程的安全。

更准确的说应该是读写安全，但并不是线程安全的，因为别的线程还能进行读写之外的其他操作。线程安全需要开发者自己来保证。

其实无论是否是原子性的只是针对于getter和setter而言，比如用atomic去操作一个NSMutableArray ，如果一个线程循环读数据，一个线程循环写数据，肯定会产生内存问题，这个就跟getter和setter就木有关系了。

至于保证线程安全 我觉得可以看看这篇文章:http://www.cocoachina.com/ios/20160707/16957.html

九 UICollectionView自定义layout如何实现?