首页天道酬勤,

,

张世龙 05-12 06:29 66次浏览

前言

本文主要讲述本人在近一周的时间里在项目中进行性能优化的学习和实践笔记,在性能优化方面有很多优秀的文章。 本文大量引用了其他文章的叙述,并根据自己的理解进行了成文化,主要从内存和流畅度两个方面对这一部分的工作进行了总结。 老板强调了性能优化的工作,但一直没有做。 这个产品正在重新计划中,终于来做性能优化的工作了。 再次阅读有趣的月饼安卓APP研发进步必经的性能优化,傅克安卓性能优化模型,TMQ团队《移动App性能评测与优化》,从中收获颇多,在此衷心感谢大家分享dpdyg。 文中有不足的地方,请批评指正。

一.内存

内存是APP非常宝贵的资源,我们必须合理“借用”。 为什么可以说是借用? 我觉得这是我自己的一点理解。 按照老话,又借又还,借起来并不难,以淡定的姿态申请内存,就要记得及时释放。 当然,如果你又借给别人了,也要告诉别人记住并还给你。 否则,很可能会泄露。 总之,内存是借来的,请记住。

1、内存抖动原因:频繁创建对象并快速释放该对象,导致JVM频繁GC;

现象: AS监视器观察内存,明显锯齿,频繁升降; 在Allocation Tracker中查看同一堆栈在短时间内持续进出的同一对象。

分析:在for循环中分配对象;

在自定义onDraw中创建对象;

解决:尽量避免上述情况,如实在无法避免,可考虑采用对象池模型处理;

2、内存泄漏概念:程序中不再使用的对象GC无法识别,一直占用的内存空间无法释放。 一方面机器内存空间减少,需要申请更多内存来浪费资源,另一方面频繁的GC导致的性能问题

常见问题定制的View设置了监听器等回调接口,没有主动释放

自定义布局中设置进入外部几个视图,未主动释放;

虽然初始化了volley等第三方库,但没有积极释放

从activity放入包含actvity中对象set的fragment中,fragment拥有该对象,fragment在destroy时不主动释放;

由非静态内部类(例如Hanlder )引起的存储器泄漏可以静态地写入内部类,并使用弱引用方案;

IO操作,使用后记住关闭流等;

自定义视图中存在类型阵列,使用后未关闭;

四大组件上下文;

方法查找AS内存使用情况;

获取AS内存快照并分析内存,找到未释放的对象,分析并验证修改;

如何避免系统附带的资源,如颜色、布局\字符串

itemView复用,如ListView和GridView;

复用Bitmap对象;

StringBuilder字符串拼接; 轻量级数据结构,如HashMap

减少Bitmap内存使用量、缩放、更改解码格式;

使用更小的图像减少内存使用量

内存回收

重点:除了使用一些检查修改的方法外,我们还需要有良好的内存管理意识。 JVM有自动内存管理机制,但由于编写了不合理的代码,无法进行GC。 所以,合理管理内存,节约资源也很重要。

二.光滑

流畅是用户体验中重要的一部分,对用户的耐心有限。 就个人而言。 如果APP应用卡死了,绝对要先卸载,否则可能再也不用了。 简单地说,应用于界面的切换、渲染,使之感到舒适,不是有纸箱现象吗? 我们通常用FPS这个指标来评价,但在《移动APP性能评测与优化》这本书中提出FPS这个指标还没有准备好,所以提出了SM的概念。 以下是平滑度优化的几个方面。

1、画得太多

这也不好说,但是在系统设置中打开调试后,可以观察到现象。 很多网络教程都是根据颜色来判断是否画得太多。 之所以会出现过多的绘制,主要是因为View的backgroud反复绘制。 首先,窗口本身有自己的后台。 要自定义自己的后台,请记住将窗口后台设置为null。

2、布局优化水平越深,布局越复杂,计算、测量等越费时间,越有可能引起丢帧现象,成为纸箱的概率越高;

对于关系布局,优选选择线性布局;

提取可重用的组件并使用include标记导入;

不常用的标签使用ViewStub;

使用merge标记降低布局的嵌套级别

在LinearLayout布局中,layout_weight属性消耗性能。

ListView的item_view尽可能简单,GetView方法尽量减少逻辑运算;

3、释放用户界面线程

吵死了的跳跳糖,我们把一些需要时间的操作放到子线程里完成。 我们也可以通过打开严格的模式来预防。 在自定义View的OnDraw方法中,可以将new对象操作、缓存策略和预加载机制降至最低。

三.分析工具及使用

本人

基本仅借助于AndroidStudio自带的工具和系统设置自带调试工具进行分析以及优化工作;静态检查:AndroidStudio执行Lint检查操作后,在检查结果Android>Lint>Performance中有许多与性能相关的选项,谨慎修改优化。

Monitors:可以直观个查看内存、CPU、GPU、网络情况;

[Allocation Tracking]:(Android性能专项测试之Allocation Tracker(Android Studio)):这个可以追踪某一过程中内存分配的情况,在查看内存抖动(涨跌变动大的时候);

[Heap Snapshot]:(使用 Android Studio 检测内存泄漏与解决内存泄漏问题):内存泄漏检测分析,我们可以通过手动GC然后获取内存快照来分析,找出造成泄漏的原因;配合Memory Usage来验证自己是否修改正确。

Method Tracing: 这个可以分析方法执行耗时、调用次数,点击CPU旁边的那个闹钟样子的按钮开始或者结束记录,可以分析某些耗时方法,来优化流畅度的问题。

系统设置:OverDraw 查找过度绘制问题;

系统设置:GPU呈现模式分析查看UI渲染、分析流畅度问题;

四、个人体会

在性能优化方面,一直研究不深。至今为止,也只是在很浅的层面上借助于工具来进行优化,也顺便了解了部分底层的一些知识。作为一名APP应用开发者,我们的目标不仅只是实现某一个功能,还要关注这个应用是否好用。在内存消耗、体验是否流畅、apk的体积大小等各方面,都直接影响了app的最终质量。其实说到底,性能体验不好,最终的原因还是程序的设计不合理,代码写的不规范,布局不合理等等原因造成的。所以,进行性能优化的工作,不仅提高了应用app的性能,同时也是帮助自己写出更优秀的代码。我们可能不能够想测试工程师那样去深入研究,但是主动防御相比起反攻而言,同样有很大的价值。

打开App,阅读手记

android 插件化,安卓无root使用shell命令