前言

一直想花时间复刻学习一下Apple产品的原生UI和动画，超级丝滑。

今天，目标是健康的心率数据统计图表。

健康及Android实现效果预览

1. Apple健康的图表交互效果：

丝滑，有数据条滑动、滑动查看数据标注两种模式；数据标注位置自适应；两端超出边界会有自动回滚的效果。

2. 本文用Android复刻的图表交互效果：

暂时着眼于核心的实现思路，细节有长足的优化空间（如自动回滚的运动曲线、快速滑动、刻度线变化等，但他们对于Demo来说不是重点）😥。

1. 页面内容分析

在开始前，我们不妨先仔细观察一下这个页面所涵盖的信息，再将其转换为我们的业务需求，提前整理好思路再开始上手写。

1.1 图表静态布局

我们把图表打散，它本质上由以下三个组件构成：

• 数据条
  
  
  
  • 单个数据条：表示单元时间内的心率分布情况，这里我们将它简化为单元时间内的心率变化范围（最小~最大）
  
  
  • 数据存储：每个数据条需要涵盖的信息有三点：时间、最小值、最大值，我们使用一个ArrayList将他们放在一起，对于那些空缺的数据，我们可以根据时间来填充数值(设为0)，以此实现在图表上的留白。
  
  
  
  


• 坐标轴 Axis
  
  
  
  • 横向：横向坐标轴、背景线及其刻度(0,50,100)几乎是静态的，只有刻度会变化，这里我们暂时忽略这一点。
  
  
  • 纵向：纵向背景线按照特定的间隔分布，滑动过程中也会跟着变化，与数据条是相对静止的。因此，我们尝试把他们和数据条捆绑在一起来实现。
  
  
  
  


• 数据标注 IndicatorLabel
  
  
  
  • 默认形态：它固定在左上角，取当前可见数据的时间范围、心率变化范围进行展示
  
  
  • 指示形态：当用户长触摸/点击图表数据条时，它就会展现在其上方；在左右边界会有位置的自适应调整。
  
  
  • 默认形态和指示形态是非此即彼的，我们可以设置一个boolean值，isShowIndicator来控制他们，true的时候展示指示形态，false就为默认形态，以此简化我们的后续处理逻辑。
  
  
  
  

1.2 图表动态效果

图表滑动与边界效果

• 滑动变化：图表左右滑动来调整，滑动过程中，上方的 默认形态数据标注的值会发生变化，纵向背景线、刻度值会跟着移动；


• 自动回滚：
  
  
  
  • 每次滑动结束后，都会有一个轻微的自动回滚，来保证窗口内呈现的完整的24个数据条。
  
  
  • 在滑动窗口超出两侧边界后，会进行自动回滚，回到原来的边界。
  
  
  
  

触摸/点击产生的数据标注

• 用户点击/触摸会触发 指示形态的数据标注，进入此状态后，手指按住屏幕左右滑动可以实现滑动数据标注的效果


• 在进入上述状态后，如果手指快速滑动，则可以恢复标注的默认形态并滑动图表。

2. 页面实现

在使用自定义View实现页面前，结合上述对布局的分析，思考一下我们的工作流程：

1. 画一个图表的框架草图，标注出重要的尺寸，确保这些尺寸能够让我们计算出每一个点的坐标；


2. 准备一个数据类来容纳每个时间点的数据，用ArrayList打包起来，作为我们的数据源；


3. 横向背景线、y轴刻度都是全程静态的，优先绘制它；


4. 将纵向背景线、x轴刻度与数据条绑定起来绘制；结合ArrayList中每一个item的索引来计算坐标、使用item的数值计算数据条的y轴位置；


5. 实现数据标注的绘制函数，它可以通过指定一个item的索引来展示出对应点的具体信息；


6. 通过重写onTouchEvent来实现点击/触摸触发数据标注的效果，实现图表的滑动效果。

脑子里粗略思考一遍每一步的可能难度，发现我们主要面临三个难题😥：

1. 使用怎样的布局可以让我们轻松地通过item的索引来计算坐标？


2. 该怎么用最简洁优雅的方式让我们的数据条动起来？


3. 同样是滑动，有时候用户需要数据条左右滑动，有时候却需要数据条不动，数据标注动，这该怎么区分呢？

为保证阅读体验，实现部分不会列出所有代码并阐述所有细节，代码可以在最下方Ctrl C+V获取。

2.1 图表的基础结构

我们按照拟定的工作流程一步步来：

2.1.1画一个图表的框架草图。

提前拆解思考过图表以后，我们可以快速画出以下结构图：

对于数据条宽度(lineWidth)，及数据条间隙宽度(lineSpace)的选取，假设我们最大可视数据条为n个，为了实现规整的页面，需要保证以下等式成立：

$\rm{(lineWidth\ +\ lineSpace)\ *\ n = chartWidth}$(lineWidth + lineSpace) ∗ n=chartWidth

其中chartWidth我们在上方结构图中标出的——存放数据条的chart的宽度；

这么做的原因很简单：假设现在n为24，那么这个chart的宽度就是 24* lineWidth +23* lineSpace + 最左侧空白宽度 + 最右侧空白宽度；如上等式保证了左右侧空白宽度都为 0.5 * lineSpace。

2.1.2 准备一个数据类

目前的需求是，存放时间，一个最小值一个最大值，所以创建一个简单的DataClass即可。

data class HeartRateChartEntry(

        

    val time: Date = Date(), val minValue:Int = 66, val maxValue:Int = 88

)

复制代码

然后我们创建一些随机数据，用ArrayList存储。

2.1.3 绘制横向背景线、y轴刻度

他们是静态的，直接用绘制出来的结构图计算chart、文本的起讫点坐标直接画就好。

• startX = (getWidth() - chartWidth)/2。当然，你也可以自己定义chart的起点，我建议这个起点的x坐标与lineWidth+lineSpace成正比


• endX = startX + chartWidth


• endY = startY = totalHeight - bottomTextHeight
  我们要绘制k条线，就首先计算线之间的距离unitDistance = chartHeight/(k-1)，每次绘制让unitDistance*i - startY就可以获取到当前横线的纵坐标了。

(0..mHorizontalLineSliceAmount).forEach{ i ->

    //获取当前要写上去的刻度

    currentLabel = .....

    

    //计算当前Y

    currentY = startY - i * mVerticalUnitDistance

    

    //画线

    canvas.drawLine(startX, currentY, endX, currentY, mAxisPaint)

    //画text

    canvas?.drawText("${currentLabel}", endX + mTextSize/3, currentY+mTextSize/3, mTextLabePaint)

    

//再画上最左侧的边界线

canvas.drawLine(startX, startY, startX, startY-mChartHeight, mAxisPaint)

}

2.1.4绘制数据条与纵向背景线

好，遇到了我们预料的难题，用什么方式绘制数据条，可以让他符合我们的滑动需求呢？

被否定的方案：

假设我们通过onTouchEvent计算手指滑动的距离，用滑动的距离来计算我们需要绘制的数据索引；但这种方式虽然符合我们静态页面的需求，但没法实现顺畅的动画效果，滑动过程中只会不停地闪烁。

究其原因是他实际上没有改变数据条绘制时的横坐标，我们再去根据onTouchEvent的滑动距离来微调他们吗？但这仍然无法避免边缘数据条的闪烁。

更好的方案：窗口

想象我们正对着坐在窗口前，我们把这个窗口假设为一个viewPort，在这个窗口，我们能够看到横向切换的风景，是因为窗口和背景之间的相对移动。

如果我们将其设想为我们的chart和数据条，可不可以把chart理解为窗口，数据条是浮在其表面的风景，然后我们只需要移动数据条，就可以切换风景(数据条滑动的视觉效果)，这可以保证不会出现割裂感，毕竟所有东西都已经绘制了，只是位置调整了。

想法看来可以一试，上手前，我们还是先画图理一下思路。

• 我们需要从右往左绘制数据条以展现时间格式


• 初始起点不如设定为chart的最右端

• 如果要向右滑动，是不是把绘图的起始点往右边移就可以了？
  
  

看来这个思路没错，我们用viewStartX作为起始点，从右向左画数据条(for循环配合数据下标计算x轴坐标)，然后去onTouchEvent的ActionMove里计算滑动的距离，动态调整viewStartX就搞定了。

不过有一点要想一想，如果我们每次都滑动都重新绘制了所有的数据条，如果数据量一大，必定会造成性能问题呀！

不过他很好解决，我们只需要计算当前窗口展示的最左和最右的数据条索引，分别为leftRangeIndex, rightRangeIndex，我们在遍历画数据条的过程中设置为只执行(leftRangeIndex-3, rightRangeIndex+3)范围即可，这就实现了每次只画窗口内+窗口边缘的数据条了。

最后，我们需要在绘制完数据条以后，截取一个窗口下来，放回到我们的chart里，我们可以通过canvas.saveLayer()和canvas.restoreToCount()配对使用来实现。

以下是绘制数据条的核心代码，看个思路就好

1. 用saveLayer()来确定一个窗口范围

val windowLayer = canvas?.saveLayer(

    left = chartLeftMargin, //chart左边界的x坐标

    top = 0F,

    right = chartRightBorner, //chart右边界的x坐标

    bottom = widthBottom //chart下边界的y坐标

)

2. 遍历我们存储数据的ArrayList，使用viewStartX和索引来计算每个数据条的横坐标，绘制出来

