疑难Bug搜寻定位之路

个人真实写照

前言

我今天心血来潮,本来想写个文章在简书上发布的,可没有想到的是他居然不允许,说是根据主管部门要求,暂停所有用户发布,直到九月28号。你知道这种感觉吗,其实也挺早就想在csdn 发文章,一直是没有时间。我是一个刚步入社会的菜鸟级安卓开发工程师。写文章的主要目的是记录自己的工作经验。废话不多说,进入今天的主题。

现在的安卓碎片化其实挺严重,由于是开源的系统,每个手机厂商都有自己的Rom。每个厂商的适配对于我这种苦逼的初级菜鸟安卓开发程序员是一大难题。但是今天讲的并不是适配的话题,哈哈哈,那么我今天要说的,到底是什么呢?
sdf.jpg

前面讲的可以当做废话,哈哈哈,今天我要讲的,是当遇到无法重现的Bug时,的其中一种定位方式。

问题来源

不知道大家有没有遇到过,开发的App,在自己的手机上流畅到死,结果客户一用就出现问题。我现在就是这样。公司的App在我手机上面跑的时候,启动速度飞快,但是到了部分客户手上,却变成了打开费劲。要等待十几秒才把主界面显示出来。
这是什么用户体验!!!!
奔溃

解决思路

不是所有手机都有问题,那首先排除了代码逻辑Bug。极大可能是第三方东西的问题。但是我们不能一味的盲目解决。首先我们得找到问题到底出现在哪里,不管能不能解决,首先得定位出现这些问题的位置。(其实我刚开始也是无头苍蝇一样,一直在百度如何提高启动速度。什么第三方初始化不要放在主线程啊等等)
后来实在没有办法,请教了有经验之人,了解了一个定位问题的办法。现在就来讲讲。

说实话,当你自己的手机,测试的手机都没有出现问题的时候,客户再不断说这个app不好用,这种感觉真不好受,感觉整个人都要自闭了。所以,定位方法就是:

定位方法

首先,你得想想为什么会出现这样,出现这样无非就几种原因:
1.第三方框架初始化的时候可能卡住了(网络或者其他原因阻塞主线程)
2.网络不好
3.获取本地数据出现问题

那么,一打开就这样,肯定是OnCreat方法里面有关系,我们了解里面的流程之后,就可以进入本篇文章的重点了。

重点

你需要一个后台服务器,如果你懂后台的话,写一个小的Demo,主要就是用于将App上传的数据,显示出来。那假如不会后台,怎么办??自行百度了解实现这是一种方法,能扩展你的知识面。不过这个很费时间哦。那怎么办嘞?这个好办,找你们公司的后台帮忙一下就好了,实现这个很简单。

那么后台服务器Demo准备好了,我们就开始在App上动刀子了。我们在每一个初始化第三方框架的结束的时候,就上传当前的手机型号、网络状态、内存剩余量、初始化的第三方信息以及最重要的完成时间(毫秒级)。什么?这些都不知道如何获取?这个我下一篇文章将详细讲解。这样子,当你Build一个测试App给用户打开的时候,通过时间的比对,你就会知道,到底哪一步是造成进入慢的罪魁祸首。多说无益,举个栗子:

扫描二维码关注公众号,回复: 15076718 查看本文章
/**
         * 初始化极光推送SDK
         */
        JPushInterface.setDebugMode(true);
        JPushInterface.init(context);
        //调用网络访问封装类,上传 Log 日志数据
        new MyLibraryLogAPI().uploadLog("initApp", "App", LogTestUtils.produceLogMsg(this, "极光推送初始化"), 1);

LogTestUtils.produceLogMsg(this, “极光推送初始化”)这个是获取到我需要的的值,具体如下:

 public static String produceLogMsg(Context context,String problemSite){
        String logMsg=null;
        logMsg="调试哪个步骤造成卡顿:" +
                "  当前手机:" + getDeviceBrand()+"   "+getSystemModel()+ 
                "  时间:"+getLogTimeString() +                                         
                "  本机总内存大小:" +getTotalMemory(context)+         
                "  当前可用内存大小:" +getAvailMemory(context)+            
                "  网络状态:" + getAPNType(context)+                                
                "  停留的定位:"+problemSite;                                          
        return logMsg;
    }

到这里,App的操作就讲完了,是不是挺简单?主要就是后台这块有点难搞。哈哈哈

当我们编译app,再手机上测试的时候,后台服务器就会打印我们上传的数据了,附上后台结果图。
后台结果图
这样子,初始化一目了然,我们只需要打包给客户,叫他打开App,咱们就能定位到问题到底出现在哪里啦!!
细心的朋友可能会发现,我给出的结果图貌似挺正常的,每一个初始化都在毫秒级就完成了。没错,确实没有任何问题,因为我现在还没有定位出来哪里出现了问题,哈哈哈哈,至少现在能知道,客户出现的问题,至少不是第三方初始化了,下一步将在网络和本地数据获取中定位。

总结

这是一个问题定位的方法,肯定还有其他更好的方法,因为我坚信一句话:办法总会比困难多,一切皆有可能!
码字不易,望点赞关注。也是自己的第一篇正式的文章,如有错误,望批评改正。??

最后,一张神图压底。
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/weixin_43683367/article/details/100676678
今日推荐