Due to the need for efficiency and dynamic development, wireless development frameworks have been updated, from Hybrid, Structured Native View, React Native, Weex, and now Flutter. What is the right framework for your team? Not just technical pursuits, but practical business needs. Recently, Youzan Mobile chose WEEX as the wireless development framework and built a closed-loop process from development, Debug, construction, release and data. This article will share them.

What is WEEx

Weex is a set of alibaba open source to build high-performance, scalable native application cross-platform development program. First of all, summarize the characteristics of WEEX:

  1. Page development is currently supportedRaxandVue

    Weex doesn’t just support Vue and Rax. You can also integrate your favorite front-end frameworks into Weex. There is a documented extension front-end framework that describes how to do this, but the process is still very complicated and tricky, and you need to understand many of the low-level details of jS-Native communication and native rendering engines.

  2. One preparation, three terminal (Android, iOS, front-end) running

    The premise is that all integrate weeX SDK, in addition, the visual performance is not exactly the same, some will have some differences, need to make adaptation. Therefore, if the WEEX page supports three terminals, you need to perform self-test on all three terminals.

  3. UI is drawn through native components, JavaScript logic runs in the JS engine, and the two communicate through JavaScriptCore

    All components used in WEEX need to be registered in the native terminal, so that they can be used in WEEX. When running, they can be searched through the map recorded during registration. Weex SDK built-in register some basic components, including list, text, input, and so on. WXJSCoreBridge encapsulates the communication between JavaScriptCore implementation native and js.

  4. Support Native extension

    Native UI components can be packaged into Components, and native logic codes can be packaged into modules. So it can be used in weeX. Natiev UI components here include Modal, WebView, image, etc. Native logic codes here include storage, network, etc.

  5. Each WEEX page will be packaged into a JS file, weeX SDK will render JS file into a View WEEx package through webpack, each page will be packaged into a separate JS file, WEEX SDK will parse JS, Draw the UI part as a View and bind the view’s events to the JS code.

Second, why use WEEX for wireless development

1. Efficiency

1) Labor cost of development

If not web end, a page should have Android and iOS 2 personal development; With Weex, only 1 development page is required.

2) Compilation speed of development

As the project grows larger, Android projects can take 2-3 minutes to compile at a time, another 10 minutes if the machine is not good, and iOS can be a bit faster and take 1-2 minutes. After the WEEx is used, the interface modification takes about 10 seconds.

3) Test efficiency

After the test, the bug is found and the repair is completed. The test always needs to download a new package for installation. After using WEEx, you can test and restart the App for bugs that are irrelevant to the original.

2. The dynamic

Weex page packaging is a JS file, as long as the dynamic delivery of JavaScript can be achieved, it can be dynamic, hot repair, even hot deployment, complete replacement or new pages.

3. The maturity

In 2016 Alibaba Double 11, Weex coverage rate in Alibaba Double 11 venue is close to 99%, the number of pages is close to 2000, covering the main venue, sub-venue, sub-venue, crowd venue and almost all of alibaba Double 11 venue business. The second opening rate of the main venue of Alibaba Singles day reached 97%, and the pages of all venues reached 93%. On December 15, 2016, Alibaba announced that it would donate the mobile open source project Weex to the Apache Foundation for incubation. In 2017, Weex grew in Alibaba business as shown in the figure below, from WeexConf 2018.

4. Access cost

After practice, a mobile terminal development, a week can start to use WEEX business development.

How to use WEEX for wireless development

Weex is actually a set of solutions. Many things in each process need to be built by ourselves. It should be built so that partners can start using WEEX at a small cost and integrate it into the existing system. In this regard, we have made the following efforts and still have a long way to go.

1. Development tool Zweex-Toolkit

Weex-toolkit is a scaffolding tool based on the official WEEX toolkit. It is used for weeX construction. Currently, it only supports VUE.