(0 until mValueArray.size).forEach { it ->

    //如果不在我们预期的绘制范围内，那就溜溜球，不画了

    if (it > drawRangeRight || it < drawRangeLeft) {

        return@forEach

    }

    //计算坐标x，数据条的y轴起讫点

    currentX = mViewStartX - (it) * (mLineWidth + mLineSpace) - chartRightMargin

    startY = baseY - mChartHeight / mYAxisRange.second * mValueArray[it].maxValue

    endY = baseY - mChartHeight / mYAxisRange.second * mValueArray[it].minValue



    if (mValueArray[it].maxValue != 0) {

        canvas?.drawLine(currentX, startY, currentX, endY, mLinePaint)

    }

3. 
   

   在我们既定的特定时间点，绘制纵向背景线和刻度（代码略了，完整版在最下方）

   
   


4. 
   

   最后，把这个窗口再存储到我们的view里去就完成了

   
   

cavas?.restoreToCount(windowLayer!!)

2.1.5 数据标注的绘制函数

前文有提到，我们的图表一共有两种数据标注的形式，一是默认形态，二是指示形态，他们是非此即彼的，我们只需要设置一个boolean变量，isShowIndicator，然后在onTouchEvent中动态设置这个变量，就可以实现他们的切换了。

同时，我们在onTouchEvent中维护一个变量indexOnClicked，它用来表示当前被点击的那个数据条的索引，并绘制指示形态的数据标注。

这里的绘制流程不赘述了。

2.2 图表的触摸事件

还是一样，理清思路再上手写代码。

我们希望：

• 
  

  图表能够判定用户的长触摸、快速滑动行为

  
  
  
  
  • 我们的图表需要能够判断以下两个状态值
    
    
    
    • 正在数据条滑动状态—isScrolling：表示用户通过快速的手指滑动 来切换 数据条（也就是改变viewStartX的坐标）
    
    
    • 正在长触摸状态-isLongTouch: 用户的手指一直停留在我们的屏幕上，这是因为他想要查看数据标注，这个状态下的切换不会切换数据条，而是切换数据标注的下标。
    
    
    
    
  
  
  
  


• 
  

  图表能够计算每次滑动的距离，动态调整viewStartX与要绘制的数组左右边界

  
  

onTouchEvent事件链

为了实现以上需求，我们需要研究一下onTouchEvent(event: MotionEvent?)

对于触摸事件，我们处理以下回调：

• ACTION_DOWN
  
  
  
  • 手指按下：无论是点击还是滑动，ACTION_DOWN都是他们的初始动作
  
  
  
  


• ACTION_MOVE
  
  
  
  • 手指滑动：在ACTION_DOWN触发后，如果手指滑动，MOVE就会被触发若干次，以表示手指在图表上的滑动
  
  
  
  


• ACTION_UP
  
  
  
  • 手指抬起：一定是点击事件的结束步，可能是滑动事件的结束步(也可能是ACTION_CANCEL)
  
  
  
  


• ACTION_CANCEL
  
  
  
  • 手势放弃：可能是滑动事件的结束步(也可能是ACTION_UP)
  
  
  
  

我们先处理该怎么让图表判断是快速滑动：

1. 我们维护一个当前时间currentTime


2. 每次ACTION_DOWN手指按下的时候，我们就记录那一时刻的时间；


3. 在遇到ACTION_MOVE的时候，我们就首先获取当前时间，减去记录的currentTime来获取时间间隔


4. 如果这个间隔小于某个时间阈值TIMEDURATION，我们把它认定为是一次快速滑动


5. 但是，我们添加限制条件，这一次move的距离必须大于某个阈值，否则视为一次轻微move(手滑产生的，不是用户的内心想法)


6. 对于后续的滑动事件来说(上图中的n号ACTION_MOVE)，他们时间可能已经超过了阈值，但他们也需要执行这个滑动任务；还记得我们提到的状态变量isScrolling吗，我们在1号ACTION_MOVE中将isScrolling设置为true，后续的n号滑动事件中，只要发现当前是isScrolling==true 是正在滑动状态，它就可以大胆开始执行滑动事件了。

据上，我们有了以下代码：

override fun onTouchEvent(event:MotionEvent?):Boolean{

//获取当前触摸点的横坐标

mCurrentX = event!!.x



when (event.action) {

    MotionEvent.ACTION_DOWN -> {

        //记录一下触摸的点，用来记录滑动距离

        mLastX = mCurrentX

        //记录现在的时间，用来判断快速滑动

        currentMS = System.currentTimeMillis()



    }

    MotionEvent.ACTION_MOVE -> {

        //获得滑动的距离

        mMoveX = mLastX - mCurrentX

        //记录一下触摸的点

        mLastX = mCurrentX



        //如果 move time <Xms and moveX > Xpx, 这是快速滑动

        if (((System.currentTimeMillis() - currentMS) < TOUCHMOVEDURATION && (abs(mMoveX) > mLineWidth)) || isScrolling) {

            isScrolling = true

            

            //更新viewStartX，实现数据条切换，记得给mViewStartX的setter加invalidate()

            mViewStartX -= mMoveX

            

            //更新左右边界

            updateCurrentDrawRange()

        }

    }

}

接着，我们来处理该怎么让图表判断是长触摸-isLongTouch:

• 怎样的事件流是长触摸呢？
  
  
  
  • 长触摸，就是用户的手放上去以后，没有抬起，只有轻微滑动
  
  
  • 我们将这个阈值设置为判断快速滑动的时间阈值为TIMEDURATION
  
  
  • 如果我们在执行ACTION_DOWN后，TIMEDURATION时间内，除了轻微滑动外，没有任何其他ACTION事件触发，那就认定为是长触摸
  
  
  
  


• 用代码来实现：
  
  
  
  • 我们在每次ACTION_DOWN后，都开启一个子线程，在TIMEDURATION后，如果他没有被取消运行，那就将isLongTouch设置为true
  
  
  • 这样我们就开启了长触摸模式，可以在ACTION_MOVE中增加判断，配合isLongTouch来展示我们的数据标注切换。
  
  
  • 同样，我们在ACTION_UP和 ACTION_MOVE显著移动的事件中，取消这个子线程。
  
  
  
  

这里，我用kotlin协程来实现的这个判断长触摸的子线程

开启协程的函数：

fun startIndicatorTimer() {

    showIndicatorJob = mScope.launch(Dispatchers.Default) {

        //用了hasTimer来辅助外面判断有没有子线程在运行

        hasTimer = true

        //延时任务进行

        delay(TOUCHMOVEDURATION + 10.toLong())

        withContext(Dispatchers.Main) {

            //长触摸了，那正在滑动状态就必须是false啦

            isScrolling = false

            //长触摸：轮到我了

            isLongTouch = true

            //找到当前被触摸的数据条索引

            setCurrentIndexOnClicked()

            //展示指示形态的数据标签

            isShowIndicator = true

            //子线程运行完毕，把标记设置为false

            hasTimer = false

        }

    }

}

关闭协程的函数：

fun turnOffIndicatorTimer() {

    if (hasTimer) {

        showIndicatorJob.cancel()

        hasTimer = false

    }

}

触摸事件里的核心代码

//节选

when(event.action){

    MotionEvent.ACTION_DOWN->{

        //记录坐标，记录时间

        mLastX = mCurrentX

        currentMS = System.currentTimeMillis()

        

        //开始子线程的任务

        startIndicatorTimer()

    }

    MotionEvent.ACTION_MOVE->{

        mMoveX = mLastX - mCurrentX

        mLastX = mCurrentX

    if(是快速滑动){

        //关闭这个长触摸判断线程

        turnOffIndicatorTimer()

    }

    //是长触摸状态，那我们激活isShowIndicator

    else if(isLongTouch){

        isShowIndicator = true

    }

    else if(不是轻微滑动){

        //关闭长触摸判断事件

        turnOffIndicatorTimer()

    }

    }

}

自动回滚

1. 我们需要每次滑动结束后去判断，让窗口内呈现完成的N个数据条
   
   
   
   • 基于我们的结构，这很容易实现，只需要让我们的viewStartX(绘画初始点)的坐标变为(lineWidth+lineSpace)的整数即可
   
   
   
   

mViewStartX - (mViewStartX - mInitialStartX).mod(mLineSpace+mLineWidth)

2. 我们要在滑动超出边界后，让窗口自动回滚到边界值
   
   
   
   • 这同样同意实现，我们通过viewStartX来判断是否出界，然后让viewStartX回到设定的边界值就好了
   
   
   
   

但我们不能采用直接给viewStartX赋值的方法，而是通过ObjectAnimator来实现顺滑的切换，我们将这个逻辑写在方法drawBackToBorder()中，并把它添加到ACTION_CANCEL和ACTION_UP的回调中，因为只有他们俩可能是触摸事件流的结尾。

别放了给viewStartX的Setter方法添加invalidate()，否则动画不会触发。😈

fun drawBackToBorder(){

    var endValue:Float = 0F



    endValue =

        //out of right borderline

    if(mViewStartX < mInitialStartX){

        mInitialStartX

        //out of left borderline

    } else if(mViewStartX > mInitialStartX + (mValueArray.size-24)*(mLineWidth+mLineSpace)){

        mInitialStartX + (mValueArray.size-24)*(mLineWidth+mLineSpace)

        //does not reach the bound, need reposition to exact place.

    } else {

        mViewStartX - (mViewStartX - mInitialStartX).mod(mLineSpace+mLineWidth)

    }



    val anim = ObjectAnimator.ofFloat(mViewStartX, endValue)

    anim.interpolator = DecelerateInterpolator()

    anim.addUpdateListener {

        mViewStartX = it.animatedValue as Float

    }

    anim.start()

}

写在最后

写博客核心是希望能复盘的同时锻炼自己讲清楚思路的能力，相比于贴代码，画图+文字阐述是更我喜欢的做的事。

感谢看到这里，如果有任何疑问，欢迎留言和我交流。😋

3. 附-代码

代码涵盖两个文件：

1. HeartRateEntry.kt 数据类


2. IsenseChart.kt 自定义view文件，没有添加外部参数StyleValue
   YunmaoLeo/AppleHealthChart (github.com)

前言

在前面的学习中，我们基本了解了一些 Canvas 的绘制，那么这一章我们一起复习一下图片的绘制几种方式，和事件的简单交互方式。

我们从易到难，作为基础的进阶控件，我们从最简单的交互开始，那就自定义一个星星评分的控件吧。

一个 App 必不可少的评论系统打分的控件，可以展示评分，可以点击评分，可以滑动评分。它的实现总体上可以分为以下的步骤：

1. 强制测量大小为我们指定的大小


2. 先绘制Drawable未评分的图片


3. 在绘制Bitmap已评分的图片


4. 在onTouch中点击和移动的事件中动态计算当前的评分，进而刷新布局


5. 回调的处理与属性的抽取

思路我们已经有了，下面一步一步的来实现吧。

话不多说，Let's go

1、测量与图片的绘制

我们需要绘制几个星星，那么我们必须要设置的几个属性：

当前的评分值，总共有几个星星，每一个星星的间距和大小，选中和未选中的Drawable图片：

    private int mStarDistance = 0;

    private int mStarCount = 5;

    private int mStarSize = 20;    //每一个星星的宽度和高度是一致的

    private float mScoreNum = 0.0F;  //当前的评分值

    private Drawable mStarScoredDrawable;  //已经评分的星星图片

    private Drawable mStarUnscoredDrawable;  //还未评分的星星图片



    private void init(Context context, AttributeSet attrs) {



        mScoreNum = 2.1f;

        mStarSize = context.getResources().getDimensionPixelSize(R.dimen.d_20dp);

        mStarDistance = context.getResources().getDimensionPixelSize(R.dimen.d_5dp);

        mStarScoredDrawable = context.getResources().getDrawable(R.drawable.iv_normal_star_yellow);

        mStarUnscoredDrawable = context.getResources().getDrawable(R.drawable.iv_normal_star_gray);

    }

测量布局的时候，我们就不能根据xml设置的 match_parent 或 wrap_content 来设置宽高，我们需要根据星星的大小与间距来动态的计算，所以不管xml中如何设置，我们都强制性的使用我们自己的测量。

星星的数量 * 星星的宽度再加上中间的间距 * 数量-1，就是我们的控件宽度，控件高度则是星星的高度。

具体的确定测量我们再上一篇已经详细的复习过了，这里直接贴代码：

    @Override

    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {

        setMeasuredDimension(mStarSize * mStarCount + mStarDistance * (mStarCount - 1), mStarSize);

    }

这样就可以得到对应的测量宽高 （加一个背景方便看效果）：

如何绘制星星？直接绘制Drawable即可，默认的Drawable的绘制为:

    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);



        for (int i = 0; i < mStarCount; i++) {

            mStarUnscoredDrawable.setBounds((mStarDistance + mStarSize) * i, 0, (mStarDistance + mStarSize) * i + mStarSize, mStarSize);

            mStarUnscoredDrawable.draw(canvas);

        }



    }

如果有5个星星图片，那么就为每一个星星定好位置：

那么已经选中的图片也需要使用这种方法绘制吗？

计算当前的评分，然后计算计算需要绘制多少星星，那么就是这样做：

    int score = (int) Math.ceil(mScoreNum);

    for (int i = 0; i < score; i++) {

        mStarScoredDrawable.setBounds((mStarDistance + mStarSize) * i, 0, (mStarDistance + mStarSize) * i + mStarSize, mStarSize);

        mStarScoredDrawable.draw(canvas);

    }

可是这么做不符合我们的要求啊 ，我们是需要是可以显示评分为2.5之类值，那么我们怎么能绘制半颗星呢？Drawable.draw(canvas) 的方式满足不了，那我们可以使用 BitmapShader 的方式来绘制。

初始化一个 BitmapShader 设置给 Paint 画笔，通过画笔就可以画出对应的形状。

比如此时的场景，我们如果想只画0.5个星星，那么我们就可以

     paint = new Paint();

    paint.setAntiAlias(true);

    paint.setShader(new BitmapShader(drawableToBitmap(mStarScoredDrawable), BitmapShader.TileMode.CLAMP, BitmapShader.TileMode.CLAMP));



    @Override

    protected void onDraw(Canvas canvas) {

        for (int i = 0; i < mStarCount; i++) {

            mStarUnscoredDrawable.setBounds((mStarDistance + mStarSize) * i, 0, (mStarDistance + mStarSize) * i + mStarSize, mStarSize);

            mStarUnscoredDrawable.draw(canvas);

        }



         canvas.drawRect(0, 0, mStarSize * mScoreNum, mStarSize, paint);

    }

那么如果是大于一个星星之后的小数点就可以用公式计算

    if (mScoreNum > 1) {

        canvas.drawRect(0, 0, mStarSize, mStarSize, paint);



        if (mScoreNum - (int) (mScoreNum) == 0) {

            //如果评分是3.0之类的整数，那么直接按正常的rect绘制

            for (int i = 1; i < mScoreNum; i++) {

                canvas.translate(mStarDistance + mStarSize, 0);

                canvas.drawRect(0, 0, mStarSize, mStarSize, paint);

            }

        } else {

            //如果是小数例如3.5，先绘制之前的3个，再绘制后面的0.5

            for (int i = 1; i < mScoreNum - 1; i++) {

                canvas.translate(mStarDistance + mStarSize, 0);

                canvas.drawRect(0, 0, mStarSize, mStarSize, paint);

            }

            canvas.translate(mStarDistance + mStarSize, 0);

            canvas.drawRect(0, 0, mStarSize * (Math.round((mScoreNum - (int) (mScoreNum)) * 10) * 1.0f / 10), mStarSize, paint);

        }



    } else {

        canvas.drawRect(0, 0, mStarSize * mScoreNum, mStarSize, paint);

    }

效果：

关于 BitmapShader 的其他用法，可以翻看我之前的自定义圆角圆形View，和自定义圆角容器的文章，里面都有用到过，主要是方便一些图片的裁剪和缩放等。

2、事件的交互与计算

这里并没有涉及到什么事件嵌套，拦截之类的复杂处理，只需要处理自身的 onTouch 即可。而我们需要处理的就是按下的时候和移动的时候评分值的变化。

在onDraw方法中，我们使用 mScoreNum 变量来绘制的已评分的 Bitmap 绘制。所以这里我们只需要在 onTouch 中计算出对应的 mScoreNum 值，让其重绘即可。

    @Override

    public boolean onTouchEvent(MotionEvent event) {



        //x轴的宽度做一下最大最小的限制

        int x = (int) event.getX();

        if (x < 0) {

            x = 0;

        }

        if (x > mMeasuredWidth) {

            x = mMeasuredWidth;

        }



        switch (event.getAction()) {

            case MotionEvent.ACTION_DOWN:

            case MotionEvent.ACTION_MOVE: {

                mScoreNum = x * 1.0f / (mMeasuredWidth * 1.0f / mStarCount);

                invalidate();

                break;

            }

            case MotionEvent.ACTION_UP: {

                break;

            }

        }



        return super.onTouchEvent(event);



    }

计算出一颗星的长度，然后计算当前x轴的长度，就可以计算出当前有几颗星，我们默认处理的是 float 类型。就可以根据计算出的 mScoreNum 值来得到对应的动画效果：

3. 回调处理与自定义属性抽取

到此效果的实现算是结束了，但是我们还有一些收尾工作没做，如何监听进度的回调，如何控制整数与浮点数的显示，是否支持触摸等等。然后对其做一些自定义属性的抽取，就可以在应用中比较广泛的使用了。

自定义属性：

    private int mStarDistance = 5;

    private int mStarCount = 5;

    private int mStarSize = 20;    //每一个星星的宽度和高度是一致的

    private float mScoreNum = 0.0F;  //当前的评分值

    private Drawable mStarScoredDrawable;  //已经评分的星星图片

    private Drawable mStarUnscoredDrawable;  //还未评分的星星图片

    private boolean isOnlyIntegerScore = false;  //默认显示小数类型

    private boolean isCanTouch = true; //默认支持控件的点击

    private OnStarChangeListener onStarChangeListener;

自定义属性的赋值与初始化操作：

    private void init(Context context, AttributeSet attrs) {

        setClickable(true);

        TypedArray mTypedArray = context.obtainStyledAttributes(attrs, R.styleable.StarScoreView);

        this.mStarDistance = mTypedArray.getDimensionPixelSize(R.styleable.StarScoreView_starDistance, 0);

        this.mStarSize = mTypedArray.getDimensionPixelSize(R.styleable.StarScoreView_starSize, 20);

        this.mStarCount = mTypedArray.getInteger(R.styleable.StarScoreView_starCount, 5);

        this.mStarUnscoredDrawable = mTypedArray.getDrawable(R.styleable.StarScoreView_starUnscoredDrawable);

        this.mStarScoredDrawable = mTypedArray.getDrawable(R.styleable.StarScoreView_starScoredDrawable);

        this.isOnlyIntegerScore = mTypedArray.getBoolean(R.styleable.StarScoreView_starIsTouchEnable, true);

        this.isOnlyIntegerScore = mTypedArray.getBoolean(R.styleable.StarScoreView_starIsOnlyIntegerScore, false);

        mTypedArray.recycle();



        paint = new Paint();

        paint.setAntiAlias(true);

        paint.setShader(new BitmapShader(drawableToBitmap(mStarScoredDrawable), BitmapShader.TileMode.CLAMP, BitmapShader.TileMode.CLAMP));

    }

