用 & 0xFF 是因位运算能精准屏蔽无关位、高效提取指定颜色分量，而 % 或除法慢且易出错；掩码需依颜色格式位宽调整，如 RGB565 中红用 & 0x1F 而非 & 0xFF。
为什么用 & 而不是 % 或除法提取 RGB 分量
因为 & 是位级屏蔽，不依赖数值大小或进制转换，只保留你关心的那几位，其余全清零。比如 0xFFAABBCC 中想取红色（高8位），右移16位后是 0x0000FFAA，但高位可能残留垃圾数据；加 & 0xFF 就能确保只留低8位——也就是干净的 0xAA。而 % 和除法要走完整算术路径，慢且易受溢出/符号影响。
& 0xFF 这个掩码到底在干啥
它本质是二进制的 11111111，和目标值做按位与，相当于“开一个8位宽的窗口”，只让低8位透过来，其他全挡掉。常见错误是误写成 & 255——虽然数值一样，但可读性差；更糟的是写成 & 0xF（只留4位）或 & 0xFFFF（留16位），会导致 G/B 混叠或 R 值错乱。
-
color = 0xFFAABBCC→R = (color >> 16) & 0xFF正确 -
R = (color >> 16) % 256可运行但不推荐，无必要引入除法 -
R = (color >> 16) & 0xF错：只取到0x0A，丢了一半红 -
R = color & 0xFF错：取到的是0xCC（B通道）
不同颜色格式下掩码和位移要同步调整
RGB 打包格式变了，掩码位置就得跟着动。不能死记 & 0xFF 就万事大吉——关键看你要的分量落在哪一段。
- 24位
0xRRGGBB：R = (c >> 16) & 0xFF，G = (c >> 8) & 0xFF，B = c & 0xFF - 32位 ARGB
0xAARRGGBB：A = (c >> 24) & 0xFF，R/G/B 同上 - 16位 RGB565：
R = (c >> 11) & 0x1F（5位红），G = (c >> 5) & 0x3F（6位绿），B = c & 0x1F（5位蓝）
这里掩码从 0xFF 换成 0x1F 或 0x3F，是因为对应通道只占 5 或 6 位，多留位会污染结果。
合成时也得用 & 0xFF 防越界
输入的 R/G/B 值如果超过 0–255 范围（比如计算中间值溢出、用户传入非法值），直接左移拼接会导致高位数据错位。必须先截断：
color = ((R & 0xFF)- 漏掉任一
& 0xFF，比如R = 300，R 就变成 <code>0x12C0000，远超24位，后续或操作会破坏 G/B 位置
真正容易被忽略的，是合成前的截断动作——很多人只记得提取时用掩码，却忘了拼回去时同样需要防御性位清理。
