李洪强iOS经典面试题141-报错警告调试

时间:2023-03-08 17:44:45
李洪强iOS经典面试题141-报错警告调试

李洪强iOS经典面试题141-报错警告调试

报错警告调试

你在实际开发中,有哪些手机架构与性能调试经验

  • 刚接手公司的旧项目时,模块特别多,而且几乎所有的代码都写在控制器里面,比如UI控件代码、网络请求代码、数据存储代码
  • 接下来采取MVC模式进行封装、重构
    • 自定义UI控件封装内部的业务逻辑
    • 封装网络请求工具类(降低耦合)
    • 封装数据存储工具类

BAD_ACCESS在什么情况下出现?

这种问题是经常遇到的,在开发时经常会出现BAD_ACCESS。原因是访问了野指针,比如访问已经释放对象的成员变量或者发消息、死循环等。

如何调试BAD_ACCESS错误?

出现BAD_ACCESS错误,通常是访问了野指针,比如访问了已经释放了的对象。快速定位问题的步骤有:
1. 重写对象的respondsToSelector方法,先找到出现EXECBADACCESS前访问的最后一个object
2. 设置Enable Zombie Objects
3. 设置全局断点快速定位问题代码所在行,接收所有的异常
4. Xcode7已经集成了BAD_ACCESS捕获功能:Address Sanitizer,与步骤2一样设置
5. analyze也行(不一定管用)

什么时候会报 unrecognized selector 异常?

  • 当调用对象(子类,各级父类)中不含有对应方法的时候,并且依旧没有给出“消息转发”的具体方案的时候,程序在运行时会crash并抛出 unrecognized selector 异常

  • objective-c 中的每个方法在运行时会被转为消息发送objc_msgSend(reciver, selector)

  • 例如 [person say]就会被转化为 objc_msgSend(person, @selector(say))

  • 运行时会根据对象(reciever) 的isa 指针找到该对象所对应的类,然后会依次在对应的类,父类,爷爷类,根类中找对应的方法

下面只讲述对象方法的解析过程:

  • 第一步:+ (BOOL)resolveInstanceMethod:(SEL)sel实现方法,指定是否动态添加方法。若返回NO,则进入下一步,若返回YES,则通过class_addMethod函数动态地添加方法,消息得到处理,此流程完毕。
  • 第二步:在第一步返回的是NO时,就会进入- (id)forwardingTargetForSelector:(SEL)aSelector方法,这是运行时给我们的第二次机会,用于指定哪个对象响应这个selector。不能指定为self。若返回nil,表示没有响应者,则会进入第三步。若返回某个对象,则会调用该对象的方法。
  • 第三步:若第二步返回的是nil,则我们首先要通过- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector指定方法签名,若返回nil,则表示不处理。若返回方法签名,则会进入下一步。
  • 第四步:当第三步返回方法方法签名后,就会调用- (void)forwardInvocation:(NSInvocation *)anInvocation方法,我们可以通过anInvocation对象做很多处理,比如修改实现方法,修改响应对象等
  • 第五步:若没有实现- (void)forwardInvocation:(NSInvocation *)anInvocation方法,那么会进入- (void)doesNotRecognizeSelector:(SEL)aSelector方法。若我们没有实现这个方法,那么就会crash,然后提示打不到响应的方法。到此,动态解析的流程就结束了。

有哪些常见的 Crash 场景?

  • 访问了僵尸对象
  • 访问了不存在的方法
  • 数组越界
  • 在定时器下一次回调前将定时器释放,会Crash

lldb(gdb)常用的调试命令?

•    p 输出基本类型//p (int)[[[self view] subviews] count]
• po 用于输出 Objective-C 对象//po [self view]
• expr 可以在调试时动态执行指定表达式,并将结果打印出来。常用于在调试过程中修改变量的值。//源代码中 a = 1 ;expr a=2 输出结果:(int) $0 = 2

如果一个函数10次中有7次正确,3次错误,问题可能出现在哪里?

这样的问题通过应聘者的分析,可以知道应聘者的功底如何。很多人的回答会是很简单的,没有从多方面去分析。这样的问题也是很有意义的,在项目开发中所产生的bug,有的时候会出现这样的情况,而代码量比较大且业务比较复杂时,通过其他工具并不能分析出来是什么bug,但是我们却可以根据出现的频率推测。笔者把这个问题当作测试部反馈过来的bug描述问题来分析一下。
参考答案:
从问题描述可知,bug不会必现的,因此无法直接定位出错之处。从以下角度出现来分析可能出错之处:
1. 因出错并不是崩溃,因此没有错误日志可看。第一步就是分析函数中的所有分支,是否在语法上存在可能缺少条件的问题。所以,检查所有的分支,确保每个分支执行的结果的正确的
2. 检测函数的参数,保证必传参数不能为空,若为空应该抛出异常。因此,用断言检测参数的正确性是很重要的。
3. 检测函数中每个分支所调用的函数返回结果是正确的,其实就是一个递归的过程(步骤1、2)

你一般是如何调试Bug的?

这个问题看起来很笼统,但又一针见血。通过应聘者的回答,可很直观地看出这个应聘者的处理bug的能力,以及其解决问题的思维。
参考答案:
Bug分为测试中的Bug和线上的Bug:
• 线上Bug:项目使用了友盟统计,因此会有崩溃日志,通过解析dYSM可以直接定位到大部分bug崩溃之处。解决线上bug需要从主干拉一个新的分支,解决bug并测试通过后,再合并到主干,然后上线。若是多团队开发,可以将fix bug分支与其他团队最近要上线的分支集成,然后集成测试再上线。
• 测试Bug:根据测试所反馈的bug描述,若语义不清晰,则直接找到提bug人,操作给开发人员看,最好是可以bug复现。解决bug时,若能根据描述直接定位bug出错之处,则好处理;若无法直观定位,则根据bug类型分几种处理方式,比如崩溃的bug可以通过instruments来检测、数据显示错误的bug,则需要阅读代码一步步查看逻辑哪里写错。
对于开发中出现的崩溃或者数据显示不正常,那就需要根据经验或者相关工具来检测可能出错之处。当然,团队内沟通解决是最好的。