自定义属性的定义xml文件：

    <!--  评分星星控件  -->

    <declare-styleable name="StarScoreView">

        <!--星星间距-->

        <attr name="starDistance" format="dimension" />

        <!--星星大小-->

        <attr name="starSize" format="dimension" />

        <!--星星个数-->

        <attr name="starCount" format="integer" />

        <!--星星已评分图片-->

        <attr name="starScoredDrawable" format="reference" />

        <!--星星未评分图片-->

        <attr name="starUnscoredDrawable" format="reference" />

        <!--是否可以点击-->

        <attr name="starIsTouchEnable" format="boolean" />

        <!--是否显示整数-->

        <attr name="starIsOnlyIntegerScore" format="boolean" />

    </declare-styleable>

在OnTouch的时候就可以判断是否能触摸

    @Override

    public boolean onTouchEvent(MotionEvent event) {

        if (isCanTouch) {



            //x轴的宽度做一下最大最小的限制

            int x = (int) event.getX();

            if (x < 0) {

                x = 0;

            }

            if (x > mMeasuredWidth) {

                x = mMeasuredWidth;

            }



            switch (event.getAction()) {

                case MotionEvent.ACTION_DOWN:

                case MotionEvent.ACTION_MOVE: {

                    setStarMark(x * 1.0f / (getMeasuredWidth() * 1.0f / mStarCount));

                    break;

                }

                case MotionEvent.ACTION_UP: {

                    break;

                }

            }

            

            return super.onTouchEvent(event);



        } else {

            //如果设置不能点击，直接不触发事件

            return false;

        }



    }

而 setStarMark 则是设置入口的方法，内部判断是否支持小数点和设置对于的监听，并调用重绘。

   public void setStarMark(float mark) {

        if (isOnlyIntegerScore) {

            mScoreNum = (int) Math.ceil(mark);

        } else {

            mScoreNum = Math.round(mark * 10) * 1.0f / 10;

        }

        if (this.onStarChangeListener != null) {

            this.onStarChangeListener.onStarChange(mScoreNum);  //调用监听接口

        }

        invalidate();

    }

一个简单的图片绘制和事件触摸的控件就完成啦，使用起来也是超级方便。

    <com.guadou.kt_demo.demo.demo18_customview.star.StarScoreView

        android:id="@+id/star_view"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:layout_gravity="center_horizontal"

        android:layout_marginTop="@dimen/d_40dp"

        android:background="#f1f1f1"

        app:starCount="5"

        app:starDistance="@dimen/d_5dp"

        app:starIsOnlyIntegerScore="false"

        app:starIsTouchEnable="true"

        app:starScoredDrawable="@drawable/iv_normal_star_yellow"

        app:starSize="@dimen/d_35dp"

        app:starUnscoredDrawable="@drawable/iv_normal_star_gray" />

Activity中可以设置评分和设置监听：

    override fun init() {



        val starView = findViewById<StarScoreView>(R.id.star_view)



        starView.setOnStarChangeListener {

            YYLogUtils.w("当前选中的Star:$it")

        }



        findViewById<View>(R.id.set_progress).click {

            starView.setStarMark(3.5f)

        }

    }

效果：

后记

整个流程走下来是不是很简单呢，此控件不止用于星星类型的评分，任何图片资源都可以使用，现在我们思路打开扩展一下，相似的场景和效果我们可以实现一些图片进度，触摸进度条，圆环的SeekBar，等等类似的控制都是相似的思路。

这一期的比较简单，我并没有上传到 Maven ，如果有需求可以去我的项目里面拿，如果有需求的话也可以自行修改，如果大家有兴趣可以查看源码点击【传送门】。你也可以关注我的这个Kotlin项目，我有时间都会持续更新。

关于事件交互的自定义View后面有时间会再出稍微复杂一点的，帮助大家巩固与复习。我心里的路线是先学绘制再学交互（因为交互的基础就是绘制），然后再学ViewGroup的嵌套、拦截、分发、排版等等，从易到难争取让大家复习个通透，当然如果有人看的话，我会继续更新。

惯例，我如有讲解不到位或错漏的地方，希望同学们可以指出交流。

如果感觉本文对你有一点点的启发，还望你能点赞支持一下,你的支持是我最大的动力。

Ok,这一期就此完结。

期望实现的效果

这个效果看上去很简单，但是等到要实现的时候，发现用常规的布局在左侧文字较长的时候，右侧文字标签的控件会控件被左侧文字挤压导致标签控件显示不了（LinearLayout、RelativeLayout都存在一样的问题）
（修改：评论给出了一种用LinearLayout实现的一种方式更便捷，那么这篇文章就当做提供另外一种方案吧- -）

使用ConstraintLayout就能解决这个问题，先贴个代码：

<androidx.constraintlayout.widget.ConstraintLayout

    android:layout_width="match_parent"

    android:layout_height="wrap_content">

    

    <TextView

        android:layout_width="0dp"

        android:layout_height="wrap_content"

        app:layout_constraintLeft_toLeftOf="parent"

        app:layout_constraintTop_toTopOf="parent"

        app:layout_constraintBottom_toBottomOf="parent"

        app:layout_constraintRight_toLeftOf="@+id/tv2"

        android:ellipsize="end"

        android:maxLines="1"

        android:id="@+id/tv1"

        android:textSize="20dp"

        app:layout_constraintHorizontal_chainStyle="packed"

        app:layout_constraintHorizontal_bias="0"

        app:layout_constraintWidth_default="wrap"

        android:text="王小明"

        />

    

    <TextView

        app:layout_constraintBottom_toBottomOf="@+id/tv1"

        app:layout_constraintRight_toRightOf="parent"

        android:background="@drawable/co_border_blue"

        app:layout_constraintLeft_toRightOf="@+id/tv1"

        app:layout_constraintTop_toTopOf="@id/tv1"

        android:id="@+id/tv2"

        android:text="父亲"

        android:paddingLeft="5dp"

        android:paddingRight="5dp"

        android:visibility="visible"

        android:textSize="15dp"

        android:textColor="#59baf5"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content" />







</androidx.constraintlayout.widget.ConstraintLayout>

核心思路

第一步先把两个文本的对齐方式约束起来

左侧文本需要在右侧文本右侧，右侧文本需要在左侧文本左侧，右侧文本还需要和父布局右对齐

关键代码

    <TextView

        android:layout_width="0dp"

        android:layout_height="wrap_content"

        app:layout_constraintRight_toLeftOf="@+id/tv2"

        android:id="@+id/tv1"

        ...

        />

        

    这里tv1设置layout_width="0dp"，即match_constraint，如果自适应则按照目前的约束方式两个文本整体会居中  

        

    

   

       

       



    <TextView

        app:layout_constraintRight_toRightOf="parent"

        app:layout_constraintLeft_toRightOf="@+id/tv1"

        android:id="@+id/tv2"

        android:text="父亲"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content" 

        ...

        />

这个时候的效果：

虽然第二种场景下满足了，但是第一种场景下是不符合期望的，这个时候需要考虑再进一步约束：

1）左侧文字需要做到自适应

2）左侧文字自适应后需要对齐到最左侧

3）自适应后左右侧文字需要连接在一起
所以进一步引入了【链条样式】

关键代码：

<TextView

    android:id="@+id/tv1"

    app:layout_constraintHorizontal_chainStyle="packed"

    app:layout_constraintHorizontal_bias="0"

    app:layout_constraintWidth_default="wrap"

    android:text="王小明"

    />

app:layout_constraintHorizontal_chainStyle="packed" 使链条上的元素都打包到一起
app:layout_constraintHorizontal_bias="0" 使左侧控件最左侧对齐
app:layout_constraintWidth_default="wrap" 使左侧文字自适应大小并且不超过约束限制，默认是“spread”，会占用所有符合约束的控件

这样就完成了目标的效果

在清明节时各大APP都会进行黑白化处理，当时在接到这个需求的时候感觉好麻烦，是不是又要搞一套皮肤？

然而在一系列搜索之后，找到了两位大神（鸿洋、U2tzJTNE）的实现方案，其实相当的简单！

让我们一起站在巨人的肩膀上来分析一下原理，并思考会不会有更简便的实现？

一、原理

两位大神的置灰方案是相同的，都能看到一段同样的代码：

Paint mPaint = new Paint();

ColorMatrix mColorMatrix = new ColorMatrix();

// 设置饱和度为0

mColorMatrix.setSaturation(0);

mPaint.setColorFilter(new ColorMatrixColorFilter(mColorMatrix));

他们都用了Android提供的ColorMatrix（颜色矩阵），将其饱和度设置为0，这样使用Paint绘制出来的都是没有饱和度的灰白样式！

然而两位在何时使用Paint绘制时选择了不同方案。

1.1 鸿洋：重写draw方法

鸿洋老师分析，如果我们把每个Activity的根布局饱和度设置为0是不是就可以了？

那根布局是谁？

鸿洋老师分析我们的布局最后setContentView最后都会设置到一个R.id.content的FrameLayout当中。

我们去自定义一个GrayFrameLayout，在draw的时候使用这个饱和度为0的画笔，被这个FrameLayout包裹的布局都会变成黑白。

// 转载自鸿洋

// https://blog.csdn.net/lmj623565791/article/details/105319752

public class GrayFrameLayout extends FrameLayout {

    private Paint mPaint = new Paint();



    public GrayFrameLayout(Context context, AttributeSet attrs) {

        super(context, attrs);



        ColorMatrix cm = new ColorMatrix();

        cm.setSaturation(0);

        mPaint.setColorFilter(new ColorMatrixColorFilter(cm));

    }



    @Override

    protected void dispatchDraw(Canvas canvas) {

        canvas.saveLayer(null, mPaint, Canvas.ALL_SAVE_FLAG);

        super.dispatchDraw(canvas);

        canvas.restore();

    }



    @Override

    public void draw(Canvas canvas) {

        canvas.saveLayer(null, mPaint, Canvas.ALL_SAVE_FLAG);

        super.draw(canvas);

        canvas.restore();

    }

}

然后我们用GrayFrameLayout去替换这个R.id.content的FrameLayout，是不是就可以做到将页面黑白化了？

替换FrameLayout的方法可以去【鸿洋】这篇文章下查看。

1.2 U2tzJTNE：监听DecorView的添加

U2tzJTNE大佬使用了另一种巧妙的方案。

他先创建了一个具有数据变化感知能力的ObservableArrayList（当内容发生变化有回调）。

之后使用反射将WindowManagerGlobal内的mViews容器（ArrayList，该容器会存放所有的DecorView），替换为ObservableArrayList，这样就可以监听到每个DecorView的创建，并且拿到View本身。

拿到DecorView，那就可以为所欲为了！

大佬使用了setLayerType(View.LAYER_TYPE_HARDWARE, mPaint)，对布局进行了重绘。至于为什么要用LAYER_TYPE_HARDWARE？因为默认的View.LAYER_TYPE_NONE会把Paint强制设置为null。

// 转载自U2tzJTNE

// https://juejin.cn/post/6892277675012915207

public static void enable(boolean enable) {

    try {

        //灰色调Paint

        final Paint mPaint = new Paint();

        ColorMatrix mColorMatrix = new ColorMatrix();

        mColorMatrix.setSaturation(enable ? 0 : 1);

        mPaint.setColorFilter(new ColorMatrixColorFilter(mColorMatrix));



        //反射获取windowManagerGlobal

        @SuppressLint("PrivateApi")

        Class<?> windowManagerGlobal = Class.forName("android.view.WindowManagerGlobal");

        @SuppressLint("DiscouragedPrivateApi")

        java.lang.reflect.Method getInstanceMethod = windowManagerGlobal.getDeclaredMethod("getInstance");

        getInstanceMethod.setAccessible(true);

        Object windowManagerGlobalInstance = getInstanceMethod.invoke(windowManagerGlobal);



        //反射获取mViews

        Field mViewsField = windowManagerGlobal.getDeclaredField("mViews");

        mViewsField.setAccessible(true);

        Object mViewsObject = mViewsField.get(windowManagerGlobalInstance);



        //创建具有数据感知能力的ObservableArrayList

        ObservableArrayList<View> observerArrayList = new ObservableArrayList<>();

        observerArrayList.addOnListChangedListener(new ObservableArrayList.OnListChangeListener() {

            @Override

            public void onChange(ArrayList list, int index, int count) {

            }



            @Override

            public void onAdd(ArrayList list, int start, int count) {

            	// 拿到DecorView触发重绘

                View view = (View) list.get(start);

                if (view != null) {

                    view.setLayerType(View.LAYER_TYPE_HARDWARE, mPaint);

                }

            }



            @Override

            public void onRemove(ArrayList list, int start, int count) {

            }

        });

        //将原有的数据添加到新创建的list

        observerArrayList.addAll((ArrayList<View>) mViewsObject);

        //替换掉原有的mViews

        mViewsField.set(windowManagerGlobalInstance, observerArrayList);

    } catch (Exception e) {

        e.printStackTrace();

    }

}

只需要在Application里面调用该方法即可。

1.3 方案分析

两位大佬的方案都非常的棒，咱们理性的来对比一下。

• 
  

  鸿洋老师： 使用自定义FrameLayout的方案需要一个BaseActivity统一设置，稍显麻烦，代码侵入性较强。

  
  


• 
  

  U2tzJTNE大佬： 方案更加简单、动态，一行代码设置甚至可以做到在当前页从彩色变黑白，但是使用了反射，有一点点性能消耗。

  
  

二、简易方案（直接复制）

既然研究明白了大佬的方案，那有没有又不需要反射，设置又简单的方法呢？

能不能使用原生方式获取DecorView的实例呢？

突然灵光一闪，Application里面不是有registerActivityLifecycleCallbacks这个注册监听方法吗？监听里面的onActivityCreated不是可以获取到当前的Activity吗？那DecorView不就拿到了！

搞起！上代码！

public class StudyApp extends Application {



    @Override

