ITPub博客

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

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

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

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

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

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

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

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

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

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

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

在我们的一个应用中有一个功能是需要显示时间的秒数分钟数等，正常的逻辑中，就是每秒去更新一次TextView的setText()从而实现数据的显示。而当我们需要这个TextVIew能够移动时，却发现移动后每秒TextVIew都会重制位置

最近新接手了一个项目的Bug修复任务，其中有一个Bug是在一个页面有一个ImageView,ImageView根据传入的图片设置宽度拉满或者高度拉满，然后根据imageView的大小通过代码绘制一个新的View，在onCreate中绘制总是位置错乱，放入onResume后，从后台重新进入应用就可以正常绘制。

最近在项目中发现有个recyclerview滑动掉帧现象很严重，刚好最近要更新一个版本，就准备把这个问题优化了

近期猛猛修bug，针对跨进程activity与activity，activity与fragment之间传递大数据可能出现的崩溃进行修复

前段时间适配target30，然后发现返回监听实效了，于是适配了下，顺便看了下finish()和onBackPressed()的区别

最近遇到的一个bug，在点击输入框第二次后才会触发设置的点击事件，然后查到了一个有意识的事情

截止到写这篇博客时，已经在开发第二个IOS项目了，特此记录这段时间的开发

这是我开发iOS项目以来的第一次开发记录，踩了很多的坑，摸索了很多也查了很多东西，不同于我在安卓上可以扒原理，看源码的技术程度，iOS开发目前还属于初级水平，只能解决问题，但是对于很多问题目前只有一些猜测，属于知其然不知其所以然

最近在开发时遇到一个需求，给定一个ListA集合，里面存储不定长度的String字符串，通过网络请求获取另外一串ListB数据，读取ListB，将ListB中含有ListA中字符串的数据放到集合前方，将不含有相关数据的放入后方