forkdump 触发的神奇 bug

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

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

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

NativeBitmap 实现

前言

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

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

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

JVMTI 的运用

文档

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

/img/in-post/artti.png

JVMTI 可以做什么

一些重要的功能包括:

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

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

dl_iterate_phdr 的 ANR 问题

最近一直在修改一个库,这个库是基于字节开源的 memory-leak-detector 修改的

由于近期增加了一系列的 hook,hook 方法众多,且几乎全量 hook 了所有 so,导致启动时会有 ANR 发生

NDK 导致的包体积问题

​最近同事在升级 Andorid13 遇到了包体积变化的问题!

具体问题:分支 A 编译产出 APK 体积为 110M,而基于分支 A 修改代码,适配 了Android13 后,体积为 160M,足足差了 50M

JNI HOOK

简介

JNI hook 是指: hook JNIEnv 提供的众多方法

正常来说,是没有这方面的需求的。但是,对于低版本的 Android 存在一些 JNI Local Reference 的溢出,超过 512 个便会触发 crash

所以,最好有一种办法可以检测出:创建了但是没有释放的 local reference

pthread 监听

简介

所谓的 native thread,其实就是只我们使用 c/c++ 做开发时,使用的 POSIX 标准的 pthread  

pthread 函数在 libc 中,而 Android 中使用的是 bionic libc(不是 GNU libc) 

pthread 常见方法

  1. pthread_create
  2. pthread_join
  3. pthread_detach
  4. pthread_exit
  5. pthread_getattr_np
  6. pthread_attr_init
  7. pthread_atter_getXXX

比较常用的是 create/join/detach 三个方法,后续的几个方法均是 pthread set/get 一些额外属性所需要的

Accelerate C++ Chapter01

Exercises

Exercise 1-1

Are the following definitions valid? Why or why not?

const std::string hello = "Hello";  
const std::string message = hello + ", world" + "!"; 

编译正确。std::string 重写了 + 操作符

Exercise 1-2

Are the following definitions valid? Why or why not?

const std::string exclam = "!";  
const std::string message = "Hello" + ", world" + exclam;  

编译报错。因为 “Hello” 为 const char *,并没有重载操作符,所以编译报错。