    public void onCreate() {

        super.onCreate();

        

        Paint mPaint = new Paint();

        ColorMatrix mColorMatrix = new ColorMatrix();

        mColorMatrix.setSaturation(0);

        mPaint.setColorFilter(new ColorMatrixColorFilter(mColorMatrix));



        registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks() {

        

            @Override

            public void onActivityCreated(@NonNull Activity activity, @Nullable Bundle savedInstanceState) {

            	// 当Activity创建，我们拿到DecorView，使用Paint进行重绘

                View decorView = activity.getWindow().getDecorView();

                decorView.setLayerType(View.LAYER_TYPE_HARDWARE, mPaint);

            }

           

			....

        });

    }

}

这样看起来是不是更简单了！使用了APP原生的方法实现了黑白化！当然也有缺点，因为在Activity级别设置，无法做到在当前页面即时变为黑白。

三、注意事项

这三种方案因为都使用了颜色矩阵，所以坑都是一样的，请注意。

3.1 启动图windowBackground无法变色

在我们可以设置渲染的时候windowBackground已经展示完毕了。

解决方案：只能在当前的包里修改，或者不去理会。

3.2 SurfaceView无法变色

因为我们使用了setLayerType进行重绘，而SurfaceView是有独立的Window，脱离布局内的Window，运行在其他线程，不影响主线程的绘制，所以当前方案无法使SurfaceView变色。

解决方案：
1、使用TextureView。
2、看下这个SurfaceView是否可以设置滤镜，正常都是一些三方或者自制的播放器。

3.3 多进程变色

我们可能会在APP内置小程序，小程序基本是运行在单独的进程中，但是如果我们的黑白配置在运行过程中发生变化，其他进程是无法感知的。

解决方案：使用MMKV存储黑白配置，并设置多进程共享，在开启小程序之前都判断一下黑白展示。

总结

最后咱们再总结一下黑白化方案。

使用了ColorMatrix设置饱和度为0，设置到Paint中，让根布局拿着这个Paint去进行重绘。

这样APP全局黑白化的介绍就结束了，希望大家读完这篇文章，会对APP黑白化有一个更深入的了解。如果我的文章能给大家带来一点点的福利，那在下就足够开心了。

下次再见！

背景

开发中会存在多个任务之间互相依赖，运行非常慢的情况，譬如Android在主线程中初始化多个SDK导致App启动慢的情况，搜索一下发现业界的通用做法是构造任务的有向无环图，拓扑排序生成有序的任务列表，然后用线程池执行任务列表(通俗的说就是先找到没有依赖的任务执行，执行完了以后再找到剩下的没有依赖的任务执行，如此反复直到执行完所有任务)，但是这个做法无法解决有的任务需要点击对话框授权的情况,基于这个情况打算再造一个轮子出来。

问题

造轮子之前先梳理了一下对这个轮子的要求，发现除了有向无环图外还是有很多细节要解决的。

-依赖任务多线程启动

-支持交互性任务，先拦截任务，交互完成以后再继续执行

-可视化有向无环图

-可视化任务执行情况

-支持多线程、主线程、主进程、第一个任务、最后一个任务等配置属性

方案

开源

TaskGraph: github.com/JonaNorman/…

线程池只能执行没有依赖关系的任务，TaskGraph开源库用有向无环图实现多线程依赖线程池，用拦截器实现交互式任务

图中添加了A任务，B任务依赖A任务执行完再执行，其中A任务需要点击对话框才能执行。

TaskGraph taskGraph = new TaskGraph();

taskGraph.addTask(new Task("A",new Runnable() {//添加A任务

   @Override

   public void run() {

   }

}).addTaskInterceptor(new Task.TaskInterceptor() {

   @Override

   public void onIntercept(Task.TaskInterceptorChain interceptorChain) {//拦截A任务，在A任务之前可以插入对话框

       AlertDialog.Builder builder = new AlertDialog.Builder(TaskGraphModule.getTopActivity());

       builder.setPositiveButton("ok", new DialogInterface.OnClickListener() {

           @Override

           public void onClick(DialogInterface dialog, int which) {

               interceptorChain.proceed();//继续

           }

       });

       builder.setNegativeButton("cancel", new DialogInterface.OnClickListener() {

           @Override

           public void onClick(DialogInterface dialog, int which) {

               interceptorChain.cancel();//取消

           }

       });

       builder.show();

   }

}));

taskGraph.addTask(new Task("B",new Runnable() {

   @Override

   public void run() {//添加B任务,B任务依赖A任务先完成

   }

}).dependsOn("A").setMainThread(true));

taskGraph.execute();

可视化有向图

搜索TASK_GRAPH_LOG: graphviz:会输出有向图日志，复制到 graphviz-visual-editor 可视化查看

可视化任务执行情况

python systrace.py -o trace.html  -a packagename sched

复制代码

packagename要替换成运行的app的包名 chrome浏览器打开chrome://tracing/,load 按钮加载trace.html

原理

依赖任务多线程启动

正常的线程池只能执行没有依赖关系的任务，怎么才能让线程池支持运行相互依赖的任务呢？
先找到所有没有进来箭头的节点执行，在该图中也就是A，执行完后删除这个节点和边，
变成了下图

继续以上步骤，找到B运行后删除B,变成下图这样

继续以上步骤，找到C D E同时运行，最终所有任务执行完毕。

把上面的步骤翻译成术语

• 有箭头的图叫有向图


• 节点有多少个进来的箭头叫入度


• 没有进来箭头的节点叫入度为0的节点


• 箭头没有形成环的图叫有向无环图


• 依次找到所有入度为0的节点叫拓扑排序

这里有个问题，多线程怎么执行拓扑排序的节点，有两种做法

1. 拓扑排序的节点列表作为runnable提交到线程池，依赖的任务线程等待其他任务完成在执行


2. 先把入度为0的所有节点提交到线程池，有一个执行完，就触发寻找剩下入度为0的节点继续执行
   两种方案我选了方案2，个人感觉方案2找到的节点执行顺序是最优的，并且不需要线程等待，代码简单而且不需要空占有线程池的线程数量

主要思想：

Grpah图有多个node节点，每个Node节点有一个Vertex顶点，多个入边edge，多个出边edge，
拓扑排序就是找所有node节点入度为0的边移除然后继续找直到找完所有节点，核心代码地址

支持交互性任务

有些任务需要交互输入，完成以后再继续执行，为了实现该功能，可以用拦截器的方式来实现。

拦截器的原理就是调用到拦截器时候会用锁等待，如果执行了proceed方法会唤醒锁然后执行下个拦截器，如果执行了cancel会唤醒锁终止所有任务标记cancel状态，每个拦截器必须调用其中一个方法，要不然会一直等待
核心代码如下：代码地址

private void nextIntercept() {

    synchronized (sync) {

        currentInterceptor = taskInterceptorQueue.poll();//获取下一个拦截器

        if (currentInterceptor == null) {

            return;

        }

        currentInterceptor.onIntercept(this);//处罚拦截器

    }

    while (!graphController.isFinished()) {

        synchronized (sync) {

            if (cancel) {//调用cancel方法会把cancel赋值为true

                throw new TaskCancelException();

            } else if (currentInterceptor == proceedInterceptor) {//如果调用了proceed会proceedInterceptor赋值为currentInterceptor

                nextIntercept();//执行下一个拦截器

                break;

            } else {

                try {

                    sync.wait();//等待执行proceed或者cancel方法

                } catch (InterruptedException e) {

                }

            }

        }

    }

}

可视化有向无环图

多个依赖任务添加进去以后如果不能可视化成图就会对影响对任务的把控程度，graphviz是一个图的可视化项目，只要把图的情况写成文本输入就会生成对应图。

  digraph pic {

    A->B;

    B->C;

    }

可视化任务执行情况

多个任务执行实时运行情况，有助于我们优化任务依赖，主要就是在每个任务执行开始调用Trace.beginSection(name),执行完调用Trace.endSection(),然后用命令

python systrace.py -o trace.html  -a packagename sched

生成trace.html,然后用chrome浏览器打开chrome://tracing/点击load按钮加载trace.html就可以查看每个任务的执行情况

支持多线程、主线程、主进程、第一个任务、最后一个任务等配置属性

任务具有多个属性，多线程、主线程、主进程等属性，该实现只要加对应判断就行，第一个任务和最后一个任务则需要遍历所有任务，添加对应依赖关系。

收获

依赖任务多线程调度本身不是很难，在该开源项目中我收获了很多，包括如何实现有向无环图，如何在多线程中实现任务拦截继发，如何使用graphviz实现可视化图，如何用systemtrace可视化任务执行，希望看完文章的同学也可以从中学到什么，谢谢大家的浏览，如果觉得可以，欢迎大家多多star这个开源项目。

背景

Lucene中根据term字典和倒排可以快速查找到相关文档的id，那怎么获取文档中的字段内容呢，这就是我们今天要讲的正排数据。

Lucene中对于某个文档的各个字段，可以通过配置来控制是否要存储进正排索引文件中，只有存储到正排索引文件中，查询的时候，有需要才能返回相应的字段。

如果理解了之前介绍过的词向量的索引文件构建，可以发现其实正排索引文件和词向量索引文件构建非常类似。

最终生成的正排索引文件有3个：

• fdt：按chunk存储doc的开启了store的字段


• fdx：chunk的索引文件，记录的是每个chunk的起始docID，以及每个chunk的起始位置，方便根据docID快速定位到chunk。


• fdm：正排索引文件的元信息，用来读取正排索引文件使用的。

前置知识

• 在对字段数据的存储时，对不同的数据类型，有不同的压缩算法，详见《单值编码压缩算法》。


• 构建chunk索引文件的时候会用到工具类FieldsIndexWriter，具体我们已经在《词向量索引文件构建》中详细介绍过了。

索引文件格式

fdm

fdm是正排索引文件的元信息，用来读取的时候使用。

字段详解

Header

文件头部信息，主要是包括：

• 文件头魔数（同一lucene版本所有文件相同）


• 该文件使用的codec名称：Lucene90FieldsIndexMeta


• codec版本


• segment id（也是Segment_N文件中的N）


• segment后缀名（一般为空）

ChunkSize

用来判断是否满足一个chunk的一种条件，如果chunk的大小超过了ChunkSize的限制，则可以构建一个chunk

NumDocs

doc总数

BlockShift

DirectMonotonicWriter需要的参数，DirectMonotonicWriter压缩存储会生成多个block，BlockShift决定了block的大小。

TotalChunks + 1

chunk总数 + 1，在生成fdx索引文件中ChunkStartDocIDs和ChunkOffsets两个字段时，使用DirectMonotonicWriter写入的值的总数。

fdxDocStartFP

fdx索引文件中ChunkStartDocIDs的起始位置

DocBlockMetas

fdx索引文件中ChunkStartDocIDs使用DirectMonotonicWriter编码存储，会生成多个block，这些block的元信息。

tvxOffsetStartFP

fdx中ChunkOffsets的起始位置

OffsetBlockMetas

fdx索引文件中ChunkOffsets使用DirectMonotonicWriter编码存储，会生成多个block，这些block的元信息。

SPEndPoint

fdx文件的结束位置，后面是fdx的footer信息。

MaxPointer

fdt文件的结束位置，后面fdt的footer信息。

NumChunks

chunk总数

NumDirtyChunks

dirtyChunk总数

NumDirtyDocs

dirtyChunk中的doc总数

Footer

文件尾，主要包括

• 文件尾魔数（同一个lucene版本所有文件一样）


• 0


• 校验码

fdt

fdt中按chunk存储各个doc所有的字段数据。

字段详解

Header

文件头部信息，主要是包括：

• 
  

  文件头魔数（同一lucene版本所有文件相同）

  
  


• 
  

  该文件使用的codec名称

  
  

  根据压缩模式的不同有两种：

  
  
  
  
  • Lucene90StoredFieldsFastData
  
  
  • Lucene90StoredFieldsHighData
  
  
  
  


• 
  

  codec版本

  
  


• 
  

  segment id（也是Segment_N文件中的N）

  
  


• 
  

  segment后缀名（一般为空）

  
  

chunk

• DocBase：Chunk中Doc的起始编号，Chunk中所有doc的真实编号需要加上这个DocBase


• NumDocsCode：是NumDocs和IsDirty，IsSlice的int组合体
  
  
  
  • NumDocs：chunk中的doc总数
  
  
  • IsDirty：chunk是否是dirtyChunk
  
  
  • IsSlice：chunk是否被分成多个slice
  
  
  
  


• DocNumFields：chunk中每个文档的字段个数。


• DocDataLengths：chunk中每个doc占用的存储空间大小。


• Doc：doc中每个store字段的信息
  
  
  
  • Field：store的字段
    
    
    
    • FieldNumAndTypeCode：FieldNumber和type的long组合体
      
      
      
      • FieldNumber：字段的编号
      
      
      • type：字段的类型
      
      
      
      
    
    
    • FieldValue：根据不同的数值类型，有不同的存储方式
      
      
      
      • 二进制/string：先存length，再存数据
      
      
      • byte/short/int：zint存储
      
      
      • long：tlong存储
      
      
      • float：zfloat存储
      
      
      • double：zdouble存储
      
      
      
      
    
    
    
    
  
  
  
  

Footer

文件尾，主要包括

• 文件尾魔数（同一个lucene版本所有文件一样）


• 0


• 校验码

fdx

fdt中所有chunk的索引信息，可以快速根据docID定位到chunk的位置。

字段详解

Header

文件头部信息，主要是包括：

• 文件头魔数（同一lucene版本所有文件相同）


• 该文件使用的codec名称：Lucene90FieldsIndexIdx


• codec版本


• segment id（也是Segment_N文件中的N）


• segment后缀名（一般为空）

ChunkStartDocIDs

所有chunk的起始docID，使用DirectMonotonicWriter编码存储，会生成多个block。

ChunkOffsets

所有chunk在fdt索引文件中的起始位置，使用DirectMonotonicWriter编码存储，会生成多个block。

Footer

文件尾，主要包括

• 文件尾魔数（同一个lucene版本所有文件一样）


• 0


• 校验码

构建源码

本文源码解析基于lucene-core-9.1.0。

• StoredFieldsConsumer负责调度正排索引文件的构建主要有：启动一个doc的处理，处理doc中的field，结束一个doc的处理，结束正排索引的构建。


• Lucene90CompressingStoredFieldsWriter负责持久化生成正排索引文件

构建涉及到的StoredFieldsConsumer和Lucene90CompressingStoredFieldsWriter逻辑其实非常简单，下面我们一起来看下。

