In QCon in April 2016, Alibaba senior director, Taobao mobile platform and new business division, Alibaichuan head Zhuang Zhuoran (also known as Ntien) announced that Ali mobile platform cross-platform development framework Weex began internal testing, and will open source in June. On the second day of QCon, Ali technical expert Xu Kai (known as ghost Road) and Ali front-end development expert Zhao Jinjiang (known as Hook) made a speech to the attendees called Weex — flexible mobile terminal high performance dynamic solution, which carried out a detailed analysis of the technical solution.
The following is a summary of the speech:
Yesterday nANTIan announced Weex open source internal beta, as of today noon, we count applications for internal beta users more than 1400 people, everyone’s enthusiasm is far more than our idea, thank you very much for your support.
In our thinking on mobile development best practices, we believe that the future of mobile development is a more balanced solution that must be both performance and dynamics. Second, it must be open and connected, as it has always been on the PC side, and in a very good state. We think the mobile Internet will definitely be based on a more popular technology system in the future, no barriers between platforms, simple and direct to use, which is what we hope to see most. Based on these assumptions, we have the Weex solution.
Weex was used in our official products for the first time on Last year’s Singles’ Day, carrying the work of the main venue. Some people may ask, is Weex in addition to the main venue, other places are more difficult? From last year’s Double 11 to now, including our own attempts and ali Intranet open source testing activities, everyone has also contributed a lot of content, including yesterday’s Keynote presentation of zombie animation, minesweepers, calculators, all kinds of rich scene things can be made through Weex, not only the main venue of the technical scheme.
Understanding of mobile development models
Let’s talk about Weex’s understanding of the mobile development model.
Most mobile apps today are a best practice. First, all mobile interfaces are divided into individual pages, with a routing control logic in the middle. At the same time, we need all kinds of rich capabilities on the mobile side to be available to developers in the form of apis. This is what we think is an ideal development model.
In terms of development model, we tend to provide developers with a development experience through some standardized things, including HTML, CSS and JS, which are very fast and easy to use. To emphasize, our syntactic design respects Web standards, including the core source code from vue.js, an excellent MVVM front-end framework. Our open source internal test synchronization was publicized overseas through vue. js Twitter and other channels, and received a very warm response. In just one day, the attention and enthusiasm of foreigners was beyond our expectation. Some people are very excited and excited and want to know when they will see the source code and contact us, which we feel is also something to be happy about.
Weex componentization and DSL syntax
Weex prepared pages naturally support componentization, first of all, our interface can be a componentization, a complex interface is divided into each component, just demonstrated are simple components, each component can be regarded as a section of Template, style, script, put into the model, corresponding to the interface structure, style details, Behavior definition. In a View, we tend to do a data binding between the data and the view that needs to be displayed and that needs to change dynamically, and then if I want to change the interface, I can do that by changing the data. This is a very smooth way to control logic and code from Model to View, which is also the basis of Weex syntax design. If the interface is complex, there may be more details or more decomposition, we need to disassemble the whole interface in modules and define each module. If the interface is complex enough, we can disassemble the interface into components first and then define the specific content of each component. It is defined in terms of structure, style, and behavior, and organically integrates these components to complete page development.
A brief description of key syntax. Let’s start with template, which has about a few elements. It starts with a virtual DOM Tree presentation, including event bindings, nesting between components, and child elements, which are the overall Template structure. Further down is style, which on the one hand samples common styles, and on the other hand makes the template structure clearer without getting bogged down in the whole concrete style description. We’re going to do a little bit of convergence here, and we’re only going to support the selector notation for a single class, just for performance reasons. Traditional CSS can be understood as an N to N database, the matching process is very complex, and the performance can not be very good guarantee. In order to ensure performance, we choose a selector in a single class, and the performance can be guaranteed.
The default is scoped. You can define a variety of classnames without worrying about colliding with other components. Global collision is one of the “seven SINS” of CSS.
In addition, you can do some display controls, such as if and repeat, which were also mentioned in the demo. This is a special one that I didn’t show you before. Append, on Android, which doesn’t perform as well, the interface loading process is something that the user is aware of, not instantaneous. We added this value to allow you to refine the granularity of the display interface. If the upper layer is appEnd equals Tree, a series of things will be loaded at once, which is a special design for performance optimization. And id, we can get that value by writing id in here, and pass it to the API as a parameter to do something with it.
The components that we have now supported, in addition to the div blank containers, images, and text that we just demonstrated, are sliders that perform well, and lists that do automatic memory management and resource management that perform well in all aspects of performance and frame rate. Input, the input field that we just did recently, that we just supported, maybe a little experimental stuff. Outside of this scope, businesses can scale horizontally on top, as described later. This is an introduction to the Template and style sections.
In the style part, we support Flexbox, which is very flexible, universal and convenient layout. With Flexbox, as long as your interface can be divided into tofu pieces, flexbox can be used to do it. At the same time, we also made fixed and sticky layouts, which means that if there is a list classification, For example, if the ABC letter of a contact is rolled out of the screen, it will stop at the top. The effect is sticky. When you swipe away, it will follow you. Also, more styles can be customized for each component, which is very flexible.
In terms of events, click is the basic event, change occurs when the value of the form changes and the first few frames of the slider changes. At the same time, we add appear and Disappear. When I enter the screen area by any operation, the appear event will be triggered, and disappear event will be triggered when I come out. Ideal for logical scenarios like lazyLoad. These events can also be scaled horizontally in their respective components.
The Script part is also mentioned in the example just now. It is mainly about viewModel design, and data and methods are the most important. After the value is modified, the value of the corresponding data binding will also change. In addition, we provide life cycle methods. When creating, when listening, and when rendering, you just need to write these three methods under data and Methods. And then there’s the native API, which also came up in the demo, so I’m not going to talk about it much.
Componentized scaffolding is very complicated, so by defining a component, let’s say I have a foo component above me, I can embed Foo in another component with a foo tag, and then I can write a and B in a Foo component, and then the foo element can be passed that way to the child element, and then I can process it. The communication between components is also an event mechanism. Each component can monitor and unbind user-defined events by and off. There are also three methods to trigger events: Pass only to itself, dispatch bubbles up to all parent components, and $broadcast broadcasts to all child components. These are very similar in design to Vue to communicate between components
In addition to the features we’ve just introduced, we’re going to have a lot more scenarios that we believe developers need and will encounter in normal development, a lot more forms, and better animations, including complex gesture scenes. In this respect, the performance, the development experience, the end result can be very good, which is what the team is trying to deliver in the future. At the same time, we hope to collect and share more relevant materials and make more tools to provide a better developer experience for everyone.
More content, including the Playground App shown just now, can be found on our official website. It is now in the open source internal testing stage, and you can submit your application so that you can visit the warehouse later to learn more specific content.
The working principles of Weex
This map we are not unfamiliar, also mentioned in front, hook said is mainly DSL this layer. Down to the Virtual DOM and Render layers; H5, I deliberately marked it in a different color to let you know that we wanted to show it on the three ends at the beginning of the design, so this place is a little brighter.
Let’s expand this picture a little bit. At the top is our DSL, which is generally called Weex file. Transformer layer is deployed to the Server, and the Server side is completed. You don’t have to worry about performance issues with our transformation because it’s already done on the server side. On the client side, the first layer is our JS-Framework, and then RenderRengine. On the left, we have our DSL file, and on the right, our jsbundle. In the DSL, the template will represent our types and child nodes. Convert classList to basic syntax conventions, including arguments. And finally the script, which is basically a literal translation. The input is Virtual DOM and the output is native or H5 view. Restore it to the tree data structure in memory. Then create the view, bind the event to the view and set the basic properties of the view. The dashed line is to go through a process in Native. On H5, it is equivalent to handing over the job to Webkit LayoutEngine to adjust the size and position of all elements. The whole picture basically explains the Weex Render process, we will be divided into three threads, different threads responsible for different things, let JS thread priority to ensure our fluency, we will have more technical documents in the future, more details released.
Weex performance, scalability, and availability
Here are some of the key points in the overall Weex architecture, which are probably the ones we’re most focused on right now, including performance, scalability, and usability.
First, performance. We have such an internal pressure test page. Our classmates put benchmark on the Playground, and you can see it if you download it. When we did the internal pressure test, we switched to 3,000 nodes, about 10 screens, with three cards on one screen and about 100 nodes on one card. Let’s take a look at the data. The first performance comparison is our loading time. For the same page, 1300 or 1600 are not particularly large, about 20%, and the frame rate difference is about one frame, which is similar to scroller. Down there is CPU, silent CPU consumption, and peak CPU during operation. The silent CPU is close to 0, we do not do 16 ms round, if do 16 ms round CPU will be higher.
This is a true business data, page launched in March after we checked, this page is a activities, the activities of the new trends in March, the activity List page to use, no special do contrast memory, the two devices is defined as a low-end machine, frame rate differential is more noticeable, both data and practical experience, fluency is probably this gap. We say often mentioned frame rate performance, load time, but often ignore a things, Native UI development usually there is no JS resources on the server load, Weex and similar dynamic scheme has a side effect, we must have a JS downloaded from the server, we put the JS built into the client, exempt from download problem, There’s a whole set of strategies involved here. We have a set of mechanics that we will open up as a separate technology product.
The next one is our compatibility. Compatibility is a problem not only for Weex, but also for partial core projects. Take Weex for example, the first row is our business code, and then look down, the above two changes, all the way to the client side, the whole scene will become N cubed. To give a specific number, my business code changed three versions, (English) three versions, and finally there will be three cubic 27 scenarios. Compatibility is something we always pay attention to. We did a few things, first of all, single test assurance, including single test of JS and H5, to ensure the very basic meaning of UT itself. The second is JS single test environment, we will generally (English) run in (English environment, but there are differences with JS security. Next is the automation work, which can also be divided into two parts: one is for comparison of screenshots, for example, we will say that we set a lot of various details of the attributes, how to say that you render is what you actually want, through the API level effect is not very good. Therefore, we will use screenshots to compare the final results with the expected results. Older and more mature kernels will do more mature, and there will be some reference. The other is layout results, quite a few, including model, including other layout classes. In fact, we can completely complete the test process through an element, its final width and height, the point in the upper left corner, through the basic information. So we work through these two pieces, and as soon as they’re ready, we’ll put them on top as soon as possible.
Then the expansibility, we first review this figure, also mentioned in front, Weex intuitive feeling is to use Weex to write a lot of pages, there is a routing mechanism, internal called navigation, to help you will be connected to the page, we provide a lot of features, by such a form of Weex we see a structure. For breakdown, if you extend a component, use anotation to identify input and output parameters for specific methods. This is a Module, you see the API on the DSL, the bottom layer is the Module. If the extension Module is the same, it’s a simple jump, basic information is brought in, business functions are implemented, one module is done, very simple.
This is the route, the whole route is just one part of the APP Framework, so there are a lot of things that need to be done in the planning. Look at components alone, including the first two, lifecycle consideration, animation and gesture, this is the most basic thing. Further down is the global communication mechanism between a number of Weex containers, data storage, network, including the following involves a bunch of sensors, including the basic FS, and partial business class things, the whole thing has synchronization in doing, but now the focus is in this piece of work. Back to the old problem, if we open a module, the upper layer provides THE API, the middle provides the adapter, if we provide free implementation will override the default, such as hand tao inside (TBxxx), override the default page (WXxxx), for everyone in the existing ability to enhance, or add new components, Or on a new Module that is already in this state.
And finally, we have usability, which I’ve talked about a lot, but I’ll just show you a couple of pictures here. This is our toolchain, red is done, yellow is done in May, June, before open source in June. The rest are things that we’re talking about internally and that we’re going to schedule time to work through, and those are tools. We will first provide you with a playground, which can be scanned with examples. The second is the debugging tool, chrome Dev Tools common features inside. As for the scaffolding, you can just use the playground for fun. If you want to make an independent APP, we will also provide scaffolding for you if you want to use Weex. The standalone project in our planning, not the final name, will eventually have a tool like APPHub. Including viewing information, displaying structures on the interface. This is the example mentioned just now. This is from playground. Although the screenshot shows that the effect of iPhone is exactly the same as that of Android, we have made a fun component library with the existing functions of Weex. Then there are our documentation, including the project guide, Reference, and Toolchain. I won’t go into details, but you can check it out.
Weex integration mode
Currently, Weex has three integration modes:
-
Full page mode o currently supports single page or whole app development using WEEX (not perfect, need to develop router and lifecycle management). This is the main mode and can be compared to RN.
-
Native Component model
O Use weex as an iOS/Android component, analogous to ImageView. This kind of demand is all over the main link of mobile shopping, such as home page, main search results, transaction component, etc. After communication with business students, the main body of this kind of Native page has been very stable, but the strong demand for local dynamic leads to frequent version issuance. Solving this kind of problem is also the focus of Weex.
O This also involves how to let Native students quickly start the “quasi-Web” development, interesting topic, we give some suggestions.
-
H5 Component model
O Use Weex in H5, analogous to WVC. Some complex or special H5 pages cannot be fully converted to Weex full-page mode (or RN) in the short term, such as cat pages, interactive pages, and some complex channel pages. Aiming at this pain point, I launched WVC project and verified such ideas in actual business: fine-tuning existing H5 pages and introducing Native to solve problems such as memory explosion of long lists, poor scrolling, poor animation/gesture experience and so on.
O WVC will be integrated into Weex, becoming Weex’s H5 Components mode. These three modes almost cover dynamic needs (for Native) or experience enhancement needs (for H5) in Amoy business. What’s more interesting is that the technical basis of all three modes is the same, which is important because it means that businesses can use Native or H5 Component modes to solve actual business pain points while smoothing the transition to Weex full-page modes. Look forward to Weex growing into the AppFramework.
Finally, here are some things we have done in the past five months or so. First we made the prototype, then we made the prototype independent of the SDK that the individual client can use, extended the style and layout, and extended the basic Component. These two months focused on the tools and open Source, and finally the end of June will be released.
This article appeared on InfoQ on April 29.
Baichuan.taobao.com is alibaba Group “cloud” + “end” core strategy is Alibaba Group wireless open platform, based on world-class back-end services and mature business components, through the opening of “technology, business and big data”, Provide mobile entrepreneurs with solutions that can quickly build apps, commercialize apps and improve user experience; At the same time, it provides diversified entrepreneurial services – physical space, incubation operation, venture investment, etc., providing comprehensive guarantee for mobile entrepreneurs.
About Alibaichuan
