1.《Android Runtime源码解析》介绍
2.Android Runtime
3.ART模式和Dalvik模式
4.ART 深入浅出 - 为何 Thread.getStackTrace() 会崩溃？

《Android Runtime源码解析》介绍

       《Android Runtime源码解析》是我创作的第二本技术专著，于6月底完成印刷，现已在各大电商平台上市。借此机会，我简要介绍本书内容，以便对此感兴趣的lua文件源码翻译朋友能有所了解。

       本书以Android .0.0_r源码为基础，从编译器开发者的视角，分析了ART的各个部分及其主要流程，旨在向读者展示ART的基本框架。由于ART发展至今，规模庞大，复杂度较高，很多细节无法完全覆盖。因此，本书选择基本框架进行介绍，以便读者根据个人兴趣深入挖掘感兴趣的细节。

       全书内容分为四个部分。第一部分包括第一章，主要介绍ART的基础知识；第二部分包括第二章至第四章，主要介绍ART中的编译器部分，包括dex2oat工具，c 模板的源码这部分属于编译时阶段；第三部分包括第五章和第六章，主要介绍ART的启动和运行，属于运行时阶段；第四部分包括第七章，主要介绍ART中的垃圾回收部分。读者可以按照顺序阅读，也可以根据自己的需要选择阅读相关部分，不影响对内容的理解。

       各章内容如下：第一章，从虚拟机基础、ART发展历史、ART核心架构和源码目录结构等方面对ART基础进行了介绍；第二章，介绍了dex2oat工具的入口、driver以及DexToDexCompiler等；第三章，分析了OptimizingCompiler中的JNI处理和Compile过程，并对Compile过程中的主要环节进行了详细阐述；第四章，介绍了OptimizingCompiler中硬件平台无关和硬件平台相关的优化，并深入分析了硬件平台无关优化中的典型优化；第五章，分析了ART在启动时的几个主要流程；第六章，分析了ART在执行时的主要流程；第七章，分析了ART GC的整体架构、种类及具体实现。共享日历web源码

       本书适合新入行的ART开发者以及想了解ART基本情况的各类开发者。

       由于作者水平有限，本书中可能存在诸多问题，敬请各位专家批评指正。

Android Runtime

       Android Runtime（ART）是Google公司推出的一种运行环境，作为Android操作系统的一部分在年首次公开。ART取代了以前的Dalvik虚拟机，将应用的字节码转换为机器码，提供新的虚拟机运行机制。与Dalvik的即时编译（JIT）技术不同，ART采用预编译（AOT）技术，提前将字节码编译为机器码，从而优化程序运行效率。ART在性能、垃圾回收、调试和性能分析上进行了改进。通过将Dalvik字节码文件（dex）转换为可执行与可链接格式（ELF），ART在应用安装过程中完成了预编译，使得运行时无需实时编译，提高了效率和续航能力。虽然ART模式下应用安装和存储需求有所增加，开源源码编写但节省了Dalvik虚拟机用于实时编译的时间。ART预览版在Android 4.4中发布，与后续版本的ART运行库在兼容性上有明显差异。

ART模式和Dalvik模式

       ART模式ART模式英文全称为:Android runtime，谷歌Android 4.4系统新增的一种应用运行模式，与传统的Dalvik模式不同，ART模式可以实现更为流畅的安卓系统体验，对于大家来说，只要明白ART模式可让系统体验更加流畅，不过只有在安卓4.4以上系统中采用此功能。

Dalvik模式

       如果要解释清楚什么是ART模式，我们就需要从Android系统的应用编译模式说起，我们都知道Android系统是以Linux系统为底层构建的，Android系统是开源(源代码公开)的，Android系统势必会适配到不同硬件配置的设备上，因此谷歌为了降低应用的开发难度在Linux底层之上构筑了一个名为“Dalvik”的虚拟机。

       因为Dalvik虚拟机的存在，Android系统的开发者只需使用谷歌提供的SDK(软件开发工具包)即可较为轻松的按照一套“规则”创建APP，不用顾忌硬件、驱动等问题，在每次执行应用的短线跟踪指标源码时候Dalvik虚拟机都会将程序的语言由高级语言编译为机器语言，这样当前设备才能够运行这一应用。

