<h2>前言</h2>    <p>我们所熟知的，Android 的图形绘制主要是基于 View 这个类实现。 每个 View 的绘制都需要经过 onMeasure、onLayout、onDraw 三步曲，分别对应到测量大小、布局、绘制。</p>    <p>Android 系统为了简化线程开发，降低应用开发的难度，将这三个过程都放在应用的主线程(UI 线程)中执行，以保证绘制系统的线程安全。</p>    <p>这三个过程通过一个叫 Choreographer 的定时器来驱动调用更新， Choreographer 每16ms被 vsync 这个信号唤醒调用一次，这有点类似早期的电视机刷新的机制。在 Choreographer 的 doFrame 方法中，通过树状结构存储的 ViewGroup，依次递归的调用到每个 View 的 onMeasure、onLayout、onDraw 方法，从而最后将每个 View 都绘制出来（当然最后还会经过 SurfaceFlinger 的类来将 View 合成起来显示，实际过程很复杂）。</p>    <p>同时每个 View 都保存了很多标记值 flag，用来判断是否该 View 需要重新被 Measure、Layout、Draw。 这样对于那些没有变化，不需要重绘的 View，则不再调用它们的方法，从而能够提高绘制效率。</p>    <p>Android 为了方便开发者进行动画开发，提供了好几种动画实现的方式。 其中比较常用的是属性动画类(ObjectAnimator)，它通过定时以一定的曲线速率来改变 View 的一系列属性，最后产生 View 的动画的效果。比较常见的属性动画能够动态的改变 View 的大小、颜色、透明度、位置等值，此种方式实现的效率比较高，也是官方推荐的动画形式。</p>    <p>为了进一步的提升动画的效率，防止每次都需要多次调用 onMeasure、onLayout、onDraw，重新绘制 View 本身。 Android 还提出了一个层 Layer 的概念。</p>    <p>通过将 View 保存在图层中，对于平移、旋转、伸缩等动画，只需要对该层进行整体变化，而不再需要重新绘制 View 本身。 层 Layer 又分为软绘层（Software Layer）和硬绘层（Harderware Layer） 。它们可以通过 View 类的 setLayerType(layerType, paint);方法进行设置。软绘层将 View 存储成 bitmap，它会占用普通内存；而硬绘层则将 View 存储成纹理（Texture），占用 GPU 中的存储。 需要注意的是，由于将 View 保存在图层中，都会占用相应的内存，因此在动画结束之后需要重新设置成LAYER_ TYPE_ NONE，释放内存。</p>    <p>由于普通的 View 都处于主线程中，Android 除了绘制之外，在主线程中还需要处理用户的各种点击事件。很多情况，在主线程中还需要运行额外的用户处理逻辑、轮询消息事件等。 如果主线程过于繁忙，不能及时的处理和响应用户的输入，会让用户的体验急剧降低。如果更严重的情况，当主线程延迟时间达到5s的时候，还会触发 ANR（Application Not Responding）。 这样当界面的绘制和动画比较复杂，计算量比较大的情况，就不再适合使用 View 这种方式来绘制了。</p>    <p>Android 考虑到这种场景，提出了 SurfaceView 的机制。SurfaceView 能够在非 UI 线程中进行图形绘制，释放了 UI 线程的压力。SurfaceView 的使用方法一般是复写一下三种方法：</p>    <pre>  <code class="language-java">public void surfaceCreated(SurfaceHolder holder);         public void surfaceChanged(SurfaceHolder holder, int format, int width,                                    int height);         public void surfaceDestroyed(SurfaceHolder holder);</code></pre>    <p>surfaceCreated 在 SurfaceView 被创建的时候调用， 一般在该方法中创建绘制线程，并启动这个线程。</p>    <p>surfaceDestroyed 在 SurfaceView 被销毁的时候调用，在该方法中设置标记位，让绘制线程停止运行。</p>    <p>绘制子线程中，一般是一个 while 循环，通过判断标记位来决定是否退出该子线程。 使用 sleep 函数来定时的调起绘制逻辑。 通过 mHolder.lockCanvas()来获得 canvas，绘制完毕之后调用 mHolder.unlockCanvasAndPost(canvas);来上屏。 这里特别要注意绘制线程和 surfaceDestroyed 中需要加锁。否则会有 SurfaceView 被销毁了，但是绘制子线程中还是持有对 Canvas 的引用，而导致 crash。下面是一个常用的框架：</p>    <pre>  <code class="language-java">private final Object mSurfaceLock = new Object();      private DrawThread mThread;      @Override      public void surfaceCreated(SurfaceHolder holder) {          mThread = new DrawThread(holder);          mThread.setRun(true);            mThread.start();      }            @Override      public void surfaceChanged(SurfaceHolder holder, int format, int width,                                 int height) {          //这里可以获取SurfaceView的宽高等信息      }        @Override      public void surfaceDestroyed(SurfaceHolder holder) {          synchronized (mSurfaceLock) {  //这里需要加锁，否则doDraw中有可能会crash              mThread.setRun(false);          }      }        private class DrawThread extends Thread {          private SurfaceHolder mHolder;          private boolean mIsRun = false;            public DrawThread(SurfaceHolder holder) {              super(TAG);              mHolder = holder;          }          @Override          public void run() {              while(true) {                  synchronized (mSurfaceLock) {                      if (!mIsRun) {                          return;                      }                      Canvas canvas = mHolder.lockCanvas();                      if (canvas != null) {                          doDraw(canvas);  //这里做真正绘制的事情                          mHolder.unlockCanvasAndPost(canvas);                      }                  }                   Thread.sleeep(SLEEP_TIME););              }          }            public void setRun(boolean isRun) {              this.mIsRun = isRun;          }      }</code></pre>    <p>Android 为绘制图形提供了 Canvas 类，可以理解这个类是一块画布，它提供了在画布上画不同图形的方法。它提供了一系列的绘制各种图形的 API， 比如绘制矩形、圆形、椭圆等。对应的 API 都是 drawXXX的形式。</p>    <p>不规则的图形的绘制比较特殊，它同于规则图形已有绘制公式的情况，它有可能是任意的线条组成。Canvas 为画不规则形状，提供了 Path 这个类。通过 Path 能够记录各种轨迹，它可以是点、线、各种形状的组合。通过 drawPath 这个方法即可绘制出任意图形。</p>    <p>有了画布 Canvas 类，提供了绘制各种图形的工具之后，还需要指定画笔的颜色，样式等属性，才能有效的绘图。Android 提供了 Paint 这个类，来抽象画笔。 通过 Paint 可以指定绘制的颜色，是否填充，如果处理交集等属性。</p>    <h2>动画实现</h2>    <p>既然是实战，当然要有一个例子啦。 这里以 TOS 里面的录音机的波形动效实现为例。 首先看一下设计狮童鞋给的视觉设计图：</p>    <p><img src="https://simg.open-open.com/show/6b485f372138fb87cb070551b7619240.png"></p>    <p>下面是动起来的效果图：</p>    <p><img src="https://simg.open-open.com/show/43bec419402edf4f37d2e463cf060c4d.gif"></p>    <p>看到这么高大上的动效图，不得不赞叹一下设计狮童鞋，但同时也深深的捏了把汗——这个动画要咋实现捏。</p>    <p>粗略的看一下上面的视觉图。 感觉像是多个正弦曲线组成。 每条正弦线好像中间高，两边低，应该有一个对称的衰减系数。 同时有两组上下对称的正弦线，在对称的正弦线中间采用渐变颜色来进行填充。然后看动效的效果图，好像这个不规则的正弦曲线有一个固定的速率向前在运动。</p>    <p>看来为了实现这个动效图，还得把都已经还给老师的那点可怜的数学知识捡起来。下面是正弦曲线的公式：</p>    <p>y=Asin（ωx+φ）+k</p>    <p>A 代表的是振幅，对应的波峰和波谷的高度，即 y 轴上的距离；ω 是角速度，换成频率是 2πf，能够控制波形的宽度；φ 是初始相位，能够决定正弦曲线的初始 x 轴位置；k 是偏距，能够控制在 y 轴上的偏移量</p>    <p>为了能够更加直观，将公式图形化的显示出来，这里强烈推荐一个网站： <a href="/misc/goto?guid=4959636049748159383" rel="nofollow,noindex">https://www.desmos.com/calculator</a> , 它能将输入的公式转换成坐标图。这正是我们需要的。比如 sin(0.75πx - 0.5π) 对应的图形是下图：</p>    <p><img src="https://simg.open-open.com/show/63acdcfd8db817c280605546b9b90620.png"></p>    <p>与上面设计图中的相比，还需要乘上一个对称的衰减函数。 我们挑选了如下的衰减函数425/(4+x4)：</p>    <p><img src="https://simg.open-open.com/show/577465db4b7d078060f65d9bb91ec407.png"></p>    <p>将sin(0.75πx - 0.5π) 乘以这个衰减函数 425/(4+x4)，然后乘以0.5。 最后得出了下图：</p>    <p><img src="https://simg.open-open.com/show/6b19091638af96676e9f85f351021f6f.png"></p>    <p>看起来这个曲线与视觉图中的曲线已经很像了，无非就是多加几个算法类似，但是相位不同的曲线罢了。 如下图：</p>    <p><img src="https://simg.open-open.com/show/81e8f2c446e533a3dacbd7bdd5d800ca.png"></p>    <p>看看，用了我们足（quan）够(bu)强(wang)大(ji)的数学知识之后， 我们好像也创造出来了类似视觉稿中的波形了。</p>    <p>接下来，我们只需要在 SurfaceView 中使用 Path，通过上面的公式计算出一个个的点，然后画直线连接起来就行啦！ 于是我们得出了下面的实际效果（为了方便显示，已将背景调成白色）：</p>    <p><img src="https://simg.open-open.com/show/2f56fcc695041847adf80cdea61f10dc.jpg"></p>    <p>曲线画出来了，然后要做的就是渐变色的填充了。 这也是视觉还原比较难实现的地方。</p>    <p>对于渐变填充，Android 提供了 LinearGradient 这个类。它需要提供起始点和终结点的坐标，以及起始点和终结点的颜色值：</p>    <pre>  <code class="language-java">public LinearGradient(float x0, float y0, float x1, float y1, int color0, int color1,                   TileMode tile);</code></pre>    <p>TileMode 包括了 CLAMP、REPEAT、MIRROR 三种模式。 它指定了，如果填充的区域超过了起始点和终结点的距离，颜色重复的模式。CLAMP 指使用终点边缘的颜色，REPEAT 指重复的渐变，而MIRROR则指的是镜像重复。</p>    <p>从 LinearGradient 的构造函数就可以预知，渐变填充的时候，一定要指定精确的起始点和终结点。否则如果渐变距离大于填充区域，会出现渐变不完整，而渐变距离小于填充区域则会出现多个渐变或填不满的情况。如下图所示：</p>    <p><img src="https://simg.open-open.com/show/252291f41a7cc0b124d0ee99fdb2a439.jpg"></p>    <p>图中左边是精确设置渐变起点和终点为矩形的顶部和底部； 图中中间为设置的渐变起点为顶部，终点为矩形的中间； 右边的则设置的渐变起点和终点都大于矩形的顶部和底部。代码如下：</p>    <pre>  <code class="language-java">LinearGradient gradient = new LinearGradient(100, mHeight_2 - 200, 100, mHeight_2 + 200,              line_1_start_color, region_1_end_color, Shader.TileMode.REPEAT);      mPaint.setShader(gradient);      mPaint.setStyle(Paint.Style.FILL);      canvas.drawRect(100, mHeight_2 - 200, 300, mHeight_2 + 200, mPaint);            gradient = new LinearGradient(400, mHeight_2 - 200, 400, mHeight_2,               line_1_start_color, region_1_end_color, Shader.TileMode.REPEAT);      mPaint.setShader(gradient);      mPaint.setStyle(Paint.Style.FILL);      canvas.drawRect(400, mHeight_2 - 200, 600, mHeight_2 + 200, mPaint);            gradient = new LinearGradient(700, mHeight_2 - 400, 700, mHeight_2 + 400,              line_1_start_color, region_1_end_color, Shader.TileMode.REPEAT);      mPaint.setShader(gradient);      mPaint.setStyle(Paint.Style.FILL);      canvas.drawRect(700, mHeight_2 - 200, 900, mHeight_2 + 200, mPaint);</code></pre>    <p>对于矩形这种规则图形进行渐变填充，能够很容易设置渐变颜色的起点和终点。 但是对于上图中的正弦曲线如果做到呢？ 难道需要将一组正弦曲线的每个点上下连接，使用渐变进行绘制？ 那样计算量将会是非常巨大的！那又有其他什么好的方法呢？</p>    <p>Paint 中提供了 Xfermode 图像混合模式的机制。 它能够控制绘制图形与之前已经存在图形的混合交叠模式。其中比较有用的是 PorterDuffXfermode 这个类。它有多种混合模式，如下图所示：</p>    <p><img src="https://simg.open-open.com/show/fcb8092fb8a388ce80194fa55ba14bcd.jpg"></p>    <p>这里 canvas 原有的图片可以理解为背景，就是 dst； 新画上去的图片可以理解为前景，就是 src。有了这种图形混合技术，能够完成各种图形交集的显示。</p>    <p>那我们是否可以脑洞大开一下，将上图已经绘制好的波形图，与渐变的矩形进行交集，将它们相交的地方画出来呢。 它们相交的地方好像恰好就是我们需要的效果呢。</p>    <p>这样，我们只需要先填充波形，然后在每组正弦线相交的封闭区域画一个以波峰和波谷为高的矩形，然后将这个矩形染色成渐变色。以这个矩形与波形做出交集，选择 SrcIn 模式，即能只显示相交部分矩形的这一块的颜色。 这个方案看起来可行，先试试。下面图是没有执行 Xfermode 的叠加图， 从图中可以看出，两个正弦线中间的区域正是我们需要的！</p>    <p><img src="https://simg.open-open.com/show/d5cf7e661023d296e333a09ea96d8709.png"></p>    <p>下面是执行 SrcIn 模式混合之后的图像：</p>    <p><img src="https://simg.open-open.com/show/b646637a5fe50037a7b1afccfcbade3e.png"></p>    <p>神奇的事情出现了， 视觉图中的效果被还原了。</p>    <p>我们再依葫芦画瓢，再绘制另外一组正弦曲线。 这里需要注意的是，由于 Xfermode 中的 Dst 指的原有的背景，因此这里两组正弦线的混合会互相产生影响。 即第二组在调用 SrcIn 模式进行混合的时候，会将第一组的图形进行剪切。如下图所示：</p>    <p><img src="https://simg.open-open.com/show/7788ec2a8d72f3480ad11dcc6821c2c5.jpg"></p>    <p>因此在绘制的时候，必须将两组正弦曲线分开单独绘制在不同 Canvas 层上。 好在 Android 系统为我们提供了这个功能，Android 提供了不同 Canvas 层，以用于进行离屏缓存的绘制。我们可以先绘制一组图形，然后调用 canvas.saveLayer 方法将它存在离屏缓存中，然后再绘制另外一组曲线。最后调用 canvas.restoreToCount(sc);方法恢复 Canvas，将两屏混合显示。最后的效果图如下所示：</p>    <p><img src="https://simg.open-open.com/show/a6a6968e58886f6d41e3a75c1cb35951.jpg"></p>    <p>这里总结一下绘制的顺序：</p>    <p>1、计算出曲线需要绘制的点</p>    <p>2、填充出正弦线</p>    <p>3、在每组正弦线相交的地方，根据波峰波谷绘制出一个渐变线填充的矩形。并且设置图形混合模式为 SrcIn</p>    <pre>  <code class="language-java">mPaint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.SRC_IN));</code></pre>    <p>4、对正弦线进行描边</p>    <p>5、离屏存储 Canvas，再进行下一组曲线的绘制</p>    <p>静态的绘制已经完成了。接下来就是让它动起来了。 根据上面给出来的框架，在绘制线程中会定时执行 doDraw 方法。我们只需要在 doDraw 方法中每次将波形往前移动一个距离，即可达到让波形往前移动的效果。具体对应到正弦公式中的 φ 值，每次只需要在原有值的基础上修改这个值即能改变波形在 X 轴的位置。每次执行 doDraw 都会根据下面的计算方法重新计算图形的初相值：</p>    <pre>  <code class="language-java">this.mPhase = (float) ((this.mPhase + Math.PI * mSpeed) % (2 * Math.PI));</code></pre>    <p>在计算波形高度的时候，还可以乘以音量大小。即正弦公式中的 A 的值可以为 volume * 绘制的最大高度 * 425/(4+x4)。 这样波形的振幅即能与音量正相关。波形可以随着音量跳动大小。</p>    <h2>动画的优化</h2>    <p>虽然上面已经实现了波形的动画。但是如果以为工作已经结束了，那就真是太 sample，naive了。</p>    <p>现在手机的分辨率变的越来越大，一般都是1080p的分辨率。随着分辨率的增加，图形绘制所需要的计算量也越来越大（像素点多了）。这样导致在某些低端手机中，或某些伪高端手机（比如某星S4）中，CPU 的计算能力不足，从而导致动画的卡顿。 因此对于自绘动画，可能还需要不断的进行代码和算法的优化，提高绘制的效率，尽量减少计算量。</p>    <p>自绘动画优化的最终目的是减少计算量，降低 CPU 的负担。为了达到这个目的，笔者总结归纳了以下几种方法，如果大家有更多更好的方法，欢迎分享：</p>    <h3>1、降低分辨率</h3>    <p>在实际动画绘制的过程中，如果对每个像素点的去计算(x,y)值，会导致大量的计算。但是这种密集的计算往往都是不需要的。 对于动画，人的肉眼是有一定的容忍度的，在一定范围内的图形失真是无法察觉的，特别是那种一闪而过的东西更是如此。 这样在实现的时候，可以都自己拟定一个比实际分辨率小很多的图形密度，这个图形密度上来计算 Y 值。然后将我们自己定义的图形密度成比例的映射到真实的分辨率上。 比如上面绘制正弦曲线的时候，我们完全可以只计算100个点。然后将这60个点成比例的放在1024个点的X轴上。 这样我们一下子便减少了接近10倍的计算量。这有点类似栅格化一副图片。</p>    <p>由于采用了低密度的绘制，将这些低密度的点用直线连接起来，会产生锯齿的现象，这样同样会对体验产生影响。但是别怕，Android 已经为我们提供了抗锯齿的功能。在 Paint 类中即可进行设置：</p>    <pre>  <code class="language-java">mPaint.setAntiAlias(true);</code></pre>    <p>使用 Android 优化过了的抗锯齿功能，一定会比我们每个点的去绘制效率更高。</p>    <p>通过动态调节自定义的绘制密度，在绘制密度与最终实现效果中找到一个平衡点（即不影响最后的视觉效果，同时还能最大限度的减少计算量），这个是最直接，也最简单的优化方法。</p>    <h3>2、减少实时计算量</h3>    <p>我们知道在过去嵌入式设备中计算资源都是相当有限的，运行的代码经常需要优化，甚至有时候需要在汇编级别进行。虽然现在手机中的处理器已经越来越强大，但是在处理动画这种短时间间隔的大量运算，还是需要仔细的编写代码。 一般的动画刷新周期是16ms，这也意味着动画的计算需要尽可能的少做运算。</p>    <p>只要能够减少实时计算量的事情，都应该是我们应该做的。那么如何才能做到尽量少做实时运算呢？ 一个比较重要的思维和方法是利用用空间来换取时间。一般我们在做自绘动画的时候，会需要做大量的中间运算。而这些运算有可能在每次绘制定时到来的时候，产生的结果都是一样的。这也意味着有可能我们重复的做出了需要冗余的计算。 我们可以将这些中间运算的结果，存储在内存中。这样下次需要的时候，便不再需要重新计算，只需要取出来直接使用即可。 比较常用的查表法即使利用这种空间换时间的方法来提高速度的。</p>    <p>具体针对本例而言， 在计算 425/(4+x4) 这个衰减系数的时候，对每个 X 轴上固定点来说，它的计算结果都是相同的。 因此我们只需要将每个点对应的 y 值存储在一个数组中，每次直接从这个数组中获取即可。这样能够节省出不少 CPU 在计算乘方和除法运算的计算量。 同样道理，由于 sin 函数具有周期性，因此我们只需要将这个周期中的固定 N 个点计算出值，然后存储在数组中。每次需要计算 sin 值的时候，直接从之前已经计算好的结果中找出近似的那个就可以了。 当然其实这里计算 sin 不需要我们做这样的优化，因为 Android 系统提供的 Math 方法库中计算 sin 的方法肯定已经运用类似的原理优化过了。</p>    <p>CPU 一般都有一个特点，它在快速的处理加减乘运算，但是在处理浮点型的除法的时候，则会变的特别的慢，多要多个指令周期才能完成。因此我们还应该努力减少运算量，特别是浮点型的除法运算。 一般比较通用的做法是讲浮点型的运算转换成整型的运算，这样对速度的提升也会比较明显。 但是整型运算同时也意味着会丢失数据的精确度，这样往往会导致绘制出来的图形有锯齿感。 之前有同事便遇到即使采用了 Android 系统提供的抗锯齿方法，但是绘制出来的图形锯齿感还是很强烈，有可能就是数值计算中的精确度的问题，比如采用了不正确的整型计算，或者错误的四舍五入。 为了保证精确度，同时还能使用整型来进行运算，往往可以将需要计算的参数，统一乘上一个精确度(比如乘以100或者1000，视需要的精确范围而定)取整计算，最后再将结果除以这个精确度。 这里还需要注意整型溢出的问题。</p>    <h3>3、减少内存分配次数</h3>    <p>Android 在内存分配和释放方面，采用了 JAVA 的垃圾回收 GC 模式。 当分配的内存不再使用的时候，系统会定时帮我们自动清理。这给我们应用开发带来了极大的便利，我们从此不再需要过多的关注内存的分配与回收，也因此减少很多内存使用的风险。但是内存的自动回收，也意味着会消耗系统额外的资源。一般的 GC 过程会消耗系统ms级别的计算时间。在普通的场景中，开发者无需过多的关心内存的细节。但是在自绘动画开发中，却不能忽略内存的分配。</p>    <p>由于动画一般由一个16ms的定时器来进行驱动，这意味着动画的逻辑代码会在短时间内被循环往复的调用。 这样如果在逻辑代码中在堆上创建过多的临时变量，会导致内存的使用量在短时间稳步上升，从而频繁的引发系统的GC行为。这样无疑会拖累动画的效率，让动画变得卡顿。</p>    <p>处理分析内存分配，减少不必要的分配呢， 首先我们需要先分析内存的分配行为。 对于Android内存的使用情况，Android Studio提供了很好用，直观的分析工具。 为了更加直观的表现内存分配的影响，在程序中故意创建了一些比较大的临时变量。然后使用Memory Monitor工具得到了下面的图：</p>    <p><img src="https://simg.open-open.com/show/be14e0fea8e9cdb92a741bfba5a224e8.png"></p>    <p>并且在log中看到有频繁的打印D/dalvikvm: GC_FOR_ALLOC freed 3777K, 18% free 30426K/36952K, paused 33ms, total 34ms</p>    <p>图中每次涨跌的锯齿意味着发生了一次GC，然后又分配了多个内存，这个过程不断的往复。 从log中可以看到系统在频繁的发起GC，并且每次GC都会将系统暂停33ms，这当然会对动画造成影响。 当然这个是测试的比较极端的情况，一般来说，如果内存被更加稳定的使用的话，触发GC的概率也会大大的降低，上面图中的颠簸锯齿出现到概率也会越低。</p>    <p>上面内存使用的情况，也被称为内存抖动，它除了在周期性的调用过程中出现，另外一个高发场景是在for循环中分配、释放内存。它影响的不仅仅是自绘动画中，其他场景下也需要尽量避免。</p>    <p>从上图中可以直观的看到内存在一定时间段内分配和释放的情况，得出是否内存的使用是否平稳。但是当出现问题之后，我们还需要借助 Allocation Tracker 这个工具来追踪问题发生的原因，并最后解决它。Allocation Tracker 这个工具能够帮助我们追踪内存对象的分配和释放情况，能够获取内存对象的来源。比如上面的例子，我们在一段时间内进行追踪，可以得到如下图：</p>    <p><img src="https://simg.open-open.com/show/a3c70ab2e283dd6920871317df2ed802.png"></p>    <p>从图中我们可以看到大部分的内存分配都来自线程18 Thread 18，这也是我们的动画的绘制线程。 从图中可以看到主要的内存分配有以下几个地方：</p>    <p>1、我们故意创建的临时大数组</p>    <p>2、来自 getColor 函数， 它来自对 getResources().getColor()的调用，需要获取从系统资源中获取颜色资源。这个方法中会创建多个 StringBuilder 的变量</p>    <p>3、创建 Xfermode 的临时变量，来自 mPaint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.SRC_IN)); 这个调用。</p>    <p>4、创建渐变值的 LinearGradient gradient = new LinearGradient(getXPos(startX), startY, getXPos(startX), endY,</p>    <pre>  <code class="language-java">gradientStartColor, gradientEndColor, Shader.TileMode.REPEAT);</code></pre>    <p>对于第2、3，这些变量完全不需要每次循环执行的时候，重复创建变量。 因为每次他们的使用都是固定的。可以考虑将它们从临时变量转为成员变量，在动画初始化的同时也将这些成员变量初始化好。需要的时候直接调用即可。</p>    <p>而对于第4类这样的内存分配，由于每次动画中的波形形状都不一样，因此渐变色必现得重新创建并设值。因此这里并不能将它作为成员变量使用。这里是属于必须要分配的。好在这个对象也不大，影响很小。</p>    <p>对于那些无法避免，每次又必须分配的大量对象，我们还能够采用对象池模型的方式来分配对象。对象池来解决频繁创建与销毁的问题，但是这里需要注意结束使用之后，需要手动释放对象池中的对象。</p>    <p>经过优化的内存分配，会变得平缓很多。比如对于上面的例子。 去除上面故意创建的大量数组，以及优化了2、3两个点之后的内存分配如下图所示：</p>    <p><img src="https://simg.open-open.com/show/a9a7e85215d37f9ec48908ba5b0d464f.png"></p>    <p>可以看出短时间内，内存并没有什么明显的变化。并且在很长一段时间内都没有触发一次 GC</p>    <h3>4、减少 Path 的创建次数</h3>    <p>这里涉及到对特殊规则图形的绘制的优化。 Path 的创建也涉及到内存的分配和释放，这些都是需要消耗资源的。并且对于越复杂的 Path，Canvas 在绘制的时候，也会更加的耗时。因此我们需要做的就是尽量优化 Path 的创建过程，简化运算量。这一块并没有很多统一的标准方法，更多的是依靠经验，并且将上面提到到的3点优化方法灵活运用。</p>    <p>首先 Path 类中本身即提供了数据结构重用的接口。它除了提供 reset 复位方法之外，还提供了 rewind 的方法。这样每次动画循环调用的时候，能够做到不释放之前已经分配的内存就能够重用。这样避免的内存的反复释放和分配。特别是对于本例中，每次绘制的 Path 中的点都是一样多的情况更加适用。</p>    <p>采用方法一种低密度的绘图方法，同样还能够减少 Path 中线段的数量，这样降低了 Path 构造的次数，同能 Canvas 在绘制 Path 的时候，由于 Path 变的简单了，同样能够加快绘制速度。</p>    <p>特别的，对于本文中的波形例子。 视觉图中给出来的效果图，除了要用渐变色填充正弦线中间的区域之外。还需要对正弦线本身进行描边。 同时一组正弦线中的上下两根正弦线的颜色还不一样。 这样对于一组完整的正弦线的绘制其实需要三个步骤：</p>    <p>1、填充正弦线</p>    <p>2、描正弦线上边沿</p>    <p>3、描正弦线下边沿</p>    <p>如何很好的将这三个步骤组合起来，尽量减少 Path 的创建也很有讲究。比如，如果我们直接按照上面列出来的步骤来绘制的话，首先需要创建一个同时包含上下正弦线的 Path，需要计算一遍上下正弦线的点，然后对这个 Path 使用填充的方式来绘制。 然后再计算一遍上弦线的点，创建只有上弦线的 Path，然后使用 Stroke 的模式来绘制，接着下弦线。 这样我们将会重复创建两边 Path，并且还会重复一倍点坐标的计算量。</p>    <p>如果我们能采用上面步骤2中提到的，利用空间换取时间的方法。 首先把所有点位置都记在一个数组中，然后利用这些点来计算并绘制上弦线的 Path，然后保存下来；再计算和绘制下弦线的 Path 并保存。最后创建一个专门记录填充区的 Path，利用 mPath.addPath();的功能，将之前的两个 path 填充到该 Path 中。 这样便能够减少 Path 的计算量。同时将三个 Path 分别用不同的变量来记录，这样在下次循环到来的时候，还能利用 rewind 方法来进行内存重用。</p>    <p>这里需要注意的是，Path 提供了 close的方法，来将一段线封闭。 这个函数能够提供一定的方便。但是并不是每个时候都好用。有的时候，还是需要我们手动的去添加线段来闭合一个区域。比如下面图中的情形，采用 close，就会导致中间有一段空白的区域：</p>    <p><img src="https://simg.open-open.com/show/cfcb278e8837a07d5b2b8b9cde024635.jpg"></p>    <h3>5、优化绘制的步骤</h3>    <p>什么？ 经过上面几个步骤的优化，动画还是卡顿？不要慌，这里再提供一个精确分析卡顿的工具。 Android 还为我们提供了能够追踪监控每个方法执行时间的工具 TraceView。 它在 Android Device Monitor 中打开。比如笔者在开发过程中发现动画有卡顿，然后用上面 TraceView 工具查看得到下图：</p>    <p><img src="https://simg.open-open.com/show/db3baf63252616618211ed935e82b5ae.png"></p>    <p>发现 clapGradientRectAndDrawStroke 这个方法占用了72.1%的 CPU 时间，而这个方法中实际占用时间的是 drawPath。这说明此处的绘制存在明显的缺陷与不合理，大部分的时间都用在绘制 clapGradientRectAndDrawStroke 上面了。那么我们再看一下之前绘制的原理，为了能够从矩形和正弦线之间剪切出交集，并显示渐变区域。笔者做出了如下图的尝试：</p>    <p><img src="https://simg.open-open.com/show/d3b36f3922034f3685bb59448d5a8ae0.jpg"></p>    <p>首先绘制出渐变填充的矩形； 然后再将正弦线包裹的区域用透明颜色进行反向填充（白色区域），这样它们交集的地方利用 SrcIn 模式进行剪切，这时候显示出来便是白色覆盖了矩形的区域（实际是透明色）加上它们未交集的地方（正弦框内）。这样同样能够到达设计图中给出的效果。代码如下：</p>    <pre>  <code class="language-java">mPath.rewind();          mPath.addPath(mPathLine1);          mPath.lineTo(getXPos(mDensity - 1), -mLineCacheY[mDensity - 1] + mHeight_2 * 2);          mPath.addPath(mPathLine2);          mPath.lineTo(getXPos(0), mLineCacheY[0]);            mPath.setFillType(Path.FillType.INVERSE_WINDING);          mPaint.setStyle(Paint.Style.FILL);          mPaint.setShader(null);          mPaint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.SRC_IN));          mPaint.setColor(getResources().getColor(android.R.color.transparent));          canvas.drawPath(mPath, mPaint);          mPaint.setXfermode(null);</code></pre>    <p>虽然上面的代码同样也实现了效果，但是由于使用的反向填充，导致填充区域急剧变大。最后导致 canvas.drawPath(mPath, mPaint);调用占据了70%以上的计算量。</p>    <p>找到瓶颈点并知道原因之后，我们就能做出针对性的改进。 我们只需要调整绘制的顺序，先将正弦线区域内做正向填充，然后再以 SrcIn 模式绘制渐变色填充的矩形。 这样减少了需要绘制的区域，同时也达到预期的效果。</p>    <p><img src="https://simg.open-open.com/show/8860002076e949fc5fdd3bc126e3fd91.jpg"></p>    <p>下面是改进之后 TraceView 的结果截图：</p>    <p><img src="https://simg.open-open.com/show/6045cb692fc5c7887bf2e44aff18945c.png"></p>    <p>从截图中可以看到计算量被均分到不同的绘制方法中，已经没有瓶颈点了，并且实测动画也变得流畅了。 一般卡顿都能通过此种方法比较精确的找到真正的瓶颈点。</p>    <h2>总结</h2>    <p>本文主要简单介绍了一下 Android 普通 View 和 SurfaceView 的绘制与动画原理，然后介绍了一下录音机波形动画的具体实现和优化的方法。但是限于笔者的水平和经验有限，肯定有很多纰漏和错误的地方。大家有更多更好的建议，欢迎一起分享讨论，共同进步。</p>    <p>腾讯 Bugly是一款专为移动开发者打造的质量监控工具，帮助开发者快速，便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类，每日日报会列出影响用户数最多的崩溃，精准定位功能帮助开发同学定位到出问题的代码行，实时上报可以在发布后快速的了解应用的质量情况，适配最新的 iOS, Android 官方操作系统，鹅厂的工程师都在使用，快来加入我们吧！</p>    <p> </p>    <p>来自：http://dev.qq.com/topic/591aa307b8157a82534f3cac</p>    <p> </p>