StoredFieldsConsumer

class StoredFieldsConsumer {

  final Codec codec;

  // 索引文件的目录  

  final Directory directory;

  final SegmentInfo info;

  // 实现类是  Lucene90CompressingStoredFieldsWriter，负责正排索引文件的持久化

  StoredFieldsWriter writer;

  Accountable accountable = Accountable.NULL_ACCOUNTABLE;

  // 前一个处理的docID  

  private int lastDoc;



  StoredFieldsConsumer(Codec codec, Directory directory, SegmentInfo info) {

    this.codec = codec;

    this.directory = directory;

    this.info = info;

    this.lastDoc = -1;

  }



  // 创建 Lucene90CompressingStoredFieldsWriter  

  protected void initStoredFieldsWriter() throws IOException {

    if (writer == null) { 

      this.writer = codec.storedFieldsFormat().fieldsWriter(directory, info, IOContext.DEFAULT);

      accountable = writer;

    }

  }



  // 开始处理一个doc

  void startDocument(int docID) throws IOException {

    assert lastDoc < docID;

    initStoredFieldsWriter();

    while (++lastDoc < docID) { // 确保doc是连续的

      writer.startDocument();

      writer.finishDocument();

    }

    //  Lucene90CompressingStoredFieldsWriter中开始处理doc 

    writer.startDocument();

  }

    

  // 每个需要构建的正排字段都会被处理

  void writeField(FieldInfo info, IndexableField field) throws IOException {

    writer.writeField(info, field);

  }



  // 结束doc的处理  

  void finishDocument() throws IOException {

    writer.finishDocument();

  }



  // 结束正排的构建  

  void finish(int maxDoc) throws IOException {

    while (lastDoc < maxDoc - 1) {

      startDocument(lastDoc);

      finishDocument();

      ++lastDoc;

    }

  }



  // 持久化正排索引文件  

  void flush(SegmentWriteState state, Sorter.DocMap sortMap) throws IOException {

    try {

      writer.finish(state.segmentInfo.maxDoc());

    } finally {

      IOUtils.close(writer);

    }

  }



  void abort() {

    IOUtils.closeWhileHandlingException(writer);

  }

}

Lucene90CompressingStoredFieldsWriter

成员变量

  // 数据文件

  public static final String FIELDS_EXTENSION = "fdt";

  // 索引文件

  public static final String INDEX_EXTENSION = "fdx";

  // 元信息文件

  public static final String META_EXTENSION = "fdm";

  /** Codec name for the index. */

  public static final String INDEX_CODEC_NAME = "Lucene90FieldsIndex";



  // 不同数据类型编码  

  static final int STRING = 0x00;

  static final int BYTE_ARR = 0x01;

  static final int NUMERIC_INT = 0x02;

  static final int NUMERIC_FLOAT = 0x03;

  static final int NUMERIC_LONG = 0x04;

  static final int NUMERIC_DOUBLE = 0x05;

  // 数据类型编码的bit数量

  static final int TYPE_BITS = PackedInts.bitsRequired(NUMERIC_DOUBLE);

  // 提取类型的掩码  

  static final int TYPE_MASK = (int) PackedInts.maxValue(TYPE_BITS);



  static final int VERSION_START = 1;

  static final int VERSION_CURRENT = VERSION_START;

  static final int META_VERSION_START = 0;



  private final String segment;

  // 索引生成工具  

  private FieldsIndexWriter indexWriter;

  private IndexOutput metaStream, fieldsStream;



  private Compressor compressor;

  private final CompressionMode compressionMode;

  // chunk的大小  

  private final int chunkSize;

  // 每个chunk最多可以存储多少个doc  

  private final int maxDocsPerChunk;

 

  // 缓存所有的字段的值

  private final ByteBuffersDataOutput bufferedDocs;

  // 下标是当前chunk中的docID的偏移量，值是对应doc的字段个数

  private int[] numStoredFields; 

  // 下标是当前chunk中的docID的偏移量，值是对应doc的所有需要store的数据在bufferedDocs中的结束位置

  private int[] endOffsets; 

  // chunk中的起始docID

  private int docBase;

  // chunk中的doc个数

  private int numBufferedDocs; 

  // chunk总数

  private long numChunks;

  // dirtyChunk总数，未满足生成chunk的条件时，强制生成的chunk是dirtyChunk

  private long numDirtyChunks; 

  // dirtyDoc总数，dirtyChunk中的doc是dirtyDoc

  private long numDirtyDocs; 

  

  // 在处理一个doc的时候，统计已经处理的field个数

  private int numStoredFieldsInDoc;

核心方法

开始处理一个doc

当前实现中是空操作。

  @Override

  public void startDocument() throws IOException {}

处理一个field

处理一个field，就是读取field的值，根据值的类型按对应的值的存储方式存入bufferedDocs缓存中。

  public void writeField(FieldInfo info, IndexableField field) throws IOException {



    ++numStoredFieldsInDoc;



    int bits = 0;

    final BytesRef bytes;

    final String string;



    Number number = field.numericValue();

    if (number != null) { // 如果是数值类型

      if (number instanceof Byte || number instanceof Short || number instanceof Integer) {

        // byte，short，int都标记为int  

        bits = NUMERIC_INT;

      } else if (number instanceof Long) {

        // long  

        bits = NUMERIC_LONG;

      } else if (number instanceof Float) {

        // float  

        bits = NUMERIC_FLOAT;

      } else if (number instanceof Double) {

        // double  

        bits = NUMERIC_DOUBLE;

      } else {

        throw new IllegalArgumentException("cannot store numeric type " + number.getClass());

      }

      string = null;

      bytes = null;

    } else {

      bytes = field.binaryValue();

      if (bytes != null) { // 是二进制

        bits = BYTE_ARR;

        string = null;

      } else { // 是字符串

        bits = STRING;

        string = field.stringValue();

        if (string == null) {

          throw new IllegalArgumentException(

              "field "

                  + field.name()

                  + " is stored but does not have binaryValue, stringValue nor numericValue");

        }

      }

    }

    // 字段的编号和类型组合体

    final long infoAndBits = (((long) info.number) << TYPE_BITS) | bits;

    bufferedDocs.writeVLong(infoAndBits);



    if (bytes != null) {

      bufferedDocs.writeVInt(bytes.length);

      bufferedDocs.writeBytes(bytes.bytes, bytes.offset, bytes.length);

    } else if (string != null) {

      bufferedDocs.writeString(string);

    } else {

      if (number instanceof Byte || number instanceof Short || number instanceof Integer) {

        bufferedDocs.writeZInt(number.intValue());

      } else if (number instanceof Long) {

        writeTLong(bufferedDocs, number.longValue());

      } else if (number instanceof Float) {

        writeZFloat(bufferedDocs, number.floatValue());

      } else if (number instanceof Double) {

        writeZDouble(bufferedDocs, number.doubleValue());

      } else {

        throw new AssertionError("Cannot get here");

      }

    }

  }

结束处理一个doc

结束doc的处理，需要做4件事：

• 如果numBufferedDocs空间不足了，需要扩容


• 记录doc对应的field个数


• 记录doc数据在bufferedDocs中的结束位置


• 判断如果满足一个chunk的生成，则生成chunk

  public void finishDocument() throws IOException {

    if (numBufferedDocs == this.numStoredFields.length) {

      final int newLength = ArrayUtil.oversize(numBufferedDocs + 1, 4);

      this.numStoredFields = ArrayUtil.growExact(this.numStoredFields, newLength);

      endOffsets = ArrayUtil.growExact(endOffsets, newLength);

    }

    // 记录doc对应的field个数  

    this.numStoredFields[numBufferedDocs] = numStoredFieldsInDoc;

    numStoredFieldsInDoc = 0;

    // 记录当前doc在bufferedDocs中的结束位置

    endOffsets[numBufferedDocs] = Math.toIntExact(bufferedDocs.size());

    ++numBufferedDocs;

    if (triggerFlush()) {

      flush(false);

    }

  }

生成一个chunk

生成一个chunk的条件：

• bufferDocs缓存超出了chunkSize


• chunk中收集的doc数量超出了maxDocsPerChunk


• 强制生成

  // 生成一个chunk的条件

  // 1.bufferDocs缓存超出了chunkSize

  // 2.chunk中收集的doc数量超出了maxDocsPerChunk

  private boolean triggerFlush() {

    return bufferedDocs.size() >= chunkSize || numBufferedDocs >= maxDocsPerChunk;

  } 



  private void flush(boolean force) throws IOException {

    // chunk数+1  

    numChunks++;

    if (force) { // 如果是强制构建chunk，可能是不满足chunk条件的，这种chunk被定义为dirtyChunk

      numDirtyChunks++;

      numDirtyDocs += numBufferedDocs;

    }

    // 生成chunk的索引  

    indexWriter.writeIndex(numBufferedDocs, fieldsStream.getFilePointer());



    // 把各个doc在bufferedDocs中的endOffsets转成length

    final int[] lengths = endOffsets;

    for (int i = numBufferedDocs - 1; i > 0; --i) {

      lengths[i] = endOffsets[i] - endOffsets[i - 1];

    }

    // 如果当前chunk的大小超出了2倍chunkSize，则需要分片  

    final boolean sliced = bufferedDocs.size() >= 2 * chunkSize;

    final boolean dirtyChunk = force;

    writeHeader(docBase, numBufferedDocs, numStoredFields, lengths, sliced, dirtyChunk);



    // 下面是压缩处理

    byte[] content = bufferedDocs.toArrayCopy();

    bufferedDocs.reset();



    if (sliced) {

      // big chunk, slice it

      for (int compressed = 0; compressed < content.length; compressed += chunkSize) {

        compressor.compress(

            content, compressed, Math.min(chunkSize, content.length - compressed), fieldsStream);

      }

    } else {

      compressor.compress(content, 0, content.length, fieldsStream);

    }



    // 更新下一个chunk的起始docID

    docBase += numBufferedDocs;

    // 重置doc数统计  

    numBufferedDocs = 0;

    bufferedDocs.reset();

  }



  private static void saveInts(int[] values, int length, DataOutput out) throws IOException {

    if (length == 1) {

      out.writeVInt(values[0]);

    } else {

      StoredFieldsInts.writeInts(values, 0, length, out);

    }

  }



  private void writeHeader(

      int docBase,

      int numBufferedDocs,

      int[] numStoredFields,

      int[] lengths,

      boolean sliced,

      boolean dirtyChunk)

      throws IOException {

    final int slicedBit = sliced ? 1 : 0;

    final int dirtyBit = dirtyChunk ? 2 : 0;

    // save docBase and numBufferedDocs

    fieldsStream.writeVInt(docBase);

    fieldsStream.writeVInt((numBufferedDocs << 2) | dirtyBit | slicedBit);



    // save numStoredFields

    saveInts(numStoredFields, numBufferedDocs, fieldsStream);



    // save lengths

    saveInts(lengths, numBufferedDocs, fieldsStream);

  }

结束构建

结束构建的时候最重要的就是生成fdx索引文件。

  public void finish(int numDocs) throws IOException {

    if (numBufferedDocs > 0) { // 如果还有未处理的doc，强制生成一个chunk

      flush(true);

    } else {

      assert bufferedDocs.size() == 0;

    }

    if (docBase != numDocs) {

      throw new RuntimeException(

          "Wrote " + docBase + " docs, finish called with numDocs=" + numDocs);

    }

    // 构建fdx文件  

    indexWriter.finish(numDocs, fieldsStream.getFilePointer(), metaStream);

    // 记录一些元信息  

    metaStream.writeVLong(numChunks);

    metaStream.writeVLong(numDirtyChunks);

    metaStream.writeVLong(numDirtyDocs);

    CodecUtil.writeFooter(metaStream);

    CodecUtil.writeFooter(fieldsStream);

    assert bufferedDocs.size() == 0;

  }

}

浅谈

前几天有个朋友问我：Android中硬件加速那么好用，为啥没被普及？，嗯？其实我也想知道。。。

手机开发中最重要的两个点：

• 1.用户点击的流畅性


• 2.界面效果的展示

早期的Android系统这两个事件都是在主线程上执行，导致用户点击的时候，界面绘制停滞或者界面绘制的时候，用户点击半天不响应，体验性很差。

于是在4.0以后，以 “run fast, smooth, and responsively” 为核心目标对 UI 进行了优化，应用开启了硬件加速对UI进行绘制。

1.硬件加速

在之前文章中我们分析过，Android 屏幕的绘制流程分为两部分：

• 1.生产者:app侧将View渲染到一个buffer中，供SurfaceFlinger消费


• 2.消费者:SurfaceFlinger测将多个buffer合并后放入buffer中，供屏幕显示

其中 第二步一直都是在GPU中实现的，而我们所说的硬件加速就是第一步中的view渲染流程。

早期view的渲染是在主线程中进行的，而硬件加速则使用一个新的线程RenderThread以及硬件GPU进行渲染，

2.CPU / GPU结构对比

• CPU （Central Processing Unit）: 中央处理器，计算机设备核心器件，适用于一些复杂的计算。


• GPU （Graphic Processing Unit）: 图形处理器，通常所说“显卡”的核心部件就是GPU，主要用于处理图形运算。

CPU和GPU结构对比：

• 黄色代表控制器（Control）：用于协调控制整个CPU的运行，包括取指令等操作。


• 绿色的ALU（Arithmetic Logic Unit）：算数逻辑单元，主要用于进行数学，逻辑计算。


• 橙色的Cache和DRAM分别为缓存和RAM，用于存储信息。

1.结构上看：CPU的ALU较少，而了解过OpenGl的同学应该知道View的渲染过程中是有大量的浮点数计算的，而浮点数转换为整数计算，可能会消耗大量的ALU单元，这对于CPU是比较难接受的。

2.CPU是串行的，一个CPU同一时间只能做一件事情，（多线程其实也是将CPU时间片分割而已），而GPU内部使用的是几千个小的GPU内核，每个GPU内核处理单元都是并行的，
这就非常符合图形的渲染过程。

GPU是显卡的核心部分，在破解密码方面也非常出色，再知道为啥哪些挖矿的使用的是显卡而不是CPU了吧，一个道理。

硬件加速底层原理：

通过将计算机不擅长的图形计算指令使用特殊的api转换为GPU的专用指令，由GPU完成。这里可能是传统的OpenGL或其他开放语言。

