补昨天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进行网络的监听：

1.ANR问题

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

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. 如何优化

我们先比照下三种启动的时间比照：

冷启动：

暖启动 ：

热启动：

我们可以看到三者的显著的差距，一个冷启动将近一分钟，反正我是不想看，每次跑项目都好慢~那么我们应该怎样做？看到有些人详情说改变项目的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)]