一，Weex架构优化
首先，我们来看一下weex的架构演变，从架构图中可以看到，它一步步的增加了WeexCore，EagleCore等模块。下面我们就来了解一下这些模块的演进。
1，JS引擎的演进
weex早期在Android上使用的是V8，但经过测试，JavaScriptCore的性能比V8的性能更好，所以便用JavaScriptCore全面替代了V8
2，WeexCore的演进
可以看到，weex最早版本只使用了和V8和JSFramework两个模块，V8主要负责js的解析。但因为js framework是js代码，效率上难免会有一些问题，所以后来便增加了WeexCore，WeexCore的主要功能便是分担JsFramework中的部分功能。
我们先了解下JsFramework的功能，他主要有下面几个部分
- 适配前端框架
- 构建渲染指令树
- JS-Native通信
- JS Service–解决跨页面复用和状态共享问题
所以，WeexCore的功能，便是用C++代码实现并逐步替代JsFramework的功能，如构建渲染指令树，即JSFramework 输出的渲染指令直接交给 WeexCore 中的 RenderManager，如与native的通信等功能，目前都已经移到了WeexCore，随着技术的演进，JsFramework的大公分功能将逐渐转移到WeexCore中，JSFramework的功能将越来越少，直至最终被完全替代。
我们看一下WeexCore的架构图
3，EagleCore的演进
我们先看看一个通用的跨平台页面展现的流程，不管是RN，还是weex，或者是快应用，流程都是如下。
根据weex团队的统计，在页面离线的情况下，整体渲染时间为300ms，js执行时间约为160ms，占比超过50%，这就意味着，js执行效率很大程度上拖慢了整体展现时间，所以这种渲染流程存在一定的性能瓶颈。而WeexEagle整体技术方案也是针对这一瓶颈，将页面和逻辑分离，利用JSON作为页面的描述，先进行页面展示再进行JS逻辑执行。
我们看一下WeexEagle是如何渲染的，他抛弃了以往下载js文件，然后执行js，构建dom的形式，而是采用下载json，然后解析json，构建dom，等到首屏渲染完成后，在去反向绑定js逻辑。
我们接着看看JSON的数据格式，可以看到JSON中已经携带了的dom结构以及Js文件
那么WeexEagle这个版本主要做了什么事呢？它主要做了下面几件事
- 下沉DOM Tree到native层维护，提高创建和更新DOM节点的性能，这样便避免了页面依赖JsFramework。
- 页面渲染不再由JsFramework中的render函数发起，而是交给EagleCore完成，使得渲染不再依赖JsFramework初始化也能进行
当然，这种架构也需要DSL支持，原来的Weex编译工具会将Vue或者Rax编译成JsBundle文件，然后再交给Weex渲染。在WeexEagle版本中，编译布局不再生成JsBundle，而是生成JSON和JS这两个文件，也就是业务和页面逻辑分离的模式。
二，Weex其他优化
1，数据传输
weex最初使用FastJSON作为数据传输，FastJSON是阿里开源的json库，目前是市面上最快的json库，解析速度远快于json和gson。之后，Weex用Wson代替FastJSON，Wson也是weex自研的数据协议，通信调用过程相比于FastJson提升了30-60%。
2，DOM解析优化
weex和快应用都是通过addElement来渲染界面的，DOM中每解析一个节点，便调用native的addElement方法给os层增加一个node，这样的好处是每一个被解析完的DOM都可以立刻显示，同事保证不会长时间阻塞主线程，坏处是可以会造成多次冗余的layout。
所以weex还有一种tree的渲染模式，即DOM树解析完成后一次提交给os层去渲染界面，这样的好处是只需要布局一次，渲染效率更高，坏处是如果tree过大，就会阻塞主线程。
node和tree可以精细化地控制页面展示的逻辑和颗粒度，一般首屏以内按tree解析，首屏以外按node解析
3，进程优化
weex将V8替换成JavaScriptCore后出现了下面几个问题
- jscore引擎线上出现了很多无法定位的稳定性问题
- jscore好用内存较大，导致低端机上app进程容易被杀
所以weex开始由单进程多线程优化成多进程单线程，主要的做法是将jscore放在单独的进程里，这样就算jscore的进程挂了，也不会导致app出问题，同是，还可以对jscore进程进行监控，自动重启等，极大的增强了weex的稳定性，但是多进程改造后在ipc通信方面也会有大量的改造。