平台：React
相关技术: Canvas API , requestAnimationFrame API
刚入职不久，接到一个需求，关于重构课程列表，撇去蛋疼的看源码修改原有的显示逻辑之外，当时最令我印象深刻的是这个圆形进度条的制作过程。
在看到这个需求时，我首先想到能不能用css3进行实现，毕竟从性能来说css3是较好的，但是发现这样最后尾巴的小点没办法解决，而且技术难度貌似不小，最终部门小伙伴说你可以用canvas尝试一下，并直接给我一个静态demo，感恩～，我也趁机研究了一下canvas api的使用。
需求
首先我们拿到这个图案先拆分为4个部分，分别说外圆灰色细圈，外圆橘色细圈，内部橘色圈，以及尾巴的小点, 下面针对一些核心绘制API进行分析
这里讲一下比较蛋疼的最外侧的圆弧和那个点的开发。
最外侧的圆弧核心代码如下：(取context这种基础咱就不写了)
context.clearRect(0, 0,直径, 直径);
context.beginPath(); <=开始绘制 ，包工头说开始搬砖了
context.lineWidth = 任意粗细； <=定义绘制粗细
context.strokeStyle = '定义画圈的颜色';
context.arc(直径 / 2, 直径 / 2, 直径 / 2 - 2*传入半径, 0, 传入需要的百分比数值 * 0.02 * Math.PI - 0.5 * Math.PI false); <=重要，绘制圆形路径
context.stroke(); <=针对strokeStyle部分结束绘制
context.closePath();<=结束路径 - 包工头说下班了
这里主要讲一下这里运用context.arc的绘制思路，这里请大家跟我回忆w3school上关于这个API的用法定义
w3school参考图(1)
前两个不用说，确定中心点，第三个通过传入一个半径，通过减去，切分的做法，"漏"出一个传入值的弧圈，可谓比较讨巧，原理看图好懂点。
传入值
而起始角和结束脚我们需要通过下面这个图(w3school参考图(2))说明，起始点0(-0.5 * Math.PI)
结束点：传入需要的百分比数值 * 0.02 * Math.PI -0.5 * Math.PI ，先别急问0.02怎么来的，分析一下。
其实可以理解为-0.5 * Math.PI(也就是1.5 * Math.PI所在位置)就是起点，因为最大值也就是1.5*PI，所以这里的增值最多为-0.5 + x = 1.5 x = 2，那么 2/100 = 0.02份/1%，那么我们上面的公式就是这么来的。
w3school参考图(2)
那么上面的圆弧算是开发完毕了，我们来做一个更难的，那个点的跟踪计算。
首先先上核心代码
context.beginPath();
context.strokeStyle= "#FF9C00";
context.lineWidth= 2;
context.fillStyle= "#FF9C00";
let radian= 传入进度 / 100 * 2 * Math.PI - 0.5 * Math.PI;
let x= Math.cos(radian)* (大圆弧直径 / 2 - 2*裁去的半径)+ 直径 / 2(圆心x点);
let y= Math.sin(radian)* (大圆弧直径 / 2 - 2*裁去的半径)+ 直径 / 2(圆心y点);;
context.arc(x, y, 0.8 * r, 0, 2 * Math.PI, false);
context.stroke();
context.fill();
context.closePath();
前四行为起手式级别，上面解释过，这里不再进行解释，我们主要分析第五行到第七行代码。
这里最难的是怎么找到这个点的位置(x,y)进行摆放，而绘制这个圆点方法如上如法炮制即可，已经比较简单了。
而我们知道数学公式里面求圆上的一点的公式
到了JS的Math.cos和Math.sin函数，我们查阅文档可以知道这两个函数中的传入值都是指的“弧度”而非“角度”，弧度的计算公式为： 2*PI/360*角度；那么你会说这样最高岂不是有2*Math.PI ? 还记得我们上面的图吗，最高也就是1.5*Math.PI,所以我们这里需要手动减去0.5*Math.PI 。因为我们在最上面的需求已经可以得到弧度 ：传入进度 / 100 * 2 * Math.PI- 0.5 * Math.PI的公式，所以通过它，我们可以得到一个类似xx Math.PI的弧度值。
如果要求算出(x1，y1)在(x0，y0)为圆心的圆上，其所在坐标，我们可以使用如下的公式得到圆点的位置。
x1 = x0 + r * cos(弧度值)
y1 = y0 + r * sin(弧度值)
那么到此我们终于可以绘制出静态的demo图了，慢着，你以为就结束了吗，naive
UI大佬:"要不咱加个动效?"
好吧～向大佬势力屈服
那么怎么让它动起来呢？如果你仔细观察会发现我们刚刚实现的绘制过程，都是传入最终参数percent来让它完成绘制的，如果我每一次 precent+1，会有什么情况？不用你猜，对的，他会一次一次的绘制进度+1，这时候我突然想到"判断渲染的条件，动画，每次+1"，脑海里浮现出面试复习时经常出现的那个巨长的API，requestAnimationFrame，不就是最适合这种场景么.requestAnimationFrame API
实际实现思路就是，初始percent传0，通过判断是否达到percent，如果不是，percent+1继续再递归调用,而且他不会产生类似setTimeInterval定时器这种影响页面性能和事件队列的副作用。
一段实现代码
progressRender(context, length, R, r, percent,slogan){
if(slogan!==0) {
percent += 1;
if (percent < this.props.progress) {
requestAnimationFrame(()=> {
this.progressRender(context, length, R, r, percent)
})
}
}
最终我们能得到如下，ps：随便找的一个转gif的网站，感觉卡卡的，但是实际还好，比较流畅。
最终效果
通过这个小需求，不仅有点锻炼数学和逻辑能力，也有点考验我们对需求应变的机动准备，如果需求增加了我们要怎么灵活的实现出来，总之，继续加油吧～
网友评论