网易严选App感觉Weex开发（已完结）

时间  2019-11-05
标签 网易 app 感觉 weex 开发 完结 繁體版
原文   原文链接

自打出生的那一天起，WEEX就免不了被拿来同React Native“一决高下”的命运。React Native宣称「Learn Once, Write Anywhere」，而WEEX宣称「Write Once, Run Everywhere」。在我看来，并无谁更好，只有谁更合适。下面我将围绕WEEX入门进行讲解。 （若是你尚不了解React Native，并想简单入门，能够阅读【整理】ReactNative快速入门笔记）javascript

网易严选App感觉Weex开发

什么都不说，先给你感觉下weex的效果。如下就是我使用weex，4*8h（不连续）作出来的demo，其中还包括素材收集，踩坑总结等时间。css

此处是github源码地址： github.com/zwwill/yanx… 感谢【Star】【Fock】支持随便搞html

不得不说，使用Weex开发App对于咱们纯前端人员来讲，是件***很爽***的事情，只要你熟悉了他的语法，基本能够作到一周上手写app。极其适合交互要求不高，时间紧迫，人手不足的同构开发需求。前端

可是，固然有可是，若是你想写出一个完美的app，你就须要在性能优化上下很大的功夫，包括动画的优化，过场的优化，图片的优化，细节的打磨等等，在这就是你须要掌握或者“能写”一些原生的代码，否则有些功能你是 实现不了的，好比status bar的属性更改，开场动画的制做，内存的回收，webview的监听等等。vue

下面咱们具体讲讲入门知识html5

Write Once, Run Everywhere

Weex 提供了多端一致的技术方案。java

  • 首先 web 开发体验在各端当中是相同的。包括语法设计和工程链路。
  • 其次，Weex 的组件、模块设计都是 iOS、Android、Web 的开发者共同讨论出来的，有必定的通用性和广泛性。
  • Weex 开发同一份代码，能够在不一样的端上分别执行，避免了多端的重复研发成本。

在同构这条路上，WEEX比ReactNative作得更完全，他“几乎”作到了，“你来使用vue写一个webapp，我顺便给你编译成了ios和android的原生app”node

至于为何要造这个轮子，官方给了如下说法android

一、今天在技术社区有大量的 web 开发者，Weex 能够赋能更多的 web 开发者构建高性能和高体验的移动应用。 二、Web 开发自己具备很是强的高效率和灵活性，这和 Weex 想解决的移动端动态性问题不谋而合。 三、Web 标准和开发体验是不少顶尖而优秀的科技公司共同讨论和建设的结果，自己的设计和理念都有极高的 四、品质保障，同时 Weex 也但愿能够借此机会努力为标准贡献一点本身的微薄之力。 五、Web 是一种标准化的技术，标准自己就是一种力量，基于标准、尊重标准、贴近标准都意味着拥有更多的可能性。 六、Web 今天的生态和社区是很是繁荣的，有不少成熟的工具、库、工程体系、最佳实践可使用、引入和借鉴。webpack

在我看来，WEEX实际上是alibaba团队提升生产效率的产物，在淘宝这类要求多端统一迭代快速的部门，三端约定一种便于统一的规范，在加上时间的发酵，渐渐的就有了此类脚手架的雏形，同时在脸书ReactNative开源带来的极大轰动后，本身也坐不住了吧^_^

好了，闲话就说到这，下面就来让咱们解剖一下WEEX的优劣良莠。

预科

入门Weex前须要了解如下知识，这样能帮助你更快的掌握 Node：Node.js 教程 Vue：《Vue.js官方教程》 ES6：《ECMAScript 6 入门》 再者就是ios和android开发语法的入门和编辑器的使用，固然

环境

系统环境要求

IOS : MacOS, 黑苹果 Android :MacOS, Linux, Windows

配置环境

你能够参考官方文档安装必须的依赖环境weex.apache.org/cn/guide/se…， 也能够直接安装如下环境

下载必须的插件： a) JDK1.8+ b) Show Package Details c) Android SDK Build Tools d) Android Support Repository

