不得不说，使用Weex开发应用程序对于我们纯前端人员来说，是件「很爽」的事情，只要你熟悉了他的语法，基本可以做到一周上手写的应用程序。极其适合交互要求不高，时间紧迫，人手不足的同构开发需求。
但是，当然有但是，如果你想写出一个完美的应用程序，你需要在性能优化上下很大的功夫，包括动画的优化，过场的优化，图片的优化，细节的打磨等等，再者，就是你需要掌握或者“能写”一些原生的代码，不然有有些功能你是实现不了的，比如状态栏的属性更改，开场动画的制作，内存的回收，webview的监听等等。
下面我们具体讲讲入门知识
写一次，随处运行
Weex提供了多端一致的技术方案。
*首先，Weex的开发和web开发体验可以说是几乎一样。包括语法设计和工程链路等。
*其次，Weex的组件，模块设计都是iOS，Android，Web的开发者共同讨论出来的，有一定的通用性和普遍性。
*Weex开发同一份代码，可以在不同的端上分别执行，避免了多端的重复研发成本。
在同构这条路上，Weex比React Native做得更彻底，他「几乎」做到了，「你来用vue写一个webapp，我顺便给你编译成了ios和android的原生app」
至于为什么要造这个轮子，官方给了以下说法
1.Web开发本身具有非常强的高效率和灵活性，这和Web开发者Weex想解决的移动端动态性问题不谋而合。
2.网页标准和开发体验是很多顶尖而优秀的科技公司共同讨论和建设的结果，本身的设计和理念都有极高的品质保障
3.同时Weex也希望可以借此机会努力为标准贡献一点自己的微薄之力。
4.Web是一种标准化的技术，标准本身就是一种力量，基于标准，尊重标准，贴近标准都意味着拥有更多的可能性。
5.Web今天的生态和社区是非常繁荣的，有很多成熟的工具，库，工程体系，最佳实践可以使用，引入和借鉴。
在我看来，Weex其实是阿里巴巴团队提高生产效率的产物，在淘宝这类要求多端统一迭代快速的部门，三端约定一种便于统一的规范，在加上时间的发酵，渐渐的就有了React Native开源带来的极大轰动后，自己也坐不住了吧^ _ ^
开发过程中必须考虑的几点：
性能
性能是一个大课题，在此就不做展开了，只稍微提及一些我们开发需要注意的几点
1.性能影响点：UI更新>UI事件响应>后台运算
2.合理优化过场&动画，过场和 console 容易引起 app crash 需要注意
3.降低 js <-> native 的通信频率
4.优化list结构，降低重排重绘压力
5.把优先级低且耗时较长的工作推后处理
Weex 的现状
Weex 解决了的
我的发布我做主（热更新）
脚本语言天生自带“热更新”，Weex 针对 React Native 的热更新策略做了优化，将 WeexSDK 事先绑到了客户端上，并且对 JSBundle 进行分包增量更新，大大提高了热更新的效率。
但优点也是缺点，如果新包依赖于心的 SDK，此情况下，我们需要发布还有新 SDK 的 app 到应用市场，用户也须从市场更新此 app。不够随着 WeexSDK 版本的稳定后，相信此策略的优势就会凸显出来。
性能问题
Weex 是一种轻量级、可扩展、高性能框架。集成也很方便，可以直接在 HTML5 页面嵌入，也可嵌在原生UI中。由于和 React Native 一样，都会调用 Native 端的原生控件，所以在性能上比 Hybrid 高出一个层次。
统一三端
虽说这是一个大胆的实践，但对于大前端社区的统一有着推动作用，显然阿里在这一方面已经迈出了第一步。基本解决了三端同等需求导致资源浪费的痛点。
但后期可能会出现这种现象，开发一个三端的 App 会从原来的个人变成四个人，多出来的那一个人负责开发 Weex 单页。
意思就是，三端统一的不够彻底，但就目前的环境下，这一句是最优方案了，却是提高了开发效率。大前端将来将如何一统三国我们且行且观望吧。
做游戏
对于一些交互视觉统一且没有很大的性能需求的游戏，Weex 还是可以胜任的。
近期笔者将尝试发布一款纯Weex构建的益智小游戏，敬请期待。
朋友们可以用这个demo体验下 Weex 版扫雷游戏开发
Weex “暂时”放弃的
虽然说大一统事件百利的事，但并非无一害。
差异化
对于一些有差异化完美体验追求的项目就只能收敛或者放弃了。
独立的 bug 修复
对于三端同时上线，一端存在 bug 的情况，Weex 并不能保证做到牵一发而不动全身。
个性化功能
比如安卓的波纹按钮、3DTouch、 Widget、iWatch版本等，目前这些功能还是没有的，不知道以后 Weex
是否将其加入到官方文档中。
不过部分功能我们也可以通过原生代码去实现，就是这么灵活！！！
网友评论