Android中的性能优化

Android中的性能优化    性能优化就是对性能的优化

它包括一下以及方面  

内存优化     UI优化（布局优化和绘制优化）

速度的优化（线程优化、网络优化（））

电量优化

启动优化

数据库优化

                                                                              数据库优化

可以通过建立索引的方法分组查询表  提高查询效率

可以优化sql语句 避免使用*

通过事物的方法

                                                                                               内存优化

为什么会对内存进行优化？因为Android 是基于java进行来发的所以当我们使用对象的时候  如果对象在使用完的时候 没有被释放掉  而且一直占用着内存空间，导致GC无法回收 所以导致了内存的泄露  严重的时候导致OOM。

GC引用点

java栈中引用对象

静态方法引用对象

方法常亮引用对象

                                                          OOM的原因

瞬间申请过大内存导致OOM               片  Fresco  Glide

长时间不能释放对象导致积累超过阈值       对象不释放

小范围积累不能释放导致卡顿    

  解决方法 

  大图片的加载      所以解决的方法就是每次控制图片加载的数量    保证滑动的时候不加载图片 所以可以用第三方的图片加载框架来加载图

  使用数据库的时候关闭curso

  使用网络连接的时候关闭连接

  使用Bitmap的时候要讲对象会回收

 使用对象的时候 用到的时候在new出来   用完之后释放资源

  使用handler的时候将hand.ler声明伪静态的  不让他一直持有activity的引用  将activity声明为弱引用对象 关联acyivity的生命周期

使用mvp的时候也是要创建弱引用对象 将activity传入 关联activity的生命周期

                                                                                 UI优化

1. 人为在UI线程中做轻微耗时操作，导致UI线程卡顿；

2. 布局Layout过于复杂，无法在16ms内完成渲染；

3. 同一时间动画执行的次数过多，导致CPU或GPU负载过重；

4. View过度绘制，导致某些像素在同一帧时间内被绘制多次，从而使CPU或GPU负载过重；

5. View频繁的触发measure、layout，导致measure、layout累计耗时过多及整个View频繁的重新渲染；

6. 内存频繁触发GC过多（同一帧中频繁创建内存），导致暂时阻塞渲染操作；

7. 冗余资源及逻辑等导致加载和执行缓慢；

8. 臭名昭著的ANR。

布局优化

Overdraw有时候是因为你的UI布局存在大量重叠的部分，还有的时候是因为非必须的重叠背景。例如某个Activity有一个背景，然后里面的Layout又有自己的背景，同时子View又分别有自己的背景。仅仅是通过移除非必须的背景图片，这就能够减少大量的红色Overdraw区域，增加蓝色区域的占比。这一措施能够显著提升程序性能。

如果布局中既能采用RealtiveLayout和LinearLayout，那么直接使用LinearLayout，因为Relativelayout的布局比较复杂，绘制的时候需要花费更多的CPU时间。如果需要多个LinearLayout或者Framelayout嵌套，那么可采用Relativelayout。因为多层嵌套导致布局的绘制有大部分是重复的，这会减少程序的性能。

绘制优化

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

• ondraw方法不需要创建新的局部对象，这是因为ondraw方法是实时执行的，这样会产品大量的临时对象，导致占用了更多内存，并且使系统不断的GC。降低了执行效率。

• Ondraw方法不需要执行耗时操作，在ondraw方法里少使用循环，因为循环会占用CPU的时间。导致绘制不流畅，卡顿等等。Google官方指出，view的绘制帧率稳定在60dps，这要求每帧的绘制时间不超过16ms（1000/60)。虽然很难保证，但我们需要尽可能的降低。

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

                                                                                  网络优化

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

Android官方规定：activity如果5s内无响应事件（屏幕触摸事件或者键盘输入事件）。BroadcastReceiver如果在10s内无法处理完成。Service如果20s内无法处理完成。这三种情况会导致ANR。

上面说的三种导致ANR的情况，绝大多数就是因为线程阻塞导致的。那么我们应该如何处理呢？Android系统为我们提供了若干组工具类来解决此问题。

Asynctask：为UI线程与工作线程之间进行快速处理的切换提供一种简单便捷的机制。适用于当下立即需要启动，但是异步执行的生命周期短暂的场景。

HandlerThread：为某些回调方法或者等待某些执行任务的执行设置一个专属的线程，并提供线程任务的调度机制。

hreadPool：把任务分解成不同的单元，分发到各个不同的线程上，进行同时并发处理。

IntentService：适合执行由Ui触发的后台任务。并可以把这些任务执行的情况通过一定的机制反馈给UI。

                                                                                       启动优化

安卓应用的启动方式分为三种：冷启动、暖启动、热启动，不同的启动方式决定了应用UI对用户可见所需要花费的时间长短

冷启动

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

应用发生冷启动时，系统一定会执行下面的三个任务：

• 开始加载并启动应用

• 应用启动后，显示一个空白的启动窗口（启动闪屏页）

• 创建应用信息

那么创建应用信息，系统就需要做一屁股的事：

• application的初始化

• 启动UI线程

• 创建Activity

• 导入视图（inflate view）

• 计算视图大小（onmesure view）

• 得到视图排版（onlayout view）

• 绘制视图（ondraw view）

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

暖启动

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

热启动

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

如何优化

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

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

主线程中涉及到Shareperference能否在非UI线程执行。

Application的创建过程中尽量少的进行耗时操作。

减少布局的层次,并且生命周期回调的方法中尽量减少耗时的操作。

                                                                                  电量优化

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

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

• 需要进行网络请求时，我们需先判断网络当前的状态。

• 在多网络请求的情况下，最好进行批量处理，尽量避免频繁的间隔网络请求。

• 在同时有wifi和移动数据的情况下，我们应该直接屏幕移动数据的网络请求，只有当wifi断开时在调用，因为，wifi请求的耗电量远比移动数据的耗电量低的低。

• 后台任务要尽可能少的唤醒CPU。（比方说，锁屏时，QQ的消息提示行就是唤醒了CPU。但是它的提示只有在你打开锁屏或者进行充电时才会进行提示。）

优化总结

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