2021年大厂iOS 面试题 - 前篇

Swift好多坑,一个人填不来,怎么办

问身边同事吧,又怕被暗笑技术差劲

1、如何追踪app崩溃率,如何解决线上闪退

当iOS设备上的App应用闪退时,操作系统会生成一个crash日志,保存在设备上。crash日志上有很多有用的信息,比如每个正在执行线程的完整堆栈跟踪信息和内存映像,这样就能够通过解析这些信息进而定位crash发生时的代码逻辑,从而找到App闪退的原因。通常来说,crash产生来源于两种问题:违反iOS系统规则导致的crash和App代码逻辑BUG导致的crash,下面分别对他们进行分析。

1.1、违反iOS系统规则产生crash的三种类型

(1) 内存报警闪退

当iOS检测到内存过低时,它的VM系统会发出低内存警告通知,尝试回收一些内存;如果情况没有得到足够的改善,iOS会终止后台应用以回收更多内存;最后,如果内存还是不足,那么正在运行的应用可能会被终止掉。在Debug模式下,可以主动将客户端执行的动作逻辑写入一个log文件中,这样程序童鞋可以将内存预警的逻辑写入该log文件,当发生如下截图中的内存报警时,就是提醒当前客户端性能内存吃紧,可以通过Instruments工具中的Allocations 和 Leaks模块库来发现内存分配问题和内存泄漏问题。

作为一个开发者,有一个学习的氛围跟一个交流圈子特别重要,这是一个我的iOS交流群:834688868,不管你是小白还是大牛欢迎入驻 ,分享BAT,阿里面试题、面试经验,讨论技术, 大家一起交流学习成长!

群内提供数据结构与算法、底层进阶、swift、逆向、flutter,整合面试题等免费资料
附上一份收集的各大厂面试题(附答案) ! 群文件直接获取
最新各大厂面试题以及进阶资料
他人很机灵,项目组的前辈们也愿意点拨他,所以,他手很快。

(2) 响应超时

当应用程序对一些特定的事件(比如启动、挂起、恢复、结束)响应不及时,苹果的Watchdog机制会把应用程序干掉,并生成一份相应的crash日志。这些事件与下列UIApplicationDelegate方法相对应,当遇到Watchdog日志时,可以检查上图中的几个方法是否有比较重的阻塞UI的动作。

application:didFinishLaunchingWithOptions: 
applicationWillResignActive:
applicationDidEnterBackground: 
applicationWillEnterForeground:
applicationDidBecomeActive:
applicationWillTerminate:

(3) 用户强制退出

一看到“用户强制退出”,首先可能想到的双击Home键,然后关闭应用程序。不过这种场景一般是不会产生crash日志的,因为双击Home键后,所有的应用程序都处于后台状态,而iOS随时都有可能关闭后台进程,当应用阻塞界面并停止响应时这种场景才会产生crash日志。这里指的“用户强制退出”场景,是稍微比较复杂点的操作:先按住电源键,直到出现“滑动关机”的界面时,再按住Home键,这时候当前应用程序会被终止掉,并且产生一份相应事件的crash日志。

1.2、应用逻辑的Bug

大多数闪退崩溃日志的产生都是因为应用中的Bug,这种Bug的错误种类有很多,比如

  • SEGV:(Segmentation Violation,段违例),无效内存地址,比如空指针,未初始化指针,栈溢出等;
  • SIGABRT:收到Abort信号,可能自身调用abort()或者收到外部发送过来的信号;
  • SIGBUS:总线错误。与SIGSEGV不同的是,SIGSEGV访问的是无效地址(比如虚存映射不到物理内存),而SIGBUS访问的是有效地址,但总线访问异常(比如地址对齐问题);
  • SIGILL:尝试执行非法的指令,可能不被识别或者没有权限;
  • SIGFPE:Floating Point Error,数学计算相关问题(可能不限于浮点计算),比如除零操作;
  • SIGPIPE:管道另一端没有进程接手数据;

常见的崩溃原因基本都是代码逻辑问题或资源问题,比如数组越界,访问野指针或者资源不存在,或资源大小写错误等。

1.3、crash的收集

如果是在windows上你可以通过itools或pp助手等辅助工具查看系统产生的历史crash日志,然后再根据app来查看。如果是在Mac 系统上,只需要打开xcode->windows->devices,选择device logs进行查看,如下图,这些crash文件都可以导出来,然后再单独对这个crash文件做处理分析。

<ignore_js_op>[图片上传中…(image-b1ea04-1554465565925-3)]</ignore_js_op>

看日志

市场上已有的商业软件提供crash收集服务,这些软件基本都提供了日志存储,日志符号化解析和服务端可视化管理等服务:

开源的软件也可以拿来收集crash日志,比如Razor,QuincyKit(git链接)等,这些软件收集crash的原理其实大同小异,都是根据系统产生的crash日志进行了一次提取或封装,然后将封装后的crash文件上传到对应的服务端进行解析处理。很多商业软件都采用了Plcrashreporter这个开源工具来上传和解析crash,比如HockeyApp,Flurry和crittercism等。

<ignore_js_op>[图片上传中…(image-8de82e-1554465565925-2)]</ignore_js_op>

crash信息

由于自己的crash信息太长,找了一张示例:

1)crash标识是应用进程产生crash时的一些标识信息,它描述了该crash的唯一标识(E838FEFB-ECF6-498C-8B35-D40F0F9FEAE4),所发生的硬件设备类型(iphone3,1代表iphone4),以及App进程相关的信息等;

