iOS开发质量的那些事

 质量问题不仅仅是商品应该注重的，在移动互联占据人们各个生活领域的前提下，产品质量更显重要，以最具人气和潜力的iOS为例，iOS从系统研发和客户端软件开发环节对质量的要求异常高，在注重用户体验的同时提升产品质量，这也是很多用户非iOS不用的原因，iOS系统已经让移动互联网的品质得到升级。那么我们在开发iOS产品时，如何提高它的质量呢？

        涉及到质量问题，这就是一个很大的话题，包括很多方面，比如代码书写的质量，开发流程的规范，项目管理的到位，测试的最后把关等各个环节。编码需要规范，命名需要有意义；接口低耦合、高内聚、易扩展，代码能重用、避免重复代码；提交代码后需要做CodeReview；Release前，自测需要充分，包括单元测试、和其他模块(服务器)的联调测试，网络性能测试，不同机型、不同系统版本、越狱与否等各个方面的测试；通过冒烟测试后才交于QA测试等等。在这里，我们主要分享从开发人员的角度如何提高产品质量，包含的内容如下：

 

一、避免异常:

从上面可以看到，iOS开发中常见的异常包括以下几种：
NSInvalidArgumentException
NSRangeException
NSGenericException
NSInternalInconsistencyException
NSFileHandleOperationException

 

        NSInvalidArgumentException

       非法参数异常(NSInvalidArgumentException)是 Objective - C 代码最常出现的错误，所以平时在写代码的时候，需要多加注意，加强对参数的检查，避免传入非法参数导致异常，其中尤以nil参数为甚。

        1. 集合数据的参数传递
           比如NSMutableArray, NSMutableDictionary的数据操作

             (1) NSDictionary不能删除nil的key
               
           (2) NSDictionary不能添加nil的对象
              
           (3) 不能插入nil的对象
               
           (4) 其他一些nil参数
               

 

         2. 其他一些API的使用
            APP一般都会有网络操作，免不了使用网络相关接口，比如NSURL的初始化，不能传入nil的http地址:
          

        3. 未实现的方法
            (1) .h文件里函数名，却忘了修改.m文件里对应的函数名
            (2) 使用第三方库时，没有添加”-ObjC” flag
            (3) MRC时，大部分情况下是因为对象被提前release了，在你心里不希望他release的情况下，指针还在，对象已经不在 了。            
                比如:
                
                

     

      

      NSRangeException

        越界异常(NSRangeException)也是比较常出现的异常，有如下几种类型:

       1. 数组最大下标处理错误

       比如数组长度count, index的下标范围[0, count -1], 在开发时，可能index的最大值超过数组的范围；

        

       2. 下标的值是其他变量赋值

       这样会有很大的不确定性， 可能是一个很大的整数值

       
       

       这里的值达到32位和64位整数的最大值，肯定是一个不正常的参数，比如：

       
        如果找不到str ，则返回NSNotFound，32位下它就是2147483647，64位下18446744073709551615 ，将它作为参数传递则会导致NSRangeException。

       3. 使用空数组

       如果一个数组刚刚初始化，还是空的，就对它进行相关操作

      
       所以，为了避免NSRangeException的发生，必须对传入的index参数进行合法性检查，是否在集合数据的个数范围内。

        NSGenericException

 

       NSGenericException这个异常最容易出现在foreach操作中，在for in循环中如果修改所遍历的数组，无论你是add或remove，都会出错，比如：

           
 

       执行上面的代码会出现以下的错误:

          

       原因就在这 "for in",它的内部遍历使用了类似 Iterator进行迭代遍历，一旦元素变动，之前的元素全部被失效，所以在foreach的循环当中，最好不要去进行元素的修改动作，若需要修改，循环改为for遍历，由于内部机制不同，不会产生修改后结果失效的问题。
            

 

       NSMallocException

       这也是内存不足的问题，无法分配足够的内存空间 
          

       NSFileHandleOperationException

       处理文件时的一些异常，最常见的还是存储空间不足的问题，比如应用频繁的保存文档，缓存资料或者处理比较大的数据:
       
        所以在文件处理里，需要考虑到手机存储空间的问题。

 