配置基础环境： a) ANDROID_HOME （如运行是遇到问题可参考此文www.jianshu.com/p/a77396301…） b) JAVA_HOME

Hello Weex

官方文档上的入门Hello world是web端的，紧接着介绍了如何集成 Weex 到已有应用

可是，身为一个web前端开发者，若是你不懂原生语音的话，介绍这些并不能起到很好的引导做用，由于web前端开发者都有***一统前端界***的野心（Web+Android+IOS），“寄人篱下”只能是暂时的。

因此快速建立并运行一个纯Weex App才是有意义的事儿。

若是你在官方教程里没有找到建立工程的教程，能够阅读此文《WEEX快速建立工程 Hello World》

Vue Native

Weex在迭代的过程当中选择了于Vue2.0握手，由于该版本的Vue加入了 Virtual-DOM 和预编译器的设计，使得该框架在运行时可以脱离 HTML 和 CSS 解析，只依赖 JavaScript，如此，Vue在和WEEX合做后，便得到了使用JS预编译原生的组件UI的能力。

同React Native同样，有人也将WEEX叫作Vue Native。

若是你对Vue还不了解，能够先学习【预科】部分推荐的《Vue.js官方教程》。

那么接下来咱们讲讲，Vue在WEEX中的不一样

Vue在WEEX中的不一样

虽然说WEEX使用vue语言写的，但毕竟是须要在不一样平台间运行的，虽然大部分语法都有支持，可是依然有部分语法是不一样的

语法差别

一、“html标签”

目前 Weex 支持了基本的容器 (div)、文本 (text)、图片 (image)、视频 (video) 等组件，注意是组件，而不是标签，虽然使用起来跟html标签很像，至于其余标签基本可使用以上组件组合而成。

二、Weex 环境中没有 DOM

由于Weex解析vue获得的并非dom，而是原生布局树

三、支持有限的事件

并不支持 Web 中全部的事件类型，详情请参考《通用事件》

四、没有BOM但能够调用原生API

在 Weex 中可以调用移动设备原生 API，使用方法是经过注册、调用模块来实现。其中有一些模块是 Weex 内置的，如 clipboard 、 navigator 、storage 等。 《clipboard 剪切板》 《navigator 导航控制》 《storage 本地存储 》 为了保持框架的通用性，Weex 内置的原生模块有限，不过 Weex 提供了横向扩展的能力，能够扩展原生模块，具体的扩展方法请参考《iOS 扩展》 和《Android 扩展》。

样式差别

Weex 中的样式是由原生渲染器解析的，出于性能和功能复杂度的考虑，Weex 对 CSS 的特性作了一些取舍 一、Weex 中只支持单个类名选择器，不支持关系选择器，也不支持属性选择器。 二、组件级别的做用域，为了保持web和 Native 的一致性，须要<style scoped>写法 三、支持了基本的盒模型和 flexbox 布局，详情可参考Weex 通用样式文档。可是须要注意的是，

  • 不支持display: none;
  • 样式属性暂不支持简写（提升解析效率）
  • flex布局须要注意web的兼容性
  • 不支持css动画和3D样式

Weex开发&调试

vue语法

举个栗子，如下是严选App Demo首页的简化代码

<template>
    <div class="wrapper">
        <text class="iconfont"></text>
        <home-header></home-header>
        <scroller class="main-list" offset-accuracy="300px">
            <refresher></refresher>
            <div class="cell-button" @click="jumpWeb('https://m.you.163.com')">
                <yx-slider :imageList="YXBanners" ></yx-slider>
            </div>
            <div class="cell-button">
                <block-1 :title="block1.title" :items="block1.items"></block-1>
            </div>
        </scroller>
    </div>
</template>
<style scoped>
    .iconfont {  font-family:iconfont;  }
    .main-list{ position: fixed; top: 168px; bottom: 90px; left: 0; right: 0;  }
