“Write once,Run Everywhere” 一次编写,多端运行。
React
迁移到MIT
协议,可惜React Native
依然没改,没有RN
的日子,还好有Weex
这位哥们顶着。虽然没有RN那么牛逼,但也算是一个不错的小兄弟。
很多人可能要问我搞了这么久的RN现在转Weex干什么?说起来,真是一个悲伤的故事
为什么不用RN
Facebook
并没有像React
那样把ReactNative
也迁移到MIT
协议,所以使用ReactNative
开发对外产品,依然有专利风险。一般的公司其实没什么影响,但我厂情况比较特殊,有好几个核心的专利技术,老板不想冒这个险。加之隔壁的阿里Weex
推得很火,那就用用看吧!
React
专利许可证具体细节欢迎出门左转看我之前的文章:《React专利许可证研究》
Weex
较RN
的优势
说老实话,和ReactNative
打交道这么久,突然换一个小兄弟上,一时还真的难以适应,甚至一脸嫌弃。Weex
和ReactNative
的设计理念也完全不同。RN
重点在Native
,以React
的方式开发跨平台App
,它注重Native
细腻的用户体验和强大的原生功能,运用 ReactNative
甚至不需要Native
工程师就能独立开发一款功能完善的App
。
Web
开发体验
独立开发App
对Weex
来说比较困难,因为它的Native
能力没有RN
那般强大而全面。它更注重 Web开发体验
,顾名思义就是像开发Web
网页一样开发跨平台App
页面,注意了是以Web
为主导,所以它的设计理念提倡 轻量 + 可拓展(至于“高性能”较RN
并没什么太大的体现),官方也推荐用Weex
和Native
混合的方式开发App
,也就是把Weex
作为一个组件融入到Native App
,替换传统的 Hybrid
模式。
没有专利限制
Weex
已经加入ASF
,没有ReactNative
的专利协议限制,可以放心大胆地使用。当然有童鞋会反问 Weex
目前还在使用 FaceBook
的 Yoga
引擎,会不会有隐患?这个短期内不需要我们操心,首先这个问题本身边缘就很模糊,其次 像阿里这样的大厂迟早会开发一套类似的引擎来替代,时间问题。
三端共用代码
Weex
既保留了H5
的灵活性,也赋予了其Native
能力,通过JavaSriptCore
+JSbridge
直接和Native
进行通信,较之 Hybrid
的WebView
+ URLScheme
方式性能好了很多。甚至可以实现传说中的 “三端融合”——也就是 Web
、iOS
、Android
端的前端部分共用一套代码,省去了独立建站和维护的麻烦。
当然有得必有失,三端兼容的坑也不少,Android
各机型 hack
就不提了,Web端其实就是个WebApp
,要利用浏览器的BOM
与三方的JS-SDK
来完成 DOM
和HTTP
以外的功能。不过使用Weex
内建的标签和样式可以很容易实现三端布局样式和基本行为的一致,还是大大地减少了工作量。
值得一提 Weex的布局单位有且只有
px
,默认的显示宽度 (viewport
) 是750px
,组件都会以750px
作为满屏宽度,但可以通过Meta.setViewport()
手动指定页面的显示宽度
Type | iPhone4 | iPhoneSE | iPhone8 | iPhone8P | iPhoneX |
---|---|---|---|---|---|
物理像素 | 640x960 | 640x1136 | 750x1334 | 1080x1920 | 1125x2436 |
显示像素 | 750x1125 | 750x1331 | 750x1334 | 750x1333 | 750x1624 |
像素比 | @0.85x | @0.85x | @1x | @1.44x | @1.5x |
对CSS3
的支持
Weex虽然也对CSS
做了一定的阉割,但比较 ReactNative
,它保留得更多,甚至支持大量的CSS3
特性,这一点值得赞叹。CSS3
作为Web开发的利器,放着不用难免可惜。下面列举Weex 和标准Web
的样式差异:
- 支持的
CSS3
特性包括:FlexBox、2D转换、过渡、线性渐变、阴影(仅Web
和iOS
)、伪类、自定义字体(iconFront
图标也能用哦) - 中支持单个 类名选择器,不支持 关系型选择器,也不支持 属性选择器
- 支持组件级别的作用域,为了保持
Web
和Native
的一致,需要<style scoped>
声明作用域 - 不支持
CSS3
动画(动画请使用Weex内建animation
模块)和3D转换 - 不支持
display: none
,用模板语法v-if
替代,不建议用opacity: 0
(Native
里有点透问题) - 类似
RN
,为了提高解析效率,Weex样式属性不支持简写,比如font
、border
、transfrom
不能简写
Weex不足之处
本节的最后,还是想吐槽几个Weex
的不足之处,希望官方能尽快升级和改进:
社区建设缓慢
这应该是最要命的,Weex
社区从去年开源到今天还是这般冷清不免令人神伤,虽然我知道阿里内部推广力度很大,但是既然选择开源,就应该跳出阿里的圈子,一些成功案例、成熟解决方案、优秀架构设计等就不应该藏着掖着,不然真的很难推广起来。我不希望遇到坑点 Google 几圈都找不到有价值的方案,GitHub上提问半天都等不到一个满意的答案(哈哈,说得有点激动啊,很感谢 mario 上次回答我的提问,希望能尽快反应到官方文档里)
Native能力提高
如果不提高Native能力,Weex
的 全页模式 价值其实不大。不要求面面俱到,但希望能再添加一些常用的,比如:statusBar
控制、位置信息、Android
动态权限分配等
真机调试工具升级
Weex
提倡Web
开发体验,所以开发和调试都以Web
为主,做静态页面还好,但我要调试Native
端的特有逻辑,就需要在Native端集成weex-devtool
。这个方案的确另辟蹊径,不过每次改完代码需要手动刷新会不会太麻烦,能不能搞个类似RN的 热替换 或 LiveReload
功能呢?
Mac端文件权限问题
在Mac端Shell工具进入Weex
的目录,无论npm
相关命令,还是git
操作都需要sudo
权限,好麻烦。我很懒的,Weex
在创建文件的时候能不能帮我把写权限的事也做了?
哈哈,是不是我太蠢没能领悟到技巧,不对的地方欢迎留言指正哈。不过前端工程师都是挑剔的,希望Weex
能不断改进和完善!