简介面向Android开发者的高级颜色选择器实现资源旨在将Photoshop中专业调色板交互移植至移动端。项目覆盖色轮选择、RGB/HSV色彩模式切换、滑块控制、Alpha透明度调整及色样管理等核心功能同时包含UI布局优化与触摸事件处理的技术细节适合想深入理解自定义View与颜色处理的中高级开发者。资源包共58个文件以Java源码、编译后的class、XML布局、PNG资源为主另含测试APK、JAR库及配置文件便于直接运行与二次开发。已有826人学习浏览压缩包仅330KB结构紧凑但内容完整。资源中的ColorPanel组件从布局绘制、事件分发到颜色空间换算均给出完整示例通过阅读源码可掌握色彩转换算法、触控反馈与性能优化的实现链路既可作为组件集成到实际项目也能作为系统学习移动端图像处理组件的参考案例对提升自定义控件能力有切实帮助。1. 为什么要亲手撸一个仿PhotoShop调色板先交代下背景。我之前在做一个偏向设计工具类的App里面有个很核心的诉求用户需要像在PhotoShop里那样自由地取色、调色。最初图省事接了个开源的颜色选择器库但实际用起来非常难受——交互太简陋只有色相条加一个方块的模式放大取色时连基本的微调都不支持更别提炼色器、最近颜色、Hex实时联动这些习惯了。后来在技术社区看到很多人在讨论类似的痛点Android原生自带的ColorPickerDialog丑到没法直视第三方库的自定义程度又有限。于是我决定自己动手基于Android的自绘体系实现一个仿PhotoShop调色板。这个项目不依赖任何第三方渲染框架核心就是自定义View加Canvas绘制纯Kotlin实现最终完整支持色相滑动条、饱和度/亮度二维取色面板、RGB分量调节、Hex实时输入、放大微调以及屏幕取色器。这篇文章适合谁看如果你正准备给App加一个专业级的调色面板或者你想搞懂PhotoShop那种取色交互背后的色值计算逻辑与手势处理方案那这篇实战记录应该能让你少走很多弯路。我会从色彩模型的选择、核心View的绘制、手势交互设计到大面板的性能优化把整个项目的关键环节拆开讲清楚。别人可能觉得调色板就是个换个颜色的小功能但真做起来你会发现它涉及ColorSpace转换、Canvas绘制效率、触摸事件分发、View局部刷新、位图像素读取等多块知识。正因为踩了不少坑我才想把完整经验沉淀下来。2. 核心算法先行HSV模型是PhotoShop取色的地基在动手写任何View之前必须先想明白一个本质问题为什么PhotoShop的调色板长得是一个色相条一个大方块而不是一堆红绿蓝数字滑杆2.1 为什么选HSV而不是RGBRGB是一种面向设备的颜色模型红绿蓝三原色叠加表达颜色。它的问题是不直观你想让颜色更青一点需要同时调整G和B普通人根本转不过弯。而HSV把颜色分解为色相Hue0-360度、饱和度Saturation0-1、明度Value0-1三个维度刚好对应人类的直觉感知这是什么颜色、颜色正不正、颜色亮不亮。PhotoShop经典取色界面就是围绕HSV设计的色相条负责选H值二维方块的横向是S、纵向是V。这个交互最大的好处是当你把H固定在某个色相后方块的左边缘是纯灰阶S0右边缘是纯色S1上边缘是最亮V1下边缘是黑色V0一屏之内就能看全所有明暗和浓淡的可能组合。2.2 HSV与RGB转换的降级方案Android的Color.colorToHSV()和Color.HSVToColor()其实已经提供了现成的转换方法底层计算我第一版也直接用了。但把玩下来发现有两点不满意一是大色块逐像素转换场景下反复调用系统方法会有额外开销二是HSVToColor对参数合法性的隐含约束不够灵活比如H值越界时会算出让人意外的颜色。所以我在项目中单独实现了一组转换函数核心逻辑保持和Android实现一致但保证输入H在0-360区间、S和V在0-1区间时一定返回预期的ARGBfun hsvToColor(h: Float, s: Float, v: Float): Int { val hue ((h % 360) 360) % 360 val sat s.coerceIn(0f, 1f) val value v.coerceIn(0f, 1f) val c value * sat val x c * (1 - kotlin.math.abs((hue / 60) % 2 - 1)) val m value - c val (r, g, b) when { hue 60 - Triple(c, x, 0f) hue 120 - Triple(x, c, 0f) hue 180 - Triple(0f, c, x) hue 240 - Triple(0f, x, c) hue 300 - Triple(x, 0f, c) else - Triple(c, 0f, x) } return Color.rgb( ((r m) * 255).toInt().coerceIn(0, 255), ((g m) * 255).toInt().coerceIn(0, 255), ((b m) * 255).toInt().coerceIn(0, 255) ) }这段逻辑本质上是把HSV色环切成六个60度的扇区每个扇区RGB三通道的变化规律是不同的线性插值。理解了这个公式后面做色相条渐变和方块面板渐变就都顺了。2.3 PhotoShop取色交互的分解动作PhotoShop的调色板看起来很复杂实际拆解下来就是三个动作的叠加拖动色相条改变H值S保持1、V保持1时得到当前色相的顶点纯色这个纯色是二维面板渐变的基准色。在二维面板点击或拖动以基准色为基础横向线性减小S饱和度为0时变灰纵向线性减小V明度为0时变黑。微调RGB或Hex把HSV结果和RGB结果做双向同步任意一侧改动都会实时刷新另一侧的显示与色块预览。只要把这三个动作的状态机和回调设计好整体功能就算成立了。我的实现里使用一个ColorState数据类维护当前色值它同时保存hsv和rgb两套表示任何UI变更都走同一个applyChange入口保证所有关联控件同步刷新。3. 色相条与二维取色面板的绘制看着像PhotoShop只是第一步这部分是视觉效果的核心。PhotoShop的色相条和二维面板都带有非常顺滑的渐变过渡想在Android里复现这种质感关键是用好SweepGradient和LinearGradient。3.1 色相条的两种画法色相条常见的表现有两种一种是直线条从左到右渐变另一种是圆环环绕一周。PhotoShop桌面端常用的是直线竖向色相条。我实现的是直线横向色相条视觉效果稳定手势也只在一维方向做。线性色相条直接用LinearGradient生成360度的连续色相渐变val colors IntArray(360) { i - hsvToColor(i.toFloat(), 1f, 1f) } val gradient LinearGradient( 0f, 0f, width.toFloat(), 0f, colors, null, Shader.TileMode.CLAMP )这里colors数组生成360个颜色每个颜色对应一个色相角度的纯色S1, V1。LinearGradient默认会在这些颜色之间做线性插值视觉上就是一条顺滑的彩虹渐变。其实更省内存的方式是只用几个关键颜色让渐变库自动插值但实测360个颜色在色相过渡上更接近PhotoShop的连续感且只初始化一次性能完全可接受。3.2 二维饱和度明度面板的叠加渐变二维面板的核心技巧在于两层渐变叠加第一层以当前色相纯色为基准从左到右从饱和到不饱和即从纯色渐变为白色第二层从上到下从透明渐变到黑色。PhotoShop里这个面板的左上角是白色S0, V1右上角是当前纯色S1, V1左下角是黑色S0, V0右下角是黑色S1, V0。理解了这四个角你就知道渐变该怎么写了// 第一层横向饱和度渐变 val saturationShader LinearGradient( 0f, 0f, width.toFloat(), 0f, Color.WHITE, currentPureColor, Shader.TileMode.CLAMP ) // 第二层纵向明度渐变 val valueShader LinearGradient( 0f, 0f, 0f, height.toFloat(), Color.TRANSPARENT, Color.BLACK, Shader.TileMode.CLAMP )绘制时先画横向饱和度渐变再叠加纵向明度渐变。这里有个必须注意的地方千万不要用Paint的setAlpha去处理明度层因为那是整体半透明会把底下渐变的边界也弄糊。正确做法是让LinearGradient自身在TRANSPARENT到BLACK之间插值这样颜色空间才是按比例压暗而不是蒙一层玻璃纸。3.3 指示器找准位置要比画得好看更重要渐变画完之后还需要画取色指示器。PhotoShop里是一个圆环加十字准星。我实现的是一个带白边的小圆private fun drawIndicator(canvas: Canvas, cx: Float, cy: Float, color: Int) { val outer Paint(Paint.ANTI_ALIAS_FLAG).apply { style Paint.Style.STROKE strokeWidth 6f color Color.WHITE } val inner Paint(Paint.ANTI_ALIAS_FLAG).apply { style Paint.Style.STROKE strokeWidth 2f color if (isColorLight(color)) Color.BLACK else Color.WHITE } canvas.drawCircle(cx, cy, 18f, outer) canvas.drawCircle(cx, cy, 14f, inner) }isColorLight这一步很重要如果当前点颜色是浅色比如黄色白色圆环几乎看不见得叠加一个深色内圈保证对比度。计算公式用的是相对亮度(0.299*R 0.587*G 0.114*B)大于180就算浅色。有不少教程只讲画个圆环但实际使用中指示器的可见性和准确位置直接决定调色体验。我第一版没加isColorLight判断结果取到亮黄色时圆环完全隐形调试了很久才发现是对比度问题。4. 手势交互让拖动、微调、实时预览都按PhotoShop的逻辑走绘制层面搞定后更大的挑战是交互。PhotoShop的调色板在主面板取色和色相条选色之间切换非常顺手而且支持点击直接跳转、拖动连续变化。这些体验背后是触摸事件处理和坐标映射的精细设计。4.1 触摸事件的命中区域划分我的调色板是三个区域组合在一个自定义ViewGroup里顶部是二维面板底部是色相条中间留着固定间距。为了让触摸逻辑清晰我在onTouchEvent里先判断触摸点落在哪个区域override fun onTouchEvent(event: MotionEvent): Boolean { val x event.x val y event.y when { y panelBottom - handlePanelTouch(event, x, y) y hueBarTop - handleHueTouch(event, x, y) } return true }注意actionDown时也要更新否则只靠actionMove会导致用户点一下没有任何反馈。而且返回true后整个View会接管手势流后续的move、up都会持续回调这点对连续拖动很重要。4.2 从触摸坐标反推HSV值不管用户点在哪个位置最终都需要把坐标变成颜色值。色相条坐标换算hue (x / hueBarWidth) * 360f然后clamp到0-360之间。面板坐标换算横向算饱和度纵向算明度val s (x / panelWidth).coerceIn(0f, 1f) val v (1f - y / panelHeight).coerceIn(0f, 1f)这里有个新手特别容易搞错的地方屏幕坐标的y轴向下增长但HSV的V值越大越亮、越靠上。因此从y坐标映射到V值时一定要用1 - y / height否则上下颠倒了用户往上拖反而变暗。拿到s和v之后再结合当前色相值h调用前面实现的hsvToColor(h, s, v)得到最新的颜色刷新指示器位置和外部回调。4.3 放大微调撑起专业感的细节PhotoShop用户最喜欢的操作之一是放大取色区域做精细调整。在移动端上我用双指缩放实现了这个需求当用户双指在面板区域捏合时面板会以两指中心点为锚点逐渐放大再配合单指拖动来微调颜色。原理并不复杂维护一个scaleFactor浮点变量双指间距变化时更新它绘制时把Canvas按锚点做缩放canvas.save() canvas.scale(scaleFactor, scaleFactor, anchorX, anchorY) // 绘制面板和指示器 canvas.restore()但触摸坐标的映射也要同步变化单指拖动时实际颜色坐标 锚点 (触摸坐标 - 锚点) / scaleFactor。这样即使面板放大了2倍手指动1像素仍然只会让颜色移动半像素的效果精细度翻倍。实测下来双指缩放加单指取色的组合在图片精确取色时特别好用。之前我们的设计师直接在手机上调出和PS完全一致的颜色靠的就是这个放大微调能力。4.4 取色器从Bitmap里读取像素颜色调色板还附带了一个屏幕取色器从相册选一张图片点击图片任意位置提取颜色。实现上核心是Bitmap.getPixel(x, y)。但这里有个大坑如果直接加载一张高分辨率图片并显示缩放后的Bitmap手指点击的坐标和原图坐标会有偏差。所以我的实现分两步走先加载原图并统一缩放到屏幕能显示的尺寸保留采样率记忆触摸时记录的是显示图上相对坐标拿颜色时用相对坐标乘回原图缩放比例val srcX (touchX / displayWidth * originalWidth).toInt() val srcY (touchY / displayHeight * originalHeight).toInt() val color bitmap.getPixel(srcX, srcY)这个大图采样用BitmapFactory.Options的inSampleSize来处理避免直接加载原图导致OOM。实际项目里选了一张8000x6000的照片测试显示图只有1500x1100左右取色依然准确。5. 联动与细节打磨Hex输入、RGB滑杆、最近颜色与状态同步如果说上面这些是骨架那联动和细节就是血肉。调色板真正好用的状态是用户拖动色相条面板颜色跟着变指示器跟着移Hex输入框实时跳动RGB滑杆同步刷新预览色块无延迟更新。这个多向同步的架构是非常值得展开的。5.1 统一状态入口避免多个控件互相刷新的死循环我设计了一个ColorStateListener接口任何UI控件的变更都会以参数形式传给一个中心调度器ColorPickerMediatorinterface ColorPickerMediator { fun onColorChanged(color: Int, source: ChangeSource) }ChangeSource是一个枚举标记这次变化来自哪个控件HUE_BAR、SAT_VAL_PANEL、RGB_SLIDER、HEX_INPUT、EYE_DROPPER。中心调度器拿到新颜色后先更新内部的currentColor再通知除变更来源之外的所有控件刷新。这样做的好处是Hex输入框触发颜色变化时不会再反向去更新Hex输入框自身避免输入-刷值-触发监听-再输入的无限循环问题。这个设计我是在第一版被死循环折磨了两次之后才想明白的强烈建议有类似需求的朋友直接采用。5.2 RGB滑杆与Hex输入的联动细节RGB滑杆比色相条简单本质是三个0-255范围的SeekBar。但设置滑杆进度时有个顺序问题如果先设置R再设置G每次设置都会触发一次onProgressChanged导致中间态颜色闪烁。解法是加一个isProgrammaticUpdate布尔标志在代码批量设置进度时挂起监听等三个滑杆都设置完再恢复fun updateSliders(color: Int) { isProgrammaticUpdate true redSlider.progress Color.red(color) greenSlider.progress Color.green(color) blueSlider.progress Color.blue(color) isProgrammaticUpdate false }Hex输入框则要处理两件事合法性校验和输入中不全局刷新。我的做法是监听TextWatcher只在文本长度等于6且全是十六进制字符时才解析并触发onColorChanged否则只改输入框的字体颜色提示用户格式不对。这样用户在输入F、FF这些中间状态时不会看到整个界面颜色乱跳。5.3 最近使用颜色与透明度棋盘格PhotoShop有最近使用颜色的小色块列表我也做了类似功能。实现时用一个LinkedHashSetInt保存历史颜色新颜色加入时如果已存在就先移除再插入保证最新颜色排在最前最多保留12个。每次取色完成时把颜色写入这个集合并刷新色块网格。透明度棋盘格是另一个容易被忽略的细节。调色板输出的ARGB颜色可能带透明通道如果预览色块直接画一个纯色用户根本看不出透明效果。因此我在预览色块下方先画一个灰白相间的小棋盘格再在上面叠加颜色private val checkerPaint Paint().apply { shader BitmapShader(checkerBitmap, REPEAT, REPEAT) } canvas.drawRect(rect, checkerPaint) canvas.drawColor(color)棋盘格的实现是预先创建一个8x8的小Bitmap左半边灰右半边白然后用BitmapShader的REPEAT模式无限平铺。这个小技巧在很多图片编辑App里都很常见但自己实现调色板时容易漏。5.4 深浅色模式适配App一般都会支持Dark Mode调色板也不能例外。我的做法是给面板和色相条的背景色做主题感知浅色模式下外边框用浅灰深色模式下用深灰指示器的阴影色也分别适配。如果你的主界面跟随系统主题这一步就一定要做否则深色模式下调色板会显得特别突兀。除了颜色字体、滑杆的thumb和track资源也建议用?attr/colorControlNormal这类主题属性能省下大量适配代码。6. 踩坑记录与性能调优从能用到好用这个项目看着不大实际开发过程中踩了很多坑。我把几个典型的、网上资料少的坑记录在这里希望对后面做类似控件的朋友有帮助。6.1 重绘范围过大导致卡顿第一版实现里每次颜色变化我都直接调用invalidate()让整个ViewGroup重绘。在低端机上快速拖动色相条时帧率明显下降面板渐变填充、指示器、预览色块全部重绘CPU占满。优化思路是把复杂的渐变层做成静态缓存色相条渐变整个条不变只有指示器在动。所以把渐变部分单独渲染到一个Bitmap每次只重绘指示器区域。二维面板渐变渐变与当前色相相关色相不变时渐变不变。因此色相变化时才重新生成面板的渐变Bitmap拖动取色时只重绘指示器。预览色块和Hex文本独立的View用invalidate只刷它们自身。这样一改快速拖动时绝大多数帧只需要重绘两个指示器CPU占用直接降了60%以上。代码结构上我用了一个GradientCache对象来缓存面板Bitmapclass GradientCache { private var hueKey: Int -1 private var bitmap: Bitmap? null fun getPanelBitmap(hue: Int, width: Int, height: Int): Bitmap { if (bitmap null || hueKey ! hue) { bitmap renderPanelBitmap(hue, width, height) hueKey hue } return bitmap!! } }6.2LinearGradient起点坐标的坑面板渐变的起点坐标有人喜欢写(0f, 0f, width.toFloat(), height.toFloat())做对角线渐变但这不是我们要的效果。二维面板必须严格横向一层、纵向一层所以起点终点必须控制在水平或垂直方向上// 横向饱和度 LinearGradient(0f, 0f, width.toFloat(), 0f, ...) // 纵向明度 LinearGradient(0f, 0f, 0f, height.toFloat(), ...)我之前有一版把两个渐变的终点都写成了(width, height)结果面板出现了诡异的斜向色带怎么调都不是PhotoShop那种四角分明的效果。排查了很久才意识到是坐标写错了。6.3 触摸边界溢出的处理当指示器位于面板最边缘时它的中心点已经贴到边界画外圈圆环时会有半个圆被裁掉。如果Canvas没裁剪圆环会超出View边界如果裁剪了看起来就很别扭。我的处理是不改变指示器的绘制位置而是把面板边界留出indicatorRadius的padding。也就是说实际可触摸区域比视觉面板大一圈绘制时把面板整体内缩指示器在视觉边界上移动时依然完整可见。这属于比较偏门的UI细节但做出来观感会精致很多设计师验收的时候一定会注意到。6.4 像素颜色读取时ARGB顺序的坑从Bitmap取色时getPixel返回的是一个Int高8位是Alpha然后依次是R、G、B。有的老机型上尤其是Android 7以下某些厂商ROMBitmap默认的像素格式是RGB_565而不是ARGB_8888此时getPixel得到的颜色会丢失Alpha信息且R、G、B的精度只有5-6位。我的处理是在创建Bitmap时显式设置inPreferredConfig Bitmap.Config.ARGB_8888再加上异常保护val options BitmapFactory.Options().apply { inJustDecodeBounds true } BitmapFactory.decodeFile(path, options) options.inSampleSize calculateSampleSize(options, targetWidth, targetHeight) options.inJustDecodeBounds false options.inPreferredConfig Bitmap.Config.ARGB_8888 val bitmap BitmapFactory.decodeFile(path, options)如果没有这个设置某些ROM上取到的颜色会明显偏绿因为RGB_565对绿色的位数分配最多印象很深。6.5 性能建议汇总对自定义View的性能优化我最后总结出几条规律放这里供参考尽量不在onDraw里创建Paint和Shader这些对象要在初始化时创建好绘制时只改变参数。渐变类是重量级对象能用缓存就缓存不要在每帧里new。触摸事件里不要做耗时操作或日志输出Log.d在快速拖动时会刷屏并影响性能。如果实时刷新预览涉及位图缩放建议用Canvas.drawBitmap配合Matrix比重新加载Bitmap高效得多。低端机上如果还是卡可以把色相条渐变色的采样数从360降到180或120视觉差异小性能提升明显。这个项目最终的整体效果已经非常接近PhotoShop的基础取色体验了横向色相条顺滑切换二维面板四角颜色分明放大微调精细取色RGB/Hex双向同步屏幕取色器也从实际照片中准确取到了目标色值。我把它集成到了App里设计师、产品、测试用下来都反馈比很多成熟App的取色器还好用。最后再分享一个通用经验任何自定义View开发的流程都是先定数据模型再定绘制方案最后做手势交互。数据模型正确了HSV转RGB、坐标映射这些计算就不会出大问题绘制方案定了性能优化点在哪里心里有数手势交互最后加调试起来反而最顺畅。如果你也想做类似的专业级调色板强烈建议按照这个顺序推进少走很多弯路。本文还有配套的精品资源点击获取 Android自定义View实现仿PhotoShop调色板：HSV取色器实战
简介面向Android开发者的高级颜色选择器实现资源旨在将Photoshop中专业调色板交互移植至移动端。项目覆盖色轮选择、RGB/HSV色彩模式切换、滑块控制、Alpha透明度调整及色样管理等核心功能同时包含UI布局优化与触摸事件处理的技术细节适合想深入理解自定义View与颜色处理的中高级开发者。资源包共58个文件以Java源码、编译后的class、XML布局、PNG资源为主另含测试APK、JAR库及配置文件便于直接运行与二次开发。已有826人学习浏览压缩包仅330KB结构紧凑但内容完整。资源中的ColorPanel组件从布局绘制、事件分发到颜色空间换算均给出完整示例通过阅读源码可掌握色彩转换算法、触控反馈与性能优化的实现链路既可作为组件集成到实际项目也能作为系统学习移动端图像处理组件的参考案例对提升自定义控件能力有切实帮助。1. 为什么要亲手撸一个仿PhotoShop调色板先交代下背景。我之前在做一个偏向设计工具类的App里面有个很核心的诉求用户需要像在PhotoShop里那样自由地取色、调色。最初图省事接了个开源的颜色选择器库但实际用起来非常难受——交互太简陋只有色相条加一个方块的模式放大取色时连基本的微调都不支持更别提炼色器、最近颜色、Hex实时联动这些习惯了。后来在技术社区看到很多人在讨论类似的痛点Android原生自带的ColorPickerDialog丑到没法直视第三方库的自定义程度又有限。于是我决定自己动手基于Android的自绘体系实现一个仿PhotoShop调色板。这个项目不依赖任何第三方渲染框架核心就是自定义View加Canvas绘制纯Kotlin实现最终完整支持色相滑动条、饱和度/亮度二维取色面板、RGB分量调节、Hex实时输入、放大微调以及屏幕取色器。这篇文章适合谁看如果你正准备给App加一个专业级的调色面板或者你想搞懂PhotoShop那种取色交互背后的色值计算逻辑与手势处理方案那这篇实战记录应该能让你少走很多弯路。我会从色彩模型的选择、核心View的绘制、手势交互设计到大面板的性能优化把整个项目的关键环节拆开讲清楚。别人可能觉得调色板就是个换个颜色的小功能但真做起来你会发现它涉及ColorSpace转换、Canvas绘制效率、触摸事件分发、View局部刷新、位图像素读取等多块知识。正因为踩了不少坑我才想把完整经验沉淀下来。2. 核心算法先行HSV模型是PhotoShop取色的地基在动手写任何View之前必须先想明白一个本质问题为什么PhotoShop的调色板长得是一个色相条一个大方块而不是一堆红绿蓝数字滑杆2.1 为什么选HSV而不是RGBRGB是一种面向设备的颜色模型红绿蓝三原色叠加表达颜色。它的问题是不直观你想让颜色更青一点需要同时调整G和B普通人根本转不过弯。而HSV把颜色分解为色相Hue0-360度、饱和度Saturation0-1、明度Value0-1三个维度刚好对应人类的直觉感知这是什么颜色、颜色正不正、颜色亮不亮。PhotoShop经典取色界面就是围绕HSV设计的色相条负责选H值二维方块的横向是S、纵向是V。这个交互最大的好处是当你把H固定在某个色相后方块的左边缘是纯灰阶S0右边缘是纯色S1上边缘是最亮V1下边缘是黑色V0一屏之内就能看全所有明暗和浓淡的可能组合。2.2 HSV与RGB转换的降级方案Android的Color.colorToHSV()和Color.HSVToColor()其实已经提供了现成的转换方法底层计算我第一版也直接用了。但把玩下来发现有两点不满意一是大色块逐像素转换场景下反复调用系统方法会有额外开销二是HSVToColor对参数合法性的隐含约束不够灵活比如H值越界时会算出让人意外的颜色。所以我在项目中单独实现了一组转换函数核心逻辑保持和Android实现一致但保证输入H在0-360区间、S和V在0-1区间时一定返回预期的ARGBfun hsvToColor(h: Float, s: Float, v: Float): Int { val hue ((h % 360) 360) % 360 val sat s.coerceIn(0f, 1f) val value v.coerceIn(0f, 1f) val c value * sat val x c * (1 - kotlin.math.abs((hue / 60) % 2 - 1)) val m value - c val (r, g, b) when { hue 60 - Triple(c, x, 0f) hue 120 - Triple(x, c, 0f) hue 180 - Triple(0f, c, x) hue 240 - Triple(0f, x, c) hue 300 - Triple(x, 0f, c) else - Triple(c, 0f, x) } return Color.rgb( ((r m) * 255).toInt().coerceIn(0, 255), ((g m) * 255).toInt().coerceIn(0, 255), ((b m) * 255).toInt().coerceIn(0, 255) ) }这段逻辑本质上是把HSV色环切成六个60度的扇区每个扇区RGB三通道的变化规律是不同的线性插值。理解了这个公式后面做色相条渐变和方块面板渐变就都顺了。2.3 PhotoShop取色交互的分解动作PhotoShop的调色板看起来很复杂实际拆解下来就是三个动作的叠加拖动色相条改变H值S保持1、V保持1时得到当前色相的顶点纯色这个纯色是二维面板渐变的基准色。在二维面板点击或拖动以基准色为基础横向线性减小S饱和度为0时变灰纵向线性减小V明度为0时变黑。微调RGB或Hex把HSV结果和RGB结果做双向同步任意一侧改动都会实时刷新另一侧的显示与色块预览。只要把这三个动作的状态机和回调设计好整体功能就算成立了。我的实现里使用一个ColorState数据类维护当前色值它同时保存hsv和rgb两套表示任何UI变更都走同一个applyChange入口保证所有关联控件同步刷新。3. 色相条与二维取色面板的绘制看着像PhotoShop只是第一步这部分是视觉效果的核心。PhotoShop的色相条和二维面板都带有非常顺滑的渐变过渡想在Android里复现这种质感关键是用好SweepGradient和LinearGradient。3.1 色相条的两种画法色相条常见的表现有两种一种是直线条从左到右渐变另一种是圆环环绕一周。PhotoShop桌面端常用的是直线竖向色相条。我实现的是直线横向色相条视觉效果稳定手势也只在一维方向做。线性色相条直接用LinearGradient生成360度的连续色相渐变val colors IntArray(360) { i - hsvToColor(i.toFloat(), 1f, 1f) } val gradient LinearGradient( 0f, 0f, width.toFloat(), 0f, colors, null, Shader.TileMode.CLAMP )这里colors数组生成360个颜色每个颜色对应一个色相角度的纯色S1, V1。LinearGradient默认会在这些颜色之间做线性插值视觉上就是一条顺滑的彩虹渐变。其实更省内存的方式是只用几个关键颜色让渐变库自动插值但实测360个颜色在色相过渡上更接近PhotoShop的连续感且只初始化一次性能完全可接受。3.2 二维饱和度明度面板的叠加渐变二维面板的核心技巧在于两层渐变叠加第一层以当前色相纯色为基准从左到右从饱和到不饱和即从纯色渐变为白色第二层从上到下从透明渐变到黑色。PhotoShop里这个面板的左上角是白色S0, V1右上角是当前纯色S1, V1左下角是黑色S0, V0右下角是黑色S1, V0。理解了这四个角你就知道渐变该怎么写了// 第一层横向饱和度渐变 val saturationShader LinearGradient( 0f, 0f, width.toFloat(), 0f, Color.WHITE, currentPureColor, Shader.TileMode.CLAMP ) // 第二层纵向明度渐变 val valueShader LinearGradient( 0f, 0f, 0f, height.toFloat(), Color.TRANSPARENT, Color.BLACK, Shader.TileMode.CLAMP )绘制时先画横向饱和度渐变再叠加纵向明度渐变。这里有个必须注意的地方千万不要用Paint的setAlpha去处理明度层因为那是整体半透明会把底下渐变的边界也弄糊。正确做法是让LinearGradient自身在TRANSPARENT到BLACK之间插值这样颜色空间才是按比例压暗而不是蒙一层玻璃纸。3.3 指示器找准位置要比画得好看更重要渐变画完之后还需要画取色指示器。PhotoShop里是一个圆环加十字准星。我实现的是一个带白边的小圆private fun drawIndicator(canvas: Canvas, cx: Float, cy: Float, color: Int) { val outer Paint(Paint.ANTI_ALIAS_FLAG).apply { style Paint.Style.STROKE strokeWidth 6f color Color.WHITE } val inner Paint(Paint.ANTI_ALIAS_FLAG).apply { style Paint.Style.STROKE strokeWidth 2f color if (isColorLight(color)) Color.BLACK else Color.WHITE } canvas.drawCircle(cx, cy, 18f, outer) canvas.drawCircle(cx, cy, 14f, inner) }isColorLight这一步很重要如果当前点颜色是浅色比如黄色白色圆环几乎看不见得叠加一个深色内圈保证对比度。计算公式用的是相对亮度(0.299*R 0.587*G 0.114*B)大于180就算浅色。有不少教程只讲画个圆环但实际使用中指示器的可见性和准确位置直接决定调色体验。我第一版没加isColorLight判断结果取到亮黄色时圆环完全隐形调试了很久才发现是对比度问题。4. 手势交互让拖动、微调、实时预览都按PhotoShop的逻辑走绘制层面搞定后更大的挑战是交互。PhotoShop的调色板在主面板取色和色相条选色之间切换非常顺手而且支持点击直接跳转、拖动连续变化。这些体验背后是触摸事件处理和坐标映射的精细设计。4.1 触摸事件的命中区域划分我的调色板是三个区域组合在一个自定义ViewGroup里顶部是二维面板底部是色相条中间留着固定间距。为了让触摸逻辑清晰我在onTouchEvent里先判断触摸点落在哪个区域override fun onTouchEvent(event: MotionEvent): Boolean { val x event.x val y event.y when { y panelBottom - handlePanelTouch(event, x, y) y hueBarTop - handleHueTouch(event, x, y) } return true }注意actionDown时也要更新否则只靠actionMove会导致用户点一下没有任何反馈。而且返回true后整个View会接管手势流后续的move、up都会持续回调这点对连续拖动很重要。4.2 从触摸坐标反推HSV值不管用户点在哪个位置最终都需要把坐标变成颜色值。色相条坐标换算hue (x / hueBarWidth) * 360f然后clamp到0-360之间。面板坐标换算横向算饱和度纵向算明度val s (x / panelWidth).coerceIn(0f, 1f) val v (1f - y / panelHeight).coerceIn(0f, 1f)这里有个新手特别容易搞错的地方屏幕坐标的y轴向下增长但HSV的V值越大越亮、越靠上。因此从y坐标映射到V值时一定要用1 - y / height否则上下颠倒了用户往上拖反而变暗。拿到s和v之后再结合当前色相值h调用前面实现的hsvToColor(h, s, v)得到最新的颜色刷新指示器位置和外部回调。4.3 放大微调撑起专业感的细节PhotoShop用户最喜欢的操作之一是放大取色区域做精细调整。在移动端上我用双指缩放实现了这个需求当用户双指在面板区域捏合时面板会以两指中心点为锚点逐渐放大再配合单指拖动来微调颜色。原理并不复杂维护一个scaleFactor浮点变量双指间距变化时更新它绘制时把Canvas按锚点做缩放canvas.save() canvas.scale(scaleFactor, scaleFactor, anchorX, anchorY) // 绘制面板和指示器 canvas.restore()但触摸坐标的映射也要同步变化单指拖动时实际颜色坐标 锚点 (触摸坐标 - 锚点) / scaleFactor。这样即使面板放大了2倍手指动1像素仍然只会让颜色移动半像素的效果精细度翻倍。实测下来双指缩放加单指取色的组合在图片精确取色时特别好用。之前我们的设计师直接在手机上调出和PS完全一致的颜色靠的就是这个放大微调能力。4.4 取色器从Bitmap里读取像素颜色调色板还附带了一个屏幕取色器从相册选一张图片点击图片任意位置提取颜色。实现上核心是Bitmap.getPixel(x, y)。但这里有个大坑如果直接加载一张高分辨率图片并显示缩放后的Bitmap手指点击的坐标和原图坐标会有偏差。所以我的实现分两步走先加载原图并统一缩放到屏幕能显示的尺寸保留采样率记忆触摸时记录的是显示图上相对坐标拿颜色时用相对坐标乘回原图缩放比例val srcX (touchX / displayWidth * originalWidth).toInt() val srcY (touchY / displayHeight * originalHeight).toInt() val color bitmap.getPixel(srcX, srcY)这个大图采样用BitmapFactory.Options的inSampleSize来处理避免直接加载原图导致OOM。实际项目里选了一张8000x6000的照片测试显示图只有1500x1100左右取色依然准确。5. 联动与细节打磨Hex输入、RGB滑杆、最近颜色与状态同步如果说上面这些是骨架那联动和细节就是血肉。调色板真正好用的状态是用户拖动色相条面板颜色跟着变指示器跟着移Hex输入框实时跳动RGB滑杆同步刷新预览色块无延迟更新。这个多向同步的架构是非常值得展开的。5.1 统一状态入口避免多个控件互相刷新的死循环我设计了一个ColorStateListener接口任何UI控件的变更都会以参数形式传给一个中心调度器ColorPickerMediatorinterface ColorPickerMediator { fun onColorChanged(color: Int, source: ChangeSource) }ChangeSource是一个枚举标记这次变化来自哪个控件HUE_BAR、SAT_VAL_PANEL、RGB_SLIDER、HEX_INPUT、EYE_DROPPER。中心调度器拿到新颜色后先更新内部的currentColor再通知除变更来源之外的所有控件刷新。这样做的好处是Hex输入框触发颜色变化时不会再反向去更新Hex输入框自身避免输入-刷值-触发监听-再输入的无限循环问题。这个设计我是在第一版被死循环折磨了两次之后才想明白的强烈建议有类似需求的朋友直接采用。5.2 RGB滑杆与Hex输入的联动细节RGB滑杆比色相条简单本质是三个0-255范围的SeekBar。但设置滑杆进度时有个顺序问题如果先设置R再设置G每次设置都会触发一次onProgressChanged导致中间态颜色闪烁。解法是加一个isProgrammaticUpdate布尔标志在代码批量设置进度时挂起监听等三个滑杆都设置完再恢复fun updateSliders(color: Int) { isProgrammaticUpdate true redSlider.progress Color.red(color) greenSlider.progress Color.green(color) blueSlider.progress Color.blue(color) isProgrammaticUpdate false }Hex输入框则要处理两件事合法性校验和输入中不全局刷新。我的做法是监听TextWatcher只在文本长度等于6且全是十六进制字符时才解析并触发onColorChanged否则只改输入框的字体颜色提示用户格式不对。这样用户在输入F、FF这些中间状态时不会看到整个界面颜色乱跳。5.3 最近使用颜色与透明度棋盘格PhotoShop有最近使用颜色的小色块列表我也做了类似功能。实现时用一个LinkedHashSetInt保存历史颜色新颜色加入时如果已存在就先移除再插入保证最新颜色排在最前最多保留12个。每次取色完成时把颜色写入这个集合并刷新色块网格。透明度棋盘格是另一个容易被忽略的细节。调色板输出的ARGB颜色可能带透明通道如果预览色块直接画一个纯色用户根本看不出透明效果。因此我在预览色块下方先画一个灰白相间的小棋盘格再在上面叠加颜色private val checkerPaint Paint().apply { shader BitmapShader(checkerBitmap, REPEAT, REPEAT) } canvas.drawRect(rect, checkerPaint) canvas.drawColor(color)棋盘格的实现是预先创建一个8x8的小Bitmap左半边灰右半边白然后用BitmapShader的REPEAT模式无限平铺。这个小技巧在很多图片编辑App里都很常见但自己实现调色板时容易漏。5.4 深浅色模式适配App一般都会支持Dark Mode调色板也不能例外。我的做法是给面板和色相条的背景色做主题感知浅色模式下外边框用浅灰深色模式下用深灰指示器的阴影色也分别适配。如果你的主界面跟随系统主题这一步就一定要做否则深色模式下调色板会显得特别突兀。除了颜色字体、滑杆的thumb和track资源也建议用?attr/colorControlNormal这类主题属性能省下大量适配代码。6. 踩坑记录与性能调优从能用到好用这个项目看着不大实际开发过程中踩了很多坑。我把几个典型的、网上资料少的坑记录在这里希望对后面做类似控件的朋友有帮助。6.1 重绘范围过大导致卡顿第一版实现里每次颜色变化我都直接调用invalidate()让整个ViewGroup重绘。在低端机上快速拖动色相条时帧率明显下降面板渐变填充、指示器、预览色块全部重绘CPU占满。优化思路是把复杂的渐变层做成静态缓存色相条渐变整个条不变只有指示器在动。所以把渐变部分单独渲染到一个Bitmap每次只重绘指示器区域。二维面板渐变渐变与当前色相相关色相不变时渐变不变。因此色相变化时才重新生成面板的渐变Bitmap拖动取色时只重绘指示器。预览色块和Hex文本独立的View用invalidate只刷它们自身。这样一改快速拖动时绝大多数帧只需要重绘两个指示器CPU占用直接降了60%以上。代码结构上我用了一个GradientCache对象来缓存面板Bitmapclass GradientCache { private var hueKey: Int -1 private var bitmap: Bitmap? null fun getPanelBitmap(hue: Int, width: Int, height: Int): Bitmap { if (bitmap null || hueKey ! hue) { bitmap renderPanelBitmap(hue, width, height) hueKey hue } return bitmap!! } }6.2LinearGradient起点坐标的坑面板渐变的起点坐标有人喜欢写(0f, 0f, width.toFloat(), height.toFloat())做对角线渐变但这不是我们要的效果。二维面板必须严格横向一层、纵向一层所以起点终点必须控制在水平或垂直方向上// 横向饱和度 LinearGradient(0f, 0f, width.toFloat(), 0f, ...) // 纵向明度 LinearGradient(0f, 0f, 0f, height.toFloat(), ...)我之前有一版把两个渐变的终点都写成了(width, height)结果面板出现了诡异的斜向色带怎么调都不是PhotoShop那种四角分明的效果。排查了很久才意识到是坐标写错了。6.3 触摸边界溢出的处理当指示器位于面板最边缘时它的中心点已经贴到边界画外圈圆环时会有半个圆被裁掉。如果Canvas没裁剪圆环会超出View边界如果裁剪了看起来就很别扭。我的处理是不改变指示器的绘制位置而是把面板边界留出indicatorRadius的padding。也就是说实际可触摸区域比视觉面板大一圈绘制时把面板整体内缩指示器在视觉边界上移动时依然完整可见。这属于比较偏门的UI细节但做出来观感会精致很多设计师验收的时候一定会注意到。6.4 像素颜色读取时ARGB顺序的坑从Bitmap取色时getPixel返回的是一个Int高8位是Alpha然后依次是R、G、B。有的老机型上尤其是Android 7以下某些厂商ROMBitmap默认的像素格式是RGB_565而不是ARGB_8888此时getPixel得到的颜色会丢失Alpha信息且R、G、B的精度只有5-6位。我的处理是在创建Bitmap时显式设置inPreferredConfig Bitmap.Config.ARGB_8888再加上异常保护val options BitmapFactory.Options().apply { inJustDecodeBounds true } BitmapFactory.decodeFile(path, options) options.inSampleSize calculateSampleSize(options, targetWidth, targetHeight) options.inJustDecodeBounds false options.inPreferredConfig Bitmap.Config.ARGB_8888 val bitmap BitmapFactory.decodeFile(path, options)如果没有这个设置某些ROM上取到的颜色会明显偏绿因为RGB_565对绿色的位数分配最多印象很深。6.5 性能建议汇总对自定义View的性能优化我最后总结出几条规律放这里供参考尽量不在onDraw里创建Paint和Shader这些对象要在初始化时创建好绘制时只改变参数。渐变类是重量级对象能用缓存就缓存不要在每帧里new。触摸事件里不要做耗时操作或日志输出Log.d在快速拖动时会刷屏并影响性能。如果实时刷新预览涉及位图缩放建议用Canvas.drawBitmap配合Matrix比重新加载Bitmap高效得多。低端机上如果还是卡可以把色相条渐变色的采样数从360降到180或120视觉差异小性能提升明显。这个项目最终的整体效果已经非常接近PhotoShop的基础取色体验了横向色相条顺滑切换二维面板四角颜色分明放大微调精细取色RGB/Hex双向同步屏幕取色器也从实际照片中准确取到了目标色值。我把它集成到了App里设计师、产品、测试用下来都反馈比很多成熟App的取色器还好用。最后再分享一个通用经验任何自定义View开发的流程都是先定数据模型再定绘制方案最后做手势交互。数据模型正确了HSV转RGB、坐标映射这些计算就不会出大问题绘制方案定了性能优化点在哪里心里有数手势交互最后加调试起来反而最顺畅。如果你也想做类似的专业级调色板强烈建议按照这个顺序推进少走很多弯路。本文还有配套的精品资源点击获取