3.OpenGL

Android端一般使用OpenGL ES来实现硬件加速。
这里简单介绍下OpenGL和OpenGL ES。

• OpenGL（Open Graphics Library）：开放式图形库，是用于渲染2D、3D矢量图形的跨语言、跨平台的应用程序编程接口（API）。这个接口由近350个不同的函数调用组成，
  用来绘制从简单的图形比特到复杂的三维景象。


• OpenGL ES(OpenGL for Embedded Systems):是 OpenGL 三维图形 API 的子集，针对手机、PDA和游戏主机等嵌入式设备而设计

如果一个设备支持GPU硬件加速渲染（有可能不支持，看GPU厂商是不是适配了OpenGL 等接口），
那么当Android应用程序调用Open GL接口来绘制UI时，Android应用程序的 UI 就是通过GPU进行渲染的。

4.Android图形系统整体架构

在介绍Android图像系统架构前，我们先来了解几个概念：如果把UI的绘制过程当成一幅画的制作过程：
那么：

• 
  

  1.画笔：

  
  
  
  
  • Skia：CPU用来绘制2D图形
  
  
  • Open GL /ES:GPU绘制2D和3D图形。
  
  
  
  


• 
  

  2.画纸：
  Surface：所有的绘制和渲染都是在这张画纸上进行，每个窗口都是一个DecorView的容器，同时每个窗口都关联一个Surface

  
  


• 
  

  3.画板：
  Graphic Buffer ：Graphic Buffer是谷歌在4.1以后针对双缓冲的jank问题提出的第三个缓冲，CPU/GPU渲染的内容都将写到这个buffer上。

  
  


• 
  

  4.合成
  SurfaceFlinger：将所有的Surface合并叠加后显示到一个buffer里面。

  
  

简单理解过程：我们使用画笔（Skia、Open GL ES）将内容画到画纸（Surface）中，这个过程可能使用OpenGl ES也可能使用Skia，
使用OpenGl ES表示使用了硬件加速绘制，使用Skia，表示使用的是纯软件绘制。

下面是Android 图形系统的整体架构：

• 
  

  Image Stream Producers：图像数据流生产者，图像或视频数据最终绘制到Surface中。

  
  


• 
  

  WindowManager ：前面一篇文章《WindowManager体系（上）》笔者说过,每个Surface都有一个Window和他一一对应，而WindowManager则用来管理窗口的各个方面：
  动画，位置，旋转，层序，生命周期等。

  
  


• 
  

  SurfaceFlinger：用来对渲染后的Surface进行合并，并传递给硬件抽象层处理。

  
  


• 
  

  HWC ： Hardware Composer，SurfaceFlinger 会委派一些合成的工作给 Hardware Composer 以此减轻 GPU 的负载。这样会比单纯通过 GPU 来合成消耗更少的电量。

  
  


• 
  

  Gralloc（Graphics memory allocator）：前面讲解的Graphic Buffer分配的内存。

  
  

5.软硬件绘制过程源码解析

前面讲解了那么多理论知识，下面从源码角度来分析下硬件加速和软件绘制过程。
“read the fking source”

在前面文章《》中分析过。View最终是在ViewRootImpl的performDraw方法最新渲染的，
而performDraw内部调用的是draw方法。
定位到draw方法：

private void draw(boolean fullRedrawNeeded) {

    ...

    if (!dirty.isEmpty() || mIsAnimating || accessibilityFocusDirty) {

        if (mAttachInfo.mThreadedRenderer != null && mAttachInfo.mThreadedRenderer.isEnabled()) {//1

            ...

            mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this);//2

    }else {

            if (!drawSoftware(surface, mAttachInfo, xOffset, yOffset, scalingRequired, dirty)) {//3

                    return;

            }

        }

    }



}

注释1：如果mThreadedRenderer不为null且isEnabled为true，则调用注释2处的mThreadedRenderer.draw，这个就是硬件绘制的入口

如果其他情况，则调用注释3处的drawSoftware，这里就是软件绘制的入口，再正式对软硬件绘制进行深入之前我们看下mAttachInfo.mThreadedRenderer是在哪里赋值的?

源码全局搜索下：我们发现ViewRootImpl的enableHardwareAcceleration方法中有创建mThreadedRenderer的操作。

private void enableHardwareAcceleration(WindowManager.LayoutParams attrs) {

            // Try to enable hardware acceleration if requested

    ...

    final boolean hardwareAccelerated =

                    (attrs.flags & WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED) != 0;

    //这里如果attrs.flags设置了WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED，则表示该Window支持硬件加速绘制

    if (hardwareAccelerated) {



            // Persistent processes (including the system) should not do

            // accelerated rendering on low-end devices.  In that case,

            // sRendererDisabled will be set.  In addition, the system process

            // itself should never do accelerated rendering.  In that case, both

            // sRendererDisabled and sSystemRendererDisabled are set.  When

            // sSystemRendererDisabled is set, PRIVATE_FLAG_FORCE_HARDWARE_ACCELERATED

            // can be used by code on the system process to escape that and enable

            // HW accelerated drawing.  (This is basically for the lock screen.)



            //Persistent的应用进程以及系统进程不能使用硬件加速

            final boolean fakeHwAccelerated = (attrs.privateFlags &

                            WindowManager.LayoutParams.PRIVATE_FLAG_FAKE_HARDWARE_ACCELERATED) != 0;

            final boolean forceHwAccelerated = (attrs.privateFlags &

                            WindowManager.LayoutParams.PRIVATE_FLAG_FORCE_HARDWARE_ACCELERATED) != 0;



            if (fakeHwAccelerated) {



                    mAttachInfo.mHardwareAccelerationRequested = true;

            } else if (!ThreadedRenderer.sRendererDisabled

                            || (ThreadedRenderer.sSystemRendererDisabled && forceHwAccelerated)) {

                    if (mAttachInfo.mThreadedRenderer != null) {

                            mAttachInfo.mThreadedRenderer.destroy();

                    }

                    ...

                    //这里创建了mAttachInfo.mThreadedRenderer

                    mAttachInfo.mThreadedRenderer = ThreadedRenderer.create(mContext, translucent,

                                    attrs.getTitle().toString());

                    if (mAttachInfo.mThreadedRenderer != null) {

                            mAttachInfo.mHardwareAccelerated =

                                            mAttachInfo.mHardwareAccelerationRequested = true;

                    }

            }

    }

}

这里源码告诉我们：

• 1.硬件加速是通过attrs.flags 设置WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED标识来启动的、


• 2、因为硬件加速是一个耗内存的操作，只是硬件加速渲染环境初始化这一操作，就要花掉8M的内存，
  所以一般永久性的进程或者系统进程不要使用硬件加速标志，防止出现内存泄露。

再看哪里调用enableHardwareAcceleration方法?
通过源码查找我们注意到ViewRootImpl的setView方法中：

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {

	//注释1

	if (view instanceof RootViewSurfaceTaker) {

		mSurfaceHolderCallback =

				((RootViewSurfaceTaker)view).willYouTakeTheSurface();

		if (mSurfaceHolderCallback != null) {

			mSurfaceHolder = new TakenSurfaceHolder();

			mSurfaceHolder.setFormat(PixelFormat.UNKNOWN);

			mSurfaceHolder.addCallback(mSurfaceHolderCallback);

		}

	}



	...



	// If the application owns the surface, don't enable hardware acceleration

	if (mSurfaceHolder == null) {//注释2

		enableHardwareAcceleration(attrs);

	}



}

注释1处：表示当前view实现了RootViewSurfaceTaker接口，且view的willYouTakeTheSurface返回的mSurfaceHolderCallback不为null，
则表示应用想自己接管所有的渲染操作，这样创建出来的Activity窗口就类似于一个SurfaceView一样，完全由应用程序自己来控制它的渲染

基本上我们是不会将一个Activity窗口当作一个SurfaceView来使用的，
因此在ViewRootImpl类的成员变量mSurfaceHolder将保持为null值，
这样就会导致ViewRootImpl类的成员函数enableHardwareAcceleration被调用为判断是否需要为当前创建的Activity窗口启用硬件加速渲染。

好了我们回到ViewRootImpl的draw方法：

1.先来看软件绘制

软件绘制调用的是drawSoftware方法。
进入

private boolean drawSoftware(Surface surface, AttachInfo attachInfo, int xoff, int yoff,

            boolean scalingRequired, Rect dirty) {

	...

	canvas = mSurface.lockCanvas(dirty);//1

	

	mView.draw(canvas);//2

	

	surface.unlockCanvasAndPost(canvas);//3



}

软件绘制基本就分三步走：

• 步骤1：lockCanvas：每个Window都关联了一个Surface，当有需要绘制UI时，就调用lockCanvas获取一个Canvas对象，这个Canvas封装了Skia提供的2D图形绘制api、

并且向SurfaceFlinger Dequeue了一块Graphic buffer，绘制的内容都会输出到这个buffer中，供SurfaceFlinger合成使用。

• 
  

  步骤2：draw：调用了View的draw方法，这个就会调用到我们自定义组件中View的onDraw方法，传入1中创建的Canvas对象，使用Skia api对图像进行绘制。

  
  


• 
  

  步骤3：unlockCanvasAndPost：绘制完成后，通知SurfaceFlinger绘制完成，可以进行buffer的交换，显示到屏幕上了，本质是给SurfaceFlinger queue 一个Graphic buffer、
  关于什么是Queue和Dequeue看下图：

  
  

软件绘制条形简图：

2.硬件加速分析：

硬件加速分为两个步骤：

• 1.构建阶段


• 2.绘制阶段

构建阶段：

这个阶段用于遍历所有的视图，将需要绘制的Canvas API调用及其参数记录下来，保存在一个Display List，这个阶段发生在CPU主线程上。

Display List本质上是一个缓存区，它里面记录了即将要执行的绘制命令序列，这些命令最终会在绘制阶段被OpenGL转换为GPU渲染指令。

视图构建阶段会将每个View抽象为一个RenderNode，每个View的绘制操作抽象为一系列的DrawOp，
比如：
View的drawLine操作会被抽象为一个DrawLineOp，drawBitmap操作会被抽象成DrawBitmapOp，每个子View的绘制被抽象成DrawRenderNodeOp，每个DrawOp都有对应的OpenGL绘制指令，同时内部也握有需要绘制的数据元。

使用Display List的好处：

• 1、在绘制窗口的下一帧时，如果某个视图UI没有发生变化，则不需要执行与他相关的Canvas API操作，即不用重复执行View的onDraw操作，
  而是直接使用上一帧的Display List即可


• 2.如果绘制窗口下一帧时，视图发生了变化，但是只是一些简单属性变化，如位置和透明度等，则只需要修改上次构建的Display List的相关属性即可，也不必重复构建

Display List模型图：

接下来我们从源码角度来看下：

前面我们分析了硬件加速入口是在ThreadedRenderer的draw方法：

mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this)

进入这个方法看看：
ThreadedRenderer.java

void draw(View view, AttachInfo attachInfo, DrawCallbacks callbacks) {

	...

	updateRootDisplayList(view, callbacks);//1

	...

	int syncResult = nSyncAndDrawFrame(mNativeProxy, frameInfo, frameInfo.length);//2通知RenderThread线程绘制

}

ThreadedRenderer主要作用就是在主线程CPU中视图的构建，然后通知RenderThread使用OpenGL进行视图的渲染（注释2处）。

注释1处：updateRootDisplayList看名称应该就是用于视图构建，进去看看

private void updateRootDisplayList(View view, HardwareDrawCallbacks callbacks) {

	//1.构建参数view(DecorView)视图的Display List

	updateViewTreeDisplayList(view);

	

	//2

	//mRootNodeNeedsUpdate true表示需要更新视图

	//mRootNode.isValid()  表示已经构建了Display List

	if (mRootNodeNeedsUpdate || !mRootNode.isValid()) {

		//获取DisplayListCanvas

		DisplayListCanvas canvas = mRootNode.start(mSurfaceWidth, mSurfaceHeight);//3

		try {

			//ReorderBarrie表示会按照Z轴坐标值重新排列子View的渲染顺序

			canvas.insertReorderBarrier();

			//构建并缓存所有的DrawOp

			canvas.drawRenderNode(view.updateDisplayListIfDirty());

			canvas.insertInorderBarrier();



			canvas.restoreToCount(saveCount);

		} finally {

			//将所有的DrawOp填充到根RootNode中，作为新的Display List

			mRootNode.end(canvas);

		}

	}

}

注释1：updateViewTreeDisplayList对View树Display List进行构建

private void updateViewTreeDisplayList(View view) {

	view.mPrivateFlags |= View.PFLAG_DRAWN;

	view.mRecreateDisplayList = (view.mPrivateFlags & View.PFLAG_INVALIDATED)

			== View.PFLAG_INVALIDATED;

	view.mPrivateFlags &= ~View.PFLAG_INVALIDATED;

	view.updateDisplayListIfDirty();

	view.mRecreateDisplayList = false;

}

看View的updateDisplayListIfDirty方法。

/**

 * Gets the RenderNode for the view, and updates its DisplayList (if needed and supported)

 * @hide

 */

@NonNull

public RenderNode updateDisplayListIfDirty() {

	//获取当前mRenderNode

	final RenderNode renderNode = mRenderNode;

	//2.判断是否需要进行重新构建

	if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0

                || !renderNode.isValid()

                || (mRecreateDisplayList)) {

				

		if (renderNode.isValid()

                    && !mRecreateDisplayList) {

			mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;

			mPrivateFlags &= ~PFLAG_DIRTY_MASK;

			//这里用于当前View是ViewGroup，且自身不需要重构，对其子View的DisplayList进行构建

			dispatchGetDisplayList();



			return renderNode; // no work needed

        }

		...

		final DisplayListCanvas canvas = renderNode.start(width, height);

		try {

			if (layerType == LAYER_TYPE_SOFTWARE) {

				//软件绘制

				buildDrawingCache(true);

				Bitmap cache = getDrawingCache(true);

				if (cache != null) {

					canvas.drawBitmap(cache, 0, 0, mLayerPaint);

				}

			} else {

				...

				if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {

					//View是ViewGroup，需要绘制子View

					dispatchDraw(canvas);

					...

				} else {

					draw(canvas);

				}

			}

		} finally {

			//将绘制好后的数据填充到renderNode中去

			renderNode.end(canvas);

			setDisplayListProperties(renderNode);

		}

	}

}