获取一台设备唯一标识的方法有哪些?

  • 现在常用的是用UUID + keychain结合来实现这个需求。

  • UUID是Universally Unique Identifier的缩写,中文意思是通用唯一识别码。它是让分布式系统中的所有元素,都能有唯一的辨识资讯,而不需要透过*控制端来做辨识资讯的指定。这样,每个人都可以建立不与其它人冲突的 UUID。在此情况下,就不需考虑数据库建立时的名称重复问题。苹果公司建议使用UUID为应用生成唯一标识字符串。

//获取一个UUID
- (NSString*)uuid {
CFUUIDRef uuid = CFUUIDCreate( nil );
CFStringRef uuidString = CFUUIDCreateString( nil, uuid );
NSString * result = (NSString *)CFBridgingRelease(CFStringCreateCopy( NULL, uuidString));
CFRelease(uuid);
CFRelease(uuidString);
return result;
}
  • 现在我们获取到了一个UUID,虽然这个标识是唯一的,但是这样还是无法保证每一次的唯一性,因为当你每次调用这个方法或者把应用卸载了,UUID会重新生成一个不同的。这个时候keychain就起到了作用。
  • 所以整个逻辑是这样的:先从keychain取UUID,如果能取到,就用这个比对,如果取不到就重新生成一个保存起来。keychain独立在App之外,是和系统统一等级的,所以你不用担心它挂掉。
  • keychain是苹果公司Mac OS中的密码管理系统。它在Mac OS 8.6中被导入,并且包括在了所有后续的Mac OS版本中,包括Mac OS X。一个钥匙串可以包含多种类型的数据:密码(包括网站,FTP服务器,SSH帐户,网络共享,无线网络,群组软件,加密磁盘镜像等),私钥,电子证书和加密笔记等。iOS端同样有个keychain帮助我们管理这些敏感信息。

  • 使用过keychain保存过账号密码的童鞋应该对这个工具非常了解,在这里不做过多解释。使用keychain需要导入Security.framework和KeychainItemWrapper.h/.m,KeychainItemWrapper.h/.m搜一下可以下载下来,拖入工程中。保存UUID代码如下:

- (void)saveUuidWithKeyChain {
KeychainItemWrapper *keychainItem = [[KeychainItemWrapper alloc]
initWithIdentifier:@"UUID" accessGroup:@"com.xxx.www"];
NSString *strUUID = [keychainItem objectForKey:(id)kSecValueData];
if (strUUID == nil || [strUUID isEqualToString:@""])
{
[keychainItem setObject:[self uuid] forKey:(id)kSecValueData];
}
}
注:这个方法中accessGroup:这个参数如果一些App设置相同的话,是可以共享的。
  • 从keychain获取UUID的方法如下:
- (NSString *)getKeychain {
KeychainItemWrapper *keychainItem = [[KeychainItemWrapper alloc]
initWithIdentifier:@"UUID" accessGroup:@"com.xxx.www"];
NSString *strUUID = [keychainItem objectForKey:(id)kSecValueData];
return strUUID;
}
  • 至此,基本上唯一标识的几个方法算是写完了,大家可以测试一下,卸载应用再重新装,从keychain读取的UUID还是和之前一样。

  • 但这里有个不确定因素,就是手机系统恢复出厂设置或者抹掉所有数据的话,这个方法也可能不起作用了,因为它是依靠钥匙串在生存,钥匙串挂掉的话它也就失效了。

你一般是怎么用 Instruments 的?

  • 这个问题也就是考察下你经验如何了, Instruments里面工具很多,也没必要逐一说明,挑几个常用的说下就好

  • 参考答案:

  • Time Profiler:性能分析
  • Zombies:检查是否访问了僵尸对象,但是这个工具只能从上往下检查,不智能
  • Allocations:用来检查内存,写算法的那批人也用这个来检查
  • Leaks:检查内存,看是否有内存泄露

你一般是如何调试 Bug 的?

  • 查看异常报告
  • 配置相关环境,重现bug
  • 代码检查
  • 用测试案例来捕获bug
  • 可以请同事一同来审查问题,有些时候当局者迷,旁观者清。

如何对iOS设备进行性能测试?

Profile-> Instruments ->Time Profiler 进行性能测试!

测试iOS版的 App 注意事项分享以下几点:

1.app使用过程中,接听电话。可以测试不同的通话时间的长短,对于通话结束后,原先打开的app的响应,比如是否停留在原先界面,继续操作时的相应速度等。

2.app使用过程中,有推送消息时,对app的使用影响

3.设备在充电时,app的响应以及操作流畅度

4.设备在不同电量时(低于10%,50%,95%),app的响应以及操作流畅度

5.意外断电时,app数据丢失情况

6.网络环境变化时,app的应对情况如何:是否有适当提示?从有网络环境到无网络环境时,app的反馈如何?从无网络环境回到有网络环境时,是否能自动加载数据,多久才能开始加载数据

7.多点触摸的情况

8.跟其他app之间互相切换时的响应

9.进程关闭再重新打开的反馈

10.IOS系统语言环境变化时

文章如有问题,请留言,我将及时更正。