forkdump 触发的神奇 bug
最近在修改私有化的 hprof dump 的库,这个库因为当时对比了koom 和 tailor
koom fork 子进程对应用影响小,但是 tailor 裁剪的 profile 文件更小,所以最终将两者结合在了一起
最近在修改的时候无意间触发了一个神奇的 bug
最近在修改私有化的 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
一些重要的功能包括:
其实远远不止,详情查看文档 https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#architecture
Baseline Profile 可以用于 Andorid 8.0 以上系统的性能优化
原理简单来说还是 dex2oat 那一套东西,但是我们可以自己收集热点代码,生成对应的二进制文件,加速执行
想要使用,查阅 https://developer.android.com/topic/performance/baselineprofiles/overview 即可
今天遇到了个神奇的问题!
测试反馈某一个渠道包,运行时 crash,其他渠道包都没问题
因为我们的渠道包的代码本质上是一样的,出现一个包有问题,其他包没问题的情况,实在百思不得其解
最近一直在修改一个库,这个库是基于字节开源的 memory-leak-detector 修改的
由于近期增加了一系列的 hook,hook 方法众多,且几乎全量 hook 了所有 so,导致启动时会有 ANR 发生
最近同事在升级 Andorid13 遇到了包体积变化的问题!
具体问题:分支 A 编译产出 APK 体积为 110M,而基于分支 A 修改代码,适配 了Android13 后,体积为 160M,足足差了 50M
JNI hook 是指: hook JNIEnv 提供的众多方法
正常来说,是没有这方面的需求的。但是,对于低版本的 Android 存在一些 JNI Local Reference 的溢出,超过 512 个便会触发 crash
所以,最好有一种办法可以检测出:创建了但是没有释放的 local reference
所谓的 native thread,其实就是只我们使用 c/c++ 做开发时,使用的 POSIX 标准的 pthread
pthread 函数在 libc 中,而 Android 中使用的是 bionic libc
(不是 GNU libc)
比较常用的是 create/join/detach 三个方法,后续的几个方法均是 pthread set/get 一些额外属性所需要的
Exercises
Are the following definitions valid? Why or why not?
const std::string hello = "Hello";
const std::string message = hello + ", world" + "!";
编译正确。std::string 重写了 + 操作符
Are the following definitions valid? Why or why not?
const std::string exclam = "!";
const std::string message = "Hello" + ", world" + exclam;
编译报错。因为 “Hello” 为 const char *,并没有重载操作符,所以编译报错。