对于任何程序来说,崩溃都是一件很难避免的事情,当然Android程序也不例外。在Android程序中,引起崩溃的多属于运行时异常或者错误,对于这些异常我们很难做到类似Checked Exception那样显式捕获,因而最终导致了程序崩溃。本文讲介绍一些如何处理崩溃的实践,比如收集崩溃的stacktrace,甚至如何避免出现程序已停止的对话框。
辛苦开发的应用终于顺利在 Play Store 上线了? 恭喜!—— 但您的开发工作还没有结束。
目录介绍 01.该库具有的功能 02.该库优势分析 03.该库如何使用 04.降低非必要crash 05.异常恢复原理 06.后续的需求说明 07.异常栈轨迹原理 08.部分问题反馈 09.其他内容说明 01.该库具有的功能 1.1 功能说明 异常崩溃后思考的一些问题 1.是否需要恢复activity栈,以及所在崩溃页面数据 2.crash信息保存和异常捕获,是否和百度bug崩溃统计sdk等兼容。是否方便接入 3.是否要回到栈顶部的那个activity(保存栈信息) 4.崩溃后需要收集哪些信息。手机信息,a
我们知道Java崩溃是在Java代码中出现了未捕获异常,导致程序异常退出,常见的异常有:NPE、OOM、ArrayIndexOutOfBoundsException、IllegalStateException、ConcurrentModificationException等等。 还有一类崩溃,也是我们不得不关注,那就是Native层崩溃,这类崩溃不像Java层崩溃那样比较清晰的看出堆栈信息以及具体的崩溃。每当遇到是都要查找分析,写这篇的目的是帮助自己做下记录,也希望能帮到有类似困扰的你,下面我们开始一起学习实践吧。 本文学习实践的demo以张绍文《Android开发高手课》中的例子进行。
当我们的app上线到应用市场之后,它发生了什么崩溃其实我们是不知道的。今天我们介绍一个方法来监控和收集用户手机上的异常崩溃同时上报给我们自己。
通过log,可以知道是imageview使用了被回收的bitmap导致的,可以具体看下崩溃地方的源码
在正方形寄存器中,我们在位图缓存上绘制客户的签名。这个位图是设备屏幕的大小,我们在创建它时发生了大量的内存不足(OOM)崩溃。
3.native层的崩溃收集可以使用编译好的breakpad.so。(参考 https://github.com/yinyinnie/breakpad-for-android.git)
开发一个手机应用有如此多的限制,比如硬件限制(CPU,内存,电池等等)。如果你的代码不是足够合理,那就准备迎接世界上最严重的问题吧:Crash。根据研究所示:
现在大部分应用都会有Java层的崩溃日志收集机制,一般就是程序crash后,展示一个上报界面,用户点击就上传了。 但是Native程序crash了,很少有做处理的,几个方面原因:
今天本来想写的题材没写完,于是就找了一篇我很久之前写的,比较简单的文章给大家看看吧。
前言 对app的线上bug的收集(友盟、云捕等)有时会得到这样的异常堆栈信息:没有一行代码是有关自身程序代码的。这使得对bug的解决无从下手,根据经验,内存不足OOM,Dialog关闭,ListVie
随着移动设备和系统的碎片化程度越来越高以及复杂的移动网络情况, 兼容性测试以及远程真机测试的重要性越来越突出。根据远程测试机/人员与开发者间的合作方式,可以分为以下几种服务:云测试服务、内测服务以及众测服务,相应的平台支持如下图。 云测试平台 云测试平台提供了远程租用真机的服务,通常是利用自动化框架来实现真机上的脚本自动化运行,或远程租用真机人工测试,或真人真机测试。由于Android端设备的种类众多,云测试服务在Android端应用广泛。国内外都提供了多种云测试平台。 1. Pefecto http:
大家都知道,现在安装Android系统的手机版本和设备千差万别,在模拟器上运行良好的程序安装到某款手机上说不定就出现崩溃的现象,开发者个人不可能购买所有设备逐个调试,所以在程序发布出去之后,如果出现了
示例代码下载 : http://download.csdn.net/detail/han1202012/8638801;
随着移动设备和系统的碎片化程度越来越高以及复杂的移动网络情况, 兼容性测试以及远程真机测试的重要性越来越突出。
来自学院内部学员 xinxi 同学的又一篇佳作,本文主要介绍了作者如何借助开源工具进行 Android 的稳定性测试,并在持续集成中使用,希望对大家有所帮助。
自Bugly上线以来,通过各位开发者的试用和口口相传,目前Bugly已经迎来了大批量的用户,在业内的反响只能用下图来形容: 当然也有很多程序员哥哥在使用的过程中遇到了一些问题,比如按照文档的引导流程正确接入了,但是上报的Crash文档却不可读,很难准确定位到Crash的所在。对于这个问题,小编跪抱技术哥哥们大腿,进行仔细查看,认真琢磨,发现原来都是符号表惹的祸。 说到这里,不禁有人要发问: 在产品开发的过程中,为了进行代码及产品保护,几乎所有的非开源App都会进行代码混淆。但是,当收集到崩溃信息后,
GC是垃圾收集的意思,内存处理是编程人员容易出现问题的地方,忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃,Java提供的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的,Java语言没有提供释放已分配内存的显示操作方法。Java程序员不用担心内存管理,因为垃圾收集器会自动进行管理。要请求垃圾收集,可以调用下面的方法之一:System.gc() 或Runtime.getRuntime().gc() ,但JVM可以屏蔽掉显示的垃圾回收调用。 垃圾回收可以有效的防止内存泄露,有效的使用可以使用的内存。垃圾回收器通常是作为一个单独的低优先级的线程运行,不可预知的情况下对内存堆中已经死亡的或者长时间没有使用的对象进行清除和回收,程序员不能实时的调用垃圾回收器对某个对象或所有对象进行垃圾回收。在Java诞生初期,垃圾回收是Java最大的亮点之一,因为服务器端的编程需要有效的防止内存泄露问题,然而时过境迁,如今Java的垃圾回收机制已经成为被诟病的东西。移动智能终端用户通常觉得iOS的系统比Android系统有更好的用户体验,其中一个深层次的原因就在于Android系统中垃圾回收的不可预知性。
在 onCompletion 代码块中进行收尾 时 , 如果是 因为异常导致 Flow 流收集元素失败 , 则可以 在 onCompletion 代码块中拿到异常信息 ;
自 HTML5 标准正式发布之后,其得天独厚的跨平台特性吸引了众多开发者的目光。 伴随着 HTML5 的发展,JavaScript 的重要性也在逐步增加,要说现在哪门语言最火的话,那一定是 JavaScript 了。 学了JavaScript 成为全栈工程师,迎娶白富美,步入人生巅峰,想想也是醉了。 但有个问题:很多开发者却并未考虑过收集 JavaScript 出错时抛出的异常信息。因为只要 JavaScript 异常后 App 不会崩溃,当没有发生过就好了。 或许,在浏览器时代,让用户刷新下页面,可以
一个应用App的启动速度能够影响用户的首次体验,启动速度较慢(感官上)的应用可能导致用户再次开启App的意图下降,或者卸载放弃该应用程序。
内存处理是编程人员容易出现问题的地方,忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃。
在今年的 Google 游戏开发者峰会上,我们为开发者带来了各种工具和服务的更新和最新动态,这些工具和服务都旨在帮助您打造高质量的游戏体验,助力您的游戏业务稳步发展。本文将为您详细介绍如何使用它们,并帮助您的游戏取得成功。
借助系统DropBoxManagerService对于系统文件目录dropbox管理的设计,了解其文件管理的规则、运行机制、读写机制、管控机制,根据其设计一个客户端日志文件管理与上报功能
今天是程序员节,各位朋友们过得好吗?深圳的天气终于变了,现在我也穿起了长袖,距离我的GoodWeather开发已经过去一年多的时间了,这个App我是完全开源,并且把开发的步骤都公布了出来,在开发过程中我遇到过很多问题,刚好借着这个机会来说一下。
谈到移动APP开发的优化方案,开发者第一时间会想到关于GPU渲染和CPU优化问题,而这两大方案确实是优化app的两把尖刀,使APP提升用户量和体验度有较高的推动力。然而我们却会忽视一个比较简单而又难记住的方面,是对用户潜在行为的预估和把控,其实也属于APP业务优化范畴。 在无法预估的就是用户的实用操作欲望的情况下,针对已经发出去的版本,我们很难知道用户喜欢什么功能,和想要怎样的功能,包括用户卸载了,甚至安装不用的情况,并且对潜在线上崩溃的问题也想知道问题出在哪里等等 ,这些对于app的成长优化也有关键的导向作用,其实这也可以算是一种对app的优化方案。
对于应用开发者而言,衡量应用成功最好的指标就是开心的用户,而且是越多越好。达到这一目的的最佳途径就是开发一个好应用,那么什么样的应用才能被称作是 “好” 应用呢?归根结底就是两件事:功能以及应用质量。前者取决于开发者的创造力以及选用的商业模型;而后者则能够被客观测量及改善。
有时候由于测试不充分或者程序潜在的问题而导致程序异常崩溃,这个是令人无法接受的,在android中怎样捕获程序的异常崩溃,然后进行一些必要的处理或重新启动 应用这个问题困恼了我很久,今天终于解决了该
对于一个应用开发者来说,没有比开心的用户更好的衡量成功的标准,而且最好是有很多这样的用户。实现这一目标的最佳方式是拥有一个人人都想用的优秀应用,不过我们所说的“优秀”指的是什么呢?它可以归结为两件事:功能和应用质量。前者最终取决于你的创造力和选择的商业模式,而后者可以客观地衡量和改进。
作者 / Yafit Becher, Product Manager & Ray Brusca, Strategic Partnerships Manager
最近在友盟收集的错误列表中,发现有个问题使得蛮多用户闪退的。根据错误信息定位到,是由于图片轮播控件com.youth.banner使用Glide异步加载图片时发生的崩溃。在开发及测试过程中,并没有发生这个问题,话不多说,直接分析错误信息。
大家都知道,我们在测试过程当中,都会遇到crash,那么我们需要收集这些日志,然后给开发处理,正常的情况下呢,我们都会去抓log来实现的。我们常用的就是.
本文的内容是关于 React Native 重写的经验分享,基于 React Native 重写 Ionic 应用Growth 过程中遇到的一些坑。 Growth 是一款专注于Web开发者成长的应用。其 1.0 和 2.0 主要使用 Ionic 实现,Ionic 1.x 的主要问题是 Angular 1.x 已经落后了。而 Ionic 2.x 则在启动的性能上不是让人满意——其实在开源方面,我是中 HDD(热闹驱动开发)的一员。 在重写的过程中,我们错误估计了其开发效率与 Ionic 2.x 是接近的,我们
在使用自己开发的android应用时,偶尔会出现 系统已停止运行 错误.这时候如果能记录错误日志,是非常有帮助的。
之前在分享的时候,都是分享一些app测试相关的,最近在研究崩溃相关的,在学习过程中,用到了bugly来收集,如何使用bugly呢,在app接入的过程中,总结了一些自己的踩过的坑。在这里分享给大家。
移动应用App的测试,往往是非常繁琐、而又重复性的工作,很多开发者在测试工作过程中浪费了大量的时间和精力,而且还得不到满意的结果。大的公司一般都会配备专业的测试人员,可是专业测试人员的成本相对较高,创
由于国内 Android 开发环境的特殊性,兼容性一直是很多开发者极为关注的问题。为此,我们特意请来了负责 Android 在中国兼容性问题的 Google 工程师为大家对一些常见问题做出解答,来看看我的工程师提到了哪些要点吧! "大家好,我是谷歌的开发技术推广工程师,主要负责 Android 在中国的兼容性问题。我们发现,每次有 Android 新版本发布时,国内有很多应用由于没有遵循最佳开发实践,或使用了依赖于底层非公开 API 的 “黑科技”,而无法直接在新版本上运行,必须做出相当的代码修改来进行兼容
微软利用 GitHub 的 CodeQL 发现其源代码是否在 SolarWinds 供应链攻击中被修改。为了调查 SolarWinds Orion 软件更新中植入的恶意软件,微软开源了其使用的 CodeQL 查询。微软使用 CodeQL 查询分析其源代码,确认其源代码中没有与 SolarWinds 事件相关的泄密指标和编码模式。
于是,我们发现, 正无穷大 的定义居然是 1.0f/0.0f 。 负无穷大 的定义为**-1.0f/0.0f**, 非数 的定义为 0.0f/0.0f
最近在群里看到有人在讨论有关内存分析的话题,比较好奇,Enmmm,也就有了今天这篇博文。
Monkey是Android中的一个命令行工具,可以运行在模拟器里或实际设备中。它向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等),实现对正在开发的应用程序进行压力测试。Monkey测试是一种为了测试软件的稳定性、健壮性的快速有效的方法。
这位同学,你是不是没有睡醒,我问的是异常日志,是你未知状态的异常,难道你要把整个项目try住?
在大学做了一个app,然后发布到百度手机助手和小米应用商店了,现在下载量达到了2万,但是估计拆卸量也挺高的。
原文 / Fred Chung · Android 开发者平台技术推广 我们刚刚推出了 Android P 的开发者预览版,旨在让开发者提早体验下一个 Android 版本,从而为您的应用作出兼容性的
可以很明显的看到,就是addCircle方法发生的崩溃,崩溃的地方是系统类Path的方法
在一个迭代开发完毕之后,ci构建好测试包,交给测试人员进行测试,随后在测试的过程中,出现了一些问题,有些很容易追踪,比如一些逻辑bug,需求没有实现,但还是有一些需要花费一些经历去排查,比如:
本文实例讲述了Android编程实现捕获程序异常退出时的错误log信息功能。分享给大家供大家参考,具体如下:
领取专属 10元无门槛券
手把手带您无忧上云