为什么是 8

先把 dp 说清楚

你每天都在写 16.dp，但可能没仔细想过它是什么。

物理像素 = dp × (屏幕 dpi / 160)

看红色那一格：5dp 在 hdpi 上是 7.5 个物理像素。

半个像素是不存在的。系统只能取整——四舍五入成 7 或者 8。于是同一个「5dp 的间距」，在某些设备上是 7px，在另一些上是 8px。你的边线会时粗时细，你的间距会时紧时松。

而 8 呢？8 × 1.5 = 12，8 × 3 = 24——全是整数。

落不落格，能查

规则清楚了，剩下的是执行。下面这台检查器把一屏的每条边（左、上、右、下）都拿去除以 8，看余数：

点「吸到网格上」。注意两件事：

1. 画面几乎没变。最大的一次挪动也只有几个像素，肉眼很难指出哪里动了。
2. 但落格率从一堆红变成了 100%。

这正是第 1 章那个论点的又一次出现：收窄的代价接近零，收益是从此有了一把尺。

哪些东西该落格，哪些不该

这里有个常见的误解：「8pt 网格」不是说所有尺寸都必须是 8 的倍数。

写进代码

// 一个文件，全 App 的间距都从这儿来
object Spacing {
    val none  = 0.dp
    val hair  = 2.dp    // 只给边框、分隔线这类
    val tiny  = 4.dp    // 图标和它的文字之间
    val tight = 8.dp    // 组内
    val snug  = 12.dp
    val base  = 16.dp   // 屏幕边距
    val group = 24.dp   // 组之间
    val block = 32.dp   // 大区块之间
    val wide  = 48.dp
    val huge  = 64.dp
}

// 用的时候：名字表达意图，数字只是实现
Column(
    verticalArrangement = Arrangement.spacedBy(Spacing.tight),
    modifier = Modifier.padding(horizontal = Spacing.base)
)

让「随手写」变难

光有 Spacing 对象没用，你还是会顺手写 13.dp。要让「随手写」比「查阶梯」更麻烦：

// detekt / ktlint 自定义规则的思路：
// UI 层（*.ui.*、*Screen.kt、*Composable）里，
// 禁止出现裸的 Int.dp / Int.sp 字面量，
// 只允许 Spacing.*、MaterialTheme.*、以及 0.dp。
//
// 例外白名单要短，而且每个例外要写注释说明为什么。

// ✗ 编译过，lint 挂
Modifier.padding(13.dp)

// ✓
Modifier.padding(Spacing.snug)

// ✓ 有出处的例外
Modifier.padding(top = statusBarHeight)   // 来自系统，不是我选的

一个例外：光学间距

最后说一个网格管不着的地方，免得你以后撞上时以为自己做错了。

当两个元素的形状差别很大时，等距未必等于看起来等距。最典型的是「一个圆形头像 + 一段文字」：如果按外框算，圆的左右会显得比方块空——因为圆的边缘是弯的，它离你的间距的「有效距离」更远。

这时候需要往回收一点点。这属于光学调整，也就是下一章的主题——那一章会告诉你这个「一点点」是可以精确算出来的，不是靠眼睛蒙的。