iOS的Mantle实战

公司项目之前的model层代码是我使用JSON工具直接生成Objective-C代码的，当时还是觉得相当省事的，毕竟我经历过无model层的NSDictionary“黑暗”时期。但是随着项目的推进，问题开始慢慢显现出来。

于是，在一个多月前，我在Objc.io上看到提及了Mantle，花了一点时间看了一下，决定先在分支上全套改用Mantle。使用了一段时间，性能没造成什么瓶颈，稳定性还是可以接受的。后来也基于Mantle、MK和RAC，把网络的请求整合在一起，在新项目上全面使用。一开始时也是没什么问题的，但后来我也逐渐发现了Mantle虽好，但不至于能解决一切问题。最近看到了《为什么唱吧iOS 6.0选择了Mantle》文章，我决定写博客记下一些model层的坑。

 

简要分析

先来简要分析一下各种构建model层方法的优点和缺点：

一、工具生成model

优点：

1、简单易用，新手也可以10秒上手

2、有一定的容错代码

3、代码生成相对工整和规范，部分工具还可以选择是否使用ARC

4、生成简单model耗时少

缺点：

1、工具生成的类名或者属性名不太符合要求，往往需要自行修改，但是修改起来相当麻烦，却需要相当专注以防有什么地方忘记修改。

2、生成的代码相当冗长。

3、对适应字段变化比较麻烦，一旦属性需要修改字段时，要么人工修改，要么重新生成，但是极有可能需要重复缺点1的步骤。

4、model之间一些继承关系还是需要自行修改继承来实现。

 

二、基于运行时生成的model（Mantle这类）

优点：

1、减少大量模版代码

2、修改字段映射时相当简便

3、扩展时相对方便

4、可以实现更多复杂的映射关系和数值转换

5、调试时的异常可以较好地发现问题

6、实现了NSCopying和NSCoding协议，可以轻松序列化

缺点：

1、基于运行时属性映射，对性能有一定影响

2、有部分容错处理需要自行解决，否则很可能崩溃（下文详解）

3、框架代码不少

 

三、NSDictionary型model

优点：

1、无需任何基础，直接可用

2、容错性相对较高

3、无视任何数据结构，均能适应

缺点：

1、维护成本昂贵

2、编译器无法检查拼写，需要定义大量key的常量，否则极其容易写错

3、调试相对麻烦

 

其实，NSDictionary型model还是有一定用途的，毕竟有些情况下，不需要浪费精力去构建一个很短小或者很快就会被释放的model。但大多数情况下，还是需要去构建一个合理的model，来保证项目的健壮性和开发效率。以前，我老大和我说，iOS应用MVC三层，M这一层其实服务端已经帮你完成了大部分，来到客户端再自己处理model，既消耗性能又降低了开发效率。当时，我觉得还是比较正确的，但随着MVC的C变得臃肿不堪，M变得越来越轻量的时候。很多东西都耦合在controller，model这层能做好的话，就能一定程度上减轻了controller的复杂度。加上工作了以后发现，一个只有NSDictionary，无真正model的商业应用，真的非常不利于维护。

基于上述的种种理由，我还是决定了正式全面使用Mantle。但Mantle不是万能的，我还是遇到了几个问题。

 

null值

如果你的属性是基本数值类型的话，JSON返回一个null值，那么在Mantle生成model的时候，果断崩溃了。这个问题和解决方案跟《为什么唱吧iOS 6.0选择了Mantle》中的一样，model中实现一下setNilValueForKey:方法即可。建议使用基类继承，那么写一次这个方法就所有model都解决了这个问题。

 

键值的合理映射

{
    "code": 1
    "result":{
        "access_token":"m_xxxxxxx",
        "user_id":1111
    }
}

例如上述JSON，假设整个JSON是一个model，那么如果直接按照JSON的格式来映射，就要新建一个“result”额外的model类。但或许不需要这么繁复，其实可以这么写

+ (NSDictionary *)JSONKeyPathsByPropertyKey
{
    return @{@"accessToken": @"result.access_token",
                  @"userId": @"result.user_id"};
}

