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

dex 和 mmap

背景

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

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

dex2oat 的现状

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

AGP BuildTools 之间的关系

​发现一个有趣的问题:

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

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

xv6 macOS 运行环境

前言

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

来看个有意思的例子:

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

DebugInfo 复用

apk 包体积这块,因为网络传输速度不断提升和手机存储空间的不断提升,越来越有点不是那么重要了

主要最近一直有这方面的需求,所以研究了一下包体积相关的东西,对于 android 的编译流程,有了更多的了解

包体积优化的一些总结

前言

最近一直在搞包体积的优化,有点点心得

并且在优化的过程中发现了原有工程的各种问题,这里总结一下。

包体积优化的一些手段

Dex 优化

R8 和 ProGuard 配置优化

  1. R8 目前已经是默认的编译优化工具,只需要 minifyEnable = true
    1. 基础功能
      1. code shrink 删减
      2. obfuscation 混淆
      3. optimization 优化
    2. R8 fullMode 模式
      1. 包体积还可以继续缩减
      2. 遇到的问题 [R8 fullMode Constructor 问题]
        1. Gson 解析问题
        2. kotlin data class
      3. 解决办法
        1. -keepclasseswithmembers class * { (…); @com.google.gson.annotations.SerializedName ; }
  2. ProGuard 配置优化
    proGuard 描述了代码混淆和删减的规则,代码删减直接缩减 dex 体积,代码混淆会使类名、方法名、变量名更短从而缩减 dex 体积。
    目前 proGuard 配置存在的一些问题:
    1. 重复
      -keepclassmembers class .entities. { ; }
      -keepclassmembers class com.xingin.xhs.model.entities.
      * { *;}
      // 范围很大
      -keep @Kotlin.Metadata class * { *; }
    2. 删除 kotlin metadata 注解
      1. kotlin metadata keep 规则导致所有 kotlin 代码被 keep
      2. 引发了一些负负反而得正的潜在问题(Gson 解析)
    3. 删除 kotlin Intrinsics
    4. 优化 optimize 并没有开启
      1. -dontoptimize:删除这条 keep 规则,才会开启 R8 的代码优化
      2. optimize 的副作用:插件化打包的内联问题
  3. 隐性存在的反射大家没有在意
    需要 Gson 解析的类的成员变量被混淆了,到底对于解析有没有影响?
    1. Gson 的解析,默认依赖反射,除非有注解
    2. 反射效率和启动耗事问题

R.class 优化

R.class 内的值,可以直接内联

不太优雅的治理 MMKV FD 的方式

前言

最近看了很多 fd 的问题,在一些机型上 fd 数量超过 1024 便会抛出 OOM。

mmkv 正常是没什么问题的,但是如果使用了过多实例,也是会占用一部分的 fd。

mmkv 每一个实例会持有两个 fd(如果你没有释放过的话),在一个大工程里,很有可能同时存在 30+ 的 mmkv 实例,也就是 60+ 的 fd,因为每个业务可能都想有自己的 mmkv 实例(文件),甚至同一个业务下的子逻辑也想有自己的 mmkv 实例,加上 java 程序员从不考虑资源释放问题(me too),这也进一步加剧了 fd 不够用···最终 OOM