ITPub博客

从SliverPersistentHeader源码，聊聊解决滑动被优先消费的设计

不论是代码优化、架构设计、性能调优都逃不开这些基本原理。离开了地基，再高深的设计模式、框架思维，都很容易成为空中楼阁

由繁至简的过程，其实是一种不一样的体验，“笨办法”或许有时候才是真正聪明的做法，真正的经验往往不是“多高明的技巧”，而是什么时候该停下折腾，选择最合适的平衡点。

在不同阶段，哪怕是“临时方案”，也有它存在的价值——它帮助我们快速推进了项目，并为后续优化打下了实践基础。

面对三端并行开发带来的巨大复杂度，我们并不急于“全栈统一”，而是更关注架构的合理性与团队协作的可持续性。Kotlin Multiplatform 为我们提供了一种相对平衡的解法：既不牺牲原生的性能与体验，也能实现核心逻辑的最大化复用。它本质上不是一种“跨平台替代品”，而是对多端架构设计能力的升级。

一个项目需要有能快速上线并且快速看到用户反馈的能力，也就应该有能够快速定位和解决问题的能力。而如果拥有随时可以重构代码的能力，那么其实不应该对“有问题的代码”产生焦虑。

有时候核心需求的「精准命中」远胜技术完美，功能的价值最终由用户的「实际使用」而非「技术指标」来定义。

我们常说 View 的“绘制不对劲”，但很多情况下问题出在测量阶段（onMeasure）和布局阶段（onLayout），本文将通过几个实际遇到的坑，帮你彻底理解 View 为什么会宽度为 0、为什么动态设置宽度不生效，甚至测量逻辑反复触发导致表现异常。

很多架构在项目初的时候看不出破绽；只有当项目维护和扩展越来越难的时候，才真正意识到——设计模式不是“装饰”，而是“地基” 。

Android拖拽view进行移动是一个很常见并且很“正常”的功能，在合理的逻辑中，可以实现并不复杂的运算，对于用户设备的性能消耗理论上也可以得到一个较好的支持。

Android低版本中的 WindowInsets 分发机制是「懒惰式且缺乏自动性」的 —— 依赖 ViewRootImpl.performTraversals() 调用链的主动触发，无法在布局未完成的场景中保证完整、时机正确地分发 Insets

在我们的项目中有一个场景，类似系统相册中点击全屏预览，再次点击退出全屏，其中顶部toolbar要处理全屏时的对状态栏的计算，原本以外只要对状态栏的处理和计算即可，但是发现一个神奇的现象，在开启底部三个金刚键之后，toolbar的计算却出现问题

最近在开发的项目中包含了很多复杂的Ui以及各种自定义view和手动添加的view，包括各种复杂的动画效果，在今天调试一个动画的时候，发现页面滑动严重的卡顿，用开发者模式的Gpu条形图发现滑动的时候gpu占用直接满了，导致疯狂掉帧，排查后发现一个非常诡异的现象：Debug 包滑动时掉帧严重，动画出现明显卡顿；但用相同代码打出的Release包运行流畅

原以为只是个图片加载问题，结果绕了一圈，发现是 Glide、Bitmap、View 三者联动下的隐秘 Bug。这是一篇关于图片透明圆角被“吃掉”的终极分析与解决方案。

Android开发中，使用 Glide 加载图片资源是一个很常见的方案。但是最近我遇到了一个十分诡异的问题：使用 Glide 加载本地 R.mipmap 资源时，加载的图片竟然不是我传入的资源 ID，而是上一次加载的另一张图片

在涉及排序、查询等敏感操作时，尽量使用编译期内联的常量（例如使用字符串模板），以确保在混淆过程中字符串不会被错误处理，从而保证功能正常。

在最近的项目开发中，遇到了一个关于布局的BUG。最开始以为这只是一次酣畅淋漓，非常麻烦的问题修复，慢慢深入发现了，只需要简单的适配即可。

Room 数据库的版本升级虽然提供了自动迁移机制，但在复杂的跨版本场景中仍然可能踩坑

在最近的项目开发中，我有个产品需求，需要修改到原来的数据库，增加一个字段，对于数据库操作原本以为很简单，但是没想到踩了一个巨大的坑，今天有空对这个问题进行分析，在这过程中学习到了很多，成长的代价总是惨痛的。

通过 WorkManager 的 beginUniqueWork 和 APPEND_OR_REPLACE 策略，我们可以优雅地管理云相册的上传任务队列