一起撸个环形 Android 图表

栏目: Android · 发布时间: 6年前

内容简介：在Android中，说到图表，我们往往都会选择找库，比如MPAndroidChart。然而更多的时候，我们往往只需要某一类型的图表，为了这个类型的图表而不得不把整个库（包含所有图表逻辑）导入进来，还是感觉有点重的。俗话说得好，自己动手，丰衣足食。

本文首发掘金（没写完orz），现重写并补全。

在Android中，说到图表，我们往往都会选择找库，比如MPAndroidChart。

然而更多的时候，我们往往只需要某一类型的图表，为了这个类型的图表而不得不把整个库（包含所有图表逻辑）导入进来，还是感觉有点重的。

俗话说得好，自己动手，丰衣足食。

于是就有了今天的甜甜圈。（为何叫甜甜圈。。。不觉得环形饼图好像个甜甜圈吗哈哈）

起源

作为程序员，一个新的需求/控件的起源，很多时候都是来源于产品，所以，这次控件的诞生，其实很简单，来源于一张优化点设计图 （只截取部分，其余部分不宜公开） ：

咋一看，这张图so easy啦~ 3只paint，3个颜色，随便画画，搞定~

可是，不知道为啥，看着这个甜甜圈还挺漂亮的，不甘心就这么简单的画出来就完事。。。

于是心里有个魅惑的声音告诉我：“既然这个不急，只是优化点，那为何不优化彻底一点，做的比这货更漂亮呢”

被魅惑的我，立马熟悉的打开AS，新建Project，填上Name，弄个类继承View，然后。。。。

然后。。。他喵的然后怎么干啊！！！！

迷茫

相信很多人写自定义控件都会有这个疑惑。。。我建好类了~ 我继承好了View了~ 接下来，，，我不会做了TAT

其实不仅仅你们，就是我写过不少的控件，现在建好一个类，我也偶尔会有这个情况。。。（嗯，可能写的还是不够多）。

原因很简单：所有的元素，都是心里所想，并没有做出一个具体的动画效果和预览，所以方向太多，一下子很迷茫。

因为当我们想完成一个控件或者动画效果是，我们往往很快就能在心里确定好我们想要什么效果，然而当我们真的要实施的时候，就会发现似乎不知道该怎么把效果变成一行行的代码。

在迷茫的时候，我的做法是，把我的期望写下来：

我的甜甜圈会动
我的甜甜圈可配置参数要多（自由度要高）
我的甜甜圈点击的时候要有个效果，至于效果，大概是浮上来呈现出Z轴上移的样子，最好能加上阴影
我的甜甜圈要简单好上手。。。

当需求写了下来，我们就可以逐步击破。

针对上面的需求点，我们逐步确定我们的方案：

甜甜圈
- 继承View，自己画
会动的甜甜圈
- Animation走起，反正就是可以逐步计算进度并让我根据值来进行不同的绘制即可
可配置多
- 因为参数比较多，因此归并到一个config类里面，采取Builder模式，形成链式配置，保持清爽的编码风格
点击效果
- 甜甜圈可以通过大小变化来造成z轴上浮的伪效果，加上BlurMaskFilter或者ShadowLayer
简单上手
- 暴露的api尽可能少，以及面向接口编程

数据

受限于篇幅，这里仅贴出核心代码，其余地方以思路讲解为主。

首先由简入繁，我们先尝试画出一个简单的甜甜圈：

so easy~依然是开头所说的，3只笔，3个角度，完事。

然而，如果我们允许外部配置更多的甜甜圈的话，那岂不是要修改这个类？如果有一个方法能够提供给我动态增删就好了。

说做就做，我们看一下目前甜甜圈需要的元素：

颜色
描述
数据（计算比例用）

也就是说，如果我们跟用户约定一个方式，约定好由用户提供这些元素，我们仅负责渲染的话，那么我们就可以实现动态增删的需求了。

那么，该如何约定呢？

假如我们要求使用一个类，也就是用户必须传给我们这个类，那么对于用户来说，是一个麻烦的使用，因为我们想绘制在图标上的数据往往都是服务器请求回来的，如果想画出甜甜圈，还得做多一步转换，这无疑是增大了复杂度，也就不符合我们简单好用的期望了。

考虑到这个，我采取了接口的方式。接口约束要求返回以上三个元素，这样做的好处是不用破坏用户原来的数据，他甚至可以用原来的数据bean来实现甜甜圈的需求，另一个好处是我可以很方便的进行扩展。

事实上，这一点也得到了使用者的认可（ps，在国外本库被评为2018年初值得关注的25个库之一，因此国外issue提出的比较多，邮件联系的也是主要是外国友人）：

根据以上条件，我们初步定义出一个接口：IPieInfo

在这之后，我们计算都可以依靠接口获取：

获取颜色决定本段甜甜圈的取色
获取数值来计算本段甜甜圈的
获取描述来绘制甜甜圈的描述

这样做可以不限制用户的数据类型，只需要实现我们的接口并对各个方法进行返回即可。

在绘制的时候，我们把用户传入的数据存到一个List中，在存入的时候，根据获取的value进行计算，得到其开始角度和结束角度，并把数据包装在一个类里面供控件内部使用。而这一切，对外部来说都是不透明的，外部使用仅仅关注的是配置，而不是计算。

点击

甜甜圈的点击是一个比较麻烦的点，主要原因如下：

甜甜圈支持起始角度设置，而对起始角度并没有做要求，也就是传入-3600°也是可以的
点击的时候需要精确判定点击的区域在哪个甜甜圈里
甜甜圈被点击后的动作，以及上一次点击的甜甜圈动画和本次点击的甜甜圈动画需要切换（一个还原一个上浮）

首先看看第一个问题，我们的甜甜圈虽然可以设置无限角度，但实际上其实归根结底可以归到0 ~ 360°之间，即便传入一个很大的值，其实也是一定倍数 * 360 + 偏移量而已，所以针对任意角度，我们需要将其收束到0 ~ 360°之间：

在点击触发的时候，我们先判断点击的位置是否在甜甜圈（或者饼图）内，判断的方法也很简单，就是初中的技巧计算两点之间的直线距离。

我们获取触摸点的x,y，计算其到中心的距离，假如当前是甜甜圈模式（环形饼图），则需要甜甜圈内径≤距离≤甜甜圈外径则判定在甜甜圈内。

计算完距离后，我们需要计算角度，我们通过角度来获取我们当前点击的是哪一段的甜甜圈。

目前我们已知点击的xy，以及中心点，这时候我们可以用atan2方法反计算出角度

//得到角度
    double touchAngle = Math.toDegrees(Math.atan2(y - centerY, x - centerX));
复制代码

这里计算出来的是-180° ~ 180°范围内的值，即以x正半轴为起始，逆时针（1、2象限）则是-180° ~ 0，顺时针（3、4象限）是0 ~ 180°。而我们的甜甜圈在开始的时候也说过，是无限角度的，当然，我们处理到0 ~ 360°，然而即便收束了起来，还是与我们计算出来的-180° ~ 180°对不上，因此我们对计算出来的角度需要做一下处理。

在这里我选择当点击的角度小于0的时候，加上360°。这里可能会有小伙伴问我为什么不是加上180°，而是加360°。

这个问题很简单，因为我们的甜甜圈在转换为0 ~ 360°之后，在1、2象限表现的是180° ~ 360°的范围，而我们点击的角度在1、2象限是-180° ~ 0，如果加上180，则是0 ~ 180°，还是无法满足我们的甜甜圈判断，因此在数值小于0的情况下，我们加上360°。