美文网首页Android开发经验谈
android性能优化全方面解析(二)

android性能优化全方面解析(二)

作者: Android征途 | 来源:发表于2019-01-09 15:18 被阅读120次

    补昨天UI优化后半段,前半段点开主页就有啦

    绘制优化

    那么什么是绘制优化?绘制优化主要是指View的Ondraw方法需要避免执行大量的操作。我将分为了2个方面。

    • ondraw方法不需要创建新的局部对象,这是因为ondraw方法是实时执行的,这样会产品大量的临时对象,导致占用了更多内存,并且使系统不断的GC。降低了执行效率。
    • Ondraw方法不需要执行耗时操作,在ondraw方法里少使用循环,因为循环会占用CPU的时间。导致绘制不流畅,卡顿等等。Google官方指出,view的绘制帧率稳定在60dps,这要求每帧的绘制时间不超过16ms(1000/60)。虽然很难保证,但我们需要尽可能的降低。

    60dps是目前最合适的图像显示速度,也是绝大部分Android设备设置的调试频率,如果在16ms内顺利完成界面刷新操作可以展示出流畅的画面,而由于任何原因导致接收到VSYNC信号的时候无法完成本次刷新操作,就会产生掉帧的现象,刷新帧率自然也就跟着下降(假定刷新帧率由正常的60fps降到30fps,用户就会明显感知到卡顿)。So,前面我们说GPU的时候也谈到了这个。总的而言,感觉还是蛮重要的…..

    网络优化

    线程是我们项目中不可缺少的重要部分,因为我们大多数数据都是从网络获取的。So,线程这个是必备用品。

    我们依旧可以通过Memory下面的Net进行网络的监听:

    image

    1.ANR问题

    相信这个问题在座的各种没少遇到过,那么什么是ANR?application not responding。应用程序无响应。那么一般什么时候会出现ANR。Android官方规定:activity如果5s内无响应事件(屏幕触摸事件或者键盘输入事件)。BroadcastReceiver如果在10s内无法处理完成。Service如果20s内无法处理完成。这三种情况会导致ANR。用张简洁的图来介绍把。看起来方便~~

    image

    2. 线程优化

    上面说的三种导致ANR的情况,绝大多数就是因为线程阻塞导致的。那么我们应该如何处理呢?Android系统为我们提供了若干组工具类来解决此问题。
    • Asynctask:为UI线程与工作线程之间进行快速处理的切换提供一种简单便捷的机制。适用于当下立即需要启动,但是异步执行的生命周期短暂的场景。
    • HandlerThread:为某些回调方法或者等待某些执行任务的执行设置一个专属的线程,并提供线程任务的调度机制。
    • ThreadPool:把任务分解成不同的单元,分发到各个不同的线程上,进行同时并发处理。
    • IntentService:适合执行由Ui触发的后台任务。并可以把这些任务执行的情况通过一定的机制反馈给UI。

    网络请求耗时会给用户带来卡顿的产品体验,虽然可以使用Loading提升用户体验,但属于治标不治本。例如,当网络差的时候我们公司的项目一个loading就是10多s。甚至更多…..我就记得我当时面试之前下了一次我们公司的项目,因为网差的问题…一个loading一分多钟。。当时砸手机的冲动都有了,别说卸软件了….

    一般多线程的情况我们可以通过Asynctask处理。(这玩意我真没怎么用过- -)我前面有说过annotation。这是google官方推出的注解。比bufferknife强大很多。这个可以快捷方便的处理多线程而且不会导致线程阻塞,而且你也可以控制线程的顺序,例如我要执行完线程A后,根据线程A的某个参数来执行线程B。以此类推…..

    至于线程池么,最多的还是要说道图片加载了~。图片加载用三方就行了想看详细介绍,我前面有说,当然除了这个还有下载操作。这就和IntentService有关联了。一般下载我很少涉及到。。用过几次android原生的downloadmanager。。感觉略坑。

    3.KO网络优化

    现在讲网络优化的重点了…重点..重点…,一般用到网最最最主要的是什么?时间!!速度!!成功率!!,时间!!速度!!成功率!!,时间!!速度!!成功率!!重要的事说三遍哈。

    4. 图片处理

    这已经不是第一次在此文提到图片了。可见图片的重要性!!

    • 使用WebP格式;同样的照片,采用WebP格式可大幅节省流量,相对于JPG格式的图片,流量能节省将近 25% 到 35 %;相对于 PNG 格式的图片,流量可以节省将近80%。最重要的是使用WebP之后图片质量也没有改变。So,去和后台的小伙伴们商量吧。。
    • 使用缩略图,我在前面写图片加载有说过,就是控制他的inside和option。然后进行图片缩放。压缩?讲道理….我并不知道网络图片怎么压缩,but,我会缩放啊~反正也不会失真。啦啦啦咬我啊?

    5. 网络请求处理

    我们可以对服务端返回数据进行缓存,设定有效时间,有效时间之内不走网络请求,减少流量消耗。对网络的缓存可以参见 HttpResponseCache

    在某些情况,我们尽量少使用GPS定位,如果条件允许,尽可能使用网络定位。

    下载、上传,我们尽可能使用断点,说个简单的,我在公司,准备下一个500M的游戏,但是下到200M的时候我下班了,此时没有了无线网,我们可以回家后用无线继续下载。So,断点续传,断点下载也是我们的必修课~,所以我前面单独提了一篇断点续传的文章。

    刷新数据时,尽可能使用局部刷新,而不是全局刷新,第一、界面会闪屏一下,网差的界面直接白屏一段时间也不是不可能。第二、流量的使用!!我又要拿我们公司项目搞事情了。一个闪屏的缓存60+M。。。没错,就是60+M。简直可怕,我清个3、5次缓存,在打开个3、5次。好了,2分钟时间,我一个月流量就没了。。。So,我前面提到的网络缓存很重要,至于会不会加在项目中,我还是要看了在说- - 一个不小心,整个项目炸了都有可能。。。

    启动优化

    众所周知,一个好的产品,除了功能强大,好的性能也必不可少。有调查显示,近50%的受访者因为apk太大而拒绝使用,近40%的受访者会因为APP性能差而卸载,性能也是造成APP用户沮丧的头号原因。

    安卓应用的启动方式分为三种:冷启动、暖启动、热启动,不同的启动方式决定了应用UI对用户可见所需要花费的时间长短。顾名思义,冷启动消耗的时间最长。基于冷启动方式的优化工作也是最考验产品用户体验的地方。谈及优化之前,我们先看看这三种启动方式的应用场景,以及启动过程中系统都做了些什么工作。

    1. 冷启动

    为什么说冷启动是耗时最长的。冷启动是在启动应用前,系统没有获取到当前app的activity、Service等等。例如,第一次启动app。又或者说杀死进程后第一次启动。那么对比其他两种方式。冷启动自然是耗时最久的。

    应用发生冷启动时,系统一定会执行下面的三个任务:
    • 开始加载并启动应用
    • 应用启动后,显示一个空白的启动窗口(启动闪屏页)
    • 创建应用信息
    那么创建应用信息,系统就需要做一屁股的事:
    • application的初始化
    • 启动UI线程
    • 创建Activity
    • 导入视图(inflate view)
    • 计算视图大小(onmesure view)
    • 得到视图排版(onlayout view)
    • 绘制视图(ondraw view)

    这其中有两个 creation 工作,分别为 Application 和 Activity creation。他们均在 View 绘制展示之前。所以,在应用自定义的 Application 类和 第一个 Activity 类中,onCreate() 方法做的事情越多,冷启动消耗的时间越长。

    2. 暖启动

    当应用中的 Activities 被销毁,但在内存中常驻时,应用的启动方式就会变为暖启动。相比冷启动,暖启动过程减少了对象初始化、布局加载等工作,启动时间更短。但启动时,系统依然会展示闪屏页,直到第一个 Activity 的内容呈现为止。

    3. 热启动

    相比暖启动,热启动时应用做的工作更少,启动时间更短。热启动产生的场景很多,常见如:用户使用返回键退出应用,然后马上又重新启动应用。

    4. 如何优化

    我们先对比下三种启动的时间对比:

    冷启动:

    image

    暖启动 :

    image

    热启动:

    我们可以看到三者的明显的差距,一个冷启动将近一分钟,反正我是不想看,每次跑项目都好慢~那么我们应该怎么做?看到有些人介绍说改变项目的theme。把它改成launcher的theme。但我觉得,这种做测试的确没问题。但是一般项目都会有闪屏页。然后从闪屏跳转到首页。我们可以按照大多数的项目来改善。怎么说的,我们可以看到一般项目都有倒计时显示。也就是说倒计时结束就自动进入首页。或者可以直接跳过进入首页。也就是说我们可以通过此方法来进行,也就是说只要他倒计时结束,不管请求是否全部获取完我们都直接进入首页。我们可以在闪屏页进行一些必要的加载,例如用户信息,定位等等,那么至于其他的,我们可以进入主页进行预加载。就和热更新一样,在用户不知情的情况下,默默的更新bug。So,对于一些网络请求,例如广告之类的。我们可以通过此方法进行预加载。

    我们还可以这样,闪屏页我们把他当作一个fragment嵌套在MainActivity中,那么我们可以在进入闪屏时直接预加载主页的view。倒计时我们把闪屏页remove掉直接显示首页。

    通过上面的介绍,我们对启动优化有了一定的了解,其实总结的话很简单。就是减少耗时操作,总结如下:
    • 主线程中涉及到Shareperference能否在非UI线程执行。
    • Application的创建过程中尽量少的进行耗时操作。
    • 减少布局的层次,并且生命周期回调的方法中尽量减少耗时的操作。

    电量优化

    有了UI优化、内存优化、代码优化、网络优化之后我们在来说说应用开发中很重要的一个优化模块—–电量优化。

    1.耗电概念

    其实大多数开发者对电量优化的重视程度极低,其实提到性能优化想到的就是内存优化,但我们不能忽视其他的优化,电量优化其实还是必要的,例如爱奇艺、优酷等等的视频播放器以及音乐播放器。众所周知,音乐和视频其实是耗电量最大的。如果用户一旦发现我们的应用非常耗电,不好意思,他们大多会选择卸载来解决此类问题。为此,我们需要进行优化。

    2.如何优化

    其实我们把上面那四种优化解决了,就是最好的电量优化。So,对于电量优化,我在此提一些建议:

    • 需要进行网络请求时,我们需先判断网络当前的状态。
    • 在多网络请求的情况下,最好进行批量处理,尽量避免频繁的间隔网络请求。
    • 在同时有wifi和移动数据的情况下,我们应该直接屏幕移动数据的网络请求,只有当wifi断开时在调用,因为,wifi请求的耗电量远比移动数据的耗电量低的低。
    • 后台任务要尽可能少的唤醒CPU。(比方说,锁屏时,QQ的消息提示行就是唤醒了CPU。但是它的提示只有在你打开锁屏或者进行充电时才会进行提示。)

    . 优化总结

    性能优化是我们进阶的毕竟之路。So,我们必须要会,至于“会”到什么程度,就要看个人理解了。其实,上面介绍的只是性能问题的冰山一角,真正的优化,我们是在项目中总结出来的。但,我们不能一味的追求优化,就例如我,现在只是在进行优化的总结,而对于真正的实行,并没有开始,因为,优化是有风险的,一个不小心,整个项目都可能炸了。所以这就需要你的经验,以及各种总结,在改进行优化的地方先进行优化,看看效果如何,例如,UI的优化以及代码的优化。可以先拿一些网上的开源项目进行优化等等。最后,尽情的享受优化把~~~

    想学习更多Android知识,或者获取相关资料请加入Android技术开发交流2群:935654177。本群可免费获取Gradle、RxJava、小程序、Hybrid、移动架构、NDK、React Native、性能优化等技术教程![图片上传失败...(image-717c06-1547042185244)]

    3333.png
    111.webp.jpg

    相关文章

      网友评论

        本文标题:android性能优化全方面解析(二)

        本文链接:https://www.haomeiwen.com/subject/wkkgrqtx.html