art模式有什么好处

       在ART模式下，系统体验到底有什么不同。要开启ART模式操作比较简单，首先是开启Android系统的开发者选项，具体开启方式同Android 4.3的一样，同样是连续

       点击7次版本号即可。接着进入开发者模式，在“选择运行环境中”将运行模式由默认的Dalvik的修改为“使用ART”，切换成功以后系统会自动重启并且自动更新系统，更新

       系统是因为系统程序也需要重新编译。切换模式后最明显的变化就是安装程序的空间明显增加，这是因为程序将编译后的机器语言会一同保存在手机中。还有一个变化

       就是运存的占用率明显降低了，这是因为开机后的系统程序已经不再需要虚拟机进行重新编译。而且最让我们欣喜的是，在ART模式下系统的流畅度有非常大的提升，不

       管是滑动界面还是运行程序，整个系统的流畅度已经达到了如丝般顺滑的地步，与iOS系统不相上下，注意这里说的如丝顺滑毫不夸张。

ART模式和Dalvik模式的不同

性能:

       ART面世以后很多人已做了测试。结果大多是ART模式下程序的加载和切换速度有一定的提升，某些特定条件下可以快%左右。Youtube上的这个视频( youtu.be 的页面)中，两部同样运行着KitKat的Nexus 7同时加载Photoshop Touch，使用ART的速度明显快于Dalvik。至于空间要求，我对底层了解不多，但ART是Ahead-Of-Time compiler，所以基本可以肯定空间上要求更高。

兼容性:

       ART只出现在开发者选项中，目前仍然处于测试阶段，兼容性仍不尽如人意。很多应用，例如，Pandora，Kingdom Rush等都无法正常运行，所以只适合用来测试和尝鲜。随着用户使用数据的收集和Google的进一步完善，相信兼容性不是大问题。而且ART只是Android底层的runtime，至少作为用户不需要担心使用上的差别。至于开发者，肯定需要在适当的时候调整开发策略，充分利用ART的优势。

取代:

       趋势上看，ART取代Dalvik只是迟早的事情。Android诞生已经5年有余，Google为了提升Android的性能已经从上到下做出了所有的努力，唯独一直没有触及Dalvik runtime。所以想进一步优化Android平台，Dalvik是非改不可的。

怎么开art模式

       1、手机待机界面，点击应用程序图标。

       2、在手机应用程序界面，找到并点击设定齿轮图标。

       3、进入手机设定界面后，找到并点击关于手机

       4、在此界面，连续点击7次内部版本号。

       5、返回后，即可看到开发者选项，点击进入开发者选项。

       6、在开发者选项菜单的底部选择切换到ART模式，切换需要重启系统。

ART 深入浅出 - 为何 Thread.getStackTrace() 会崩溃？

       ART 深入浅出：Thread.getStackTrace() 崩溃原因剖析

       Thread.getStackTrace() 在卡顿检测中常被调用，但频繁调用可能导致崩溃，崩溃堆栈通常显示为：VMStack_getThreadStackTrace() -> ThreadList::SuspendThreadByPeer() 等。本文将逐步解析其崩溃机制。

       在 ART (Android Runtime) 的源码 Android 版本中，VMStack.cc 的 GetThreadStack 函数是关键，它涉及线程挂起和回调生成调用栈的过程。首先，通过 SuspendThreadByPeer() 函数挂起线程，然后回调生成调用栈，最后恢复线程。然而，这个过程可能因超时引发问题，例如当 SuspendThreadByPeer() 在线程状态检查中判断线程未挂起时，超时会触发 ThreadSuspendByPeerWarning()，严重时会导致 Runtime::Abort。

       通常，使用 ThreadList::SuspendThreadByThreadId() 函数可以避免这种 Crash，因为它在超时后只会产生警告，而不是终止。超时时间默认为 秒，如果线程长时间未能挂起，可能源于 ART 挂起线程的机制。在旧版 ART 中，挂起线程通过 ModifySuspendCount() 函数设置标志位，但在新版本中，这个逻辑已有所改变。

       深入探究，Java 的 Check Point 概念在其中起关键作用。解释执行的 switch/case 语句和机器码执行都有检查点，这些检查点会暂停线程执行，进行垃圾回收、调试等操作。当 Thread.getStackTrace() 触发挂起时，会进入 CheckSuspend() 函数，依据状态标志位决定挂起或执行检查点。真正的挂起操作会在析构函数中执行，通过 wait 函数挂起线程，直到其他线程执行到唤醒操作。

       总结来说，Thread.getStackTrace() 崩溃源于线程挂起操作与检查点执行的同步问题。当线程未能及时进入检查点，getStackTrace() 的等待时间过长，从而导致崩溃。理解了这个机制，就能避免此类问题的发生。