iOS开发质量提高速成篇

原创
2016/06/20 18:39
阅读数 61

       涉及到质量问题,这就是一个很大的话题,包括很多方面,比如代码书写的质量,开发流程的规范,项目管理的到位,测试的最后把关等各个环节。编码需要规范,命名需要有意义;接口低耦合、高内聚、易扩展,代码能重用、避免重复代码;提交代码后需要做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的内存。
 
      修改如下:
      

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部