iOS中解决后台返回的null导致的崩溃问题

之前在做项目的时候没怎么在意后台返回的null这个问题，因为只有数据为空的时候后台才可能返回null，而在做项目过程中大多数页面是有数据的，即使没有数据大多数情况下返回的也不是null。然而不怕一万，就怕万一，总会有万一的情况，而这种情况还是出现在了上线之后，一旦返回null就会让App崩溃。后来和后台沟通了一下为什么会返回null，并且希望后台不要返回null。我们的后台使用PHP写的，后台开发人员告诉我，PHP是弱语法，返回的null也是自动生成的，有时返回的是null，有时返回的是“null”字符串，而有时返回的是“”空字符串。后台说之后这些会进行一下统一，尽量不返回null。之后的统一是之后的事，现在还得对null进行处理。

我之前的处理方式是对可能返回null的地方进行一下判断，如果是null就不取值，然而发现这个工程量巨大，而且由于不确定到底哪些地方会返回null，会遗漏某些可能返回null的地方(其实在取数据的时候也可以先判断我们要取的数据是否是我们所需的类型，比如我们要取的数据是字典类型，就判断如果是字典就取值，否则不取值)。于是上网查查是否有人也遇到过类似的问题，以及别人是怎么解决的，没想到真有人也遇到过这种问题，并且有解决方法。

解决后台返回的null导致的崩溃问题就是在项目中导入一个分类：NullSafe。这个分类是一个外国的哥们写的，这个分类大概的作用就是将发送给null对象的消息发送给nil，这样就不会崩溃了。

下面的话都是网上的话，我只是重复一遍。

当我们给null发送消息的时候，会发生崩溃，而给nil发送消息不回发生崩溃。NullSafe这个分类将发送给null的而null又无法处理的消息做了如下几步处理：

1.创建一个方法内存，这个缓存会缓存项目中类的所有类名。

2.遍历缓存，寻找是否已经有可以执行此方法的类。

3.如果有的话，返回这个NSMethodSignature。

4.如果没有的话，返回nil，接下来会走forwardInvocation方法。

5.[invocation invokeWithTarget:nil];将消息转发给nil。

我们还是应该从根源处解决这个问题，我们不应该让后台返回给我们null。

启发：敢于去想，多查资料。