</style>
<script>
    var navigator = weex.requireModule('navigator');
    import util from '../../src/assets/util';
    import Header from '../components/Header.vue';
    import refresher from '../components/refresh.vue';
    import YXSlider from '../components/YXSlider.vue';
    import Block1 from '../components/Block1.vue';
    export default {
        components: {
            'home-header': Header,
            'refresher': refresher,
            'yx-slider': YXSlider,
            'block-1': Block1
        },
        data () {
            return {
                YXBanners: [
                    { title: '', src: 'http://doc.zwwill.com/yanxuan/imgs/banner-1.jpg'},
                    { title: '', src: 'http://doc.zwwill.com/yanxuan/imgs/banner-2.jpg'},
                    { title: '', src: 'http://doc.zwwill.com/yanxuan/imgs/banner-3.jpg'}
                ]
            }
        },
        methods: {
            jumpWeb (_url) {
                const url = this.$getConfig().bundleUrl;
                navigator.push({
                    url: util.setBundleUrl(url, 'page/web.js?weburl='+_url) ,
                    animated: "true"
                });
            }
        }
    }
</script>
复制代码

若是以上代码脱离工程单独出现，基本上是没法得知他是weex工程。此处可切实感觉到weex的web开发体验

名不副实的<标签/>

<template>
  <div>
    <text v-for="(v, i) in list" class=“text”>{{v}}</text>
    <image style="" src=“"></image> <video class="video" :src="src" autoplay controls @start="onstart" @pause="onpause" @finish="onfinish" @fail="onfail"></video> </div> </template> 复制代码

weex工程中经常使用的标签有<div/>，<text/>，<image/>，<video/>（组件另算），由此四种标签基本能够知足绝大多数场景的需求，虽然说此标签同web工程下的标签用法一致，但此处的标签已再也不是咱们前端口中常提的html标签，并且名不副实的weex标签，确切讲是weex组件。

经过weex-loader、vue-loader、weex-vue-render的解析最终转换输出的即是实际的组件，有此设计只是为了完成**“web开发体验”**的目标。可是咱们身为上层的开发人员要清楚本身天天“把玩”的究竟是个什么“鬼”。

阉割版CSS

其实用阉割版来形容 weex 的 css 支持度并不合适，但若是从“web开发体验”的角度来衡量，那么这个形容词也是能够理解的。（此处对weex寄有厚望^_^）

单位

weex 中的全部 css 属性值的单位均为 px，也可省略不写，系统会默认为 px单位。

选择器

Weex 中只支持单个类名选择器，不支持关系选择器，也不支持属性选择器。

/* 支持单个类名选择器 */
.one-class {
  font-size: 36px;
}
/* 不支持关系选择器 */
.parent > .child {
  padding-top: 10px;
}
/* 不支持属性选择器，不支持 v-cloak指令 */
[v-cloak] {
  color: #FF6600;
}
复制代码

这个只是对样式定义的限制，不影响样式类名的使用，在标签中能够添加多个样式类名，如：

<template>
  <div class="one two three"><div>
</template>
复制代码

盒模型

weex支持css基本的盒模型结构，但须要注意的是

  • box-sizing 属性值默认为 border-box
  • margin，padding，border等属性暂不支持合并简写

FlexBox

weex中对flexbox布局支持度很高，但依然有部分属性并不支持，如 align-items:baseline;、align-content:space-around;、align-self:wrap_reverse;等。

具体weex对flexbox的支持和布局算法，可经过此文进行了解由FlexBox算法强力驱动的Weex布局引擎，此处便再也不赘述。

显隐性

在 weex 的 ios 和 android 端，并不支持 display 属性。

所以，不能使用 display:none; 来控制元素的显隐性，所以vue语法中的 v-show 条件渲染是不生效的。

咱们可使用 v-if 代替，或者用 opacity:0; 来模拟。

须要注意的是，ios和android端并不能使用 opacity:0; 来彻底模拟 visibility: hidden;，由于，当opacity的只小于等于0.01时，native控件便会消失，占位空间还在，但用户没法进行交互操做，点击时会发生点透效果。

CSS 3

Weex支持css3属性，虽然支持并不够，但相较RN的“不能用”已是强大不少了。

