今天遇到了个神奇的问题！

测试反馈某一个渠道包，运行时 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) 

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 一些额外属性所需要的

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 *，并没有重载操作符，所以编译报错。

​

背景

最近依葫芦画瓢搞了一个 dex2oat 的优化实验，用于冷启动场景

全量编译的情况下，劣化 400ms，部分编译的情况下有大概 100ms(数据在逐渐缩小)

dex2oat 的现状

其实在 Android 10 以后，之前的 dex2oat 命令行已经失效了，目前能有效触发 dex2oat 的只能依靠 jit 强制编译命令

​发现一个有趣的问题：

今天同事突然问我：“你看这个什么情况，我没使用 resGuard 相关的资源混淆的东西啊，打出来的包为什么资源被混淆了？”

因为他们在做 AGP7.0 的升级，AGP 的升级往往又带着各种 buildTools 的升级，而 aapt2 又是 buildTools 的一部分，那我肯定是往这方面怀疑。

​

前言

oh，技术真的浮躁，也真的没用~~

来看个有意思的例子：

fastjson2 FASTJSON2是FASTJSON项目的重要升级，目标是为 下一个十年 提供一个高性能的JSON库

背景

一直对于 O(N) 和 O(logN) 没什么概念，只是知道肯定后者更快。但是快到什么个程度？不知道

直到最近做了一个上万量级的数据查找才有了真实体验

结论就是：两者可以有三个数量级的差异