前言 对app的线上bug的收集(友盟、云捕等)有时会得到这样的异常堆栈信息:没有一行代码是有关自身程序代码的。这使得对bug的解决无从下手,根据经验,内存不足OOM,Dialog关闭,ListVie
最近,收到两家大客户反馈的bug,都是我们android版本sdk报的bug。既然大客户给我们报bug了,那必须十分重视对待。
导语:最近实在是太忙了,没有怎么更新公众号,也没有怎么认真去写一些内容,在这里先给关注我的朋友说一声抱歉,可能在接下来的一段时间,还是很忙,但是我会争取抽空多分享一下技术文章,给大家看,共同进步,也希望有能力的人可以一起出来分享。 我们在做应用开发的时候,需要程序的崩溃信息,来进行bug的修复和版本的更新,每一个应用程序都会有bug,所以都需要在后台纪录这些bug日志,然后上传到服务器,让程序员看,并进行修复。现在也有很多第三方的jar包能实现这种功能,比如友盟统计等,但是终究不如自己写的方便。好了,废话不
Android OS由3层组成,最底层是Kernel,上面是Native bin/lib,最上层是Java层:
处理应用的bug,这是每个程序员的基本功,实际项目中天天都有各式各样的bug,因此学会如何使用Logcat、Android Lint以及Android Studio内置的调试器就非常有必要啦!
王竞原,负责网游刀锋铁骑项目,高级开发工程师,使用C++已有10年,非常喜欢C++,特别是C++11。希望能与广大的C++爱好者多交流。 一、什么是Android的C/C++ NativeCrash Android上的Crash可以分两种: 1、Java Crash java代码导致jvm退出,弹出“程序已经崩溃”的对话框,最终用户点击关闭后进程退出。 Logcat 会在“AndroidRuntime”tag下输出Java的调用栈。 2、Native Crash 通过NDK,使用C/C++开发,导致
本文由腾讯云加社区整理和发布,原文链接:cloud.tencent.com/developer/article/1004735,内容有删减和改动。
本人所在项目组主要负责一款Android平台产品的开发,因为用户量比较大,正式版本发布后,每天Crash次数的上报量都在几十万量级,即便是内测版,每天Crash次数的上报量也在两三千次。面对如此庞大的上报量,能否快速准确的定位问题直接关系到Crash的解决率,我们项目组在这方面做了比较多的尝试,现在在这里给大家分享一下比较有效的一些做法,也欢迎大家一起来探讨和分享。 1 利用Bugly平台的工具自动还原堆栈 刚接入Bugly的时候,看着大量混淆后的java堆栈,着实让人头大。每次定位问题都要到处找mappi
Android 的 Crash 是件让人头疼的事,测试阶段好好的代码一上线就各种崩溃,即使是一个微不足道的 bug 也得发个 hotfix。很多时候我们更希望即使个别功能没法使用也不要崩溃,比如点击图片想看大图时,由于 onClick 回调中没做判空处理等导致 APP 崩溃了,这时我们更希望即使不能看大图也不要崩溃,这时你可以考虑使用 Bandage,当然 Bandage的强大之处远不止这些。
没有代码,就没有bug。程序员在编码时,总会比不避免的出现bug。倒不是因为我们热爱制造bug,创造机会和测试妹子频繁沟通。而是现实情况很复杂,存在着很多不确定性。尤其是那些崩溃从stacktrace上来看,完全想象不到和项目代码之间的直接联系。
之前写过一篇热修复的文章,那时候刚开始接触,照猫画虎画的还算比较成功。但是那种修复需要重新启动APP,也就是在JAVA层实现的热修复。我们知道目前Android主流的修复还有在Native层实现修复的,就是在Native层替换方法,不用重新启动APP。今天写了个Demo,下面主要分享一下它的主要原理。
在日常开发的过程中应该不可避免的会发生 crash,无论你的程序写的多么完美,都不可能完全避免 crash 的发生,可能是由于 Android 底层的 bug,也可能是由于不充分的机型适配或者是糟糕的网络状况。当 crash 发生时,系统就会kill掉正在执行的程序,现象就是闪退,或者提醒用户程序已经停止运行,这对用户来说是很不友好的,也是我们不愿意看到的,更早的是当用户发生 crash,我们开发者却无法得知程序为何 crash,即便我们想去解决这个 bug,但是由于无法知道用户当时的 crash 信息,所以往往也无能为力,幸运的是,Andorid 提供了处理这类问题的方法,接下来我们就来一起看看到底 Android 给我们提供了什么方法来解决这个棘手的问题
行军打仗,你需要一个向导;如果没有向导,你需要一个地图;如果没有地图,至少要学习李广,找一匹识途的老马;如果你连老马也没有,那最好可以三个臭皮匠好好讨论,力图胜过一个诸葛亮;如果三个臭皮匠连好好讨论也做不到,那就是典型的乌合之众了,最好写代码前,点上三炷香,斟上一杯浊酒,先拜拜菩萨,再拜拜谷歌。
最近,手头上的项目基本开发完成,优化也做的差不多了,本以为可以安心准备上线。然而老板却反映说测试人员发现 App 总会出现一些莫名的 bug.
有时候开发完会发现莫名奇妙的bug,bug 来了咱不怕,那就解决呗。但是这 bug 贼得很,几个小时甚至几天出来调戏你一次,撒手就跑,就问你服不服。所以为了让 App 中的 bug 尽可能的减少,好好研究了下 Android 平台的自动化测试,在此总结一下。
楼主在写一个分类型recyclerivew的时候遇到了如上的错误,这就尴尬了,关键是没报问题出现在哪一行,这就有点懵逼了,然后打各种打log,debug,数据都没有问题,目测晚上搞了有两个多小时,没搞定...有点小失落
组内对于 React Native 的实践已经快一年了,我们组主要负责的是美团外卖 M 端的前端业务,涵盖了美团外卖的 CRM、供应链、合同和结算等系统,我们的用户主要是美团的 BD,也就是广大的地推团队,他们是贵司的制胜法宝,我们是他们的贴心小棉袄。
在使用 AccessibilityService 遍历包含 WebView 的 AccessibilityNodeInfo 时会在某些情况下必现 StackOverflowError 的错误,导致应用崩溃。
在做Android 项目的时候,有时候可能有这样的需求,将一个View 或者一个布局文件转换成一个Bitmap 对象。
在一个迭代开发完毕之后,ci构建好测试包,交给测试人员进行测试,随后在测试的过程中,出现了一些问题,有些很容易追踪,比如一些逻辑bug,需求没有实现,但还是有一些需要花费一些经历去排查,比如:
事情的起因是这样的,某天工作群里,我看到我们部门的同事guting发了这样一条消息。
在android开发过程中,我们经常遇到异常的问题,崩溃抛出异常的时候,是非常令人烦闷的。但是异常有一个好处,使得app能在编译的时候给我们提供一些bug信息,有时可能比较模糊,有时可能很精准,甚至提示报错行。基于这一点,今天我们就来讲讲android中的异常吧。
相信程序员们都有一个共同的女朋友。这个女朋友总是阴魂不散,时不时还不忘调戏下男朋友程序员,而且你依然对她欲罢不能、想入非非。
身为开发的我,在离职廊坊的某公司后,无数次的怀念小路童鞋,其测试专业性以及敬业程度让我曾经一度吐槽,你好烦。不过可以得瑟的是至少软件很湿稳定,至少没有出现过大型严重 Bug。
假如AndroidManifest.xml的 meta-data>CHANNEL 是渠道的标准
大家都知道,现在安装Android系统的手机版本和设备千差万别,在模拟器上运行良好的程序安装到某款手机上说不定就出现崩溃的现象,开发者个人不可能购买所有设备逐个调试,所以在程序发布出去之后,如果出现了
直接看重点部分------> 看log的第3行,大概意思是Java运行时进程异常,分析这应该是运行时的异常,不是代码问题,根据以往经验,首先查看gradle配置文件开始检查,发现在编译时多了出现了一个这样的一段代码:
目录介绍 01.该库具有的功能 02.该库优势分析 03.该库如何使用 04.降低非必要crash 05.异常恢复原理 06.后续的需求说明 07.异常栈轨迹原理 08.部分问题反馈 09.其他内容说明 01.该库具有的功能 1.1 功能说明 异常崩溃后思考的一些问题 1.是否需要恢复activity栈,以及所在崩溃页面数据 2.crash信息保存和异常捕获,是否和百度bug崩溃统计sdk等兼容。是否方便接入 3.是否要回到栈顶部的那个activity(保存栈信息) 4.崩溃后需要收集哪些信息。手机信息,a
根据需求编写测试用例,执行测试。单个功能(等价类、边界值、正常和异常)和交互功能。注意:功能测试点提取和用例设计方法都跟web测试一致,但是APP有-一些自己特性测试,也需要加到测试点中。
作为一名光荣而高大上的前端开发工程师,最痛苦的事情是什么?多年的搬砖经验告诉我,那一定是:
ActionBar的问题 Navigation View是Android Support Library中的一个新的组件,该组件提供类似于Sliding Menu的抽屉功能,在张兴业的博客中有讲解到具体的使用方法。作者用的貌似就是Google官方提供的例子,但是在使用过程中产生了不少的问题,主要原因是使用的编译环境不一样。 在原文中,有这样一段代码: getActionBar().setHomeButtonEnabled(true); getActionBar().setDisplayHom
概述 当Android应用程序出现未捕获的异常,都会弹出一个强制退出的弹框,在这种情况下,用户体验非常差。且发布到线上后,开发没法定位Bug的位置,这就需要一个能全局捕获异常,并且将这个异常log上传
要使用AccountManager类的每种方法,都需要在应用的AndroidManifest.xml中分别声明使用相应的权限。 表 5.3-1 显示了权限和方法的对应关系。
说起Android适配,恐怕是每一个Android开发/测试工程师心里的痛,且不论Android设备品牌众多、分辨率各异等痛点,单论Android版本的繁多也会提高Android APP的开发/测试成本。如果能了解Android版本之间的变更差异,会让开发/测试事半功倍。本文即是从这个角度出发,给读者带来一点福利。 故事的开始,须先来说说本文的主角:腾讯路宝,是一款驾车导航APP,腾讯MIG地图平台部打造出品的一款为广大驾车用户提供精准导航和路况的产品。 以下故事就是发生在这款APP上的,且等我慢慢叙来:
Monkey程序由Android系统自带,是Android SDK提供的一个命令行工具, 可运行Android模拟器和实体设备上。Monkey会发送伪随机的用户事件流,通过Monkey程序模拟用户触摸屏幕、滑动、 按键等操作来对程序进行压力测试,检测多长时间发生异常、会Crash、以及内存泄露检测可称为随机测试或稳定性测试。
本文实例讲述了Android编程实现项目中异常捕获及对应Log日志文件保存功能。分享给大家供大家参考,具体如下:
https://blog.csdn.net/weixin_45912307/article/details/109501092 1. Web 端测试和 App 端测试有何不同(常见)
有些时候由于Android系统的bug或者其他的原因,导致我们的webview不能验证通过我们的https证书,最明显的例子就是华为手机mate7升级到Android7.0后,手机有些网站打不开了,而更新了webview的补丁后就没问题了,充分说明系统的bug对我们混合开发webview加载https地址的影响是巨大的。那么我们怎么去解决这个问题呢?
最近在做低功耗蓝牙开发的时候突然遇到这样一个问题,出现这个情况的时候是我的一个App在Android12、和鸿蒙系统的手机上都正常的情况下,我用Android10去进行测试,然后出现这个问题,问题异常日志描述如下。
乍眼一看,小伙伴们觉得这部分其实在异性兄弟那里就做过介绍和分享了,其实不然,上次介绍和分享的大哥是uiautomatorviewer,是一款定位工具。今天介绍的是一个java库,提供执行自动化测试的各种API。
经查得知Android10后,plus获取设备信息等一些操作不在支持了。同样的代码在原来版本的HX中可以直接真机调试运行在Android10设备上,可正常启动未发现其他异常。由于我是离线打包的,所以断定打包过程一些api无法用了。但是官方的基座可以在老版本HX上直接运行在Android10上,推测基座版本和HX关系不大,应该是最新的。
缘起 上一篇博文中讲到了几种实现全屏显示Activity内容的方法。然而实际在实现中发现了一些问题,在本篇博文中进行总结下。首先交代一下开发环境,本人使用的是Android Studio 1.5.1,因此使用Eclipse ADT开发或者低版本的SDK的时候可能不会碰到这个问题。首先看onCreate()方法中的实现代码: 1 @Override 2 protected void onCreate(Bundle savedInstanceState) { 3 super.onCrea
设置 code style XML 右上角 Set from然后选择Predefined Style… Android即可
最近,荣幸的给部门面试了一些初试的人员,在面试的过程中,发现一些人,对于一些常见的测试的面试题都不能好好的把握回答。或许是因为紧张,我打算更新几篇文章,简单的介绍下面试过程中常见的问题。很多问题呢,是我面试中遇到的,或者我经常出题给面试者的问题。其实问题都是基础的问题,不难。但是往往的回答不是特别满意。
笔者在项目中实际有写过单元测试的代码,也用过一些单元测试的框架,但对单元测试的理解都很浅显,直到有一次在InfoQ编辑徐川主导的微信群里面看了蘑菇街小创同学的分享,加深了我对单元测试的兴趣和理解,他针对android平台的单元测试写了一个系列的文章,从什么是单元测试、单元测试的意义、各种方法怎样做单元测试、单元测试和集成测试的区别、各种测试框架和开源库在写单元测试时如何很好地被使用、以及如何mock、在PC上运行需要依赖android设备环境的测试等方面都做了非常详细的介绍,下文中的很多观念都是看了他的文章吸收得来的。
C#脚本未捕获的异常,与Android和Native未捕获异常很大的区别是,未捕获异常不会照成引用的闪退。所以,C#脚本的异常危害相对较小,但是同样更加容易存在在游戏中。闪退问题能够及时发现并进行修复。C#脚本异常,抛出的时机不同,危害性也有所不同; 在Start、Awake等函数抛出的异常,会造成Update、OnGUI无法正常运行,游戏可能表现为无响应、图片确实等。Update、OnGUI的异常也一定会引起游戏逻辑及画面上的一些异常。
领取专属 10元无门槛券
手把手带您无忧上云