iOS自我开发准则之-防崩处理

程序崩溃，乃最大错误，测试最喜欢的就是看到app崩溃，当我们了解了在哪几种情况下比较容易出现崩溃的时候，我们最好把所有可能出现崩溃的地方都堵上。正所谓，一个好开发者就是当他在横穿单行道时也会往两边都看看。

数据防崩处理

数据结构/数据类型

最常见的崩溃之一就是 unrecognized selector sent to… 所以为了避免造成非本类方法被调用，我们在使用数据之前，要么对数据类型进行判断，要么强转数据类型。然而，强转类型也有一定几率转不成功，因此还是判断类型比较安全。

最容易出问题的地方无外乎是非自己创建的数据，即获取到的数据，无论是用户输入，文件读取还是请求来的数据，都有类型不确定性，因此类型判断就变得尤为重要。

正所谓防火防盗防后台，引用某位大神的名言：后台的数据类型是永远不值得信任的。 并不是贬低后台研发人员，意思是说只有我们考虑到了所有的可能性，才可以以不变应万变，这样即使某天后台研发人员对于数据类型做了修改，我们的app一样可以运行。

数据非空判断

虽然当某个对象为空时，一般调用方法不会产生崩溃，但是，有特殊情况。

1. 当一个空对象做为字典的value被写入字典时，程序崩溃。
   
2. 当一个数组对象为空时，以索引来读取数组内元素时（array[index]），数组越界崩溃。
   
3. 当一个可变数组添加一个空对象时，程序崩溃。
   
4. 当定义了一个block属性时，如果在block属性被赋值之前就调用block，程序崩溃，也就是必须在调用block之前进行非空判断

当然，非空判断不仅用于防崩，其他跟数据处理相关的地方都会做。

数组元素个数判断

既然提到的数组越界，那么对于数组元素个数的判断就尤为重要，尤其涉及到当获取或则操作数组内某个元素时，先判断数组元素个数是否大于0和索引是否小于数组元素个数就必须要做了。

代码/运行逻辑防崩处理

代码逻辑

由于代码逻辑错误或使用了不正确的修饰符或者类所引起的崩溃数不胜数，举几个栗子：

• 以assign来修饰代理属性。
• 以copy来修饰可变字符串或可变数组。
• for循环中的流程控制变量更改超过了数组元素个数。

还有很多情况，但，这些可能会引起崩溃的地方我们都可以在写代码的时候尽量去避免，虽然常在河边站哪有不湿鞋，但鞋子湿多了，也就知道哪里有水坑了。

运行逻辑

所谓的运行逻辑错误引起的崩溃是指，在代码编译后不会出现任何错误，数据没有任何问题的情况下，由于某些逻辑考虑不周全引起的崩溃。

比如：

• 由于对系统版本判断不完整，导致新系统版本中的某些系统库在老版本中找不到，老系统版本的机型上就会崩溃。
• 当本地缓存数据结构修改后，没有对老版本缓存数据进行及时更新，导致的数据结构或类型不对的崩溃。
• 某种不良操作引起的主线程UI卡死，被系统强制关闭

好吧，我也知道万事都考虑周全是不可能的，但我们可以尽可能的考虑周全，亡羊补牢，犹未为晚。

先这样，及时发现，及时补充