我对Weex学的不深，是这样看待它的：
写一套.we或者.vue，由Weex环境转化成.js
.js里描述的是对于移动端的抽象，本身就可以在网页运行
对于IOS和Android，可以对.js进行解析，.js里抽象的移动端，都可以在IOS和Android里找到对应的组件去替代
加载.js的时候
1.解析.js保存的布局文件
2.创建View
3.设置布局参数
4.设置点击事件
5.绑定数据到View上
然后这个View就形成了，再扔给Activity.setContentView
然后事件流仍然是走在.js中，无论是初始化时间流，还是后续事件流。
我猜测View接受到触摸事件后，会立刻回传到JS
所以整个事件流是在.js里的
遇到Module、Component就会走Native层
同时Component的任务还会延迟到下一次ASYNC渲染信号到来的时候执行
所以大概有这么几层
1.JS内核层，用于处理JS
2.Framework层，有各种Manager，封装了和JS内核层的交互，并由此提供基础服务
3.线程处理层，处理线程切换等
4.组件层，Module、Component具体功能在Native的执行
感觉上好像是模仿了Android的架构
Weex的几个注意点
线程模型
1.JS、Native交互线程
2.DOM解析线程
3.UI操作线程
此外反射的消耗
我不太清楚Weex的注解采用的是不是编译时注解，这一点性能上是可以优化的
开发模式的转变
Native开发模式是：一个模块一个组，还有一个公共模块组
Native开发中，公共模块已经承担了架构与框架任务，业务模块只剩下了业务逻辑。
所以用了Weex以后，只不过是把业务逻辑从Native转移到了JS，Native仅保留了公共模块。
其实都一样啊，业务开发程序员对于架构和框架是无感的，只剩下了需求理解+复杂业务逻辑的处理，是开发Java还是开发JS，其实都一样。。。
所以现在招人都在意你会不会一点JS，毕竟是要你用JS去开发业务的，不可能初出茅庐就让你去架构公共服务。