最近不知道为什么，我司又开始缩减包体积了，在这个 app 都 100-200M 的年代，在这个 5G 遥遥领先的年代，不知道卷个啥？

那问题不大，既然有需求，我们照做便是

前置思考

Android 包体积由多方面构成，这个我之前的文章里也有说过，所以包体积缩减的手段有很多，这个就不一一介绍了

前段时间看了下 Elk(十分简单的 JS VM，其实算是个 parser + interpreter 吧)的代码，学到了一些计算机基础的东西。

比如，我写代码这么久，甚至不知道 double 的内存结构和 7FF 代表什么。比如，因为没有系统学习过编译原理等等，没有 opcode 相关的概念，如何设计 interpreter(又想回去读书了……)。

一直想学习一下如何写一个 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