13、主线程任务太多导致异常退出(The application may be doing too much work on its main thread)...

今天花费了一天的时间来解决这个bug。

这种在程序运行期间出现的问题比较棘手,如果再没有规律的话就更难解决。

还好这个bug是由规律的,也就是说在程序执行半个小时左右后就会因为此异常而导致程序退出;那么在网上找了下原因,无非是说一下几点:

1、把业务放在子线程中去完成,然后通过handler来更新界面

2、通过runOnUiThread的方法来实现

再补充一点就是:优化代码,将不需要重复执行的代码执行一次就ok了,特别是需要绘制UI的代码更不能随便放在重复执行的地方

 

 

 

一、bug现场还原

我的程序就是类似一个会自动播放图片的网络图片浏览器

通过定时器来每隔10s去执行一次图片的网络请求,得到图片后设置为imagview将要显示的图片;通过这两步基本就完成基本需求了。

但是当程序在运行30分钟,也就是播放了100多张不同的照片后,出现了“Skipped 62 frames!  The application may be doing too much work on its main thread”这样的bug,同时还伴随“GC_FOR_ALLOC freed 2755K, 18% free 13874K/16884K, paused 3753ms, total 3756ms”这样的错误

 

二、bug出现的原因

从报出的异常本身来说,意思就是主线程任务太重,内存耗用太多。但是我用的是BitmapUtils这个工具库,只有第一次会进行网络请求,之后就会用默认的缓存数据

所以说问题肯定不在网络请求数据这块,那就是在imageVIew设置图片资源这里。

仔细看看,不应该有问题啊,就这几个代码:

1 linearParams = new RelativeLayout.LayoutParams(
2                         CommonUtils.getScreenWidth(contextShowCall), CommonUtils.getScreenHeight(contextShowCall));
3 imageView.setLayoutParams(linearParams);
4 String imgUrl = "http://"+QiNiuBucketName+".com1.z0.glb.clouddn.com/image-"+pic_casted_index+".jpg"; 5 6 relativeLayoutShowCall.setBackgroundDrawable(new BitmapDrawable(lastBitMap)); 7 bitmapUtils.display(imageView, imgUrl, bigPicDisplayConfig, callback);

从代码上来看,前3行的代码,在imageView在程序其他地方没有对其修改的前提下,是不用重复设置的。将前三行代码放到程序初始化的地方,再运行程序后,发现运行2小时内暂时未发现问题。

问题锁定在了这3行代码:重复从内存中申请变量,重复设置控件的宽度和高度,再加上必须得重绘图片,对于主线程来说确实任务较重,那么通过将调整代码后确实减轻了主线程的任务量(只是重绘imageView的图片就可以了)。

 

总结:

1、对于在程序运行期间出现的bug,要寻找规律,寻找规律的方法之一就是在多个设备同时执行同一程序,进而快速定位错误出现的时间点和错误日志

2、最好是在程序异常时能够保证100%将异常数据发送到开发者邮箱或者管理工具,很抱歉,我还没找到一款能符合条件的(国外的mint splunk、国内的友盟都做不到100%)

3、eclipse的logcat默认只可以缓存5000条数据,可以这样设置,从而方便查看系统log:

 

转载于:https://www.cnblogs.com/kunyashaw/p/4302059.html

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
你的Web服务器和应用到底能够支持多少并发用户访问?在出现大量并发请求的情况下,软件会出现问题吗?这些问题靠通常的测试手段是无法解答的。本文介绍 了Microsoft为这个目的而提供的免费工具WAS及其用法。另外,本文介绍了一种Web应用的性能优化方法,并利用WAS测试了它的性能改善程度。 随着服务器端处理任务的日益复杂以及网站访问量的迅速增长,服务器性能的优化也成了非常迫切的任务。在优化之前,最好能够测试一下不同条件下服务器的性能表现。找出性能瓶颈所在是设计性能改善方案之前的一个至关紧要的步骤。    本文介绍Microsoft的Web Application Stress Tool(WAS,Web应用负载测试工具)在Web服务器性能测试中的应用(注:Stress基本含义为“重压;压力”等,本文称之为“负载”)。另 外,我们还将通过WAS评估一种相对简单的网站性能改善方法,这种方法的基本思想是在服务器上生成静态的HTML页面、避免过多的数据库调用。   负载测试是任何Web应用的开发周期中一个重要的步骤。如果你在构造一个为大量用户服务的应用,搞清楚你的产品配置能够承受多大的负载非常重要。如果你在构造一个小型的Intranet网站,测试能够暴露出最终会导致服务器崩溃的内存漏洞以及竞争情况。 无论是哪种情形,花些时间对应用进行负载测试可以获得重要的基准性能数据,为未来的代码优化、硬件配置以及系统软件升级带来方便。即使经费有限的开发组 织也可以对它们的网站进行负载测试,因为Microsoft的WAS是可以免费下载的。WAS要求Windows NT 4.0 SP4或者更高,或者Windows 2000。为了对网站进行负载测试,WAS可以通过一台或者多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies,也能够模拟各种浏 览器类型和Modem速度,它的功能和性能可以与数万美元的产品相媲美。如果你对WAS和Microsoft的另外一个测试工具Web Capacity Analysis Tool (WCAT)之间的差别感兴趣,可以访问Microsoft Web工具的比较页面。 要对网 站进行负载测试首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法之一创建脚本:通过记录浏览器的活动;通过导入IIS日志;通过把WAS指向 Web网站的内容;或者手工制作。图1所显示的是通过记录浏览器事件生成的脚本的一部分,网站是Microsoft的Duwamish Book Store。Duwamish是Microsoft开发的电子商务Web应用示例,从Duwamish网站的“Phase 4”链接可以下载这个软件包。下载包中包含了它自己的WAS测试脚本。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值