关于app 的稳定性的报告

续之前的“ App再瘦身 ”。

这个帖子整理我遇到过的iPhone App Crash 类型以及解决办法。Crash 原因有很多,不同技术所导致的Crash 会不同。整理出来的经验应该会相对片面,有错误的地方和任何问题,请毫不犹豫的指出。

保证App 持续稳定运行是非常必要的,开发人员应该把维护产品稳定性、提高产品性能意识融入到每次编写代码过程当中,这也是很多公司考察优秀开发人员的一个重要环节。

Crash 原因
Crash 原因有共性,归纳起来有:
• 内存管理错误
• 程序逻辑错误
• SDK 错误 (部署版本< 编译版本)
•  主线程阻塞


内存管理错误
内存管理是iPhone 开发所要掌握的最基本问题,特别是使用引用计数手动管理内存的情况。内存管理错误包括:
• 内存泄漏:未释放不会再使用对象。比如alloc 忘记release,malloc 忘记free 。可用XcodeProduct 菜单下的Analyze 功能来解决该问题;
• 引用出错:引用已经被释放的对象指针。很多“莫名其妙”的Crash 都是由于窗体经历的生命周期所导致的(viewDidUnload viewDidLoad ),在iOSSimulator 里模拟内存警告就可以解决该问题;

• 内存警告:App 使用的内存超出设备的限制,iOS 将强制挂起App ,强制挂起iOS 是不会记录Crashlog Flurry 也无法记录。内存泄漏、快速/ 大量的分配内存都可能导致内存警告,这时候应该尽可能的释放不需要的资源。通过Instruments->Allocations 里的Heapshot 功能能够找出哪些资源未被释放。


WWDC 2012 Session242 - iOS App Performance_ Memory 是专门讨论内存管理这个话题。

程序逻辑错误
数组越界、堆栈溢出、并发操作、逻辑错误。扎实的编码基础、严谨细致的工作习惯、清晰的思路可以避免这类错误;

SDK错误
这个错误出现的现象是有的设备运行正常,有的会Crash 。原因是未找到框架、类、方法、属性。比如:用iOS5.0 SDK 编译并运行在iOS4.0 的设备上,5.0 Twitter 框架在4.0 的设备上找不到。这种问题常出现在用苹果新发布的Xcode 编译原有的工程。
未找到框架的解决办法是:部署版本>= 编译版本。iOS 框架向后兼容做的很棒,部署版本> 编译版本一般不会出现问题。
未找到 类、方法、属性 的解决办法是: 先判断是否存在再使用
if(NSClassFromString(@"MFMailComposeViewController"))
respondsToSelector:

主线程阻塞
主线程阻塞超过10s iOS 将强制挂起App 。把长时间的任务放到后台线程去执行,可使用NSThread,NSOperation, dispatch WWDC2012 Session235 - iOS App Performance_ Responsiveness 有详细的介绍。

解决 Crash
思路是:定位Crash 的程序代码,预测Crash 原因,寻找解决方案,测试。


有多种方式可以定位Crash 的程序代码:
• Debug 模式时,iOSSimulator 断点测试定位Crash 的堆栈;
• 真机连接iTunes 查看Crashlog (Debug 模式下)
• 通过Flurry 的错误记录查看;

定位之后,就是重新思考程序上下文逻辑,并有理由的预测Crash 出现的原因。预测的越多,理解的越深。

寻找解决方案的方法有:
• 浏览苹果官方SDK 文档,找出错误原因;
• Google 搜索Crash 输出的信息,重点查找行业内技术论坛:cocoachina stackoverflow iphonedevsdk 等;
• 查看历届WWDC 的视频、示例代码;
• 在工程里添加环境变量: NSZombieEnabled NSDebugEnabled ,输出有价值的信息;
• 如果未找到任何信息,可以寻求 苹果官方论坛 、业内技术论坛的帮助;


测试
找到解决方案后就需要测试,测试功能输入输出的准确性、程序性能、是否引入新的bug 。测试有专业的测试工程师来负责,但开发工程师不能依赖测试工程师来发现问题,尽量独立解决已知存在的问题。
由于Xcode 部署工程到真机上比较耗时间,如果可以的话尽可能用iOSSimulator 来测试,以减少测试的时间。

建议开发工程师有一个checklist ,在产品测试时自己逐一过一下上面常见的问题,这个能够避免大部分Crash 。下图是我们一个产品的FlurryError 记录,那120 个错误Session 是测试Crash 时留下的。当然这个记录是没有包括iOS 将强制挂起App 的情况。



  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
本次测试采取负载测试、并发测试、可靠性测试。测试方案采取模拟真实用户使用场景,模拟指定人数在一定时间点击界面产生的请求数。 在并发10(单位个/s)、20、40、80、160、500、1000、2000的基准下,调整用户数(虚拟用户用一个线程,下统称线程数)、点击准备时间(用户点击时间模拟时间,下称Ramp-up单位秒)和用户点击次数(下称循环),例如10个用户,每个用户每5秒点击1次,则线程数为10,Ramp-up为5,循环数为1。详细测试策略请看2.1。 对登录、数据新增(用户)、编辑(用户)、获取(用户)和删除(用户)进行负载测试,获得其稳定负载值。 对全站使用策略100-100-1-1进行并发测试,挑选用户服务所有接口。基础数据服务中挑选和用户服务关联的功能接口5个,组织结构接口4个,和用户服务无关的行政区3个接口。具体接口请查看附件1。 对全站进行可靠性测试,根据以上测试接口,选择稳定的并发数后持续测试-模拟时长8+小时。 稳定性测试是通过运行状态和资源指标的2个方面来分析及评估系统的稳定性,请求记录项响应的时间平均值、最小值、最大值、标准偏差、异常(百分比)、吞吐量、接收、发送、平均字节数,服务器资源指标CPU、Memory,在此额外添加记录数据库数据。通过调试测试策略、分析实验数据得出相关系统稳定性的结论,从而达到平台能力验证、规划能力、性能调优、缺陷发现等目的。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值