At qcon in April 2016, Zhuang zhuoran (Hua mingnantian), senior director of Alibaba, head of Taobao mobile platform and new business business business division, and Alibaba Baichuan, announced that weex, the cross platform development framework of Alibaba mobile, began internal testing and will be open-source in June. On the second day of qcon, Ali technical expert Xu Kai (huamingguidao) and Ali front-end development expert Zhao Jinjiang (huaminggougu) gave a speech to participants on weex – Flexible high-performance dynamic solution for mobile terminals, and made a detailed analysis of this technical solution.
The following is the arrangement of the speech content:
Yesterday, Nantian announced that weex launched the open source internal test. As of this noon, we have counted more than 1400 users applying for the internal test. Your enthusiasm far exceeds our imagination. Thank you very much for your support.
In our thinking of mobile development best practices, we believe that the future of mobile development is a more balanced solution, which must be both performance and dynamic. Second, it must be open and interconnected, and the PC side has always been like this, which is also a very good state. We think the mobile Internet will certainly be based on a more popular technology system in the future. There is no gap between platforms, and it is simple, direct and easy to use. This is what we hope to see most. Based on these assumptions, we have weex solution.
Weex has been used in our official products for the first time since last year’s double 11, and has carried the work of the main venue of double 11. Some people will ask, is weex more difficult than being the main venue? From last year’s double 11 to now, including our own attempt and Alibaba intranet to do open source internal testing activities, we have also contributed a lot of content, including yesterday’s keynote demonstration of zombie animation, Minesweeper, calculator, all kinds of rich scenes can be made through weex, not just the technical scheme of the main venue.
Understanding of mobile development model
Let’s talk about weex team’s understanding of the mobile development model.
Today, the vast majority of mobile app is such a best practice. First, all interfaces of mobile app are divided into pages, with a routing control logic in the middle. At the same time, we need a variety of mobile capabilities, which are provided to developers in the form of APIs. This is an ideal development model.
From the perspective of development model, we tend to provide developers with some standardized things, including HTML, CSS, JS, which are very fast and easy to learn syntax as a development experience. Here, we emphasize that our syntax design respects the web standard, including the core source code from vue.js, a very good MVVM front-end framework. Our open source internal test has been publicized overseas through vue.js’s Twitter and other channels, and received very warm response. In a short day, the attention and enthusiasm of foreigners are beyond our expectation. Some people are very excited and excited, want to know when to see the source code, and contact us, we think it is also a happy thing.
Weex’s componentization and DSL syntax
The page written by weex naturally supports componentization. First of all, our interface can be componentized. A complex interface can be divided into each component. What we just demonstrated is a simple component. Each component can be regarded as a piece of template, style, script, which is put into the model, corresponding to the structure, style details, and behavior definition of the interface. In view, we tend to make a data binding for the data and the parts of the view that need to be displayed and have dynamic changes. After binding, if I want to change the interface, I can do it by changing the data. This is a very smooth control logic and code mode from model to view, which is also the basis of the upper level syntax design of weex. If the interface you are working on is more complex, there may be more details, or more decomposition, we need to take the whole interface as a unit to disassemble, and define each module. If the interface is complex enough, you can first disassemble it into components, and then define the specific content of each component. The definition method is to define it from the perspective of structure, style and behavior, and combine these components in an organic way to complete page development.
A brief description of the key syntax. First, let’s look at template. There are several elements. First of all, it is a virtual DOM tree display, including event binding. Components and components can also be nested, and there can also be child elements. This is the overall template structure. The next step is style. On the one hand, we can sample the common style, on the other hand, we can make the template structure more clear, so that it will not fall into the whole specific style description. We will do some convergence here. We only support the selector writing of a single class, mainly from the perspective of performance. Traditional CSS can be understood as a N-to-N database. The matching process is very complex, and the performance can not be guaranteed very well. In order to ensure the performance, we set the selector in a single class, and the performance can be guaranteed.
In addition, our style naturally defaults to scoped. You can define all kinds of classnames without worrying about conflicts with other components. Global conflicts are one of the “seven sins” of CSS. In fact, we attach great importance to this, so in practice we have scoped it.
Other, you can do some display control, such as if and repeat, which were mentioned in the demonstration just now. The one I didn’t demonstrate just now is very special. Append. Under android with poor performance, the user can sense the loading process of the interface, not in a flash. We add this value to let you refine the granularity of the display interface. If the upper layer makes append equal to tree, a series of things in it will be loaded once. This is a special design from the perspective of performance optimization. Then there is the ID. we can get the value by writing the ID here, and pass it to the API as a parameter for processing.
The components we have now supported, in addition to the div blank container, picture and text just demonstrated, we also support the slider: a slider component with good performance, and a list component with automatic memory management and resource management in performance, which makes the performance and frame rate better. There’s also input, which we’ve only recently done, which we just supported, and maybe there’s something experimental. Beyond this scope, the business side can expand horizontally at the upper level, which will be described in detail later. This is an introduction to the template and style sections.
In the style part, we support flexbox, which is a very flexible, general and convenient layout. With flexbox, as long as your interface can be split into tofu blocks, you can use flexbox to make them. At the same time, we also make two special layouts: fixed and sticky. Sticky means that if there is a list classification, such as contact ABC letters rolling out of the screen, they will stop at the top. That’s the effect If it’s sticky, it will follow you when you drag it away. It’s a common thing among all kinds of mobile applications. Similarly, more styles can be customized for each component, which is very flexible.
From the event point of view, click is the basic event, and change occurs when the value of the form changes and the sliding frame changes. At the same time, we add the appearance and disappear. When I enter the screen area through any operation, the appearance event will be triggered, and when I come out, the disappear event will be triggered, which is very suitable for some logic scenes such as lazyload. These events can also be horizontally expanded in their respective components.
Just mentioned in the script part of the example, it is mainly the ViewModel design, the most important is data and methods. 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 data monitoring is completed, and when rendering is completed, you only need to write these three methods under data and methods. There are also native APIs, which also appeared in the demonstration just now. I will not introduce them here.
Componentization is very complex. By defining subcomponents, for example, I have a foo component above. Foo can be embedded in other components through the foo tag. When data is transferred, a and B can be written in the foo component. Foo elements can be transferred to the subcomponents in this way, and then processed. The communication between components is also an event mechanism. Each component can listen to and unbind custom events through $on and $off. There are three ways to trigger an event: only pass it to itself, dispatch bubbles up to all parent components, and $broadcast broadcasts to all child components. These designs are very similar to Vue, so as to achieve the communication between components.
In addition to the features just described, we will also provide richer scenes, more forms, and better animation display, including complex gesture scenes, which are believed to be needed by developers and will be encountered in normal development in the future. In this regard, the performance, development experience and final effect can be very good, which is what the team is trying to provide to you in the future. At the same time, we hope to collect and share more relevant materials, make more tools, and provide better developer experience for you.
More content, including the playground app just demonstrated, can be found on our official website. Now it is in the stage of open source internal testing. You can submit an application and visit the warehouse later to learn more specific content.
How weex works
This picture is not new to all of us. As mentioned earlier, the main point of Gougu is DSL. Then go down to the virtual Dom and render layer; H5, I purposely marked it with different colors, to let you know that at the beginning of our design, we wanted to show it on the three ends, so this place was slightly brighter.
Let’s expand the picture a little bit. At the top is our DSL. We usually call it weex file. We deploy it to the server through the transformer layer, and the server is finished. You don’t need to worry about whether our conversion has performance problems, because this has been completed on the server side. To the client, the first layer is our JS framework, and finally to renderrengine. Looking down, on the left side is our DSL file, on the right side is the converted jsbundle. In the DSL, the template will represent our types and sub nodes, and convert the classlist into the basic syntax convention, including the conversion of independent variables. Finally, the script is basically literal translation. If the input is virtual Dom and the output is native or H5 view, restore the tree data structure in memory, create a view, bind the event to the view, and set the basic properties of the view. The dotted line is a process on native. On H5, it’s equivalent to giving WebKit layoutene the task to do, and readjusting the size and position of all elements. The whole picture basically explains the weex render process. We will divide it into three threads. Different threads are responsible for different things. Let JS threads give priority to our fluency. In the future, we will have more technical documents and put out more details.
Weex’s performance, expansion, and availability
The following are the key points in the overall weex architecture, which may be the most concerned, including performance, expansion and availability.
First of all, performance. We have such a press test page inside. Our classmates put the benchmark on the playground. If you download it, you can see it. When we do the internal pressure test, we adjust to 3000 nodes, about 10 screens, one screen has three cards, and one card has about 100 nodes. Let’s take a look at the data. The first performance comparison is our load time. The same page 1300 and 1600 is not very large. It’s about 20%. The frame rate is about one frame away. The scroller is almost the same. The memory is better because we use the recycle view here. It’s better. Next, there is CPU, silent CPU consumption, and the peak value of CPU during operation. The silent CPU is close to 0:00. We don’t do 16 millisecond rotation. If we do 16 millisecond rotation, the CPU will be higher.
This is a real business data. After the launch of the page in March, we have a look at it. This page is an activity, a new fashion activity in March. This activity page does not use list, and there is no special memory comparison. These two devices are defined as low-end machines, and the frame rate differential pressure is quite obvious. Whether it’s data or actual experience, the fluency may be such a gap. We say that performance often refers to frame rate and loading time, but often ignores one thing. In native UI development, JS resources are usually not loaded on the server side. Weex and similar dynamic schemes have a side effect. We have a JS that must be downloaded from the server side. We build JS into the client side to avoid the problem of downloading. Here, a complete set of strategies are involved. We have a set of internal mechanism, which will be opened as an independent technical product later.
The next one is our compatibility. Compatibility is not only for weex, but also for partial internal nuclear projects. For example, the first row of weex is our business code. Looking down, the above two changes, until the client, the whole scene will become n cube. To give you a specific number, my business code has been changed to three versions, and there will be three cubes and 27 scenarios. Compatibility is a problem that we always pay attention to. We have done several things. First, single test guarantee, including single test of JS and H5, guarantees the meaning of the most basic ut itself. The second is JS single test environment. We usually run (in English), but there are still differences with JS security. Next is the automation work. This work can also be divided into two parts: one is for the comparison of screenshots. For example, our classmates will say that we have set many kinds of detail attributes. How can you say that what you render is what you really want? The effect of API level is not very good. So we will compare the final result with the expected result through screenshots, and the mature kernel will be more mature, which will also have some reference. In addition, layout results, quite a part, including model, including other layout classes, in fact, we can completely pass an element, and finally its width and height, the point at the upper left corner, through basic information, let it complete the test process. So we go through these two pieces of work, once mature, we will put them on it as soon as possible.
Then it’s extensibility. Let’s review this picture first. As mentioned earlier, at present, weex gives you an intuitive feeling that you can write many pages with weex. There is a routing mechanism called navigation inside to help you connect pages. We provide many features, which form a structure you can see in weex. In terms of subdivision, if you extend a component, some specific methods are used to identify input and output parameters with anonation. This is a module. What you see on the DSL is the API, and the bottom layer is the module. If the extension module is the same, it is a very simple jump. Basic information is brought up to realize business functions. A module is completed, which is very simple.
This is the route. The whole route is only a link in the app framework, so there are still many things to do in the next planning. Look at the components separately, including the first two. Next, consider the lifecycle, and then the animation and gesture. We think they are the most basic things. Next is the global communication mechanism between multiple weex containers, data storage and network, including a bunch of sensors involved below, including basic FS and partial business. The whole thing is being done synchronously, but now the work is focused on this part. Back to the old problem, if we open a module, the upper layer provides the API, and the middle provides the adapter. If we provide free implementation, we will overwrite the default page, such as tbxxx, wxxxx. For you, we have reached this state in terms of existing capabilities, new components, or new modules.
Finally, our usability. There are many things mentioned above. Just show a few pictures here. This is our tool chain. Red means finished. Yellow means finished in May and June, before the official open source in June. The rest are things that we are discussing in-house and we will arrange time to complete gradually. These are tools. First of all, we will provide you with a playground, which can scan the code, and also has its own examples. The second is debugging tools, which are common functions of chrome dev tools. Another is the scaffold. If you just play with it, you can use the playground. If you want to make an independent app by yourself, we will also provide you with the scaffold if you want to make it with weex. The independent project in our plan, not the final name, will eventually have a tool similar to apphub. Including information viewing and structure display on the interface. This is the example just mentioned. This is in the playground. Although the screenshot shows that the iPhone effect is exactly the same as Android, a more interesting component library has been made with the existing functions of weex. Then there are our documents, including project guide, reference and toolchain. I won’t talk about the details. You can go and have a look.
How weex integrates
At present, weex has three ways of integration:
Full page mode
O currently, it supports the use of single page or the use of weex for the whole app (it is not perfect, and needs to develop router and life cycle management). This is the main mode, which can be compared with RN.
Native component mode
O use weex as an IOS / Android component, similar to ImageView. This kind of demand spreads all over the main links of manual search, such as home page, main search results, transaction componentization, etc. after communicating with business students, the main body of this kind of native page has been very stable, but the strong demand of local dynamic leads to frequent publishing, so solving this kind of problem is also the focus of weex.
O this also involves how to let native students quickly start “quasi Web” development. It’s an interesting topic. Please give more suggestions.
H5 component mode
O use weex in H5, similar to WVC. Some of the more complex or special H5 pages cannot be completely converted to weex full page mode (or RN) in a short period of time, such as cat super, interactive pages, some complex channel pages, etc. Aiming at this pain point, I have launched WVC project, and verified the idea in the actual business: make fine-tuning on the existing H5 page, introduce native to solve the problems of long list memory explosion, rolling is not smooth, animation / gesture experience is poor, etc.
O WVC will be integrated into weex and become the H5 components mode of weex.
These three models almost cover the dynamic demand (for native) or experience improvement demand (for H5) of Taoyuan business. What’s more interesting is that the technical basis of these three modes is consistent, which is very important, which means that the business side can use native or H5 component mode to solve the actual business pain points, and at the same time smoothly transition to weex full page mode. We look forward to the day when weex grows up to appframework.
Finally, there are some things we have done in the past five months. First of all, we have made the prototype version. Then, we have made the prototype version independent of the SDK that can be used by the independent client. We have extended the basic component. These two months, we have focused on the tools and the work of open source. Finally, it will be open at the end of June.
Alibaba Baichuan (Baichuan. Taobao. Com) is the core strategy of Alibaba Group’s “cloud” + “end”. Based on the world-class back-end services and mature business components, through the opening of “technology, business and big data”, Alibaba Group provides mobile creators with solutions that can quickly build apps, commercialize apps and improve user experience. At the same time, Alibaba Group provides Diversified entrepreneurial services – physical space, incubation and operation, venture capital, etc., provide comprehensive protection for mobile entrepreneurs.