vivo高启强

项目升级到 AGP8 以后 一直有个问题，有一个 利用 jacoco 做代码覆盖率的插件 一直会导致项目编译失败，偶现，且 build 失败给出的 堆栈信息迷惑性很强，导致问题排查方向错了，最后发现是

linux下多线程文件操作的坑 有一块业务之前的代码逻辑大概是： 图片下载以后会在kotlin中的协程中 对这个图片进行一系列的读写操作，但是因为业务逻辑会在 bindViewHolder 中进行处理

日志分析 典型的NE问题，而且该crash集中在 <=android9 的版本上，可以粗估一下该问题属于系统bug，在android10上得到了官方修复 一般碰到这种疑似系统bug的，可以去issue

CodeLocator 应该是我平时工作中使用频率最高的idea插件了，只可惜不适配K2 mode 这里有idea的官方文档 教你怎么做插件适配 idea官方推荐的适配方式 之前我是clone了cod

AGP8.0+ 如何 处理图片压缩任务 上一篇文章中，我们知道如何寻找mergeRes的任务hook点 这篇文章就基于上篇文章的结论 来做一下 编译期压缩图片的任务 有了doLast的回调函数，那我们

在以前的agp版本中，我们可以onVarint回调中直接获取到任意task的provider，这让我们可以很轻松的插入一个任务到android的编译过程中 在8.0+以后 这个方案失效了， 这个会导致

最近一直在做agp8.0+的插件适配，涉及到不少知识点，踩到不少坑，特此记录下 gradle和gradle-api的区别 我们在插件开发的时候 如果你看官方的demo 你会发现他们现在都是给你grad

因为宿主app 升级到AGP8的缘故，Booster 需要升级到5.0版本， 该版本 transform 实现 有部分问题 ，这里给出临时性的解决方案 获取不到gradle.properties 中的

AsyncLayoutInflater 能否提高页面渲染速度？ 答案是不能的，至少大部分情况不能。 源于默认的 AsyncLayoutInflater 使用的子线程没有指定优先级 在我们默认主线程xm