最近测试组同事反映seekbar控件点选不中最后一格，随后我研究了下源码，发现了确实有此问题

seekbar通过setMax()来设置“最大值”，实际上这个最大值就是细分的程度，假如设成10，整个seekbar即细分成10份，设成100，及细分成100份，设置越大seekbar滑动起来最“流畅”

假如Max设为3整个seekbar即分成三段，0~1,1~2,2~3

由于在trackTouchEvent()中，setProgress((int)progress, true)使用了强制转换，出现了如下规律

当progress在[0,1)时，滑块显示在0位置

当progress在[1,2)时，滑块显示在1位置

当progress在[2,3)时，滑块显示在2位置

当progress在3时，滑块显示在3位置

由此可以看出，最后一格很难点中。

作小修改：

int progressRound = Math.round(progress);

setProgress(progressRound, true);

如此之后便有如下规律

当progress在[0,0.5)显示在0位置

当progress在[0.5,1.5)，滑块显示在1位置

当progress在[1.5,2.5)时，滑块显示在2位置

当progress在[2.5,3]时，滑块显示在3位置

这样修改之后，个人觉得更符合常理，不知道这个算不算seekBar中一个小小的设计缺陷~~

今天测试组同事又反应，星星评分控件不准确了。。我才恍然大悟以上做的修改是错误的。 星星评分控件（RatingBar）和seekBar一样，也是继承的AbsSeekBar，经过上面的修改之后，评分显示会往前跳了一格。。

原来框架的真是不可以随便改动的。。o(╯□╰)o~~只得改回来，seekBar的bug另想办法~~

最近测试组同事反映seekbar控件点选不中最后一格，随后我研究了下源码，发现了确实有此问题 seekbar通过setMax()来设置“最大值”，实际上这个最大值就是细分的程度，假如设成10，整个seekbar即细分成10份，设成100，及细分成100份，设置越大seekbar滑动起来最“流畅” 假如Max设为3整个seekbar即分成三段，0~1,1~2,2~3 android :max=“255” （最大的滑动值，从0开始） android :progress=“255”（初始时滑动条的位置） <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns: android ="http://schemas. android .com/apk/res/ android " android :layout_wi 1.继承 SeekBar 自定义类 中 重写onDraw(Canvas canvas)方法 绘制进度条 protected synchronized void onDraw(Canvas canvas) { if(progr