这样做就可以很方便地映射到对应的属性上，同时也不需要额外新建一个model类。这里为什么没写“code”的映射呢，因为如果属性名和JSON的键名一致时，是可以省略不写映射的，具体大家可以看看Mantle的源码。

 

值的类型问题

这个问题是最棘手的，不能说后台坑队友，但是JSON的数值类型和文档不符乃家常便饭。作为和用户最近的前线，我只能想尽办法去收尾，不能完全放任不管吧。常规的方法不外乎以下几种：

1、转换model前先进行预处理JSON数据，把类型不符的值转换或者删除掉

2、为这些容易崩溃的值，都写上NSValueTransformer的转换

 

这些的确都能解决问题，但是效率就下降了很多，你得关注各种各样的可能出现的情况。相信我，要是你这么做，你连睡觉都睡不好。

我列举一下几种类型不符会导致的异常：

1、属性是BOOL类型，返回值是string类型。

2、属性是NSString类型，返回值是number类型，Mantle只会转换出NSNumber类型。你调用length等NSString的专用方法时，你懂的。

3、使用了类似上面"result.access_token"的映射，但返回值不是object类型（例如array类型）。

4、属性是NSArray，使用了转换，返回值是object。

 

放心，实际情况中，绝对不会只有上述4种可能的。不过幸运的是，Mantle帮大家处理了1、3、4这些情况（如果object和array都是使用了转换方法的话，在转换的时候会处理这些异常的），只会在调试模式下抛出异常，Release的时候是不会崩溃的。如果大家不想在调试的时候被这些异常打断的话，可以注释掉MTLValidateAndSetValue这个方法中的对应代码。

接下来大家可能觉得太匪夷所思了，为什么一个小小的客户端还得因为用个Mantle就要去规避这么多陷阱。我就是遇到这么多陷阱，想到了解决方法，自己也是成长了。针对JSON的类型，我有了以下的考虑：

JSON其实就是只有4种类型，string、number(int 、bool…)、object、array。在Objective-C对应也就是，NSString、NSNumber、NSDictionary、NSArray，因此要规避类型问题也是从这几个类着手。这里要说一下为什么属性有int、bool等，我只归了一类NSNumber。因为实质上，Mantle只是转换了NSNumber类型的对象出来，在setValue的时候，是由系统根据类型调用了对应的NSNumber方法。由于number和string的类型错误是最常见，同时也是最隐蔽的（调用类似intValue的方法看不出端倪），为此我写了一个AvoidMTLModelCrash的category，github上的地址，使用了这个category以后，关于NSString和NSNumber类型问题的崩溃基本都可以解决。如果是NSArray或者NSDictionary设置到NSString的属性也是无法检测的，但是面对如此严重的类型问题，我建议还是和小伙伴一起坐下来，好好谈谈“人生”吧。

 

灵活的转换

例如某些接口返回的数据是数组，但很多时候只需要用到这个数组的第一个元素。我们可以直接将数组里面的一个元素影射出来。

+ (NSValueTransformer *)pointListJSONTransformer
{
    return [MTLValueTransformer transformerWithBlock:^id(NSArray *array) {
        return [array firstObject];
    }];
}

除了属性映射和每个属性固定的类型转换，MTLJSONSerializing的协议还有classForParsingJSONDictionary这么一个方法可以改变解释后的类。例如B、C均继承A，用Mantle生成A类对象。A类可以通过这个方法，选择不同的子类生成对象。但是对外可见的接口也是A类的接口，这样就类似NSArray一样（NSArray其实也是有很多子类的）。

 

序列化

由于，Mantle已经实现了序列化的协议，所以不需要额外的代码即可直接序列化。但是，如果你的属性中有不能直接序列化的类型或者不想使用序列化的时候，可以声明为私有成员，或者使用BlockKit的“NSObject+BKAssociatedObjects”来动态添加属性。这样子，Mantle就不会把这些属性进行序列化了。

 

小小的总结

model的框架对项目影响深远，如果为了不在以后的项目留下坑，那model这一层还是要多加思考，免得造成了维护不能的境地。