Android----APP性能优化
性能优化的目标
快
如何让 app 在运行过程过不卡顿,运行流畅,速度快,也就是说如何解决卡顿呢?我们先看看那些因素影响卡顿?
-
UI,包括ui的绘制,刷新等
-
启动,包括冷启动,热启动,温启动等
-
跳转,页面跳转,前后台切换
-
及时反馈,点击事件,滑动,系统事件
UI
这个涉及到 android 的系统显示原理,我们简单了解一下:
Android 显示过程可以简单概括为:Android 应用程序把经过测量,布局、绘制后的 surface 缓存数据,通过 SurfaceFlinger 把数据渲染到显示屏幕上, 通过 Android 的刷新机制来刷新数据。也就是说应用层负责绘制,系统层负责渲染,通过进程间通信把应用层需要绘制的数据传递到系统层服务,系统层服务通过刷新机制把数据更新到屏幕上。
换一种方式说:Android 系统每隔 16ms 发出 VSYNC 信号,触发对 UI 进行渲染,如果每次渲染都成功,这样就能够达到流畅的画面所需的 60FPS。(注:FPS 表示每秒传递的帧数。)在理想情况下,60 FPS 就感觉不到卡,这意味着每个绘制时长应该在16 ms 左右。如果某个操作花费的时间是 24ms ,系统在得到 VSYNC 信号时就无法正常进行正常渲染,这样就发生了丢帧现象。也就是延迟了,这种现象在执行动画或滑动列表比较常见,还有可能是你的 Layout 太过复杂,层叠太多的绘制单元,无法在 16ms 完成渲染,最终引起刷新不及时.
那么我们如何解决呢,主要从两点入手:ui布局,绘制优化和主线程优化?
布局优化
-
避免ui布局优化可以先从合理使用背景色开始,比如:如果子view和父布局公用一个背景色就没有必要了。
-
减少不必要的嵌套,一般建议不超过5层
-
合理使用各种布局,尽量使用 LinearLayout 和 FrameLayout,因为 RelativeLayout 需要比较复杂,测绘也比较费时,强调一下这个是相对的,不是说 LinearLayout 一定比 RelativeLayout 好。
-
合理使用 include、merge 和 ViewStub,使用include和merge增加复用,减少层级; ViewStub 按需加载。
-
推荐使用 google 已经出来的新的布局 ConstraintLayout,这个有机会说。
绘制优化
我们之前说过根据 Android 系统显示的原理,View 的绘制频率保证 60fps 是最佳的,这就要求每帧绘制时间不超过16ms(16ms = 1000/60),因此要减轻 onDraw() 的负担。所以在绘制时要注意两点:
-
onDraw 中不要创建新的局部对象。
-
onDraw 方法中不要做耗时的任务。
还有就是刷新,刷新的话尽量减少不必要的刷新和尽可能减少刷新面积
启动优化
冷启动
冷启动是指安装 apk 后首次启动应用程序,或者应用程序上次结束,进程被杀死后重新打开app.
在冷启动开始时,系统有三个任务。这些任务是:
-
加载并启动应用程序
-
启动后立即显示应用程序的空白启动窗口
-
创建应用程序进程
当系统为我们创建了应用进程之后,会执行以下的操作:
-
application 的初始化
-
启动 UI 线程
-
创建 Activity
-
导入视图(inflate view)
-
计算视图大小(onmesure view)
-
得到视图排版(onlayout view)
-
绘制视图(ondraw view)
应用程序进程完成首次绘制后,系统进程会交换当前显示的背景窗口,将其替换为主活动。此时至此启动完成,用户可以使用程序(app)了,那么这里就会有两类创建:
-
Application 的创建
当 Application 启动时,会有一个空白的启动窗口保留在屏幕上,直到系统首次完成绘制应用程序,白屏才会消失,这也是为什么启动app会出现白屏,这个问题,我也有提到过解决方式 Anroid 白屏
-
Activity的创建
当 Application 首次启动完成绘制后,我们的 UI 线程会执行主活动进行以下操作:
-
初始化值。
-
执行其构造函数。
-
执行其回调方法,比如 Activity 的 onCreate()对应生命周期的状态,onCreate() 方法做的事情越多,冷启动消耗的时间越长。暖(温)启动
暖(温)启动
暖启动比冷启动时间更短。在暖启动中,系统都会把你的 Activity 带到前台。如果应用程序的 Activity 仍然驻留在内存中,那么应用程序可以避免重复对象初始化、布局加载和渲染,但系统依然会展示闪屏页,直到第一个 Activity 的内容呈现为止。比如:当应用中的 Activities 被销毁,但在内存中常驻时,应用的启动方式就会变为暖启动 。
热启动
热启动的启动时间比暖启动还要更短。你比如,我用户 Back 退出应用程序,然后又重新启动,应用程序会再次执行 Activity 的 onCreate(),但会从 Bundle(savedInstanceState)获取数据,我们平时应用成勋崩溃,不也是通过该方法保存数据的吗。
针对启动方式的优化
Application 的创建过程中尽量少的进行耗时操作。比如:
Application 的 onCreate() 中进行友盟,bugly, okhttp,地图,推送等 init() 等操作。如果是必须在 onCreate 中进行的如:okhttp 等网络请求框架我们在 onCreate 中进行,其他的友盟,百度地图啥的我们可以等程序起来后再 onResume 方法中执行,bugly 等 sdk 可以异步加载。
在生命周期回调的方法中尽量减少耗时的操作
这个里面的优化方式就是:避免 I/O 操作、反序列化、网络操作、布局嵌套等。
省
省内存
主要是加载图片,动不动就 OOM,对于图片的压缩无非是:
-
图片尺寸压缩
-
图片质量压缩
此处代码省略,网上一大堆。Glide就是采用了 Lrucache 和 LruDiskCache 推荐使用。
其他
这都是本人的一些建议:
-
序列化采用推荐的 Parcelable 代替 Serializable
-
集合如果是插入和删除用的多,建议使用 LinkList。如果修改用的多,建议 ArrayList。
-
写程序要思考,避免创建不必要的对象。
-
对常量使用 static final,适用于基本类型和 String 常量。
-
使用增强的 for 循环语法(foreach)。
-
避免使用浮点数,浮点数比 Android 设备上的整数慢约2倍。
-
尽可能少用 wrap_content,wrap_content 会增加布局 measure 时计算成本。
-
删除控件中无用的属性。
-
合理使用动画,某些情况下可以用硬件加速方式来提供流畅度,或者采用自定义view代替动画,最后记得在Activity的ondestory()方法中调用Animation.cancle()进行动画停止。
-
注意 webview 和 handler,一般在首次加载后 webview 就会存在于内存中,容易内存泄漏。
-
考虑 StringBuilder 代替 String
-
数据量比较大或者内存比较宽裕考虑 HashMap,其他建议使用 SpareArray
1.作者:Syw 2.出处:http://www.cnblogs.com/syw20170419/ 3.本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。 4.如果文中有什么错误,欢迎指出。以免更多的人被误导。 |