swift错误处理与调试

错误处理:

在编码中,如果在开发阶段,则尽可能暴露可导致错误或者崩溃的问题,这样所有问题在编码阶段或者测试阶段解决,不再遗留到发布版本后的使用阶段。

在此过程中错误处理和调试手段显得很重要,这章先讲错误处理:

使用oc做错误处理主要是进行防御性编程代码书写,类似对象为空或者数组越界时,

if(index <0  ||  index>array.count)  {

     return

}

swift中则引入了guard 表达式,也是先处理条件达不到的情况进行防御性编码,不过swift的可选类型使用是的代码更加简洁,例如task?.doTask(),这里就隐含了

if task != nil  {

    task.doTask

}

而oc在错误信息代码抓取并判断就没有swift的do catch机制了,现在swift的do catch中调用try类型的方法与java的try catch很像,相比较java灵活但是显得繁琐,如下图:


swift错误处理与调试_第1张图片
1

swift中的try有三种:

第一种如图1,程序员手动抓取并处理

第二种则是 try? riskFunc(),系统帮我们处理,如果异常,则返回nil,否则返回正确结果

第三种则是 try! riskFunc(),告诉系统方法没危险,一旦出错,会导致直接崩溃

try使用场景则是看方法说明,如果有throws标注,则建议进行异常处理,代码更健壮如下图:


swift错误处理与调试_第2张图片
2

注意方法说明的throws,位置在方法体中位置:->URLRequest前面,参数括号后面。

错误处理函数定义如:

func canThrowAnError() throws {

    // 这个函数有可能抛出错误

}

Xcode调试:

调试目的:

1.数据正确性判断(如数值是否在合理范围内)

2.崩溃处理(如出错代码定位)

3.代码流程确认

4.界面图层或者效果如动画

1和3都可以通过日志打印进行处理,oc中主要是NSLog这个类来打印,然后通过配置开发和生产环境来去掉生产环境的日志打印提升性能

此外数据正确性还可以使用断言,如:

let age = -3

assert(age >= 0, "A person's age cannot be less than zero")

// 因为 age < 0,所以断言会触发

此外先决条件也可以对数据错误做处理,例如:

precondition(index >0, "Index must be greater than zero.")

此外fatalError(_:file:line:)类似,例如自己封装的view不支持xib,则可以在initCoder方法中进行

2崩溃处理,包括线上崩溃和开发中的崩溃。

4图层调试主要是可以使用图层背景色设置以及图层截取

图层调试:

swift错误处理与调试_第3张图片
3

崩溃来源则主要是有:

1》Xcode官方反馈的渠道,在Xcode的Window-》Organizer中的crash,前提是你在Xcode的Preferrence中登陆了账号,这个可以多人共用。

2》类似友盟崩溃收集等第三方SDK,这个一般可以直接看到崩溃性代码和对应模块,如果看不到需要进行重复操作来复现,因为拿不到崩溃的收集,所以无法进行符号化定位崩溃

3》可拿到崩溃日志,主要是测试阶段,则可以直接进行(crash文件     dsYM文件symbolicatecrash)的符号化定位崩溃问题

通过上面几个方式确认的bug如果无法定位到准确代码,则需要使用到断点调试与日志打印了。

断点调试:

1.普通断点,这个可以用来跟踪代码执行流程,配合lldb指令(po xxx变量)查看实时数值或者属性的值,因此适合用来进行精细化代码定位。也就是已经确认了是某一个模块或者某几个函数出问题,最后的定位

2.条件断点,顾名思义,就是可以对断点的执行进行条件设置,如下图:

swift错误处理与调试_第4张图片
4这个可以对某个函数或者代码进行再进一步的分析,也可以直接使用逐步调试。如下图:
swift错误处理与调试_第5张图片
5

全局类型的Exception断点,用来跟踪无提示的crash,例如直接在main函数中崩溃的问题。

符号断点则可以在制定函数中执行调试操作,例如某个页面的某个方法

swift错误处理与调试_第6张图片
6

个人而言,定位bug一般使用exception配合一般断点就可以定位大部分的bug了。不过防患与未然是最好的解决方法如防御性代码、code review、单元测试也算,不过自己还没用过,汗一个-_-!

Analyze静态代码分析:

找出代码潜在错误,如内存泄露,未使用函数和变量等问题,个人使用一般是在项目提测之前,code review和自我功能逻辑测试阶段进行检测

swift错误处理与调试_第7张图片
7

1、逻辑错误:访问空指针或未初始化的变量等;

2、内存管理错误:如内存泄漏等; 比如ARC下,内存管理不包括core foundation

3、声明错误:从未使用过的变量;

4、Api调用错误:未包含使用的库和框架。

缺点: 静态内存分析由于是编译器根据代码进行的判断, 做出的判断不一定会准确, 因此如果遇到提示, 应该去结合代码上文检查一下

Instrument检测:

一般是进行内存泄漏和性能优化时使用,

swift错误处理与调试_第8张图片
8

这个后面会有专门一节讲这个,内存泄漏一般在运行时如果发现下图中内存有爆发性增长而不下降,则需要进行代码检查,如果代码模块确定,例如每次打开某页面退出后内存不下降则直接代码检查即可。若代码太多或者不确定具体模块,则使用instrument进行检查比较适合。

性能优化主要是有tableview或者collectionview的卡顿,动画的卡顿与内存优化。这个也在后面专门一节进行说明,一般的内容格式变化不多的应用开发时基本用不到,粗暴一点的直接使用AsyncDisplayKit即可。

僵尸对象:

iOS中把那些已经release但还没完全消失的对象叫做僵尸对象,对已经release的对象再次释放,就会发生异常。

补充:

OC中的野指针:  1个指针指向的对象已经被释放了.那么这个指针就叫做野指针

内存泄露" (栈区的指向已经释放, 堆区的空间没有释放, 这时堆区的空间就被泄露了)堆区,需要程序员手动管理

20180412

你可能感兴趣的:(swift错误处理与调试)