首页 > 代码库 > iOS的Mantle实战

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都解决了这个问题。

 

键值的合理映射

1 {2     "code": 13     "result":{4         "access_token":"m_xxxxxxx",5         "user_id":11116     }7 }

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

1 + (NSDictionary *)JSONKeyPathsByPropertyKey2 {3     return @{@"accessToken": @"result.access_token",4                   @"userId": @"result.user_id"};5 }

这样做就可以很方便地映射到对应的属性上,同时也不需要额外新建一个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的属性也是无法检测的,但是面对如此严重的类型问题,我建议还是和小伙伴一起坐下来,好好谈谈“人生”吧。

 

灵活的转换

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

1 + (NSValueTransformer *)pointListJSONTransformer2 {3     return [MTLValueTransformer transformerWithBlock:^id(NSArray *array) {4         return [array firstObject];5     }];6 }

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

 

小小的总结

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

iOS的Mantle实战