2)基本信息描述的是crash发生的时间和系统版本;

3)异常类型描述的是crash发生时抛出的异常类型和错误码;

4)线程回溯描述了crash发生时所有线程的回溯信息,每个线程在每一帧对应的函数调用信息(这里由于空间限制没有全部列出);

5)二进制映像是指crash发生时已加载的二进制文件。以上就是一份crash日志包含的所有信息,接下来就需要根据这些信息去解析定位导致crash发生的代码逻辑, 这就需要用到符号化解析的过程(洋名叫:symbolication)。

1.4、解决线上闪退

首先保证,发布前充分测试。发布后依然有闪退现象,查看崩溃日志,及时修复并发布。

2、什么是事件响应链,点击屏幕时是如何互动的,事件的传递。

<ignore_js_op>[图片上传中…(image-7b6265-1554465565925-1)]</ignore_js_op>

事件响应链

对于iOS设备用户来说,他们操作设备的方式主要有三种:触摸屏幕、晃动设备、通过遥控设施控制设备。对应的事件类型有以下三种:

1、触屏事件(Touch Event)

2、运动事件(Motion Event)

3、远端控制事件(Remote-Control Event)

2.1、响应者链(Responder Chain)

响应者对象(Responder Object),指的是有响应和处理事件能力的对象。响应者链就是由一系列的响应者对象构成的一个层次结构。

UIResponder是所有响应对象的基类,在UIResponder类中定义了处理上述各种事件的接口。我们熟悉的UIApplication、 UIViewController、UIWindow和所有继承自UIView的UIKit类都直接或间接的继承自UIResponder,所以它们的实例都是可以构成响应者链的响应者对象。

响应者链有以下特点:

1、响应者链通常是由视图(UIView)构成的;

2、一个视图的下一个响应者是它视图控制器(UIViewController)(如果有的话),然后再转给它的父视图(Super View);

3、视图控制器(如果有的话)的下一个响应者为其管理的视图的父视图;

4、单例的窗口(UIWindow)的内容视图将指向窗口本身作为它的下一个响应者

需要指出的是,Cocoa Touch应用不像Cocoa应用,它只有一个UIWindow对象,因此整个响应者链要简单一点;

5、单例的应用(UIApplication)是一个响应者链的终点,它的下一个响应者指向nil,以结束整个循环。

2.2、点击屏幕时是如何互动的

iOS系统检测到手指触摸(Touch)操作时会将其打包成一个UIEvent对象,并放入当前活动Application的事件队列,单例的UIApplication会从事件队列中取出触摸事件并传递给单例的UIWindow来处理,UIWindow对象首先会使用hitTest:withEvent:方法寻找此次Touch操作初始点所在的视图(View),即需要将触摸事件传递给其处理的视图,这个过程称之为hit-test view。

UIWindow实例对象会首先在它的内容视图上调用hitTest:withEvent:,此方法会在其视图层级结构中的每个视图上调用pointInside:withEvent:(该方法用来判断点击事件发生的位置是

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Dagger是网易杭州研究院QA团队开发的一个轻量级、运行稳定的WebUI自动化测试框架,主要基于Selenium及TestNg可以认为是对Selenium进行二次封装的一个框架(俗称 造轮子 )。之所以把这个轮子开源出来,主要在于经过了公司内部多个项目的实践,也取得了不错的成效,因此,希望开源以后可以对大家有所帮助及参考。 设计理念 Dagger首先是一个WebUI自动化框架,提供了赖以操纵浏览器的一些APIAPI数量不多,少于20个,但从实践上,已经基本涵盖95%的应用场景了(其余5%比较 个性 的自动化操作一般是封装在业务逻辑层面,有时候甚至会须要hack) Dagger其次是一个测试框架,使用TestNg管理和运行用例,TestNg相关断言内嵌于上述API中。因此,在我们的测试用例里面不应该看到单独的TestNg断言的 Dagger还是一种设计风格:简约。无论是Dagger框架本身还是基于Dagger编写的测试用例,都是十分light及straightforward的,以至于会让人感觉有点土。但实践中,这两者确保了低成本、易用性、可维护性 WebUI自动化从业界看,难推进,易烂尾,原因基本在于:维护成本高、运行速度慢、稳定性差 Dagger专注于WebUI自动化,从技术上克服了速度与稳定问题(见下文)。只封装够用的浏览器操作为API,并充分简化/强化这些API,以简约的风格去降低自动化的学习及使用成本。同时,在实践中,我们主要使用Dagger编写冒烟用例、其次是主干用例,少写逻辑复杂功能,不写边边角角功能,让用例也保持清爽(在整个自动化实施过程中,会定期进行用例Review),同样易于后期维护 主要特性 API极少,易于上手,详见这里. 提供比较完备的文档,便于快速入门,详见这里. 支持单机多浏览器并发执行,大大缩短用例执行时间,详见这里 通过修改TestNg源码实现失败用例自动重运行(详见这里)由此几乎消除WebUI自动化中常见的虚假失败 默认使用Chrome浏览器,原因详见这里 失败用例自动截屏 后续工作 加入Flex/Flash自动化支持 如何使用 Dagger十分适合中小型团队从零开始WebUI自动化,这样的话,只须要直接下载整个Dagger代码就行了,Dagger本身都已经配置好了,下载后看一下使用文档就可以直接开始写用例了 也可以把Dagger打成Jar包,导入已有的自动化框架中,详见这里 标签:Dagger  自动化测试
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值