断断续续调试好几天，才把X5WebView的整体流程大概了解清除。本篇是上篇，侧重于讲java层的逻辑。
整个WebKit主要分为2个线程，一个是Ui线程，也就是应用程序使用WebView所在的主线程，另一个WebCore线程。webview.java运行在ui线程，webviewcore运行在webkit线程，之间通过消息通信。不同webview对应不同webviewcore（同一个webkit线程）。
WebView的消息处理，主要是Ui线程和WebCore线程的交互。一部分Ui线程向WebCore发送的命令操作消息，例如LOAD_URL，另一部分是来自Ui的touch消息。
从网上找来的一张图：（出处见文末）
其中，WebViewClassic是WebView的Provider，或者说是delegate，凡是涉及到消息处理或者需要跟WebCore交互的接口，都是直接调用WebViewClassic的同名函数。
WebViewCore是C层真正的webkit的代理层。位于另外一个线程。而相对的WebViewClassic属于ui线程。总体的逻辑是，WebViewClassic负责接收和处理来自UI的各种消息，如绘制、触屏消息，然后发送到WebViewCore。WebViewCore经过进一步处理后，再转发给c层。
这里要注意的是，Ui线程第一次向WebCore线程发送的消息，并没有直接被分发到WebCore线程中去。而是被缓存在WebViewCore中的mMessages list中，因为有可能在WebKit的消息处理框架还未初始化完毕，Ui线程就已经开始向WebCore线程发送消息了。所以，当WebViewCore最后初始化完毕之后，会调用transferMessages()，在transferMessages中将mMessages中的消息通过mHandler全部send到WebCore线程中去。
下面我们重点来看关于排版和宽高变化相关的逻辑。
排版和宽高变化相关的逻辑主要集中在WebViewClassic.java 、WebViewCore.java、ZoomManager.java、ScaleGestureDetector.java中。
当WebViewClassic.java：onHandleUiTouchEvent接收到触屏消息时，转发给ScaleGestureDetector，ScaleGestureDetector是个负责收集到双指放大和双击放大的手势的类，当检测到这两种消息后，通知ZoomManager。
例如
在WebViewClassic.onHandleUiEvent ->mZoomManager.handleDoubleTap中
实现了双击放大
ZoomManager负责存储关于缩放的各种参数，以及判断什么情况下应该缩放。最终缩放相关的消息会走到
ZoomManager.handleScale ->
ZoomManager.setZoomScale->
WebViewClassic.sendViewSizeZoom。
所有宽高以及缩放变化相关的逻辑最后都会走到
WebViewClassic.sendViewSizeZoom。
sendViewSizeZoom其实也是个代理函数，这里会收集当前页面的宽高、屏幕高度、缩放系数等，发送到WebViewCore线程的viewSizeChanged。viewSizeChanged再调用nativeSetSize，将参数设置到C层。
sendViewSizeZoom中有几个地方需要注意一下，下面看代码：
int viewWidth = getViewWidth();
int newWidth = Math.round(viewWidth * mZoomManager.getInvScale());
// This height could be fixed and be different from actual visible height.
int viewHeight = getViewHeightWithTitle() - getTitleHeight();
int newHeight = Math.round(viewHeight * mZoomManager.getInvScale());
int actualViewHeight = Math.round(getViewHeight() * mZoomManager.getInvScale());
这里的viewWidth即为webview控件自身的宽度（当然，还需要减去滚动条）。
viewHeight是view的高度+标题栏-标题栏，也就是说，无论标题栏怎么缩上放下，这个值不变。而下面的actualViewHeight就不一样，actualViewHeight代表的是屏幕可视区域的高度，也就是说，会随着标题栏上下移动而移动。
下面开始收集参数，发送给WebViewCore线程。
ViewSizeData data = new ViewSizeData();
data.mWidth = newWidth;
data.mHeight = newHeight;
这里发送的是newWidth，是乘以了缩放系数倒数的高宽，也就是说，如果屏幕被放大的话，webkit内核拿到的是一个缩小的矩形，排版的时候，也是根据这块区域进行。
再看viewSizeChanged，在这接收到sendViewSizeZoom发送过来的参数后，需要再进行一些加工。例如宽度data.mWidth就调用了calculateWindowWidth。calculateWindowWidth首先判断了getUseWideViewPort。如果为true，则进行了一系列如适屏排版、默认DPI等处理。
例如，如果设置了默认mViewportWidth，则一直使用mViewportWidth；也就是说，如果设置过UseWideViewPort，则缩放功能无效，宽度是通过一系列别的参数计算出来。
处理过后的width再拿出去用。如果width在刚才发生变化，则高度会根据之前ViewSizeData 保存的高宽比重新调整。
加工完后，viewSizeChanged调用nativeSetSize，以及contentDraw，开始刷新webview。
contentDraw中，会发送消息给ui线程通知刷新。
浏览器的排版宽度受上层ui设置的webview宽度影响。如果webview没设置或者是设置成0，浏览器内核会用默认的排版宽度320px进行排版。这个逻辑是在
WebViewCore.cpp 构造函数里写着
, m_screenWidth(320)
, m_screenHeight(240)
其中m_screenWidth，会在setSizeScreenWidthAndScale里设置。
而setSizeScreenWidthAndScale即是nativeSetSize调用过来。所以一直向上追溯的话，m_screenWidth是被sendViewSizeZoom的newWidth决定的，也就是说，而m_screenHeight是被actualViewHeight决定的。这两个都跟随着缩放而变化。
另一方面，滚动和屏幕绘制也会引起sendViewSizeZoom：
WebViewClassic.sendViewSizeZoom(boolean) line: 3954
WebViewClassic.contentSizeChanged(boolean) line: 5150
WebViewClassic.recordNewContentSize(int, int, boolean) line: 3787
WebViewClassic.setNewPicture(WebViewCore$DrawData, boolean) line: 12193
WebViewClassic$PrivateHandler.handleMessage(Message) line: 10971
WebViewClassic$PrivateHandler(Handler).dispatchMessage(Message) line: 102
Looper.loop() line: 136
ActivityThread.main(String[]) line: 5050，
标题栏浮动也会引起sendViewSizeZoom：
WebViewClassic.sendViewSizeZoom(boolean) line: 3952
WebViewClassic.onFloatAddressBarChanged(boolean) line: 14107
X5WebViewAdapter(WebView).onFloatAddressBarChanged(boolean) line: 3011
X5WebViewAdapter.onFloatAddressBarChanged(boolean) line: 1178
AddressBarDataSource.onFloatAddressBarAnimationEnd(boolean) line: 257
AddressBarController.onFloatAddressBarHideAnmationEnd() line: 2764
FloatAddressBar.computeScroll() line: 716
但sendViewSizeZoom中其实是有个判断的，只有确实宽高发生变化，才会发送消息到Core线程，除非强制刷新。这也避免了不必要的性能开销。
下面开始看屏幕绘制相关逻辑。
以下是网上说的（出处见文末）
webviewcore.cpp的contentInvalidate()会调用webviewcore.cpp的contentDraw(),这个函数会回调webviewcore.java中的contentDraw().
webviewcore.java contentDraw() 会发送消息EventHub.WEBKIT_DRAW。这个消息在webViewCore.java的EventHub的transferMessage()中处理，
调用WebViewCore.java的webkitDraw();
webkitDraw()中会先调用nativeRecordContent()，nativeRecordContent()会调用WebViewCore.cpp中recordContent().
recordContent()会调用recordPictureSet().
recordPictureSet()中会调用layoutIfNeededRecursive()以便得到最新的contentwidth和contentheight()
layoutIfNeededRecursive()会调用FrameView.cpp的Layout()从而触发整颗RenderTree的Layout.
recordPictureSet()在调用layoutIfNeededRecursive()后，会接着调用rebuildPicture()。
rebuildPicture()会创建一块新的SKPicture,
SkPicture 用来记录绘制命令，这些命令会在以后draw到一个指定的canvas上。
这个SKPicture将被保存在WebViewCore.cpp中的 m_content的WTF::Vector<Pictures> mPictures结构中。
SKPicture 的实例作为参数传给SkAutoPictureRecord的构造函数。
SKAutoPictureRecord的构造函数会调用SKPicture的beginRecording().
在SKPicture的beginRecording(）函数中会创建一块SKBitmap,和一块SkPictureRecord。并将新创建的SKBitmap作为Device设置给SKPictureRecord.
SKPictureRecord继承自SKCanvas.
SKPictureRecord会作为参数传给PlatformGraphicsContext的构造函数，赋值给SKCanvas类型的变量mCanvas.
PlatformGraphicsContext会作为参数构造WebCore::GraphicsContext。
WebCore::GraphicsContext的构造函数会调用platformInit().
GraphicContext.cpp封装了平台相关的图形库信息，不同的平台会重新实现GraphicContext定义的接口。
Android平台的GraphicContext实现在文件GraphicContextAndroid.cpp中。
所以WebCore::GraphicsContext中调用的PlatformInit()的具体实现在GraphicContextAndroid.cpp中。
PlatformInit()会新创建一个GraphicsContextPlatformPrivate实例。这是典型的代理模式。
即GraphicsContext中含有一个与具体平台相关的私有成员变量GraphicsContextPlatformPrivate来处理平台相关的逻辑。
发送给GraphicsContext的请求都转发给这个代理类来执行。
传给WebCore::GraphicsContext构造函数的PlatformGraphicsContext实例变量的指针会保存在GraphicsContextPlatformPrivate实例变量的成员变量m_platformGfxCtx中。
这样我们就清楚通过GraphicsContext类得到的SKCanvas就是我们前面提到的调用SKPicture的beginRecording()时新建的一块SKPictureRecord.
它的Device是同一函数中创建的一块SKBitmap。
WebCore::GraphicsContext作为参数传给webFrameView的draw()函数。
之所以调用的是WebFrameView的draw()函数是因为WebFrameView的构造函数会调用 frameview->setplatformwidget(this)，将自身作为platformwidget 设置给FrameView.
接下来就是WebFrameView的draw()函数触发的webkit的绘制过程，这个过程中的所有绘制命令都记录在上述新建的SKPicture中。
WebFrameView会调用FrameView的paintContents()同时将WebCore::GraphicsContext作为参数传进去。
FrameView的paintContents()会先调用needsLayout()判断下是否需要重新Layout，如果需要则进入Layout过程，停止Webkit的paint过程。
如果不需要重新Layout,paintContents()会调用RenderView对应的RenderLayer进行具体的paint过程。
RenderView是DOM Tree的根节点Document对应的RenderTree上的节点，也是RenderTree的根节点。
RenderView对应的RenderLayer是RenderLayer Tree上的根节点。
总结一下就是：
webviewcore.cpp.contentInvalidate() ->
webviewcore.cpp.contentDraw()-->
webviewcore.java.contentDraw().->
EventHub.WEBKIT_DRAW->
webViewCore.java EventHub.transferMessage()中处理，
WebViewCore.java.webkitDraw()->
WebViewCore.java.nativeRecordContent()
WebViewCore.cpp.recordContent().->
WebViewCore.cpp.recordPictureSet(). ->
WebViewCore.cpp.layoutIfNeededRecursive()以便得到最新的contentwidth和contentheight()
recordPictureSet->SKPicture
然后在异步的onDraw里面，通过drawContent->nativeCreateDrawGLFunction
绘制到canvas里。
contentInvalidate 在webviewcore.cpp很多地方都可以产生，如设置了全局背景色等。就会产生重绘消息。
这里要注意的是，
在WebViewCore.java.webkitDraw的 WebViewClassic.nativeRecordContent中才获取了真实的draw.mContentSize，然后再
发消息NEW_PICTURE_MSG_ID到WebViewClassic.setNewPicture；
setNewPicture是从WebViewCore.webkitDraw发出来的，
webview类或者页面自身通过contentInvalidate产生WEBKIT_DRAW消息，引起webcore绘制，绘制完后通过NEW_PICTURE_MSG_ID消息引起webview无效，从而使得webview的onDraw被调用，把内容显示到屏幕上。
另外一处有意思的是，webview控件整个过程其实位置是不会变的，一直都是顶着屏幕最上方，而标题栏的浮动，让webview看起来整体下移，是在onDraw里调用canvas.translate(0, getTitleHeight());实现的。当然，事件处理里面也需要做一些偏移。
当触屏消息让整个webview滚动的时候，其实是安卓系统负责滚动，C层的webkit，只需要在onDraw->drawContent更新可显示区域，让可显示区域整体（mVisibleContentRect）下移。这里我尝试注释掉calcOurVisibleRect的r.offset，则只能显示当前一屏幕的，下面的都是空白，说明在drawContent里，如果不通知c层绘制，则屏幕是滚动了，但没有绘制出内容。
另外，mContentHeightm才表示网页真正的大小，比如一个百度新闻的页面，有4000多，而是mContentHeightm正是在
WebViewClassic.recordNewContentSize里获取到的。
还有几个函数，如WebViewCore.java::setupViewport ，
WebViewCore.java::didFirstLayout，逻辑也很复杂，setupViewport 大体的意思就是通过外部设置的一系列参数，初始化一些viewport的变量，如mViewportWidth等。其中能影响到的因素有适屏排版，网页的mete，默认DPI等。感觉写的非常复杂，有点混乱，希望以后能整理一下。
其他一些零散点：
WebViewClassic.onOverScrolled （onOverScrolled->onScrollChanged
）处理了滚动的阻尼效应；
drawOverScrollBackground负责绘制网页由xx提供技术支持的隐藏背景。
mInOverScrollMode表示是否拉出界了；
WebViewCore.cpp:viewSizeChanged的 updateDisplayMetrics()
以及mBrowserFrame.nativeOrientationChanged(mOrientation);
处理了转屏相关；
参考文献：
原文地址：http://blog.csdn.net/weolar/article/details/45874537
