最近开始试水weex开发，使用这么长一段时间，感觉写weex还是非常方便的。作为一个android开发，免不了要追查一下weex的sdk源码。今天，就以weex sdk for android为例，分析sdk的
<a href="https://github.com/alibaba/weex/tree/dev/android">源码:https://github.com/alibaba/weex/tree/dev/android</a>
整体分析下拉，按照js文件的渲染过程，绘制出了下面架构图：
为了更加详细的说明整个渲染过程，我对源码进行了分析。并结合示例，进行了日志分析；比如，我们要开发如下一个简单的组件(红色方框内)：
那么，我们的wxc-title.we源码为：
上述.we文件经过weex编译之后，生成的js文件，经过格式化如下：
上述分别使用了三个function，对template、style和script进行了封装；那么，这个文件是怎么被weex sdk执行并解析，最终生成结构化的view的呢？
从扫码开始，首先经历如下过程；依次经过readerpage，createinstance，一直到wxbridge的exejs方法；也就是说，最终，java通过调用native的exejs方法，来执行js文件的。
紧接着时序图1：执行到jni层的java_com_taobao_weex_bridge_wxbridge_execjs方法;
然后js通过native调用wxbridge的callnative方法，达到js调用java代码的目的；
jni层的部分代码如下：
接着上面的时序图，开始做页面的创建；关键的代码在wxrenderstatement中的createbodyondomthread，该方法通过创建跟布局的mgodcomponent,通过递归generatecomponenttree生成component的逻辑树结构;然后，在wxrenderstatement的createbody方法中，生成view，绑定属性和数据；具体如下图所示：
以上面的weex页面为例：使用playground扫码之后的调用过程中的日志为：
首先，我们看一下android原声的view绘制过程：
主要是measure测量大小，layout确定位置。
其次，我们对比一下weex的wxcomponent的测量和布局过程；
主要是通过csslayout进行测量，使用view的setlayoutparams来确定view在父viewgroup中的位置。
核心代码如下：
渲染过程对比：
weex的渲染过程，上面已经写的比较清晰了；对于android，其渲染过程大致可以总结为：
1.编译期使用aapt对xml进行编译，生成二进制的xml
2.运行时，使用xmlblock构建xmlpullparser，通过layoutinflater的rinflater进行解析，最终生成view；
那么，两种方式的解析效率差异有多大呢？官方的数据如下：
目前以飞猪app的购物车为例：weex，native，以及投放到手淘的h5，进行了帧率对比，数据如下：
weex无论在createbody、addelement，还是在callnative中对module的调用，都还有很多优化空间。比如，可以把部门运行时的工作，搬到编译期做，这样可以加快页面的渲染时间；在渲染之后，滑动过程中的帧率对比发现，weex和native基本相近，比h5的表现要好。