没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
试读
441页
众所周知,移动开发已经来到了后半场,为了能够在众多开发者中脱颖而出,我们需要对某一个领域有深入地研究与心得,对于Android开发者来说,目前,有几个好的细分领域值得我们去建立自己的技术壁垒,如下所示: 1、性能优化专家:具备深度性能优化与体系化APM建设的能力。 2、架构师:具有丰富的应用架构设计经验与心得,对Android Framework层与热门三方库的实现原理与架构设计了如指掌。 3、音视频/图像处理专家:毫无疑问,掌握NDK,深入音视频与图像处理领域能让我们在未来几年大放异彩。 4、大前端专家:深入掌握Flutter及其设计原理与思想,可以让我们具有快速学习前端知识的能力。
资源推荐
资源详情
资源评论
Android性能优化学习手册
深入探索Android稳定性优化
前言
众所周知,移动开发已经来到了后半场,为了能够在众多开发者中脱颖而出,我们需要对某一个领域有
深入地研究与心得,对于Android开发者来说,目前,有几个好的细分领域值得我们去建立自己的技术
壁垒,如下所示:
1、性能优化专家:具备深度性能优化与体系化APM建设的能力。
2、架构师:具有丰富的应用架构设计经验与心得,对Android Framework层与热门三方库的实现
原理与架构设计了如指掌。
3、音视频/图像处理专家:毫无疑问,掌握NDK,深入音视频与图像处理领域能让我们在未来几年
大放异彩。
4、大前端专家:深入掌握Flutter及其设计原理与思想,可以让我们具有快速学习前端知识的能
力。
在上述几个细分领域中,最难也最具技术壁垒的莫过于性能优化,要想成为一个顶尖的性能优化专家,
需要对许多领域的深度知识及广度知识有深入的了解与研究,其中不乏需要掌握架构师、NDK、
Flutter所涉及的众多技能。从这篇文章开始,笔者将会带领大家一步一步深入探索Android的性能优
化。
为了能够全面地了解Android的性能优化知识体系,我们先看看我总结的下面这张图,如下所示:
要做好应用的性能优化,我们需要建立一套成体系的性能优化方案,这套方案被业界称为
APM(Application Performance Manange),为了让大家快速了解APM涉及的相关知识,笔者已
经将其总结成图,如下所示:
7、责任归属
二、
Crash 优化
1、单个 Crash 处理方案
2、Crash 率治理方案
3、Java Crash
4、Java Crash 处理流程
5、Native Crash
6、疑难 Crash 解决方案
7、进程保活
8、总结
三、
ANR 优化
1、ANR 监控实现方式
2、ANR 优化
3、关于 ANR 的一些常见问题
4、理解 ANR 的触发流程
四、
移动端业务高可用方案建设
1、业务高可用重要性
2、业务高可用方案建设
3、移动端容灾方案
五、
稳定性长效治理
1、开发阶段
2、测试阶段
3、合码阶段
4、发布阶段
5、运维阶段
六、
稳定性优化问题
1、你们做了哪些稳定性方面的优化?
2、性能稳定性是怎么做的?
3、业务稳定性如何保障?
4、如果发生了异常情况,怎么快速止损?
七、总结
一、正确认识
首先,我们必须对App的稳定性有正确的认识,它是App质量构建体系中最基本和最关键的一环。如果
我们的App不稳定,并且经常不能正常地提供服务,那么用户大概率会卸载掉它。所以稳定性很重要,
并且Crash是P0优先级,需要优先解决。 而且,稳定性可优化的面很广,它不仅仅只包含Crash这一部
分,也包括卡顿、耗电等优化范畴。
1、稳定性纬度
应用的稳定性可以分为三个纬度,如下所示:
1、Crash纬度:最重要的指标就是应用的Crash率。
2、性能纬度:包括启动速度、内存、绘制等等优化方向,相对于Crash来说是次要的,在做应用性
能体系化建设之前,我们必须要确保应用的功能稳定可用。
3、业务高可用纬度:它是非常关键的一步,我们需要采用多种手段来保证我们App的主流程以及
核心路径的稳定性,只有用户经常使用我们的App,它才有可能发现别的方面的问题。
2、稳定性优化注意事项
我们在做应用的稳定性优化的时候,需要注意三个要点,如下所示:
1、重在预防、监控必不可少
对于稳定性来说,如果App已经到了线上才发现异常,那其实已经造成了损失,所以,对于稳定性的优
化,其重点在于预防。从开发同学的编码环节,到测试同学的测试环节,以及到上线前的发布环节、上
线后的运维环节,这些环节都需要来预防异常情况的发生。如果异常真的发生了,也需要将想方设法将
损失降到最低,争取用最小的代价来暴露尽可能多的问题。
此外,监控也是必不可少的一步,预防做的再好,到了线上,总会有各种各样的异常发生。所以,无论
如何,我们都需要有全面的监控手段来更加灵敏地发现问题。
2、思考更深一层、重视隐含信息:如解决Crash问题时思考是否会
引发同一类问题
当我们看到了一个Crash的时候,不能简单地只处理这一个Crash,而是需要思考更深一层,要考虑会不
会在其它地方会有一样的Crash类型发生。如果有这样的情况,我们必须对其统一处理和预防。
此外,我们还要关注Crash相关的隐含信息,比如,在面试过程当中,面试官问你,你们应用的Crash率
是多少,这个问题表明上问的是Crash率,但是实际上它是问你一些隐含信息的,过高的Crash率就代表
开发人员的水平不行,leader的架构能力不行,项目的各个阶段中优化的空间非常大,这样一来,面试
官对你的印象和评价也不会好。
3、长效保持需要科学流程
应用稳定性的建设过程是一个细活,所以很容易出现这个版本优化好了,但是在接下来的版本中如果我
们不管它,它就会发生持续恶化的情况,因此,我们必须从项目研发的每一个流程入手,建立科学完善
的相关规范,才能保证长效的优化效果。
3、Crash相关指标
要对应用的稳定性进行优化,我们就必须先了解与Crash相关的一些指标。
1、UV、PV
PV(Page View):访问量
UV(Unique Visitor):独立访客,0 - 24小时内的同一终端只计算一次
2、UV、PV、启动、增量、存量 Crash率
UV Crash率(Crash UV / DAU):针对用户使用量的统计,统计一段时间内所有用户发生崩溃的
占比,用于评估Crash率的影响范围,结合PV。需要注意的是,需要确保一直使用同一种衡量方
式。
PV Crash率:评估相关Crash影响的严重程度。
启动Crash率:启动阶段,用户还没有完全打开App而发生的Crash,它是影响最严重的Crash,对
用户伤害最大,无法通过热修复拯救,需结合客户端容灾,以进行App的自主修复。(这块后面会
讲)
增量、存量Crash率:增量Crash是指的新增的Crash,而存量Crash则表示一些历史遗留bug。增
量Crash是新版本重点,存量Crash是需要持续啃的硬骨头,我们需要优先解决增量、持续跟进存
量问题。
4、Crash率评价
那么,我们App的Crash率降低多少才能算是一个正常水平或优秀的水平呢?
Java与Native的总崩溃率必须在千分之二以下。
Crash率万分位为优秀:需要注意90%的Crash都是比较容易解决的,但是要解决最后的10%需要付
出巨大的努力。
5、Crash关键问题
这里我们还需要关注Crash相关的关键问题,如果应用发生了Crash,我们应该尽可能还原Crash现场。
因此,我们需要全面地采集应用发生Crash时的相关信息,如下所示:
堆栈、设备、OS版本、进程、线程名、Logcat
前后台、使用时长、App版本、小版本、渠道
CPU架构、内存信息、线程数、资源包信息、用户行为日志
接着,采集完上述信息并上报到后台后,我们会在APM后台进行聚合展示,具体的展示信息如下所示:
Crash现场信息
Crash Top机型、OS版本、分布版本、区域
Crash起始版本、上报趋势、是否新增、持续、量级
最后,我们可以根据以上信息决定Crash是否需要立马解决以及在哪个版本进行解决,关于APM聚合展
示这块可以参考 Bugly平台 的APM后台聚合展示。
然后,我们再来看看与Crash相关的整体架构。
6、APM Crash部分整体架构
APM Crash部分的整体架构从上至下分为采集层、处理层、展示层、报警层。下面,我们来详细讲解一
下每一层所做的处理。
1)、采集层
首先,我们需要在采集层这一层去获取足够多的Crash相关信息,以确保能够精确定位到问题。需要采
集的信息主要为如下几种:
错误堆栈
设备信息
行为日志
其它信息
剩余440页未读,继续阅读
QY’UniverseSpace
- 粉丝: 1w+
- 资源: 28
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
- 1
- 2
前往页