使用硬件加速的drawText过程

硬件加速不是万能的，使用的好可以使速度更快，使用方式不当，不仅得不到加速的效果，而且还可能会引起其他的问题，合适的，才是最好的。

使用硬件加速的drawText函数调用流程如下:

ViewRootImpl.java :

scheduleTraversals()

->TraversalRunnable

->doTraversal()

->performTraversals()

->performDraw()

->Draw():attachInfo.mHardwareRenderer.draw(mView, attachInfo,this,

                        animating ? null :mCurrentDirty);

然后便走到的HardwareRenderer.java的draw，继续跳转到HardwareCanvas.java的drawDisplayList，继续跳转的GLES20Canvas.java的drawDisplayList，通过JNI调用，跳转到

android_view_GLES20Canvas.cpp的android_view_GLES20Canvas_drawDisplayList，自此，到了

DisplayListRenderer.cpp                                                     

replay                                       

->drawText

->FontRenderer.cpp

->renderText

->render(SkPaint* paint, const char* text, uint32_t start,uint32_t len,

                                          intnumGlyphs, int x, int y, RenderMode mode, uint8_t *bitmap,

                        uint32_t bitmapW,uint32_t bitmapH, Rect* bounds, const float* positions)

->drawCachedGlyph

->appendMeshQuad

->appendMeshQuadNoClip

->issueDrawCommand

->checkTextureUpdate

->glTexSubImage2D

主要跟踪的是有缓存更新操作的流程。

         在中文文本比较多的时候，Android4.0及4.1中，使用硬件加速，比较容易出现卡顿现象，是因为中文的缓存效果不理想，经常会走checkTextureUpdate检查更新，glTexSubImage2D是个比较耗时的函数，如果有刷新，一般都有5ms以上。在文本是英语时，是没有此问题的，Google原始的问题，暂时还没有想到解决方式，4.2中，代码有所改动，不知性能是否有所改善，有待验证。