APP 冷启动 /热启动

什么是冷启动

冷启动就是在应用启动前，系统中没有该应用的任何进程信息。
比如说第一次打开，应该杀死再开启。

冷启动/热启动的区别

热启动：用户使用返回键退出应用，然后又马上重新启动应用
冷启动，系统会重新创建新的进程分配给它，所以会先创建和初始化 application类，再创建和初始化MainActivity类，然后会进行测量啊，布局绘制等等，最后显示在界面上。
热启动，会从已有的进程来启动，所以不会走application类，而直接走MainActivity 类。

冷启动 时间的计算

在 android 4.4 之后，提供了一个方法
这个时间值，从应用启动（创建进程）开始计算，到完成视图的第一次绘制，即activity 内容对用户可见为止。

冷启动的流程

点击App 启动图标的时候：
android系统会从 Zygote 进程中fork 创建出一个新的进程
创建和初始化 Application 类，创建MainActivity 类
inflate 布局 ，当onCreate/onStart/onResume 方法都走完
contentView 的measure/layout/draw 显示在界面上

Application 的构造方法 -->attachBaseContext() --> applicaition 的onCreate() --> Activity 的构造方法 --> act 的 onCreate() ---> 配值主题中的背景 属性 等等 -----> onStart() -----> onResume() -----> 测量布局 绘制 显示在界面上。

重点之 冷启动的优化

• 减少onCreate( ) 方法的工作量
  用户总要等待一个启动时间，而我们所能做的 就是 在 applicaiton 和第一个MainActivity 类 减少 onCreate() 的工作量，从而减短时间冷启动时间，但是又不得不使用一些第三方SDK，可以使用一些懒加载，在真正使用的地方再去初始化。
  在Activity 创建的过程中，其实是会经过一系列 framework层的代码。但是懒加载也有不好的地方，就是很难把所有的场景都列出，哪个第三方是 先使用的，所以一般还是放在 applicaition 去初始化
• 不要让Application 参与 业务操作
• 不要在 Application 进行耗时操作
• 不要以静态变量的方式 在Application 中保存数据
• 布局 / mainThread 的 操作

其他优化

android 不要用静态变量存储数据
因为在Android 中，进程不是安全的，有时候会被杀掉，下次是 重新初始化的 进程，数据不安全。
使用其他 数据传输文件：文件 / sp / contentProvider
传输数据可以用intent

有关Sharepreference 问题
不能跨进程同步
在多进程读写的时候，不能跨进程的读写数据，或者获取数据， 每个进程都会维护自己的一份sharepreference 副本，在它运行过程中，其他进程是无法获取这个shareprefer 副本，只有在应用结束之后，才能将每个进程的副本持久化的修改到文件系统当中。
存储Sharepreference 的文件过大问题
android 五大存储之一： 网络，数据库，contentProvider，文件，sp。
以 key -vlaue 成对存储的
如果存的文件比较大
第一个问题就是：获取值的时候有可能阻塞主线程，影响性能，有可能引起界面卡顿。
第二个问题就是：解析式会产生大量的 临时对象，会造成频繁的垃圾回收，大量的gc 造成内存抖动。
key-value 存在内存中，耗内存

内存对象的序列化
序列化：将对象 的状态信息转化为可以存储传输的的形式的过程

• Serializable java 的 序列化方式 会产生大量的临时变量，引起垃圾回收
• Parcelable 是 android中自带的一种序列化方式，比Serializable 性能更好，有个明显的缺点就是，不能把那些要存储在磁盘上的数据用parcelabel 来序列化 ，其本质就是为了实现对象在进程间的传递，并不是一个通用的序列化机制，用的场合基本都是android的进程间的通信。