Android首次启动卡顿问题分析

想第一时间获取我的最新文章,请关注公众号: 技术特工队

在有些 Android 机器上首次启动时会出现很明显的卡顿问题,且比较明显的是只会在安装后的首次出现,很是奇怪,那么要分析这个问题则需要了解启动的不同类型的区别以及不同版本间的区别了。

启动的分类

启动分三种,首次安装后的冷启动,冷启动,热启动

首次安装完的冷启动

这个指的是用户对APK进行安装后,首次进行打开的过程。

app的冷启动

指当启动应用时,后台没有该程序的进程。

热启动

指程序依然在,启动时通过已有进程启动应用。

虚拟机区别

Dalvik(Android5.0 以下系统)

在5.0以下的版本中,默认的虚拟机为Dalvik,Dalvik虚拟机与Java虚拟机有差不多的特性,都是解释执行的。Dalvik采用的是JIT(及时编译)技术。 .dex格式是专为Dalvik设计的一种压缩格式,在每次执行应用的时候Dalvik虚拟机都会将程序的语言由高级语言编译为机器语言。

在应用启动时 JIT通过进行连续的性能分析来优化程序代码的执行,在程序运行的过程中,Dalvik虚拟机在不断的进行将字节码编译成机器码的工作,这样当前的程序才能运行。启动程序优化代码并存储在Dalvik缓存中。Dalvik第一次加载后会生成Cache文件,以提供下次快速加载,所以第一次会很慢。

优缺点

优点:

  • 1、 占用空间较小
  • 2、 安装速度快

缺点:

  • 1、 启动速度慢

    ART-Android RunTime (Android 5.0 以上系统)

在5.0以上的系统默认采用了ART(Android RunTime)模式,它正式的取代了以往的Dalvik虚拟机,ART能够把应用程序的字节码转换为机器码,是Android所使用的一种新的虚拟机,ART采用Ahead-of-time(AOT)技术,此种模式对Dalvik进行了很多的优化,包括性能,以及垃圾回收器等。

在ART模式下系统在安装应用的时候会进行一次预编译,在安装应用程序时会先将代码转换为机器语言存储在本地,这样在运行程序时就不会每次都进行一次编译了,执行效率也大大提升。

优缺点

优点:

  • 1、系统性能的显著提升。
  • 2、应用启动更快、运行更快、体验更流畅、触感反馈更及时。
  • 3、更长的电池续航能力。
  • 4、支持更低的硬件。

缺点:

  • 1、占用更多空间
  • 2、安装时间变长

对上面两个有个很好的比喻:

Dalvik 是已经折叠起来的自行车,每次骑都要先组装自行车才能骑
ART 是已经组装好的自行车,每次骑直接上车就能走人

综合分析

Dalvik是执行的时候编译+运行的模式。而ART是编译好的直接进行运行。
如果我们的应用比较大,比如有多个dex文件,那么这时候在不同虚拟机平台上启动速度是很不一样的,在Dalvik的虚拟机上,需要将每一个dex文件转化为机器码,dex越多越大则耗时越高,所以对于首次安装的冷启动是很慢很慢的,有时可能还会造成 ANR ,当然第一次之后会将相应的缓存保存在data/dalvik-cache下面,后续的冷启动读取缓存进行加载运行。相对会比首次安装后启动快很多。
然而在ART的模式下,由于其是在安装的过程中进行这部分处理的,所以应用的启动速度不受这些的影响。

解决方法

对于在Dalvi虚拟机上的目前是没有很好的办法去解决首次安装后的冷启动,因为这个是系统虚拟机的限制导致此问题,此过程是必经之路。

瞎方法(不推荐)
对于系统定制开发来说,可以在自己代码中起一个很普通的service,什么都不做,启动起来只有就自己结束。然后另外一个系统常驻的service,监听系统新增的应用包,监听到后启动这个应用的空白service,这个过程就相当于让程序能够自运行一下。让虚拟机首次启动执行的过程跑一遍,加快后续在启动的一个启动速度。当然这样就会导致系统与应用有些耦合。当然这只是一个瞎推荐的方法。

相关的参考资料

Activity 启动 Display 延迟问题源码分析代码如下:http://blog.csdn.net/kc58236582/article/details/60134836

Google 官方对于启动时间一些说明: https://developer.android.com/topic/performance/launch-time.html

想第一时间获取我的最新文章,请关注公众号: 技术特工队

WangXin wechat
欢迎订阅我的微信公众号,第一时间获取最新文章!
坚持原创技术分享,您的支持将鼓励我继续创作!