如下几种属性咱们在开发前须要知道她的支持度

  • transform：目前只支持2D转换
  • transition：v0.16.0+的SDK版本支持css过分动画，可根据状况配合内建组件 animation 实现动画交互
  • linear-gradient：目前只支持双色渐变色
  • font-family：weex 目前只支持ttf和woff字体格式的自定义字体

第三方工具库

因为使用了加强版的webpak打包工具weexpack，支持第三方框架也是件天然而然的事情。

经常使用的有 vuex、vue-router 等，可根据项目实际状况引入须要的第三方工具库

npm包管理

npm 包管理是前端开发朋友们再熟悉不过的包管理方式了。这也是为何ReactNative和Weex都选择这种管理方式的缘由。

如下是本工程的 package.json 文件，这里就不作讲解了，不熟悉的朋友点这里->NPM 使用介绍

{
  "name": "yanxuan-weex",
  "version": "1.0.0",
  "description": "a weex project",
  "main": "index.js",
  "scripts": {
    "build": "webpack",
    "build_plugin": "webpack --config ./tools/webpack.config.plugin.js --color",
    "dev": "weex-builder src dist -w",
    "serve": "webpack-dev-server --config webpack.dev.js -p --open"
  },
  "keywords": ["weex"],
  "author": "zwwill",
  "license": "MIT",
  "dependencies": {
    "vue": "^2.4.2",
    "vue-router": "^2.7.0",
    "vuex": "^2.1.1",
    "vuex-router-sync": "^4.3.0",
    "weex-html5": "^0.4.1",
    "weex-vue-render": "^0.11.2"
  },
  "devDependencies": {
    "babel-core": "^6.21.0",
    "babel-loader": "^6.2.4",
    "babel-plugin-add-module-exports": "^0.2.1",
    "babel-plugin-transform-runtime": "^6.9.0",
    "babel-preset-es2015": "^6.9.0",
    "babel-runtime": "^6.9.2",
    "css-loader": "^0.26.1",
    "history": "^4.7.2",
    "quick-local-ip": "^1.0.7",
    "vue-loader": "^13.0.4",
    "vue-template-compiler": "^2.4.2",
    "webpack": "^2.7.0",
    "webpack-dev-server": "^2.4.2",
    "weex-builder": "^0.2.7",
    "weex-loader": "^0.4.5",
    "weex-router": "0.0.1"
  }
}
复制代码

UI尺寸适配

Weex 容器默认的显示宽度 (viewport) 是 750px，页面中的全部组件都会以 750px 做为满屏宽度。

这很像移动设备的逻辑像，好比iPhone 6的物理像素宽为750，逻辑像素

Type iPhone 3G iPhone 4 iPhone 6 iPhone 6Plus
物理像素 320x480 640x960 750x1134 1080x1920
逻辑像素 320x480 320x480 375x667 414x736
像素比 @1x @2x @2x @3x

类比在Weex中，若是全部的显示宽度都是用默认值750，那么显示出来的实际像素信息为

Type iPhone 3G iPhone 4 iPhone 6 iPhone 6Plus
物理像素 320x480 640x960 750x1134 1080x1920
显示像素 750x1125 750x1125 750x1134 750x1333
像素比 @0.427x @0.85x @1x @1.44x

因此咱们在使用weex作UI适配时就没有所谓的@2x图和@3x图，全部的尺寸都是Weex帮咱们根据750做为基数宽作的缩放。

固然，Weex 提供了改变此显示宽度的API，setViewport，经过此方法能够改变页面的显示宽度，能够实现每一个页面根据本身的需求改变基数逻辑尺寸

所以对于一些固定的icon，不建议使用普通的静态图片或者雪碧图，这里建议使用矢量的字体图片，有如下优势：

  1. 适量图不会变糊
  2. 使用方便，经过css的字号控制大小，不用适配机型和屏幕尺寸
  3. 引用ttf文件，体积小，且容易更新

本地调试

Weex的调试方式有多种，若是说RN的调试模式是解放了原生开发的调试，那么weex的调试方式能够说是赋予了web模式调试原生应用的能力。