二、错误处理

       在进行函数调用的时候，如果有NSError的参数传递，最好都处理以下，特别是一些网络和文件的处理，比如：

       文件操作错误

       比如在删除文件时，有可能发生错误，我们需要做一些处理
       

 
       网络处理错误

       在使用NSURLConnection进行网络请求时，发生错误是难免的，必须做相应处理
       

 

三、本地缓存的兼容处理

         在APP的运行过程中，难免会有I/O的操作，一般的情况，从技术的角度来看也不会出什么问题，但是业务逻辑上可能就需要特别注意了，比如APP升级版本后，可能保存缓存数据的格式发生变化了，读取数据后的处理逻辑也就相应发生变化，这时就需要考虑兼容旧版本数据的处理,否则对升级用户了说，很可能由于异常发生崩溃。

        

四、解析网络数据

          客户端开发时，对接收到的服务器数据，需要特别小心，因为经过网络传输回来的数据都是不可信的，什么问题都可能发生，比如协议中该有的字段没有，是整数型的字段结果传了一个子串，Json格式的内容变成xml了…，所以我们在解析服务器数据时，需要有充分的异常处理机制。
 

五、代码静态检查

        在开发完成后，需要对代码进行静态检查，这样能发现一些内存泄露以及一些warning。

       1. 内存泄露
            (1) MRC
            在MRC的时候，内存泄露是个大问题，一不小心就会中招

              

           注意上面的代码并不是L63行存在泄漏，我们点击“Potential leak of an object”前面的箭头，指示会出现一些变化，如下图。
           

           alloc一个对象的时候，其内存计数内存计数(retain count)+1
           
         
           
           因为content的setter方发会将object的内存计数+1，如下代码，content是retain属性。执行完L62代码后，self.content的内存计数就为 2
            
 
           建议修改方案：
           
 

          (2) ARC

          在ARC下，这方面的问题就少很多了，但也还是会出现的，比如：
          使用CF CG有关的函数，内存的释放还是需要手动调用的,不调用则会造成内存泄漏
          
          CFUUIDRef和CFStringRef都需要手动释放
       
           
           CGImageRef类似也需要手动释放
 
       在iOS中，怎么避免内存泄漏的产生呢？除了开发经验的积累，我们也可以通过两个方法来发现内存泄漏，以便及时修复，一个就是上面讲到的静态分析(Analyze)，比较简单；对于静态没有检测出来的内存泄露问题，需要使用动态的方法，下一节来分享。

 

       2. 无效数据监测（Dead store）

         Unused、Never read....这个比较简单，修改即可。

 

       3. 逻辑错误监测（Logic error）

         

       Tag不等于1、2和3的时候，就会出现很问题了。len is a garbage value。建议在声明变量时，同时进行初始化。

 

       4. 其他一些warning

       对完美主义者来说，warning在Xcode里始终都比较碍眼，直接消除。

 

六、Instruments分析

       Analyze分析内存泄露不能把所有的内存泄露查出来，有的内存泄露是在运行时，用户操作时才产生的。在 C、C++混编时，对于C++的内存分配，也是需要手动释放，比如iOS中使用Openssl来进行RSA的加解密操作，其中就有很多的内存操作，如果不进行手动释放，Analyze是检查不出来的，这个时候就需要用到Instruments了。

        初始化
        
        释放的代码注释掉
        
        这个时候使用Analyze分析，一点内存泄漏也没有，我们使用Instruments来分析
 
        "Product” -> “Profile"：
        

        按上面操作，build成功后跳出Instruments工具，选择Leaks工具，这时候Instruments工具就运行起来了，显示效果如下：
         
 

        点击上面的”红色的圆圈”，才会启动对应的APP，这时”红色的圆圈”变成”黑色的正方形”：
        
 

        这时用户就可以在APP上任意操作，查看内存使用情况，选择”Leak Checks”项，右边的图中，如果是”绿色的勾”表示内存使用正常，”红色的叉”则表示有内存泄漏，这时点击”黑色的正方形”，让APP暂停下来。
         
 
        这时你只要在”Reponsible Frame”中双击对应的方法，就会跳转到具体的代码，比如双击”MS_RSA_Public_E”:
        
       代表malloc后没有使用free释放OutBuf的内存。
 
       修改如下:

       

转自：http://crash.163.com/#news/!newsId=12?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io