​

背景

最近依葫芦画瓢搞了一个 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) 没什么概念，只是知道肯定后者更快。但是快到什么个程度？不知道

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

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

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

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

​

前言

最近被 shadow 和 跨进程的 router 搞得头疼，感觉这俩框架跨进程部分写的略微有点混乱。

如果是纯用反射传 className，那就跨进程传字符串，然后再分发咯 = handleMessage 呗，应该写的比较聚合才对。

​

前言

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

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

包体积优化的一些手段

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 内的值，可以直接内联

​

前言

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

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

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

​

前言

不知道大家使用 Fresco 时，有没有遇到过这种情况呢？

一些文章上是说，导致的原因是在设置了 圆角 的情况下，设置错了 ScaleType 导致图片不能铺满整个 View，进而出现了图中的情况。

前言

最近来了个新环境，做了第一个需求——直播答题。

这边的风格大致就是：先在能使用的库的基础上快速完成需求，整个开发时间大概在2-3周，客户端总共俩人，我主要负责直播间内的业务逻辑。