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

前言

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 是有偏见的)，抓住核心的理念应该会很好理解，其实就是一个事件流的问题。