With the increase of pages and the complexity of business, the project will gradually become huge. If all pages run slowly every time. To solve this problem, you can use Zweex-Toolkit to create and build project templates. When running, you can only run the pages in the specified directory, as long as you add parameters after NPM start, such as:

npm run start hi,helloworld
Copy the code

This means that only pages in the HI directory and helloWorld will be run. In addition, we support:

  • The new pagezweex page
  • Open the debugzweex debug

2. Implementation of ZanWeex SDK

What the official WEEX SDK does is input a JS file and return a view. Taking into account the routing and personalization needs of each application, the ZanWeex SDK does nothing else at this point but returns a view that the business side can add to the view where it wants to display it. The ZanWeex SDK does several things:

1) Support delivery configuration, support dynamic, can complete the replacement of the entire page

The weeX page is packaged as a JS file, so it can be delivered for dynamic update. Therefore, a configuration is required to associate the relationship between the page routing and the JS file. Therefore, we designed the following data structure:

H5: indicates the page routing address. You can directly use the H5 address generated by the publishing platform

Js: address of the packaged JS file

Version: The lowest supported version of the App, because if a new page requires a Native extension, a new version will be released to support it

Md5: To verify integrity, we add md5 to the configuration for each JS file.

2) Support independent configuration of multiple modules without mutual influence there will be multiple modules in an App, and each module may be responsible for by an independent team. Therefore, in order to reduce coupling, we will configure independently. Each module can independently manage its own configuration and access weeX independently, independent of the host App.

3) Preload page template, support page template cache and configuration cache

  • If there is no caching, every time the page template is pulled from the server, it will not be able to reach the second opening, not much different from the H5 page without caching. Our SDK will preload the page template to the local, opened pages will be cached in memory. The render time will be closer to the native render time.

4) Support hot reloading during development and experience like front-end development

  • If you do not have hot reloading, you will have to exit the page and re-enter it every time you modify it. To eliminate this operation, hot reloading is necessary.
  • Weex project local development, through webpack-dev-server to start a Websocket, Zan Weex SDK opened a WEEX page, to establish a connection with it. Webpack-dev-server sends the compilation status of the project to ZanWeex SDK, and when it receives the instruction that the rendering is complete, it rerenders the page, so as to achieve hot reloading.

5) Support page adaptation, providing environment variables ZanWeex SDK will provide the following four variables to be used in WEEX pages to facilitate page configuration.

  • The height of the container: weex. Config. Yzenv. ViewHeight
  • The width of the container: weex. Config. Yzenv. ViewWidth
  • The status bar height: weex. Config. Yzenv. StatusBarHeight
  • At the bottom of the column height (for iPhone X, 0) other: weex. Config. Yzenv. BottomHeight

During the development phase, logs in the WEEx SDK source code and js console. Log output, as well as JS running errors, can only be viewed through XCode and Android Studio. This is very inconvenient for a developer who only knows one side. When you open the WEEX page, this entry will be displayed. You can click to view the output logs.

7) Parameter transfer Forward parameter transfer: jump from page A to page B. Parameter transfer is A scenario that the development process will definitely encounter. Parameters of renderByH5 provided by SDK include URL, Params and data. When rendering, the business side can pass the parameters directly after the URL, or pass them in through params and data, and fetch them in different ways:

  • Url behind the parameters, will be passed into data, WEEX page in data directly defined parameters will automatically assign;

  • Params parameters can be obtained through weex.config.name in the WEEx page.

  • Data Indicates the parameter passed in. The method of obtaining the parameter is the same as that in the first method.

  • Reverse parameter passing: It is also common to return from page B to page A with parameters. The SDK provides a unified storage class, ZParamStorage, to temporarily store parameters. Page B will store data in the storage when it returns, and page A will fetch data from the storage when it displays, and then empty the storage.

  • Non-jump parameter transmission: The BroadcastChannel can be used to transmit parameters between WEEX pages, and the transmission between WEEX and Native pages can be realized by encapsulation Module.

3. Page development

