​

前言

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

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

包体积优化的一些手段

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周，客户端总共俩人，我主要负责直播间内的业务逻辑。

前言

https://www.youtube.com/watch?v=Mj5P47F6nJg

这个演讲太棒了，演讲人是 Roman Elizarov - Project Lead for the Kotlin Programming Language

按照他的 PPT 我自己总结了一下

Kotlin Coroutines Design Story

首先 kotlin 的协程库 = 线程池 + 任务调度，但是这个调度过程比较复杂，而且整个过程也并没有直接接管 JVM 或者 操作系统层面的东西，所以也没有 go routines 的神奇的抢占调度。 然后只有一个关键字 suspend, suspend 函数机制

​

前言

又好久好久没更新了，主要是最近研究的东西对我来说都比较难，内功不够 的情况下，写不出东西来。

C/C++ 被我暂时搁置了

最近本来是打算捡起来 C++ 的(也 Hello World 了一下 Rust，这个语言感觉对于以前写 Java 的人来说， 看起来理解起来都好别扭啊···)。

前言

鉴于好多人对于跨端技术觉得玄之又玄，我自己虽然没有实际从0到1的写过跨端框架，但是使用过 Yoga(React-Native 的布局引擎)做过一些简易的跨端的事且后来使用过 Weex，对于跨端研究过一阵，所以来科普一下。

前言

RxJava 是一个经常让人出错的库，有的同事第一次接触完全搞不懂，个人感觉是没抓住核心的理念(其实我个人对于 RxJava 是有偏见的)，抓住核心的理念应该会很好理解，其实就是一个事件流的问题。

前言

内存泄漏对于日常简单的业务开发而言 很常见也不常见(如果你还是说 Handler 那一套的话，除非你使用 Handler 做 timer，否则 总有一个时间 会释放所谓的内部类引用的 Activity 等对象)。一般作为业务开发能制造内存泄漏的情景，我遇到的有几种(当然可能存在更多的情况)：

前言

Handler、Looper、MessageQueue 是老生常谈的话题了，你可能会觉得没什么好讲的啊，网上文章也一堆。

这里我有几个问题问一下，如果你都很清晰，那就完全不需要看此文。