为什么唱吧iOS 6.0选择了Mantle

关注

转载最新推荐文章于 2026-05-30 08:14:08 发布 6.6k 阅读 AI 写同款· GEO 优化 ›

iOS ——Mantle Mantle--国外程序员最常用的iOS模型&字典转换框架，Mantle可以轻松把JSON数据、字典（Dictionary）和模型（即Objective对象）之间的相互转换，支持自定义映射，并且内置实现了NSCoding和NSCoping，大大简化归档操作。立即下载

最近唱吧iOS的6.0版本已经成功上线了。18人月的投入，2500个commit，几十万行的代码修改。唱吧iOS已经从内至外焕然一新，感谢一起并肩作战的小伙伴们。

6.0一个很重大的修改就是基于Mantle重建(新建)了Model层。这里不对Mantle作更多介绍，只分享一下使用Mantle的决策及执行过程。

我们遇到的问题

唱吧是一款上线2年多的App，产品形态的演进和迭代非常快。因此不可避免的遗留了各种问题：

Model层不健全，没有统一的结构，不同工程师做法差异很大；多数是哑类型，且没有统一的序列化机制
业务逻辑冗余、分散、不一致
模块划分随意，依赖关系混乱，维护困难
NSDictionary作为承载业务的数据类型在各处出现(sqlite, Model object, API, Notification, web, OpenURL etc.)，参数和值的正确性完全没有编译器检查，字符串很容易写错，风险延后至运行时，易产生低级bug
基本没有文档和注释(结合上一点，不挂debugger很难读懂代码)
几百个API，业务复杂，变动快，重构难；同一个API请求可能有重复和不一致
API的一些参数和返回值，同一个参数/返回值可能存在类型差异；由于API需要向前兼容，修改API有成本

除此之外，还有其他工程上的约束：

不能影响现有的API，所有的事情只限于iOS端的修改
代码即文档，因为没有精力维护文档
对不同Model的持久化方式作迁移
避免写大段枯燥的Model的序列化/反序列化代码
没有时间造出足够成熟、健壮可重用的组件及撰写文档

上述的问题都是长期存在且需要解决的，否则严重影响开发效率及代码质量。11年的时候我还在做社交游戏的时候，设计并实现了一套简单的基于Objective-C Runtime的数值表Model结构及转换工具(Model<=>csv)供数值策划使用。但想写出一套成熟的方案还是有一些距离，而且也没有资源和时间作维护、测试和文档。

顺着这个思路找到了JSONModel和Mantle，前者刚刚1.0，后者在Github for Mac中广泛使用且社区更成熟(甚至Slack上有channel)，所以成为了更好的选择。

事实也证明这个选择是对的，6.0上线后，crash率比之前的版本有显示的降低，并且Mantle相关的crash占总crash的比率不到3%，大可以直接用在大型的产品上。

除了成熟稳定，Mantle基本解决了我们遇到了的所有问题。下面具体介绍一些通用性Mantle使用经验，基本的使用方法请直接移步Mantle的README。

Property名称转换

由于API使用的开发语言与iOS所使用的Objective-C是截然不同的，所以可能将一些保留关键字作为property的名称(如id)，或者不小心override掉基类的属性(如description)。还有可能API中使用了一个很糟糕的名称，或者使用了不符合Objective-C命名规范的名称，这些我们都需要作转换。

只需要实现MTLJSONSerializing protocol并在+JSONKeyPathsByPropertyKey方法中定义好新旧名称的映射关系即可，Mantle会在序列化及反序列化时对属性名进行自动的转换。

     
      + (
      NSDictionary *)JSONKeyPathsByPropertyKey {
     
         
      return @{
     
             
      @"identifier": 
      @"id",
     
             
      @"displayDiscription": 
      @"description",
     
             
      @"thisIsANewShit": 
      @"newShit",
     
             
      @"creativeProduct": 
      @"copyToChina",
     
             
      @"betterPropertyName": 
      @"m_wired_propertyName"
     
     
          }
     
     
      }

好了很多吧？没错，只需要定义一次名称的映射关系就可以了，Mantle负责model与JSON之间的双向转换。不需要将这种逻辑写得到处都是，并且还得维护它的一致性。

Property的类型映射

iOS中处理URL使用的是NSURL类型，但JSON只支持基本的字符串，Mantle可以自动帮你转换成NSURL。

     
      + (NSValueTransformer *)URLJSONTransformer {
     
         
      return [NSValueTransformer valueTransformerForName:MTLURLValueTransformerName];
     
     
      }

NSValueTransformer负责在不同类型间进行双向转换，请读者研究一下Mantle的实现方式。在此前提下，留给读者一个问题(其实这是一个真实的故事，类似的故事还有很多，详见iOS应用开发之十大坑队友)：

假设我们有一个entity，名字且叫KTVConcreteEntity吧，它有一个属性名字叫entityID，类型是NSInteger。问题来了，entityID可能在另外一个API的response中是字符串类型，在不直接修改Mantle的源码的前提下怎么搞？欢迎在下方留言讨论。

空标量异常

有的时候API的response会有空值，比如copyToChina可能不是每次都有的，JSON是这样儿的：

     
      {
     
     
          "
      copyToChina": 
      null
     
     
      }

Mantle在这种情况会将newShit转换为nil，但如果是标量如NSInteger怎么办？KVC会直接raise NSInvalidArgumentException。

Mantle是基于KVC给property赋值的，KVC提供了- (void)setNilValueForKey:(NSString *)key方法，让我们为nil指定一个合理的替代值，我们来看一下此方法的解释：

Invoked by setValue:forKey: when it’s given a nil value for a scalar value (such as an int or float).
Subclasses can override this method to handle the request in some other way, such as by substituting 0 or a sentinel value for nil and invoking setValue:forKey: again or setting the variable directly. The default implementation raises an NSInvalidArgumentException.

对于标量来讲，多数情况下合理的值即为0，我们来看下代码：

     
      @interface MTLModel (KTVNullableScalar)
     
     
      @end
     
     
     
      @implementation MTLModel (KTVNullableScalar)
     
     
      - (
      void)setNilValueForKey:(
      NSString *)key {
     
     
          [
      self setValue:@
      0 forKey:key];  
      // For NSInteger/CGFloat/BOOL
     
     
      }
     
     
      @end