updateDisplayListIfDirty主要作用：

• 1.获取当前View的RenderNode。


• 2.如果需要或者支持则更新当前DisplayList

判断是否需要进行重新构建的条件如下：

• 1.mPrivateFlags 设置了 PFLAG_DRAWING_CACHE_VALID，表明当前缓存已经失效，需要重新构建


• 2.!renderNode.isValid()：表明当前Display List的数据不合法，需要重新构建


• 3.mRecreateDisplayList的值等于true，一些其他原因需要重新构建

mRenderNode在View的构造方法中初始化：

public View(Context context) {

	...

	mRenderNode = RenderNode.create(getClass().getName(), this);

}

构建过程如下：

• 1.使用renderNode.start获得一个与当前View关联的DisplayListCanvas。


• 2.使用draw(canvas)，将当前View以及子View绘制到当前DisplayListCanvas


• 3.使用renderNode.end(canvas)，将已经绘制在 DisplayListCanvas 的 Display List Data 填充到当前 View 关联的 Render Node 中

通过上面几个步骤就将View树对应的DisplayList构建好了。而且这个构建过程会递归构建子View的Display List

我们从绘制流程火焰图中也可以看到大概流程：

红色框中部分：是绘制的DecorView的时候，一直递归updateDisplayListIfDirty方法进行Display List的构建
其他颜色框部分是子View Display List的构建

绘制阶段

这个阶段会调用OpenGL接口将构建好视图进行绘制渲染，将渲染好的内容保存到Graphic buffer中，并提交给SurfaceFlinger。

回到ThreadedRenderer的draw方法：
ThreadedRenderer.java

void draw(View view, AttachInfo attachInfo, DrawCallbacks callbacks) {

    ...

    updateRootDisplayList(view, callbacks);//1

    ...

    int syncResult = nSyncAndDrawFrame(mNativeProxy, frameInfo, frameInfo.length);//2

}

在注释1中创建好视图对应的Display List后，在注释2处调用nSyncAndDrawFrame方法通知RenderThread线程进行绘制

nSyncAndDrawFrame是一个native方法，在讲解nSyncAndDrawFrame方法前我们先来看ThreadedRenderer构造函数中做了哪些事。

ThreadedRenderer(Context context, boolean translucent, String name) {

	//这个方法在native层创建RootRenderNode对象并返回对象的地址

	long rootNodePtr = nCreateRootRenderNode();

	mRootNode = RenderNode.adopt(rootNodePtr);

	mRootNode.setClipToBounds(false);

	//这个方法在native层创建一个RenderProxy

	mNativeProxy = nCreateProxy(translucent, rootNodePtr);

}

nCreateRootRenderNode和nCreateProxy方法在android_view_ThreadedRenderer.cpp中实现：

static jlong android_view_ThreadedRenderer_createRootRenderNode(JNIEnv* env, jobject clazz) {

    RootRenderNode* node = new RootRenderNode(env);

    node->incStrong(0);

    node->setName("RootRenderNode");

    return reinterpret_cast(node);

}

static jlong android_view_ThreadedRenderer_createProxy(JNIEnv* env, jobject clazz,

        jboolean translucent, jlong rootRenderNodePtr) {

    RootRenderNode* rootRenderNode = reinterpret_cast(rootRenderNodePtr);

    ContextFactoryImpl factory(rootRenderNode);

    return (jlong) new RenderProxy(translucent, rootRenderNode, &factory);

}

RenderProxy构造方法：

RenderProxy::RenderProxy(bool translucent, RenderNode* rootRenderNode, IContextFactory* contextFactory)

        : mRenderThread(RenderThread::getInstance())//1

        , mContext(nullptr) {

    ...

}

注意到mRenderThread使用的是RenderThread::getInstance()单例线程，也就说整个绘制过程只有一个RenderThread线程。

接着看RenderThread::getInstance()创建线程的方法：

RenderThread::RenderThread() : Thread(true)

	...

	Properties::load();

    mFrameCallbackTask = new DispatchFrameCallbacks(this);

    mLooper = new Looper(false);

    run("RenderThread");

}

居然也是使用的Looper，是不是和我们的主线程的消息机制一样呢？哈哈
调用run方法会执行RenderThread的threadLoop方法。

bool RenderThread::threadLoop() {

	...

    int timeoutMillis = -1;

    for (;;) {

        int result = mLooper->pollOnce(timeoutMillis);

		...

        nsecs_t nextWakeup;

        {

            ...

            while (RenderTask* task = nextTask(&nextWakeup)) {

                workQueue.push_back(task);

            }

            for (auto task : workQueue) {

                task->run();

                // task may have deleted itself, do not reference it again

            }

        }

        if (nextWakeup == LLONG_MAX) {

            timeoutMillis = -1;

        } else {

            nsecs_t timeoutNanos = nextWakeup - systemTime(SYSTEM_TIME_MONOTONIC);

            timeoutMillis = nanoseconds_to_milliseconds(timeoutNanos);

            if (timeoutMillis < 0) {

                timeoutMillis = 0;

            }

        }



        if (mPendingRegistrationFrameCallbacks.size() && !mFrameCallbackTaskPending) {

			...

            requestVsync();

        }



        if (!mFrameCallbackTaskPending && !mVsyncRequested && mFrameCallbacks.size()) {

            ...

            requestVsync();

        }

    }



    return false;

}

石锤了就是应用程序主线程的消息机制模型，

• 
  
  
  
  1. 空闲的时候，Render Thread就睡眠在成员变量mLooper指向的一个Looper对象的成员函数pollOnce中。
  
  
  
  


• 
  
  
  
  2. 当其它线程需要调度Render Thread，就会向它的任务队列增加一个任务，然后唤醒Render Thread进行处理。Render Thread通过成员函数nextTask获得需要处理的任务，并且调用它的成员函数run进行处理。
  
  
  
  

这里做个小结：
ThreadedRenderer构造方法中

• 1.初始化mRootNode指向native层的一个RootRenderNode


• 2.初始化mNativeProxy指向native层的RenderProxy


• 3.在native层创建RenderProxy时，同时也会创建RenderThread线程，这个线程机制和我们主线程消息机制一直，轮询等待获取绘制任务。

好了回头看nSyncAndDrawFrame的native方法

nSyncAndDrawFrame同样也在android_view_ThreadedRenderer.cpp中实现：

static int android_view_ThreadedRenderer_syncAndDrawFrame(JNIEnv* env, jobject clazz,

        jlong proxyPtr, jlongArray frameInfo, jint frameInfoSize) {

    LOG_ALWAYS_FATAL_IF(frameInfoSize != UI_THREAD_FRAME_INFO_SIZE,

            "Mismatched size expectations, given %d expected %d",

            frameInfoSize, UI_THREAD_FRAME_INFO_SIZE);

    RenderProxy* proxy = reinterpret_cast(proxyPtr);

    env->GetLongArrayRegion(frameInfo, 0, frameInfoSize, proxy->frameInfo());

    return proxy->syncAndDrawFrame();

}

这个方法返回值是proxy->syncAndDrawFrame()，进入RenderProxy的syncAndDrawFrame方法：

int RenderProxy::syncAndDrawFrame() {

    return mDrawFrameTask.drawFrame();

}

这里的 mDrawFrameTask.drawFrame其实就是向RenderThread的TaskQueue添加一个drawFrame渲染任务，通知RenderThread渲染UI视图。

如下图：

mDrawFrameTask是DrawFrameTask中的函数

int DrawFrameTask::drawFrame() {

	...

    postAndWait();



    return mSyncResult;

}



void DrawFrameTask::postAndWait() {

    AutoMutex _lock(mLock);

    mRenderThread->queue(this);

    mSignal.wait(mLock);//锁住等待锁释放

}



void RenderThread::queue(RenderTask* task) {

    AutoMutex _lock(mLock);

    mQueue.queue(task);

    if (mNextWakeup && task->mRunAt < mNextWakeup) {

        mNextWakeup = 0;

        mLooper->wake();

    }

}

看到这就知道了drawFrame其实就是往RenderThread线程的任务队列mQueue中按时间顺序加入一个绘制task，并调用mLooper->wake()唤醒RenderThread线程处理。

说到底还是主线程消息机制那套东西。

注意DrawFrameTask在postAndWait的mRenderThread->queue(this)中是将this传入任务队列，所以此任务就是this自己。后面执行绘制任务就使用到了OpenGL对构建好的DisplayList进行渲染。

经过上面的分析，整个硬件绘制流程就有个清晰模型了

点到为止，后面代码大家可以自行找到源码阅读。

绘制阶段这块可能比较复杂些，因为基本上都是native层的东西，有的消化下。

硬件加速和纯软件绘制对比

呈现模式分析工具

Android 4.1（API 级别 16）或更高版本的设备上，

执行以下步骤开启工具：

• 1.启动开发者选项；


• 2.在“监控”部分，找到“GPU呈现模式分析”（不同厂商命名有所区别）；


• 3.点击“GPU呈现模式分析”，弹出页面中，选择“在屏幕上显示为条形图”即可。

这时，GPU 呈现模式工具已经开启了，接下来，我们可以打开我们要测试的APP来进行观察测试了。

视觉呈现

GPU 渲染模式分析工具以图表（以颜色编码的直方图）的形式显示各个阶段及其相对时间。

Android 10 上显示的彩色部分：

注意点:

• 1.一个应用对应一个图形


• 2.沿水平轴的每个竖条代表一个帧，每个竖条的高度表示渲染该帧所花的时间（以毫秒为单位）。


• 3.中间绿色的线是16.6ms的分割线，高于绿色线表示出现了掉帧


• 4.通过加宽竖条降低透明度来反应比较耗时的帧


• 5.每个竖条都有与渲染管道中某个阶段对应的彩色区段。区段数因设备的 API 级别不同而异。

颜色块含义

Android 6.0 及更高版本的设备时分析器输出中某个竖条的每个区段含义：

4.0（API 级别 14）和 5.0（API 级别 21）之间的 Android 版本具有蓝色、紫色、红色和橙色区段。低于 4.0 的 Android 版本只有蓝色、红色和橙色区段。下表显示的是 Android 4.0 和 5.0 中的竖条区段。

GPU 呈现模式工具，很直观的为我们展示了 APP 运行时每一帧的耗时详情。我们只需要关注代表每一帧的柱状图的颜色详情，就可以分析出卡顿的原因了。

好了，现在来回答标题帧的内容，既然硬件优化这么好用，为啥没被普及？

理由如下：

• 1.稳定性，开启硬件加速后，有小概率出现画面崩溃，所以在一些视频播放器会给个开关让用户手动开关。


• 2.功耗：GPU的功耗远远大于CPU，所以使用场景比较少，一般在游戏端开启硬件加速辅助游戏运行。


• 3.内存消耗：使用OpenGL接口初始化就需要8M作用的内存。


• 4.兼容性：不兼容某些接口和api。

这就是所谓的双刃剑吧！用得好还好，用不好就鸽蛋了。。

前言

接下来我们来了解一下 Path 类的一些特性。Path 类用于描述绘制路径，可以实现绘制线段、曲线、自定义形状等功能。本篇我们介绍 Path 的一个描述类 PathMetric 的应用。通过本篇你会了解以下两方面的内容：

• PathMetric 类简介。


• PathMetric 的应用。

PathMetric 简介

PathMetric 是一个用于测量 Path 和抽取子路径（sub-paths） 的工具，通过 Path 类的 computeMetrics方法可以返回一组PathMetric 类。为什么是一组，而不是一个呢？这是因为 Path 可能包含多个不连续的子路径，比如通过 moveTo 可以重新开启新的一段路径。
通过 PathMetric 可以获取到 Path 的长度，路径是否闭合，以及某一段路径是否是 Path的子路径。PathMetrics 是一个迭代器，因此在不获取其中的 PathMetric 对象时，并不会实际进行 Path 的相关计算，这样可以提高效率。另外需要注意的是，通过 computeMetrics 方法计算得到的是一个当前Path 对象的快照，如果在之后更改了 Path 对象，并不会进行更新。
我们来看一下 PathMetric 的一些属性和方法。

• length：Path 对象其中一段（独立的）的长度；


• isClosed：判断 Path 对象是否闭合；


• contourIndex：当前对象在 PathMetrics 中的次序；


• getTangentForOffset：这个方法通过距离起点的长度的偏移量（即从0 到 length 中的某个位置）返回一个 Tangent 对象，通过这个对象可以获取到 Path 某一段路径途中的任意一点的位置以及角度。以下面的图形为例，从点（0, 0）到点（2, 2）的线段总长度为2.82，如果我们通过getTangentForOffset获取距离起始点1.41 的位置的Tangent 对象，就会得到该位置的坐标是(1, 1)，角度是45度（实际以弧度的方式计算）。

• extractPath：通过距离 Path 起点的开始距离和结束距离获取这段路劲的子路径，如下图所示。

PathMetric 应用

我们来通过 PathMetric 实现下面动图的效果。

这张图最开始绘制的是一条贝塞尔曲线，是通过 Path 自带的贝塞尔曲线绘制的，代码如下所示。

Path path = Path();

final curveHeight = 60.0;

final stepWidth = size.width / 4;

path.moveTo(0, size.height / 2);

path.quadraticBezierTo(size.width / 2 - stepWidth,

    size.height / 2 - curveHeight, size.width / 2, size.height / 2);

path.quadraticBezierTo(size.width / 2 + stepWidth,

    size.height / 2 + curveHeight, size.width, size.height / 2);

quadraticBezierTo这个方法就是从 Path 当前的终点到参数3，4（参数名为 x2，y2）绘制一条贝塞尔曲线，控制点为参数1，2（参数名为 x1，y1）。
动画过程中曲线上的红色圆点就是通过 PathMetric 得到的，动画对象 Animation 的值从0-1变化，我们通过这个值乘以曲线的长度就能得到getTangentForOffset方法所需的偏移量，然后就可以确定动画过程中绘制圆点的位置了，代码如下所示。

for (var pathMetric in metrics) {

    var tangent =

        pathMetric.getTangentForOffset(pathMetric.length * animationValue);

  

    paint.style = PaintingStyle.fill;

    canvas.drawCircle(tangent!.position, 4.0, paint);

}

