dex 和 mmap
背景
最近依葫芦画瓢搞了一个 dex2oat 的优化实验,用于冷启动场景
全量编译的情况下,劣化 400ms,部分编译的情况下有大概 100ms(数据在逐渐缩小)
dex2oat 的现状
其实在 Android 10 以后,之前的 dex2oat 命令行已经失效了,目前能有效触发 dex2oat 的只能依靠 jit 强制编译命令
最近依葫芦画瓢搞了一个 dex2oat 的优化实验,用于冷启动场景
全量编译的情况下,劣化 400ms,部分编译的情况下有大概 100ms(数据在逐渐缩小)
其实在 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 呗,应该写的比较聚合才对。
最近一直在搞包体积的优化,有点点心得
并且在优化的过程中发现了原有工程的各种问题,这里总结一下。
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周,客户端总共俩人
,我主要负责直播间内的业务逻辑。