update 运行期优化

master
Omooo 5 years ago
parent 92723f1780
commit 23c77568ba
  1. 14
      blogs/Android/性能优化/包体积优化.md
  2. 60
      blogs/JVM/晚期(运行期)优化.md
  3. 2
      blogs/computer_network/深入理解计算机系统/计算机系统漫游.md

@ -21,6 +21,16 @@
优化之前,肯定需要了解包体积是由哪些部分组成的? 优化之前,肯定需要了解包体积是由哪些部分组成的?
APK 包含以下目录:
- META-INF/:包含 CERT.SF 和 CERT.RSA 签名文件,以及 MANIFEST.MF 清单文件。
- assets/:包含应用的资源,应用可以使用 AssetManager 对象检索这些资源。
- res/:包含未编译到 resources.arsc 中的资源。
- lib/:包含特定于处理器软件层的编译代码。此目录包含每种平台类型的子目录,如 armeabi、armeabi-v7a、arm64-v8a、x86、x86_64 和 mips。
- resources.arsc:包含已编译的资源,此文件包含 res/value/ 文件夹的所有配置中的 XML 内容。打包工具会提取此 XML 内容,将其编译为二进制文件形式,并将相应内容进行归档。此内容包括语言字符串和样式,以及未直接包含在 resources.arsc 文件中的内容(例如布局文件和图片)的路径。
- classes.dex:包含以 Dalvik/ART 虚拟机可理解的 DEX 文件格式编译的类。
- AndroidManifest.xml:包含核心 Android 清单文件。此文件列出了应用的名称、版本、访问权限和引用的库文件。该文件使用 Android 的二进制 XML 格式。
![](https://i.loli.net/2019/04/01/5ca15e3a3181e.png) ![](https://i.loli.net/2019/04/01/5ca15e3a3181e.png)
事实上,安装包无非就是 Dex、Resource、Assets、Library 以及签名信息这五部分,以下我们就针对这五部分进行优化。 事实上,安装包无非就是 Dex、Resource、Assets、Library 以及签名信息这五部分,以下我们就针对这五部分进行优化。
@ -157,12 +167,12 @@ ANDROID_SDK=/Users/omooo/Library/Android/sdk redex app-debug.apk -o app-resize.a
#### 参考 #### 参考
[https://developer.android.com/topic/performance/reduce-apk-size](https://developer.android.com/topic/performance/reduce-apk-size)
[包体积优化(上):如何减少安装包大小?](https://time.geekbang.org/column/article/81202) [包体积优化(上):如何减少安装包大小?](https://time.geekbang.org/column/article/81202)
[包体积优化(下):资源优化的进阶实践](https://time.geekbang.org/column/article/81483) [包体积优化(下):资源优化的进阶实践](https://time.geekbang.org/column/article/81483)
[减少 APK 的大小,Android 官方这样说](https://juejin.im/entry/5824447ca0bb9f0058d9d281)
[支付宝 App 构建优化解析:Android 包大小极致压缩](https://mp.weixin.qq.com/s/_gnT2kjqpfMFs0kqAg4Qig) [支付宝 App 构建优化解析:Android 包大小极致压缩](https://mp.weixin.qq.com/s/_gnT2kjqpfMFs0kqAg4Qig)
[美团 Android App包瘦身优化实践](https://tech.meituan.com/2017/04/07/android-shrink-overall-solution.html) [美团 Android App包瘦身优化实践](https://tech.meituan.com/2017/04/07/android-shrink-overall-solution.html)

@ -11,4 +11,62 @@
在部分的商用虚拟机(HotSpot),Java 程序最初是通过解释器进行解释执行的,当虚拟机发现某个方法或代码块的运行特别频繁时,就会把这些代码认定为 “热点代码”。为了提高热点代码的执行效率,在运行时,虚拟机将会把这些代码编译成与本地平台相关的机器码,并进行各种层次的优化,完成这个任务的编译器就称为即时编译器,即 JIT 编译器。 在部分的商用虚拟机(HotSpot),Java 程序最初是通过解释器进行解释执行的,当虚拟机发现某个方法或代码块的运行特别频繁时,就会把这些代码认定为 “热点代码”。为了提高热点代码的执行效率,在运行时,虚拟机将会把这些代码编译成与本地平台相关的机器码,并进行各种层次的优化,完成这个任务的编译器就称为即时编译器,即 JIT 编译器。
#### HotSpot 虚拟机内的即时编译器 ### HotSpot 虚拟机内的即时编译器
先来思考以下几个问题:
1. 为何 HotSpot 虚拟机要使用解释器和编译器并存的架构?
2. 为何 HotSpot 虚拟机要实现两个不同的即时编译器?
3. 程序何时使用解释器执行?何时使用编译器执行?
4. 哪些程序代码会被编译为本地代码?如果编译为本地代码?
5. 如何从外部观察即时编译器的编译过程和编译结果?
#### 解释器与编译器
尽管并不是所有的 Java 虚拟机都采用解释器与编译器并存的架构,但很多主流的商用虚拟机,如 HotSpot、J9等,都同时包含解释器与编译器。解释器与编译器两者各有优劣:当程序需要迅速启动和执行的时候,解释器可以首先发挥作用,省去编译的时间,立即执行。在程序运行后,随着时间的推移,编译器逐渐发挥作用,把越来越多的代码编译成本地代码之后,可以获取更高的执行效率。当程序运行环境中内存资源限制较大,可以使用解释执行节约内存,反之可以使用编译执行来提高效率。同时,解释器还可以作为编译器激进优化时的一个 “逃生门”,让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段,当激进优化的假设不成立,如加载了新类后类型继承结构出现变化、出现 “罕见陷阱” 时可以通过逆优化退回到解释状态继续执行。
HotSpot 虚拟机中内置了两个即时编译器,分别称为 Client Compiler 和 Server Compiler,或者简称为 C1 编译器和 C2 编译器。用户可以配置虚拟机参数强制虚拟机运行于解释模式或者编译模式。
由于即时编译器编译本地代码需要占用程序运行时间,要编译出优化程度更高的代码,所发费的时间可能更长;而且想要编译出优化程度更高的代码,解释器可能还要替换编译器收集性能监控信息,这对解释执行的速度也有影响。为了在程序启动响应速度与运行效率之间达到最佳平衡,HotSpot 虚拟机还会逐渐启用分层编译的策略。分层编译根据编译器编译、优化的规模与耗时,划分出不同的编译层次,其中包括:
* 第 0 层
程序解释执行,解释器不开启性能监控功能(Profiling),可触发第 1 层编译。
* 第 1 层
也称为 C1 编译,将字节码编译为本地代码,进行简单、可靠的优化,如有必要将加入性能监控的逻辑。
* 第 2 层
也是将字节码编译为本地代码,但是会启用一些编译耗时较长的优化,甚至会根据性能监控信息进行一些不可靠的激进优化。
实施分层编译后,Client Compiler 和 Server Compiler 将会同时工作,很多代码都可能会被多次编译,用 Client Compiler 获取更高的编译速度,用 Server Compiler 来获取更好地编译质量,在解释执行的时候也无需再承担收集性能监控信息的任务。
#### 编译对象与触发条件
上文中提到过,在运行过程中会被即时编译器编译的 “热点代码” 有两类,即:
* 被多次调用的方法
* 被多次执行的循环体
前者很好理解,一个方法被调用的多了,方法体内代码执行的次数自然就多,它成为 “热点代码” 是理所当然的。而后者则是为了解决一个方法只被调用过一次或少量的几次,但是方法体内部都存在循环次数较多的循环体的问题,这样循环体的代码也被重复执行多次,因此这些代码也应该认为是 “热点代码”。
对于第一种情况,由于是由方法调用触发的编译,因此编译器理所当然的会以整个方法作为编译对象,这种编译也是虚拟机中标准的 JIT 编译方式。而对于后一种情况,尽管编译动作是由循环体所触发的,但编译器依然会以整个方法(而不是单独的循环体)作为编译对象。这种编译方式因为编译发生在方法执行过程之中,因此形象的称之为栈上替换(OSR )。
那多少次才算 “多次” 呢?虚拟机如何统计一个方法或一段代码被执行多少次了呢?解决这两个问题,也就回答了即时编译被触发的条件。
判断一段代码是不是热点代码,是不是需要触发即时编译,这样的行为称为热点探测,其实进行热点探测并不一定要知道方法具体被调用了多少次,目前主要的热点探测判定方式有两种,分别如下:
* 基于采样的热点探测
采用这种方法的虚拟机会周期性的检查各个线程的栈顶,如果发现某个方法经常出现在栈顶,那么这个方法就是 “热点方法”。基于采样的热点探测的好处是实现简单、高效,还可以很容易的获取方法调用关系,缺点是很难精确地确认一个方法的热度,容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。
* 基于计数器的热点探测
采用这种方法的虚拟机会为每个方法(甚至是代码块)建立计数器,统计方法的执行次数,如果执行次数超过一定的阈值就认为它是 “热点方法”。这种统计方法实现起来要麻烦一些,需要为每个方法建立并维护计数器,而且不能直接获取到方法的调用关系,但是它的统计结果相对来说更加精确和严谨。
在 HotSpot 虚拟机中使用的是第二种 --- 基于计数器的热点探测方法,因此它为每个方法准备了两类计数器:方法调用计数器和回边计数器。
在确定虚拟机运行参数的前提下,这两个计数器都有一个确定的阈值,当计数器超过阈值溢出了,就会触发 JIT 编译。

@ -68,8 +68,6 @@ linux> gcc -o hello hello.c
##### 系统的硬件组成 ##### 系统的硬件组成
1. 总线 1. 总线
贯穿整个系统的是一组电子管道,称为总线,它携带信息字节并负责在各个部件间传递。通常总线被设计成传送定长的字节快,也称为字。字中的字节数是一个基本的系统参数,各个系统中都不尽相同。现在的大多数机器字长要么是 4 个字节(32位),要么是 8 个字节(64位)。 贯穿整个系统的是一组电子管道,称为总线,它携带信息字节并负责在各个部件间传递。通常总线被设计成传送定长的字节快,也称为字。字中的字节数是一个基本的系统参数,各个系统中都不尽相同。现在的大多数机器字长要么是 4 个字节(32位),要么是 8 个字节(64位)。

Loading…
Cancel
Save