As mentioned earlier, WEEX pages can currently be written in VUE or Rax. The syntax of Vue and Rax is not stated here. Here is a summary of several problems that can easily get stuck in actual development.

1) How to determine whether a page is implemented with WEEx?

It can be argued that all new pages can be developed using WEEx, the difference being how many native capabilities the page uses. You can call native capabilities by customizing modules and use native components by customizing Components.

2) When do YOU need to customize a Module?

  • When native abilities are needed, such as:
    • To invoke the system select picture interface
    • Call and send SMS functions
    • Open other apps
  • Invoke existing business logic, for example:
    • Encryption and decryption logic
    • The login logic

3) When do YOU need a custom Component?

  • If a component is already implemented using Native, it can be packaged as a Component for consistency
  • If a component cannot be implemented using WEEX, such as map component, ultra long graph display, etc

4) How to realize the layout of multiple shells?

Weex page rendering hierarchy, from top to bottom, the lower the layout, display the higher. So for the layout of the shells, put it at the bottom.

5) How to realize the animation of the page?

The official WEEX SDK has encapsulated the Animation module can be directly used, complex animation can be implemented using BindingX.

6) How to reuse weeX code?

The code can be pulled out of the component.

  • As a UI component, detached into a component that exposes property parameters and event interfaces;
  • As a separate JS function, it is separated into a JS for other pages to import;
  • CSS styles can also be detached into a CSS file for other pages to import;
  • If multiple component forms are included, they can be introduced through mixins.

4. Build and package platforms

We developed a project-by-project build platform:

  • Multiple branches can be added to each project, which can be branches of different warehouses. A project may be cross-team and cross-module, but it needs to be released together.
  • The build is built through WebPack, and once built, it supports publishing offline storage and online CDN

We also developed an app-by-app weeX distribution platform:

  • Application here is an abstract concept, not a traditional “application”, can be understood as a module
  • After the construction platform is completed, the service side can click to go to the publishing platform for publishing. No operation is required except the minimum supported version number for the first time.
  • The release platform supports grayscale release, full release and rollback.
  • The release platform will show weeX usage on the end, rendering time, rendering error, download time, etc

Problems encountered and solutions

In the development process, many problems can be solved by reading the source code, such as:

  • Does iconFONT already support caching when you use it?

    A: It is supported, including memory cache and file cache. Memory cache uses familyName as the key, and file cache uses MD5 (URL) as the local file name

  • Can functions implemented by module return parameters?

    A: The module functions UIThread and JSThread. JSThread is synchronous for JS threads and supports direct return of parameters. UIThread is asynchronous to JS threads and does not support returning arguments directly. Only callback can be used

In addition, we have addressed many common issues in ZanWeexSDK, including dynamic implementation, multi-module support, cache management, Hot Reloading, log viewing, page adaptation, parameter passing, etc.

In addition, there will be some common questions, listed here:

  1. What is the update mechanism for configuration? Update failed. How do I open the WEEx page?

    A: The configured update interface is open to the business side to call, and the business side decides when to call the update interface. The SDK does three things to try to ensure that the configuration can be updated successfully:

    1) If the interface fails to be pulled, three retries will be performed.

    2) When the network changes from no network to a network, the SDK will check whether the configuration has been pulled. If not, it will take the initiative to pull

    3) Allow the business side to build in the configuration and JS file, when pull failure, SDK will read from the built-in configuration

  2. What is the versioning of the configuration?

    A: When configuring each release, the lowest version of the App supported by the release is specified. Each request carries the App version number, and the server only returns the latest configuration that matches that version number.

  3. Is screen rotation supported or not?

    Answer: Yes. After rotation, the screen will be landscape, weex will render according to landscape size, the problem is that as long as you write a page that conforms to this change, it is no different from native implementation of the page.

5. Things to continue to do in the future

  1. Component library construction
  2. Performance statistics, such as frame rate, memory, CPU
  3. Incremental update and push update of configuration and JS files
  4. down-cycled