This article from the preparation of weex code, see how it finally arrived on the end

Weex overall structure

  • Business code exists on the server
  • The WEEX environment is installed in the terminal

Write vUE code locally

A typical VUE, or WEEX code is as follows (I copied it from someone else)

<template>
  <foo a="{{x}}" b="1" class="bar"></foo>
</template>

<style>
  .bar {width: 200; height: 200}
</style>

<script>
  module.exports = {
    data: function () {
      return {x: 100}
    }
  }
</script>
Copy the code

packaging

The VUE code will be rotated

define('@weex-component/main'.function () {
  module.exports = {
    data: function () {
      return {x: 100}
    }
  }
  module.template = {
    type: "foo",
    attr: {
      a: function () {return this.x},
      b: 1,
      classname: ['bar']
    }
  }
  module.style = {
    bar: {width: 200, height: 200}
  }
})
bootstrap('@weex-component/main')
Copy the code

Webpack then goes on to do some compression and packaging, becoming a JS bundle. Upload to the server.

Do not mix with the VUE framework itself

In Web development, the framework code is bundled with the business code, and the fundamental reason is that the browser environment cannot be customized. Without the framework code, the VUE code will not work. But in Weex, you have the ability and you have to build something on the server, and you just put the framework part on the server, which can greatly reduce the size of the bundle on the server.

Pull a package

After the weeX is uploaded to the server, you need to pull the latest package to load the WEEX. This is also the basis of dynamic. As for the pull package version, a configuration like “MIS system” will do.

Package cache

Generally, the WEEX version is not updated as frequently as the Web version. Therefore, an offline cache can be configured on the weeX to save traffic and ensure offline availability.

Get JS running

Package pulled down, the first thing to make JS run, provide the engine. Native will not work, this is the most basic capability provided by the Weex SDK, which is JSCore/V8 in the picture.

On the framework

What happens when you run? As mentioned earlier, the bundle does not include the vue framework, which is part of the SDK environment. After the bundle is removed, a framework is installed, which is called Weex-VUe-framework. React itself only provides the parts related to Virtual DOM until patch is issued with node operation (add, delete, modify) commands. The command execution after patch is handed over to other modules according to different platforms, such as DOM react-DOM and cross-terminal React-Native. The weex-VUE-framework is almost the same as vue.js, except that vue.js outputs DOM nodes, while Weex-Vue-framework patches out operations on native controls.

Operation/response Native

The source code is framed and needs further interaction with the native:

  • Patch Out node operation command (Add, Delete, modify) –> Perform operations on native controls
  • Invoke native capabilities, such as taking photos and making phone calls
  • Responds to events triggered by native controls

In Weex SDK, this part is implemented by JS-native Bridge. Bridge maintains all interactive methods, including registration and invocation at both ends, through a global. See the list below. Two important methods are provided: callNative and callJS.

Js native – callNative

CallNative is implemented by native code, registered in global for JS invocation, and sends instructions to Native, such as rendering, networking, authorizing and other client-side TOAST apis, to achieve the first two kinds of interaction. Js calls native automatically by calling the taskCenter send method. TaskCenter is bound to the Document object when the Document is initialized.

taskCenter.send->sendTasks->taskCenter.callbackManager.add(v)->global.callNative(... args)Copy the code

For example, patch generates a command to create a node and makes similar calls:

callNative({
  module: 'dom',
  method: 'addElement',
  args: ['_root', {
    ref: '2'.type: 'text',
    attr: { value: 'oh' },
    style: { textAlign: 'center', fontSize: 200 }
  }]
})
Copy the code

Of course, there is more than one way to tune JS native, which is just a general way. In fact, bridge is a registration mechanism where native registers its capabilities with the global, usually starting with call, when a call is not registered

callAddElement: function()
callNative: function()
callNativeComponent: function()
callNativeModule: function(a)Copy the code

Native js – callJS

CallJS is implemented by JS and is used by Native to send instructions to JS to achieve the third interaction. When the native control fires the event, native initiates the fireEvent, calls the callJS method, packages the Method name and parameters into JSON and passes them to JS. Js receives it with receiveTasks and distributes it to the Framework receiveTasks. ReceiveTasks calls fireEvent, finds the instance based on instanceID, and invokes fireEvent of instance.document.

callJS-> receiveTasks -> fireEvent -> instance.document.fireEvent -> if(domChanges){updateElement} -> element.fireEvent
Copy the code

Attached: global all methods

    callAddElement: function()

    callJS: function()

    callNative: function()

    callNativeComponent: function()

    callNativeModule: function()

    clearIntervalWeex: function()

    clearTimeoutWeex: function()
    createInstance: function()
    destroyInstance: function()
    getRoot: function()
    nativeLog: function()
    receiveTasks: function()

    refreshInstance: function()

    registerComponents: function()

    registerMethods: function()

    registerModules: function()

    registerService: function(a)setIntervalWeex: function(a)setTimeout: function(a)setTimeoutWeex: function()
    unregisterService: function(a)Copy the code

The resources

  • www.jianshu.com/p/3622fce02…
  • www.jianshu.com/p/32285c709…
  • Segmentfault.com/a/119000001…