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的进程间的通信。