kizitonwose/Calendar项目中的背景绘制优化：解决多选日期时的白线问题

问题背景

在实现日历视图的多选日期功能时，开发者可能会遇到一个视觉问题：当用户连续选择多个日期时，日期单元格之间偶尔会出现白色竖线。这种现象在日历宽度无法被7（一周的天数）整除时尤为明显，会导致UI显示不连贯，影响用户体验。

技术原理分析

这个问题本质上源于Drawable对象的共享使用方式。在原始实现中，开发者将背景Drawable对象提取为全局变量供所有日期单元格复用。这种设计虽然节省了内存，但带来了一个关键缺陷：

1. Drawable尺寸固定：当Drawable被首次创建时，它会根据第一个使用它的视图尺寸进行内部测量
2. 布局分配不均：在日历视图中，当总宽度不能被7整除时，系统会将剩余像素分配给某个日期单元格，导致该单元格比其他单元格略宽
3. 尺寸不匹配：共享的Drawable仍保持初始较小尺寸，无法填满被分配了额外像素的单元格，从而露出背景形成白线

解决方案

正确的实现方式是为每个日期单元格创建独立的Drawable实例：

class DayViewContainer(view: View) : ViewContainer(view) {
    // 每个容器实例拥有自己的Drawable
    val rangeStartBackground = view.context.getDrawableCompat(R.drawable.bg_start).also {
        it.level = 5000 
    }
    // 其他Drawable声明...
}

这种改造带来了以下优势：

1. 尺寸自适应：每个Drawable会根据所在视图的实际尺寸进行测量
2. 显示完整性：无论单元格被分配多少额外像素，Drawable都能完整填充
3. 内存考量：现代Android设备的资源管理已足够优秀，这种级别的对象创建不会造成显著内存压力

实现建议

在实际开发中，建议开发者：

1. 避免共享可变UI资源：特别是与视图尺寸相关的Drawable对象
2. 注意布局整除性：对于需要严格对齐的UI元素，考虑使用约束布局等现代布局方案
3. 性能平衡：在内存敏感场景，可考虑对象池技术，但要确保正确处理尺寸变化

总结

这个案例展示了Android UI开发中一个典型的设计考量：资源共享与显示效果的平衡。通过将Drawable实例从全局共享改为视图独占，我们既解决了显示异常问题，又保持了代码的简洁性。这种解决方案不仅适用于日历组件，对于其他需要动态尺寸适配的UI场景也具有参考价值。