接下来是动画过程中的我们看到红色曲线会逐步覆盖蓝色曲线，这就是用 extractPath获取子路径完成的，在动画过程，我们控制 extractPath的结束位置，就可以逐步完成原有曲线的覆盖了，实现代码只有两行，如下所示。

var subPath =

    pathMetric.extractPath(0.0, pathMetric.length * animationValue);

canvas.drawPath(subPath, paint);

最后是底下的填充，填充我们使用了渐变色，这个利用了之前我们讲过的Paint 对象的 shader 属性实现，具体可以参考之前的文章。填充其实就是一段闭合的 Path，只是在动画过程中控制右边绘制的边界就可以了，然后上面跟随曲线的部分还是基于子路径完成的。填充部分实现代码如下。

var fillPath = Path();

fillPath.moveTo(0, size.height);

fillPath.lineTo(0, size.height / 2);

fillPath.addPath(subPath, Offset(0, 0));

fillPath.lineTo(tangent.position.dx, size.height);

fillPath.lineTo(0, size.height);

paint.shader = LinearGradient(

  begin: Alignment.topCenter,

  end: Alignment.bottomCenter,

  colors: [Colors.red[400]!, Colors.blue[50]!],

).createShader(Rect.fromLTRB(

  0,

  size.height / 2 - curveHeight,

  size.width,

  size.height,

));

canvas.drawPath(fillPath, paint);

完整代码已经提交至：绘图相关代码，文件名为：path_metrics_demo.dart。

总结

本篇介绍了 Flutter 路径Path 的工具类 PathMetric的介绍和应用，通过 PathMetric 我们可以定位到 Path 的指定位长度的位置的信息，也可以通过起始点从 Path 中抽取子路径。有了这些基础，就可以实现很多场景的应用，比如曲线上布局标识或填充，标记指定位置的点等等。

Kotlin 拥有函数式编程的能力，运用得当，可以简化代码，层次清晰，利于阅读，用过都说好。

然而操作符数量众多，根据使用场景选择合适的操作符是一个很大的难题，网上搜索了许久只是学习了一个操作符，还要再去验证它，实在浪费时间，开发效率低下。

一种方式是转至命令式开发，将过程按步骤实现，即可完成需求；另一种方式便是一次学习多个操作符，在下次选择操作符时，增加更多选择。

本篇文章当然关注的是后者，列举一些比较常用 Kotlin 操作符，为提高效率助力，文中有图有代码有讲解，文末有参考资料和一个交互式学习的网站。

让我们开始吧。

1. reduce

reduce 操作符可以将所有数据累加（加减乘除）得到一个结果

listOf(1, 2, 3).reduce { a, b ->

    a + b

}



输出：6

如果 flow 中没有数据，将抛出异常。如不希望抛异常，可使用 reduceOrNull 方法。

reduce 操作符不能变换数据类型。比如，Int 集合的结果不能转换成 String 结果。

2. fold

fold 和 reduce 很类似，但是 fold 可以变换数据类型

有时候，我们不需要一个结果值，而是需要继续操 flow，可使用 runningFold 。

flowOf(1, 2, 3).runningFold("a") { a, b ->

    a + b

}.collect {

    println(it)

}



输出：

a

a1

a12

a123

同样的，reduce 也有类似的方法 runningReduce

flowOf(1, 2, 3).runningReduce { a, b ->

    a + b

}.collect {

    println(it)

}



输出：

1

3

6

3. debounce

debounce 需要传递一个毫秒值参数，功能是：只有达到指定时间后才发出数据，最后一个数据一定会发出。

例如，定义 1000 毫秒，也就是 1 秒，被观察者发出数据，1秒后，观察者收到数据，如果 1 秒内多次发出数据，则重置计算时间。

flow {

    emit(1)

    delay(590)

    emit(2)

    delay(590)

    emit(3)

    delay(1010)

    emit(4)

    delay(1010)

}.debounce(

    1000

).collect {

    println(it)

}



输出结果：

3

4

rebounce 的应用场景是限流功能

4. sample

sample 和 debounce 很像，功能是：在规定时间内，只发送一个数据

flow {

    repeat(4) {

        emit(it)

        delay(50)

    }

}.sample(100).collect {

    println(it)

}



输出结果：

1

3

sample 的应用场景是截流功能

debounce 和 sample 的限流和截流功能已有网友实现，点击这里

5. flatmapMerge

简单的说就是获得两个 flow 的乘积或全排列，合并并且平铺，发出一个 flow。

描述的仍然不好理解，一看代码便能理解了

flowOf(1, 3).flatMapMerge {

    flowOf("$it a", "$it b")

}.collect {

    println(it)

}



输出结果：

1 a

1 b

3 a

3 b

flatmapMerge 还有一个特性，在下一个操作符里提及。

6. flatmapConcat

先看代码。

flowOf(1, 3).flatMapConcat {

    flowOf("a", "b", "c")

}.collect {

    println(it)

}

功能和 flatmapMerge 一致，不同的是 flatmapMerge 可以设置并发量，可以理解为 flatmapMerge 是线程安全的，而 flatmapConcat 不是线程安全的。

本质上，在 flatmapMerge 的并发参数设置为 1 时，和 flatmapConcat 基本一致，而并发参数大于 1 时，采用 channel 的方式发出数据，具体内容请参阅源码。

7. buffer

介绍 buffer 的时候，先要看这样一段代码。

flowOf("A", "B", "C", "D")

.onEach {

    println("1 $it")

}

.collect { println("2 $it") }



输出结果：

1 A

2 A

1 B

2 B

1 C

2 C

1 D

2 D

注意输出的内容。

加上 buffer 的代码。

flowOf("A", "B", "C", "D")

.onEach {

    println("1 $it")

}

.buffer()

.collect { println("2 $it") }



输出结果：

1 A

1 B

1 C

1 D

2 A

2 B

2 C

2 D

输出内容有所不同，buffer 操作符可以改变收发顺序，像有一个容器作为缓冲似的，在容器满了或结束时，下游开始接到数据，onEach 添加延迟，效果更明显。

8. combine

合并两个 flow，长的一方会持续接受到短的一方的最后一个数据，直到结束

flowOf(1, 3).combine(

    flowOf("a", "b", "c")

) { a, b -> b + a }

.collect {

    println(it)

}



输出结果：

a1

b3

c3

9. zip

也是合并两个 flow，结果长度与短的 flow 一致，很像木桶原理。 

flowOf(1, 3).zip(

    flowOf("a", "b", "c")

) { a, b -> b + a }

.collect {

    println(it)

}



输出结果：

a1

b3

10. distinctUntilChanged

就像方法名写的那样，和前一个数据不同，才能收到，和前一个数据想通，会被过滤掉。

flowOf(1, 1, 2, 2, 3, 1).distinctUntilChanged().collect {

    println(it)

}



输出结果：

1

2

3

1

最后

以上就是今天要介绍的操作符，希望对大家有所帮助。

参考文章：Android — 9 Useful Kotlin Flow Operators You Need to Know

Kotlin 交互式操作符网站：交互式操作符网站

1 wait和 sleep 的区别

wait是Object的方法，wait是对象锁，锁定方法不让继续执行，当执行notify方法后就会继续执行，sleep 是Thread的方法，sleep 是使线程睡眠，让出cpu，结束后自动继续执行

2 View和SurfaceView的区别

View基于主线程刷新UI，SurfaceView子线程又可以刷新UI

3. View的绘制原理

View为所有图形控件的基类，View的绘制由3个函数完成
measure,计算视图的大小
layout,提供视图要显示的位置
draw,绘制

4. 简述TCP，UDP，Socket

TCP是经过3次握手，4次挥手完成一串数据的传送
UDP是无连接的，知道IP地址和端口号，向其发送数据即可，不管数据是否发送成功
Socket是一种不同计算机，实时连接，比如说传送文件，即时通讯

5.进程和线程的区别

概念：进程包括多个线程，一个程序一个进程，多线程的优点可以提高执行效率，提高资源利用率
创建：Thread类和Runnable接口，
常用方法有：
start()用于启动线程
run()调用线程对象中的run方法
join()合并插队到当前线程
sellp()睡眠释放cpu资源
setPriority()设置线程优先级

6.RecyclerView和ListView的区别

缓存上:前者缓存的是View+ViewHolder+flag，不用每次调用findViewById,后者则只是缓存View
刷新数据方面，前者提供了局部刷新，后者则全部刷新

7.MVC ，MVP，MVVM

MVC:View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些 业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于View，但是 View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
MVP：MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负 责显示。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。
MVVM：数据双向绑定，通过数据驱动UI，M提供数据，V视图，VM即数据驱动层

8.说下 Activity 跟 跟 window ， view 之间的关系？

Activity 创建时通过 attach()初始化了一个 Window 也就是PhoneWindow，一个 PhoneWindow 持有一个DecorView 的实例，DecorView 本身是一个 FrameLayout，继承于 View，Activty 通过setContentView 将xml 布局控件不断 addView()添加到 View 中，最终显示到 Window 于我们交互；

9.Java中堆和栈的理解

在Java中内存分为两种，一种是栈内存，另一种是堆内存

堆内存：用于存储Java中的对象和数组，当我们new一个对象或创建一个数组的时候，就会在堆内存中开辟一段空间给它，用于存放，堆内存的特点：先进先出，后今后出，②可以动态的分配内存的大小，生存期不必告诉编译器，但存取速度较慢；

栈内存：主要用来执行程序用，比如基本类型的变量和对象的引用变量，其特点：①先进后出，后进后出，②存取速度比堆快，仅次于寄存器，栈数据可以共享，但其在栈中的数据大小和生存期必须是确定的；

栈内存和堆内存都属于Java内存的一种，系统会自动去回收它，但对于堆内存开发人员一般会自动回收。

栈是一块和线程紧密相关的内存区域，每个线程都有自己的栈内存，用于存储本地变量、方法参数和栈调用一个线程中存储的变量，对于其他线程是不可见的，而堆是所有线程共享的一个公用内存区域，对象都在堆里创建，但为了提升效率，线程会从堆中拷贝一个缓存到自己的栈中，如果多个线程使用该变量，就可能引发问题，这是volatile修饰变量就可以发挥作用，他要求线程从主存中读取变量的值。

10.Android常用的数据存储方式（4种）

使用SharedPreference存储：保存基于xml文件存储的key-value键值对数据，通常用来存储一些简单的配置信息；

文件存储方式：Context提供了两个方法来打开数据文件的文件IO流；

SQLite存储数据：SQLite是轻量级的嵌入式数据库引擎，支持SQL语言；

网络存储数据：通过网络存储数据；

11.Activity生命周期中的7个方法：

onCreate( )：当Activity被创建时调用；

onStart( )：当Activity被创建后将可见时调用；

onResume( )：（继续开始）当Activity位于设备最前端，对用户可见时调用；

onPause( )：（暂停）当另一个Activity遮挡当前Activity，当前Activity被切换到后台时调用；

onRestart( )：（重新启动）当另一个Activity执行完onStop（）方法，又被用户打开时调用；

onStop( )：如果另一个Activity完全遮挡了当前Activity时，该方法被调用；

onDestory( )：当Activity被销毁时调用；

12.Activity的四种启动模式

standard、singleTop、singleTask和singleInstance，他们是在配置文件中通过android：LauchMode属性配置；

standard：默认的启动模式，每次启动会在任务栈中新建一个启动的Activity的实例；

SingleTop：如果要启动的Activity实例已位于栈顶，则不会重新创建该Activity的实例，否则会产生一个新的运行实例；

SingleTask：如果栈中有该Activity实例，则直接启动，中间的Activity实例将会被关闭，关闭的顺序与启动的顺序相同；

SingleInstance：该启动模式会在启动一个Activity时，启动一个新的任务栈，将该Activity实例放置在这个任务栈中，并且该任务栈中不会再保存其他的Activity实例；

Activity任务栈：即存放Activity任务的栈，每打开一个Activity时就会往Activity栈中压入一个Activity

任务，每当销毁一个Activity的时候，就会从Activity任务栈中弹出一个Activity任务，

由于安卓手机的限制，只能从手机屏幕获取当前一个Activity的焦点，即栈顶元素（

最上面的Activity)，其余的Activity会暂居后台等待系统的调用；

13.View的绘制原理

View为所有图形控件的基类，View的绘制由3个函数完成
measure,计算视图的大小
layout,提供视图要显示的位置
draw,绘制

14.Okhttp连接池复用机制

15. Rxjava里面有几个角色

Observable：俗称被订阅者，被订阅者是事件的来源，接收订阅者(Observer)的订阅，然后通过发射器(Emitter)发射数据给订阅者。

Observer：俗称订阅者，注册过程传给被订阅者，订阅者监听开始订阅，监听订阅过程中会把Disposable传给订阅者，然后在被订阅者中的发射器(Emitter)发射数据给订阅者(Observer)。

Emitter：俗称发射器，在发射器中会接收下游的订阅者(Observer)，然后在发射器相应的方法把数据传给订阅者(Observer)。

Consumer：俗称消费器，消费器其实是Observer的一种变体，Observer的每一个方法都会对应一个Consumer，比如Observer的onNext、onError、onComplete、onSubscribe都会对应一个Consumer。

Disposable：是释放器，通常有两种方式会返回Disposable，一个是在Observer的onSubscribe方法回调回来，第二个是在subscribe订阅方法传consumer的时候会返回

16.RxJava操作符包含的操作符类型有如下几种：

1、创建操作符 ：创建被观察者（Observable）对象&发送事件

2、转换操作符：变换被观察者(Observable)发送的事件。将Observable发送的数据按照一定的规则做一些变换，然后再将变换的数据发射出去。变换的操作符有map,flatMap，concatMap,switchMap,buffer,groupBy等等。

3、 合并操作符：组合多个被观察者(Observable)&合并需要发送的事件。包含：concatMap(),concat(), merge(),mergeArray(),concateArray(),reduce(),collect(),startWith(),zip(),count()等

4、功能操作符：辅助被观察者(Observable) 发送事件时实现一些功能性需求，如错误处理，线程调度。
5、过滤操作符：用于将Observable发送的数据进行过滤和选择。让Observable返回我们所需要的数据。过滤操作符有buffer()，filter()，skip()，take()，skipLast()，takeLast()，throttleFirst()，distainctUntilChange()。