方法一

此方法多用于解决bug，检测控件的布局问题

# 调试单个页面
$ weex debug your_weex.vue
# 调试整个工程
$ weex debug your/path -e App.vue
复制代码

执行调试命令后，会将指定的文件打包成 JSBundle，并启动一个 weex Devtool 服务（http://localhost:8088可访问，以下图），同时将 JSBundle 文件传递至该服务跟路径下的weex文件夹内（http://localhost:8088/weex/App.js，实际是下图右边二维码的的内容）。

使用Weex Playground App扫下左二维码进入调试模，见下图

再次扫码右方二维码，点击【inspector】便可进入调试模式。

每个控件都是相同的数据结构

<view class="WXText" frame="{{0,0},{414,736}}" hidden="NO" alpha="1" opaque="YES"></view>
复制代码
  • class：表明原声空间类型
  • frame：表示空间的坐标和大小
  • hidden：表明显隐性，css中visibility设置的值
  • alpha：不透明度，css中opacity设置的值
  • opaque：默认为YES，打开绘图系统性能优化的开关，即不去计算多透明块重合后的真正颜色，从而减少GPU的压力，weex中具体有没有地方能够设置这个开关暂时不清楚，有猎奇心的朋友能够研究下。

方法二

此方法多用于开发调试，试试观察结果

$ weex your_weex.vue
复制代码

若是出现access权限报错，使用管理员指令

$ sudo weex your_weex.vue
复制代码

此时本地同时启动一个watch的服务器用于检查代码变动，自动从新构建JSBundle，视觉同步刷新。

上图看到的效果即为H5页面的效果，咱们通常在整个单页编写完成后在使用 Weex Playground App 扫码查看真机效果，或者你也能够在编写的同时使用真机观察代码的运行效果，每次从新构建包到重绘的速度仍是很快的。

但前提是你要保证，你的手机和电脑的连在同一个局域网下，而且使用IP访问。

Weex的原理

虽说，weex能够抹平三端开发的差别，可是知其然也应知其因此然使用起来才能游刃有余。

打包

熟悉RN的人都知道，RN的发布实际上就是发布一个JSBundle，Weex也是这样，但不一样的是，Weex将工程进行分包，发布多个JSBundle。由于weex是单页独立开发的，每一个页面都将经过weex打包器将vue/we页面打包成一个单独的JSBundle，这样的好处在于减小单个bundle包的大小，使其变的足够小巧轻量，提升增量更新的效率。

# 仅打包
$ npm run build
# 打包+构建
$ weex build ios
# 打包+构建+安装执行
$ weex run ios
复制代码

以上三种均会触发weex对工程进行打包。 在咱们执行了以上打包命令后，全部的工程文件将被单独打成一个独立的JSBundle，以下：

打包后的JSBundle有两种格式 

# 由.vue文件打包出来的包格式（简写），使用vue2.0语法编写
// { "framework": "Vue"} 
/******/ (function(modules) { 
          .......
/******/ })
复制代码
# 由.we文件打包出来的包格式（简写），使用weex语法编写
// { "framework": "Weex" }
/******/ (function(modules) { 
          .......
/******/ })
复制代码

不一样的头部是要告诉使用什么语法解析此JSBundle。

至此，咱们准备“热更新的包”就已经准备完毕了，接下就是发包执行了。

发包

打包后的 JSBundle 通常发布到发包服务器上，客户端从服务器更新包后便可在下次启动执行新的版本，而无需从新下载 app，由于运行依赖的 WeexSDK 已经存在于客户端了，除非新包依赖于新的 SDK，这也是热更新的基本原理。

【WeexSDK】包括

  • 【JS Framework】JSBundle 的执行环境
  • 【JS-Native Bridge】中间件或者叫通信桥梁，也叫【Weex Runtime】
  • 【Native Render Engine】解析 js 端发出的指令作原生控件布局渲染

执行

