@946898963
2021-02-15T08:26:56.000000Z
字数 3968
阅读 580
Android应用性能优化
注意Multidex弊端，也可能导致应用启动速度过慢。
AndroidAdvanceWithGeektime/Chapter07
Android Systrace 基础知识 -- Systrace 简介
AspectJ介绍(一)
于AspectJ，你需要知道的一切
冷启动的定义：冷启动就是在启动应用前，系统中没有该应用的任何进程信息。
热启动的定义：用户按返回键退出应用，然后又马上重新的启动应用。
与热启动的区别：一是定义上的区别，二是从启动的特点来说，冷启动，创建进程，创建Application，然后创建MainActivity，热启动则不需要创建Application。
冷启动时间的计算：这个时间值从应用启动（创建进程）开始计算，到完成视图的第一次绘制（即Activity的内容对用户可见）为止。Android 你应该知道的的应用冷启动过程分析和优化方案还可以看看博客中的例子
热启动的时候不会在出现那个空白窗口了！！！！自己做了实验，所以网上某些博客的说法是错误的。
网上找的博客：
应用发生冷启动时，系统有三件任务要做：
1，开始加载并启动应用；2，应用启动后，显示一个空白的启动窗口；3，创建应用进程信息；
系统创建应用进程后，应用就要做下面这些事情：
1，初始化应用中的对象 (比如 Application 中的工作)；2，启动主线程 (UI 线程) ；3，创建第一个 Activity；4，加载内容视图 (Inflating) ；5，计算视图在屏幕上的位置排版 (Laying out)；6，绘制视图 (draw)。
来看一下Google官方文档《Launch-Time Performance》对应用启动优化的概述；
应用的启动分为冷启动、热启动、温启动，而启动最慢、挑战最大的就是冷启动：系统和App本身都有更多的工作要从头开始！应用在冷启动之前，要执行三个任务：
加载启动App；App启动之后立即展示出一个空白的Window；创建App的进程；而这三个任务执行完毕之后会马上执行以下任务：创建App对象；启动Main Thread；创建启动的Activity对象；加载View；布置屏幕；进行第一次绘制；
在冷启动的时间段内发生了什么？
首先我们要知道当打开一个Activity的时候发生了什么，在一个Activity打开时，如果该Activity所属的Application还没有启动，那么系统会为这个Activity创建一个进程（每创建一个进程都会调用一次Application，所以Application的onCreate()方法可能会被调用多次），在进程的创建和初始化中，势必会消耗一些时间，在这个时间里，WindowManager会先加载APP里的主题样式里的窗口背景（windowBackground）作为预览元素，然后才去真正的加载布局，如果这个时间过长，而默认的背景又是黑色或者白色，这样会给用户造成一种错觉，这个APP很卡，很不流畅，自然也影响了用户体验。
视频中：
首先，Zygote进程fork出一个新的进程，然后，创建和初始化Application类，创建MainActivity类，接着，inflate布局，当onCreate，onStart，onResume方法都走完，后执行contentView的measure，layout，draw显示在屏幕上。
Application的静态代码块，构造方法----->attachBaseContext---->Application的onCreate方法---->Activity的静态代码块，构造方法---->Activity的onCreate方法---->配置主题中的背景等属性---->onStart----》onResume----> 测量布局绘制显示在屏幕上。
综合：
加载启动App；App启动之后立即展示出一个空白的Window；创建App的进程（在进程的创建和初始化中，势必会消耗一些时间，在这个时间里，WindowManager会先加载APP里的主题样式里的窗口背景（windowBackground）作为预览元素）；而这三个任务执行完毕之后会马上执行以下任务：创建App对象（执行静态代码块-构造函数-onCreate方法）；启动Main Thread；创建启动的Activity对象（执行静态代码块-构造函数-onCreate方法）；加载View（在OnCreate方法中，通过setContentView方法加载并解析布局）；布置屏幕（在此过程中还会执行Acitivity的onStart，onResume方法，不过和布局的measure，layout，draw并不会同步执行的，有可能onStart，onReume方法执行完毕还没有执行完measure，layout，draw，也有可能是measure，layout，draw执行完了，但是onStart，onReume方法还没有执行完）；进行第一次绘制；
网上找的博客：
作为普通应用，App进程的创建等环节我们是无法主动控制的，可以优化的也就是Application、Activity创建以及回调等过程。
同样，Google也给出了启动加速的方向：
1, 利用提前展示出来的Window，快速展示出来一个界面，给用户快速反馈的体验；2, 避免在启动时做密集沉重的初始化（Heavy app initialization）；3, 定位问题：避免I/O操作、反序列化、网络操作、布局嵌套等。
备注：方向1属于治标不治本，只是表面上快；方向2、3可以真实的加快启动速度。接下来我们就在项目中实际应用。
注意是启动的Activity的主题，不是整个APP的主题样式，同时注意启动主Activity的之前，要将样式切换回来。
方案一建议阅读：
Android深度性能优化--启动优化（一篇就够）
启动体验设计-闪屏，启动页，引导页
Android 你应该知道的的应用冷启动过程分析和优化方案
Android冷启动实现APP秒开
Android冷启动实现APP秒开
方案二三
减少 onCreate() 方法的工作量，从而缩短冷启动的时间。
像应用中嵌入的一些第三方SDK，都建议在Application中做一些初始化工作，开发人员不妨采取懒加载（延迟加载）的形式移除这部分代码，而在真正需要用到第三方 SDK 时再进行初始化。
不要在APPlication进行耗时操作，比如有些开发者会在自己的APP里一系列文件夹或文件（比如我自己），这些I/O操作应该放到"确实该使用的时候再去创建"亦或者是数据库的一些操作。
布局也是很重要的，尽量的去减少布局的复杂性，布局深度，因为在View绘制的过程中，测量也是很耗费性能的。
异步初始化组件
梳理业务逻辑，延迟初始化组件、操作
正确使用线程
去掉无用代码、重复逻辑等
异步、延迟初始化及操作的依据？
注意一点：并不是每一个组件的初始化以及操作都可以异步或延迟；是否可以取决组件的调用关系以及自己项目具体业务的需要。保证一个准则：可以异步的都异步，不可以异步的尽量延迟。让应用先启动，再操作。
视频中：
1，减少onCreate方法的工作量
2，不要让Application参与业务的操作
3，不要在Application中进行耗时的操作
4，不要以静态变量的方式在Application中保存数据
5，尽量降低布局的复杂性
总结：
冷启动是无法避免的
1，不要在Application中进行耗时的操作，一些耗时的操作能异步的异步，不能异步的能采用延迟操作的采用延迟操作（延迟两种方案，一种方案是说APP启动完成了，但是没用到这个第三方框架，这时候也去加载，另一种是虽然APP启动完成了，但是我们只有在用到这个第三方框架的时候才去加载）（耗时操作，SDK的初始化，某些文件的读写，把某些数据从文件或者数据库中读出来或者写进去）
2，尽量降低布局的复杂性
3，优化代码，去掉无用代码、重复逻辑等。
4，减少onCreate方法的工作量（同Application）
5，不要让Application参与业务的操作（不要在这里初始化和业务模块相关的数据，只是初始化和整个应用相关的数据）
做的冷启动优化的方式
打印时间的工具TraceView?, AOP?,AspectJ?
建议阅读：