一直想学习一下如何写一个 VM，但是苦于各种成熟 VM 代码量庞大，阅读困难，无从学起

即使 lua 的古老版本的代码，对于我这种没有任何编译背景和语言设计背景的人来说，很难理解源码在写什么、在处理什么问题

概述

所谓 Android GC/JIT 抑制，即是将 Android GC(部分)/JIT Task 处理任务的过程(Run 方法) hook，强行 sleep 一段时间。因为 JIT 和 GC 目前均为单线程执行，所以没有并发问题，也刚好阻塞后续任务。

前言

最近遇到了一个有意思的问题，为了让首页更快的展示出来，将首页的请求提前到了 Application onCreate 阶段。但是带来了一个问题，请求的频次大大增加了，且对于后端来说，首页的请求还是比较消耗资源的。

前言

最近帮 RN 业务方查内存泄漏问题，发现了 fbjni 这个库挺有意思的

正好借助 RN 源码例子，讲述一下 fbjni 是如何控制 java 和 c++ 层对象的生命周期的

源码阅读

下面会贴一些 RN 中的源码 和 fbjni 的源码，不用关心 RN 源码中的对象是做什么的，我们这里只关注对象如何被创建和如何被释放的

最近发现线上有一些 used recycled bitmap crash

似乎是问题一直存在，但是近期版本增多了，不过不是我负责，也不好多说什么

其实我觉得主要是造轮子的对于轮子本身理解不够深刻，导致的问题

今天遇到了一个 jni pending exception，好在之前也遇到过，所以我当即就知道肯定是我这行 jni 调用之前就已经出现了 java exception

但是为什么会走到我的代码中？这就是个巧合的事情了

​ 最近在修改私有化的 hprof dump 的库，这个库因为当时对比了koom 和 tailor

koom fork 子进程对应用影响小，但是 tailor 裁剪的 profile 文件更小，所以最终将两者结合在了一起

最近在修改的时候无意间触发了一个神奇的 bug

​

前言

最近一直在治理 OOM 问题，OOM 问题分为多种，其中有一种的原因是 java heap 空间不足

这种 OOM 多发生于低版本手机，或者是存在严重的内存泄漏的高版本手机

现在很多 APP minSdk 都升级到了 21， 这时候低版本 Bitmap 一直分配在 java heap 中，是内存大户，一张大图占用10M级别的内存很正常。而一些低版本的 java heap 只有 128/256M，很容易就 OOM

​

文档

https://source.android.com/docs/core/runtime/art-ti?hl=zh-cn

JVMTI 可以做什么

一些重要的功能包括：

1. 重新定义类。
2. 跟踪对象分配和垃圾回收过程。
3. 遵循对象的引用树，遍历堆中的所有对象。
4. 检查 Java 调用堆栈。
5. 暂停（和恢复）所有线程。

其实远远不止，详情查看文档 https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#architecture

​

Baseline Profile

Baseline Profile 可以用于 Andorid 8.0 以上系统的性能优化

原理简单来说还是 dex2oat 那一套东西，但是我们可以自己收集热点代码，生成对应的二进制文件，加速执行

想要使用，查阅 https://developer.android.com/topic/performance/baselineprofiles/overview 即可