涂鸦框架的优化——解决绘制时的卡顿问题,纵享丝滑

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u012964944/article/details/89211683

前言

喜大普奔,涂鸦框架Doodle迎来重大更新!

V5.5: 增加优化绘制的选项,可优化绘制速度和性能,纵享丝滑。

boolean optimizeDrawing = true; // 是否优化绘制,建议开启,可优化绘制速度和性能.
DoodleView mDoodleView = new DoodleView(this, bitmap, optimizeDrawing, doodleListener);

真是太不容易了!

其实在很早之前,笔者就已经感受到涂鸦时的卡顿,特别是随着涂鸦越多卡顿越明显,奈何当时心有余而力不足,一直找不到最佳的解决方法。直到最近灵感爆发,终于解决之,纵享丝滑!

问题的初步解决

当涂鸦越来越多时,操作时的卡顿越明显,同时也导致涂鸦的轨迹不够圆滑。初步分析是因为DoodleView每次刷新绘制都会把所有的涂鸦都绘制一遍,因此涂鸦越多,绘制越耗时。

private void doDraw(Canvas canvas) {
  ...
    for (IDoodleItem item : mItemStack) { // 耗时:绘制所有涂鸦
        ...
        item.draw(canvas); 
        ...
    }
}

借助Android Studio的Profiler工具查看cpu的主要耗时在绘制方法里:

其实除了当前正在操作的涂鸦需要重新绘制之外,其他涂鸦都是没有变化,并不需要重绘。那么怎么做到只绘制需要重绘的部分呢?

通过研究微信的图片编辑,发现当前正在操作的涂鸦绘制在View画布中,而当涂鸦绘制完成时把涂鸦合并到图片上,即涂鸦被绘制到了图片上,后续都是直接绘制这张新的图片。所以每次刷新View都只绘制图片和当前正在操作的涂鸦。(而涂鸦框架Doodle之前都是绘制图片和所有的涂鸦)

这可以通过对比绘制前后的效果看出来:

左边是正在绘制时(即手指在屏幕中滑动)的效果,线条圆滑,因为View画布的分辨率相当于屏幕分辨率,所以绘制出来的线条也清晰。而右边是绘制结束时(即手指抬起后)的效果,线条边缘出现锯齿,因为图片的分辨率较低,因此绘制在图片上的线条较模糊。

于是,笔者参照这个思路优化绘制,果然最终的效果很明显,再也不会随着涂鸦的增多而变得越来越卡,由于每次刷新基本上只绘制图片和当前正在操作的需要重绘的涂鸦,所以耗时基本稳定,不会递增。

那么问题是不是完美解决了呢!?

——没有!

进一步的优化

笔者再次对比了微信涂鸦,发现微信涂鸦的在绘制曲线时特别圆滑,而涂鸦框架Doodle却缺少这般丝滑,

左边是微信涂鸦快速滑动绘制出的圆,而右边则是初步优化后涂鸦框架Doodle绘制的圆。作为追求完美的人,这方面我们不能输给人家,必须解决!

我们再次借助万能的Profiler查找问题:

原来主要耗时drawBitmap上面!

其实图片没有变化并不需要重绘,我们可不可以不绘制图片,而只绘制当前正在操作的涂鸦呢?当然可以!

首先这里要强调的是,”不需要重绘“的意思是View刷新时不会触发onDraw()方法,进而触发drawBitmap逻辑,但图片还是会显示在View中。这里涉及到Android系统中绘制机制中的硬件加速。当我们有多个view时,调用其中一个View的invalidate()表示该view需要刷新,会触发onDraw方法,但其他的View并不会被重绘(即不会触发相应的onDraw()逻辑)。这一点可从View的源码得知,大家可稍微了解下:

// View.java
/**
 * This method is called by ViewGroup.drawChild() to have each child view draw itself.
 *
 * This is where the View specializes rendering behavior based on layer type,
 * and hardware acceleration.
 */
boolean draw(Canvas canvas, ViewGroup parent, long drawingTime) {
  final boolean hardwareAcceleratedCanvas = canvas.isHardwareAccelerated();
    /* If an attached view draws to a HW canvas, it may use its RenderNode + DisplayList.
     */
    boolean drawingWithRenderNode = mAttachInfo != null
            && mAttachInfo.mHardwareAccelerated
            && hardwareAcceleratedCanvas;
    ...
    if (drawingWithRenderNode) { //支持硬件加速
        renderNode = updateDisplayListIfDirty(); // 更新需要重绘的列表
        ...
    }
    ...
    }
}

 /**
     * Gets the RenderNode for the view, and updates its DisplayList (if needed and supported)
     */
    @NonNull
    public RenderNode updateDisplayListIfDirty() {
        ...
        if (renderNode.isValid()
                && !mRecreateDisplayList) { // 当前view不需要重绘
            mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;
            mPrivateFlags &= ~PFLAG_DIRTY_MASK;
            dispatchGetDisplayList(); // 检查下层的子view是否需要重绘,并更新

            return renderNode; // no work needed
        }
        // 不支持硬件加速,会触发`draw()->onDraw()`逻辑
        ...
}

既然如此,我们需要重新设计DoodleView的结构,使其作为一个容器组件(ViewGroup),包含两个子View,分别用于绘制背景图片和当前正在操作的涂鸦。

这样,如果仅仅调用ForegroundView实例的invalidate()方法,只会重绘ForegroundView,耗时仅在这里。相反,如果BackgroundView发生变化需要重绘,则需要调用其invalidate()方法.

OK!大功告成,纵向丝滑吧!

后话

注意:开启后涂鸦item被选中编辑时时会绘制在最上面一层,直到结束编辑后才绘制在相应层级。

代码是需要不断优化和重构的,也许今天以为很好的实现,到了明天就会被更好的方案替代,这需要我们不断地实践和验证,加油吧!

最后请大家多多支持涂鸦框架>>>>开源项目Doodle!一个功能强大,可自定义和可扩展的涂鸦框架

没有更多推荐了,返回首页