Weex 的 iOS 和 Android 客户端的【JSFramework】中都会运行一个 JavaScript 引擎，来执行 JS bundle，同时向各端的渲染层发送规范化的指令，调度客户端的渲染和其它各类能力。iOS 下选择了 JavaScriptCore 内核，而在 Android 下选择了 UC 提供的 v8 内核（RN两端都是JavaScriptCore 内核）。

JSBundle被push到客户端后就会在JSFramework中执行，最终输出三端可读性的VNode节点，数据结构简化以下：

{
  tag: 'div',
  data: {
    staticStyle: { justifyContent: 'center' }
  },
  children: [{
    tag: 'text',
    data: {
      staticClass: 'txt'
    },
    context: {
      $options: {
        style: {
          freestyle: {
            textAlign: 'center',
            fontSize: 200
          }
        }
      }
    },
    children: [{
      tag: '',
      text: '文字'
    }]
  }]
}
复制代码

有了统一的VNode节点，各端便可根据本身的方法解析渲染原生UI了，以前的全部操做都是一致的，包括文件格式、打包编译过程、模板指令、组件的生命周期、数据绑定等。

然而因为目标执行环境不一样（浏览器和 Weex 容器），在渲染真实原生UI的时候调用的接口也不一样。

此过程发生在【Weex SDK】的【Weex Runtime】中。

最总【Weex Runtime】发起渲染指令callNative({...})有RenderEngine完成渲染

总结一下

  • weex文件分包打包成单个JSBundle文件
  • 发布到发包服务器上，经过热更新push到用户的客户端，交由【Weex SDK】执行解析
  • SDK中的【JS Framework】执行Bundle脚本生成Virtual DOM
  • Virtual DOM经由各端执行环境【Weex Runtime】解析翻译成执行指令
  • 【Native RenderEngine】接收到指令后执行渲染操做，做出渲染出完整的界面

官方配图：

扩充配图：

Weex 的工做模式

1. 全页模式

目前支持单页使用或整个App使用Weex开发（还不完善，须要开发Router和生命周期管理）。

本文先行的严选demo即是使用第二种全屏模式，使用Weex开发整个App，期间触碰到Weex的在此模式下诸多不足，如StatusBar控制、Tab切换、开场动画自定义、3DTouch、 Widget等等原生的特点功能没有现成的API，须要咱们本身扩展，甚至扩展不了。所以并不能彻底“灭掉”原生。

因此，目前在阿里内部使用较多的是此模式中的单页模式，这也是为何官方文档在介绍原理后就直接奔入集成到原生应用的主题上去了。

2. Native Component模式

把Weex看成一个iOS/Android组件来使用，类比ImageView。这类需求遍及手淘主链路，如首页、主搜结果、交易组件化等，这类Native页面主体已经很稳定，可是局部动态化需求旺盛致使频繁发版，解决这类问题也是Weex的重点。

3. H5 Component模式

在H5种使用Weex，类比WVC。一些较复杂或特殊的H5页面短时间内没法彻底转为Weex全页模式（或RN），好比互动类页面、一些复杂频道页等。这个痛点的解决办法是：在现有的H5页面上作微调，引入Native解决长列表内存暴增、滚动不流畅、动画/手势体验差等问题。

另外，WVC将会融入到Weex中，成为Weex的H5 Components模式。

严选 App Demo 实现过程当中的感想

Vue-Router & Tab

因为Weex没有封装Tab的组件，所以笔者使用了不少方法来实现Tab切换的功能。

一、vue-router：router思想方便管理，可是每次切换都是新的实例，没有tab模式 二、opacity、visablity：此处须要注意，Weex的渲染机制和web是有区别的，对夫层设置opacity或者visiablity隐藏是没法同时隐藏定位为position:fixed; 的子元素。 三、position、transform：改变tab层的位置，此方法在定位为position:fixed; 的子元素上依然无效。

image & iconfont

Weex中全部的静态资源基本都是网络资源，包括图片、字体图片等，因此使用iconfont图标是再合适不过的了。

此demo中全部的icon均使用的iconfont。

此处强烈推荐一个站点www.iconfont.cn。

