APP性能优化---启动耗时优化

当我们再使用一个app应用时，如果这个app点击桌面图标后，比较长的时间都没有响应，那对这个app的第一印象就不是很好，甚至就直接卸载掉了，这简直是一个app致命的结果。
那么，我们如果做可以给用户一个比较好的使用体验呢，下面就一步一步来了解一下：

app启动状态

三个状态：冷启动，温启动，热启动。

1.冷启动：
在下面几个清空下出现：设备重新启动，或者新安装的app还没有启动使用过，这时候就是冷启动。系统进行冷启动后才创建应用进程。

2.热启动：
将Activity 从后台唤醒到前台来运行，此时应用的所有的activity还在内存中，不需要重新创建，初始化、绘制页面等工作。

3.温启动：
温启动和介于上述两种状态下的一个启动，他的开销要比热启动高。例如用户退出app后，再次重新启动app ,这时候app进程未必被销毁，虽然需要执行onCreate来重新创建来继续运行。

启动耗时的2-5-8 原则##

1.当启动耗时 < 2s，用户会觉得响应很快；

2.当启动耗时 2s<= && < 5s ，则响应速度还可以；

3.当启动耗时》，则响应速度就很慢，不过还可以接受

4.当启动耗时 > 8s ，就会觉得很糟糕了，不可以接受

启动耗时统计

了解了上述启动的一些内容后，我们该如何统计启动耗时呢？实际上不同的应用业务场景需要初始化的内容不同，不同的终端设备，启动耗时都不同，即使是同一应用同一设备也会存在启动耗时不同的，所以启动耗时并没有一个统一的标准。我们之所有要做启动耗时统计，要满足产品对启动耗时的要求。

统计指令：
在命令行切换到adb的目录下：

adb shell  //进入shell命令

am   start -S -W   com.xxxx.xxx / XXXActivity

说明：
1.am 命令的 s , w都是大写
2.com.xxxx.xxx 是应用的包名
3. XXXActivity 是应用的main，launcher的activity 
4. 包名和activity之间是有一个 “   /  ”  (笔者因为漏写 / ，踩了很久的坑)

输出结果：

ThisTime: 968
TotalTime: 968
WaitTime: 978
Complete

Status: ok
ThisTime: 1028
TotalTime: 1028
WaitTime: 1041
Complete

Status: ok
ThisTime: 1029
TotalTime: 1029
WaitTime: 1046
Complete

说明：
ThisTime : 表示一连串启动Activity的最后一个Activity的启动耗时
TotalTime：表示新应用启动的耗时，包括新进程的启动和Activity的启动，但不包括前一个应用Activity pause的耗时
WaitTime：总的耗时，包括前一个应用Activity pause的时间和新应用启动的时间


所以我们只需要关心 total Time 的时间就可以了。（建议可以多次执行上述命令，统计一个大概的启动时间，比如笔者执行完后，大概耗时是在1s左右）

注：其他统计工具profiler 在内存优化中介绍

优化建议

有了上述统计的优化时间统计，我们就到启动页面去进行分析，发现在activity的onResume中做了异步的网络请求：

    //检查版本更新
    override fun onResume() {
        super.onResume()
            if (presenter != null) {
                presenter.requestForUpgrade()
            }
    }

那么这个耗时的请求我们是否可以在启动完成后进行呢，答案是肯定。下面就是优化后的代码:

//检查版本更新
 override fun onResume() {
        super.onResume()
        Looper.myQueue().addIdleHandler {
            if (presenter != null) {
                presenter.requestForUpgrade()
            }
            false
        }
    }

那么优化后的耗时统计又如何呢？我们执行命令看看结果：

Status: ok
ThisTime: 979
TotalTime: 979
WaitTime: 988
Complete

Status: ok
ThisTime: 952
TotalTime: 952
WaitTime: 961
Complete

Status: ok
ThisTime: 954
TotalTime: 954
WaitTime: 980
Complete

Status: ok
ThisTime: 996
TotalTime: 996
WaitTime: 1014
Complete

Status: ok
ThisTime: 956
TotalTime: 956
WaitTime: 976
Complete

可以看出我们得优化有那么一丢丢的效果，虽然不是很明显，但是就像“一分钱也是爱”一样的，积少成多，慢慢来优化。

在此仅做一些技术记录，供学习参考。优化进行中。。。。。