愿历尽千帆 归来仍少年

愿历尽千帆 归来仍少年

Android 系统层捕捉所有应用崩溃情况推送到钉钉实践之路
项目痛点出现偶现崩溃或ANR,因为没有开启日志开关,后面尝试复现又比较困难,研发同事比较苦恼,无从下手还有一个测试同事抓取日志后还要记录时间点,再上传到JIRA上,研发同事下载日志还需要搜索报错点,整个流程比较费时 初步想法可不可以将所有ANR,Crash等出错信息的关键日志片段直接传给服务器,在后面的摸索过程中发现钉钉可以提供对外的URL接口,这样的话直接传给钉钉就很方便了,正好平时的办公用的也是这个软件,这样一来就省去了很多的步骤,一步到位 以下是实做的步骤记录,只是实现了一个初稿,后面还需要不断优化完善 Step1: 获取钉钉的Webhook地址这个地址后面作为推送的目标地址 在钉...
一个滑动冲突问题的分析流程
问题需求原先效果是用户在ViewPager上长按会弹出一个dialog,现在加了一个需求:用户有时候在长按时出现手指向左或向右微小滑动,此时也需要判断为长按并弹出dialog 初步分析外边的ViewPager是可以左右滑动的,现在希望单个界面即子view接收到触摸事件后能接管本次事件序列中后续事件,即子View接收到触摸事件后,注意此时手指未松开,所以还处于一次完整的事件序列中,等待一段时间Android默认是400ms后会识别为长按事件,此时子View的长按事件被触发。那么问题来了,怎么才能在子view接收到触摸事件并能接管本次事件序列呢?这就要说到老生常谈的事件拦截了,正常拦截事件有...
一个底层内存分配异常导致无法进入launcher问题分析
问题平台Android go 复现概率always 问题现象解锁后,Launcher图标未能加载出,按虚拟back,home键,下拉状态栏响应异常缓慢 前言Android Go是一个简化版本的Android O(及以上),能够在超低端的Android手机上流畅运行,具体量化就是RAM仅为512MB至1GB的机型 初步分析首次合入MTK提供的Android Go代码后开机,解锁后Launcher图标没有加载出,鉴于该平台代码是芯片商已经调试稳定后释放,Launcher本身应用出问题的概率比较小,操作发现下拉状态栏异常卡顿 第一反应是会不会是内存很紧张呢? 有可能的哦,ok, 下面开始分析日...
一个屏幕滑动无响应问题的分析流程
问题现象在应用中出现屏幕右滑无响应 复现概率:once 问题平台:Android N MT6739 Step1 初步分析考虑到当时按power键能够退出应用回到待机(项目中对power键功能进行了定制),说明没有发生死机刚接到问题的时候,第一反应是觉得可能发生了ANR,与测试同事沟通,当时没有弹框出来。ok,拿到机器后, 将data/anr文件夹pull出来看下,内容为空。进到event日志中. 搜索"am_anr"关键字,没有搜到。测试同事所言没错,当时没有弹框出来是因为并没有发生ANR。那会不会是低内存呢,这样猜想并不是没有道理的。因为我们机器本身内存比较小,之...
一个无法开机问题的分析流程
问题平台Android7.1.1 MT6739 问题现象走完一部分开机动画后停留在recovery界面,无法进入系统 初步分析:开机后进入recovery ,以往经验来看猜测是重要进程启动异常,可能被连续被kill Step1 日志分析需要的日志:eng版本uart log+main log(如果已经进入Android的话)+data/aee_exp下的db文件(如果有db生成的话) Step1.1 抓取串口日志首先说下串口日志的获取方式:串口线中的白色接TX,黑色线接地,我这里是在windows下抓取,使用了一个SSCOM的工具,MTK平台上波特率需要选择921600, 这个工具使...
基于开源框架SlidingUpPanel二次开发
项目需求写一个SystemUI,默认是隐藏,手指在Launcher界面顶部往下滑动时,SystemUI显示并随着手指滑动高度不断变化,直到往下铺满屏幕 初步分析最初的想法是在原生SystemUI基础上进行修改,在看了原生SystemUI代码后,word天,原生SystemUI代码量十分庞大且代码结构比较复杂,很多地方耦合比较高,初步估计厘清需要耗费的时间会比较长。于是有了单独写一个的想法,这样代码比较简洁,以后项目上也方便复用。 设计框架下拉面板显然需要一个自定义布局,这个自定义View高度能够手指滑动变化,ok,理论上并不复杂github兜一圈,看看有没有类似的框架,茫茫大海中找到了一...
avatar
Steven li