在此平台你能够找到几乎全部你须要的icon，你也能够上传本身的icon到本身建立的项目中。同时该系统还提供生成ttf、woff资源，而且作了cdn加速和gzip压缩，是否是跟weex很配呢？

不过也有风险，就是，若是哪天阿里不在维护并回收该平台的资源了，你的app可能就会变成这样，全是方框，或者padding掉你H5的页面

固然，这种及状况出现的概率很小，若是你是一个大公司，你手上有更好的资源急速方案，那就本身保存吧。

webview

UIWebView是咱们开发App经常使用的一个控件，不过Weex帮咱们封装好的API明显时不够用的，目前只有pagestart、pagefinish、error，并无封装像RN那样的onShouldStartLoadWithRequest拦截地址请求的API，在我看来，这有些不合理，并不清楚轮子的制造者是什么意图。

性能

性能是一个大课题，在此就不作展开了，只稍微说起一些咱们开发须要注意的几点

  • 性能影响点：UI更新>UI事件响应>后台运算
  • 合理优化过场&动画，过场和 console 容易引发 app crash 须要注意
  • 下降 js <-> native 的通讯频率
  • 优化list结构，下降重排重绘压力
  • 把优先级低且耗时较长的工做推后处理

Weex的现状

Weex解决了的

个人发布我作主（热更新）

脚本语言天生自带“热更新”，Weex针对RN的热更新策略作了优化，将WeexSDK事先绑到了客户端上，而且对JSBundle进行分包增量更新，大大提升了热更新的效率。

但优势也是缺点，若是新包依赖于心的SDK，此状况下，咱们须要发布还有新SDK的app到应用市场，用户也须从市场更新此app。不够随着WeexSDK版本的稳定后，相信此策略的优点就会凸显出来。

性能问题

Weex是一种轻量级、可扩展、高性能框架。集成也很方便，能够直接在HTML5页面嵌入，也可嵌在原生UI中。因为和ReactNative同样，都会调用Native端的原生控件，因此在性能上比Hybrid高出一个层次。

统一三端

虽然说这是一个大胆的实践，但对于大前端社区的统一有着推进做用，显然阿里在这一方面已经迈出了第一步。基本解决了三端同等需求致使资源浪费的痛点。

但后期可能会出现这种现象，开发一个三端的App会从原来的我的变成四我的，多出来的那一我的负责开发Weex单页。

意思就是，三端统一的不够完全，但就目前的环境下，这一句是最优方案了，倒是提升了开发效率。大前端未来将如何一统三国咱们且行且观望吧。

作游戏

对于一些交互视觉统一且没有很大的性能需求的游戏，Weex仍是能够胜任的。

近期笔者将尝试发布一款纯Weex构建的益智小游戏，敬请期待。

朋友们能够用这个demo体验下Weex 版扫雷游戏开发

Weex “暂时”放弃的

虽说大一统事件百利的事，但并不是无一害。

差别化

对于一些有差别化完美体验追求的项目就只能收敛或者放弃了。

独立的bug修复

对于三端同时上线，一端存在bug的状况，Weex并不能保证作到牵一发而不动全身。

个性化功能

好比安卓的波纹按钮、3DTouch、 Widget、iWatch版本等，目前这些功能仍是没有的，不知道之后Weex是否将其加入到官方文档中。

声明

以上均为我的看法，不表明官方。若有不当之处还望指正。

参考

[ 1 ] Weex官方文档 - weex.apache.org/cn/referenc… [ 2 ] 场景研读 - Native 性能稳定性极致优化 - https://yq.aliyun.com/articles/69005 [ 3 ] 门柳 - 详解 Weex JS Framework 的编译过程 - https://yq.aliyun.com/articles/59935?spm=5176.8067842.tagmain.66.1QA1fL [ 4 ] 阿里百川 - 深度揭秘阿里移动端高性能动态化方案Weex - https://segmentfault.com/a/1190000005031818 [ 5 ] 一缕殇流化隐半边冰霜 - Weex 是如何在 iOS 客户端上跑起来的 - http://www.jianshu.com/p/41cde2c62b81

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程