hanks10100 / incubator-weex

Mirror of Apache Weex

Weex

A framework for building Mobile cross-platform UI.

platform	status
Android
iOS
Mobile Web

Support Android 4.1 (API 16), iOS 8.0+ and WebKit 534.30+.

For Windows

Please INSTALL Git for Windows and run all the following commands in git-bash.

Meet Weex

• Install Weex Playground App to see examples we already written.
• If you want to write a demo, install weex-toolkit in Node.js 8.0+ and
• Run weex init to generate & start a simple project in an empty folder.
• Follow the instructions in the project README.
• Enjoy it.

Use Weex

• Tutorial
• Documents

Android

• Prerequisites
  • Install Node.js 8.0+
  • Under project root
    • npm install, install project
    • ./start
    • Install Android Environment
    • Install NDK r16
    • Install Cmake 3.9.0+
• Run playground, In Android Studio
  • Open android/playground
  • In app/java/com.alibaba.weex/IndexActivity, modify CURRENT_IP to your local IP
  • Click (Run button)
• Add an example

Runtime

On Android Platform , Weex code is executed in weex_v8core which is based on Google V8 JavaScript engine.

iOS

• run playground

  • Prerequisites
    • Install Node.js 8.0+
      • Under project root
        • npm install, install project
        • ./start
      • Install iOS Environment
      • Install CocoaPods
  • Run playground
    • cd ios/playground
    • pod install
    • Open WeexDemo.xcworkspace in Xcode
    • Click (Run button) or use default shortcut cmd + r in Xcode
    • If you want to run the demo on your device, don't need to modify CURRENT_IP manually. In DemoDefine.h(you can search this file by Xcode default shortcut cmd + shift + o), modify CURRENT_IP to your local IP
  • Add an example

• integrate to your application

  • CocoaPods

    Add the following line to your Podfile:

    pod 'WeexSDK'
  

  run pod install

  • Carthage

    Add the following line to your Cartfile:

    github "apache/incubator-weex"
  

  Run carthage update, and you should now have the latest version of WeexSDK in your Carthage folder.

Mobile Web

see weex-vue-render.

Scripts

See SCRIPTS.md for more information.

IDE Plugin & Syntax Highlight & DevTool

Weex team have developed a DevTool to help you to improve the debugging efficiency.

See more stuff on this wiki page

Weex Community

• StackOverflow: Ask questions about Weex.
• SegmentFault (cn): 中文交流与讨论
• FAQ
• Articles (cn): Weex 相关文章集合
• Telegram Russian Community Group

Contributing

See Weex Contributing Guide for more information.

incubator-weex's Issues

[Proposal] Native directives for recyclable list

需求背景

• 长列表（无限列表）在移动端很常见，会消耗大量渲染时间和内存，通常是性能瓶颈。
• 长列表中有大量节点不在可视区，回收并复用这些节点可以减少内存占用和创建新列表时的开销。
• 在 Weex 场景下，列表的渲染由前端框架实现，原生端无法介入此渲染过程，很难实现复用。

为了提升渲染性能，可以考虑提供新的渲染长列表的方式。

设计方案

设计思路：

• 前端框架中不将长列表展开，而是将列表数据和子节点的结构发送到客户端。
• 客户端根据数据和子节点的结构渲染生成列表，并且实现节点的回收和复用。

js 和 native 通信的数据格式

在定义列表的时候（假设是 <list> 组件），将把所有列表数据传递给客户端；在写列表的子组件的时候（假设是 <cell> 组件），会将其中添加的绑定关系发送给客户端，而不是在前端框架中展开取值。

通知 native 添加绑定的语法：

{ '@binding': 'prop' }

凡是遇到一个带有 @binding 属性的对象，都将其视为动态内容；属性值是个字符串，对应了列表每条数据里的某个字段。

通信格式的例子

上层语法还未确定，本例子只是用来说明 js 和 native 直接的通信格式。

<list :list-data="longList">
  <cell>
    <text>@[title]</text>
    <image src="@[source]">
  </cell>
</list>

将上述模板发送到客户端时应该是这样的：

{
  type: 'list',
  attr: {
    listData: [{ title: '', source: '' }, ..., {}]
  }
}

{
  type: 'cell',
  children: [{
    type: 'text',
    attr: {
      value: { '@binding': 'title' }
    }
  }, {
    type: 'image',
    attr: {
      src: { '@binding': 'source' }
    }
  }]
}

无论列表数据有多长，都将只向 native 发送这两个渲染指令。当列表数据有变化时，只需要重新发送数据，不需要前端框架再次执行渲染。

其他说明

在 Rax 中，可以直接写出绑定结构，不需要额外编译。

<list list-data={this.state.longList}>
  <cell>
    <text attr={ { value: { '@binding': 'title' } } }></text>
    <image src={ { '@binding': 'title' } }>
  </cell>
</list>

当普通文字和绑定混用时，则应该将其转换为如下格式：

<text>begin @[ content ] end</text>

{
  type: 'text',
  attr: {
    value: ['begin ', { '@binding': 'content' }, ' end']
  }
}

优缺点分析

优势：

• js 和 native 之间传递的数据量和频率变小。
• native 实现复用后内存开销变小。

初步实测，性能提升特别明显，尤其在内存占用方面。（数据待补充）

缺陷：

• 对现有语法改动较大，有破坏性，无论是前端框架还是原生渲染器都需要做大量修改。
• 容易和现有绑定语法混淆，代码不直观可读性差，在便携式的注意事项也变多了。