Today, in mobile terminals, especially in apps like Mobile Taobao, the problem of dynamics has gradually become a thorny one. By “dynamic”, we mean to optimize the flexibility, iteration cycle and cost of mobile applications to the extreme. For example, the home page of mobile Taobao store allows merchants to decorate their stores in real time and update their commodities, activities and other information; Another example is the venue page of each promotion on Taobao and Tmall, which requires us to flexibly adjust the interface information and status in time to ensure that we keep up with the pace of promotion on the day of the rapidly changing activities and deal with various emergencies.
Why do you want to solve the dynamic problem
There are many inevitable factors for the emergence of dynamic demand: behind our mobile application is a platform-level or even eco-level e-commerce system, which needs to be able to accept all rivers and features high-speed circulation. Many mobile applications in the market also have similar objective forms and appeals. At the same time the whole industry accumulation on the mobile end so far is not enough to form, the user experience of product and the way of interaction in the early period of the details are completely grasp, a mobile application, objectively requires more attempt and exploration, and even “trial and error”, and the dynamic degree and the evolution of product iteration speed have a strong positive correlation; Third, we don’t have to reinvent the wheel on multiple sides for these dynamics, and we shouldn’t be constantly triggering new releases. So the issue of dynamics is particularly important on mobile today.
History of dynamic problems
The dynamic problem is not only unique to mobile terminals. In the long history of Internet technology development, desktop terminals also exist and experience similar things. The conclusion on the desktop today seems to be that the W3C’s long-advocated WebPlatform (also known as Web Apps or HTML5 or browsers), However, it also went through the process of de-platform differentiation, native plug-in support (Flash Player), device performance improvement, rendering engine optimization, etc.
On the mobile end, Alibaba’s wireless business Division, brother teams and the whole industry are making various positive attempts and practices:
-
Hybrid scheme: Taking WebView as the container and HTML5 as the cornerstone, dynamic product development is supported by the extension of defining native features, such as the WindVane container inside mobile Phone Taobao, which is usually very dynamic. However, the problem is as obvious as the dynamic itself, that is, the lack of performance and presentation effect. And want to give full play to its advantages in the project, developers in the front-end knowledge and experience of the accumulation of higher requirements, the space is limited not to do too much expansion.
-
Structured Native View scheme: Render at native level with Native View as container, define a set of data format (such as XML or JSON, etc.) describing view structure, and then dynamically change or request new such data information to achieve dynamic interface effect. For example, apps such as “Dynamic P”, “Bird’s Nest”, “Dynative” and “PageKit” have been developed in Alibaba Group. These apps rely on a structured interface description and focus on the dynamic performance of pure output dimension. However, they have some common shortcomings, such as dynamic processing of other dimensions, such as logic dynamics. Load policy dynamics, etc.
-
React Native solution: It is commonly referred to as RN and uses Native as the rendering engine. The script engine supports Virtual DOM conversion and logical control of the interface to achieve dynamic interface. RN in ali many team got the first half year practice, including my own wireless business, but the effect is not satisfactory, the first is an RN level is very heavy, on request, load, rendering, interaction, stability, etc are not ideal, and the technical solution in the community of iteration and evolution has been full of uncertainty, This creates a lot of confusion for team product-level use and follow-up.
In fact, we feel that RN is more of a new mobile development framework than it is designed to enhance the dynamics of existing mobile applications. RN is expected to solve the dynamic problem because it introduces a JavaScript engine on the client side.
Rethinking mobile dynamic scenarios: Weex
To sum up, we can see many solutions to dynamic problems, but they are all limited. After continuous observation and discussion, the team decided to come up with a better technical solution for mobile terminal dynamics — this is Weex today!
Weex design concept and thought process
Weex in our view has a lot of features, such as:
-
Dedicated to mobile terminal, full scheduling native capabilities
-
Fully resolve or avoid performance bottlenecks
-
Flexible extension, multi-terminal unity, elegant “downgrade” to HTML5
-
Keep development costs and learning costs low
-
Fast iteration, lightweight real-time release
-
Integrate into the existing native technology system
-
Engineering management and monitoring, etc
However, Weex’s core appeal is to solve the dynamic problem of mobile terminals. It has three distinct characteristics:
-
Lightweight: compact size, simple syntax, easy access and use
-
Extensible: The business can decentralize horizontal customization of components and functional modules
-
High performance: high speed loading, high speed rendering, smooth experience
Weex is designed for mobile dynamic issues, and these advantages are natural and pursuit of perfection. The team designed and implemented the whole technical solution based on these three aspects.
In Weex design and practice, the team also had a profound insight: to find a balance between performance and dynamics.
Looking at so many dynamic technology solutions, there are several necessary paths:
-
Development/configuration of dynamic content
-
Cloud deployment of dynamic content
-
The client requests dynamic content
-
Clients put dynamic content into the final effect
If we’re not just dealing with purely presentational dynamic content, then there’s another step to go through
-
Development/configuration of dynamic content
-
Cloud deployment of dynamic content
-
The client requests dynamic content
-
The client parses dynamic content and logic into views
-
The client renders the view as final and handles the user interaction
Which of these links is worth extending, which links need more dynamics, and which links are performance bottlenecks are the key to the whole solution. Through thinking and discussion, we can easily find that:
-
Dynamic content development/configuration needs to be implemented quickly
-
Cloud deployments need to be as decentralized and scalable as possible
-
Client requests require as little data transfer as possible and as fast a loading process as possible
-
Client-side content parsing is dynamic
-
Client interaction responses need to be dynamic, as decentralized as possible, and scaleable horizontally
-
Client interface rendering needs to be high performance, as decentralized as possible, and horizontally scalable
So there are a few key decisions in our solution:
-
The transformation and processing capabilities of Transformer between content development/configuration and cloud deployment are required to balance the development experience with the amount of data requested by clients
-
The client side needs to have a JavaScript engine that handles dynamic logic, provides dynamic loading strategies, and needs to do the complicated side parsing as early as possible
-
The description of dynamic content requires the separation of structure, style, data and behavior to ensure that complex content can be decomposed
-
Client interface rendering requires native rendering capability to ensure performance
-
The boundary between Native rendering and JavaScript engine is placed in the Virtual DOM, and the two communicate through the convention of the Virtual DOM instead of template + data or other boundaries to ensure the balance of rendering performance and flexibility
-
Dynamic content publishing, client access, components, and JS apis all need horizontal scalability to ensure that the Weex core is light and focused, and can support more service scenarios
Weex core work chain details
The core design concept of Weex is a dynamic solution that integrates three terminals. Cloud students can realize real-time release and dynamic deployment, template pre-parsing processing, front-end students can realize dynamic content parsing and processing into Virtual DOM in JS Framework, and client students can provide support for rendering implementation and native features. Next, business students can implement the development or configuration of dynamic content according to DSL.
Weex in DSL design a lot of reference to the specification of Web standards, and through the mainstream and mature MVVM mode to write template, style, script, we in learning cost, development habits for business students to consider a lot, so that business students can quickly learn and get started, Js and its author Yu Xi, we have made in-depth use and reference in the design of the upper DSL and the implementation of JS Framework, and benefited a lot from the communication with the author.
Secondly, in order to improve the performance and reduce the performance loss of the client, Weex realized the work of DSL Transformer on the server side. It can convert XML + CSS + JavaScript code into JS Bundle that can be executed efficiently with small amount of data when the template is released. Synchronize the storage to the cloud, such as the Web Server and CDN.
Again, in order to ensure the dynamic business logic, Weex preruns a SET of JS Framework in the client JavaScript engine, which is responsible for parsing the whole JS Bundle. The native end is only responsible for the Virtual DOM parsing and layout, the implementation of UI rendering, and the implementation of basic NETWORK communication, file reading and writing, gesture processing and other basic APIS.
In addition, in order to effectively improve work efficiency, Weex JS Bundle can achieve cross-platform rendering display of three terminals. Business students can develop a Weex JS Bundle to achieve the normal display of iOS, Android and HTML5 three terminals.
All native components and JS apis are modular. Business students can register new modules and methods to achieve decentralized capability expansion.
There are a few more details about Weex performance tuning:
-
The JS Framework realizes a responsive view layer by relying on data collection, plus a layer of optimization of diff algorithm, which can effectively filter redundant operations and complex calculations.
-
The Native end performs asynchronous thread processing for communication, Virtual DOM parsing and layout implementation to prevent UI thread from blocking.
-
The UI component nodes are multiplexed, and the image resources are monitored and reclaimed, which can effectively reduce the occupation of memory.
-
For real-time processing, Weex allows third parties to implement native customization requirements to ensure smooth experience.
Figure: Weex critical performance test compared with similar solutions
> Note: The data is from the laboratory test results, the test interface is about 60 “pits” of the product list, the test model is: > – iOS: iphone5-ios 9.1 > – Android: Samsung SM-N9006-Android 5.0
Weex project practice in Tmall Double 11
Weex participated in and supported the mobile terminal interface display and dynamic processing of the main venue in the Singles’ Day project. The interface module and business logic processing of the main venue are realized in the front-end development. Meanwhile, mobile Tmall and mobile Taobao are connected on the client.
Challenges at the main venue of last year’s Double Eleven
In every double eleven, the main venue is a very important link. A large amount of traffic to users, shops, goods from various ways to gather here as the starting point of landing. The complexity, flexibility, and experience of the content are extremely demanding. According to our experience in the past years, strengthening the diversion capacity of the venue, flattening the level of the sub-venue, rationalizing the operation workload, and optimizing the experience and performance are very important details. Meanwhile, the three improvement goals of the main venue this year are also presented:
App-based experience means we need to have performance and experience beyond traditional HTML5; Flat levels mean that each level is richer and more complex, and the main venue is no exception; Content personalization requires us to comprehensively upgrade every link in the early stage of content generation, algorithm, delivery, client content loading and interface presentation.
Weex’s role in the main meeting
To do this, you cannot do it with a good idea or idea alone, or with the super execution of employees, or by throwing money at machines. This problem needs technical drive to solve! Requires sophisticated design and implementation. Weex team in the entire double 11 preparation process and the demand side on the above issues for in-depth communication and exchanges, and came up with effective technical solutions, very good to solve many of the key links of the problem, and Weex as a new technical solution is very good to withstand such an important “test”!
First of all, we realized a development of iOS/Android/HTML5 in the main venue of Singles’ Day through Weex. Multi-terminal synchronous display ability, and display effects and all aspects of experience are native level.
Secondly, we cooperated with the algorithm team to realize the personalized requirements of the main venue of this year’s Singles’ Day, namely the so-called “thousands of faces”, and realized the end-to-end display of static data of the business operation configuration and dynamic data of the personalized recommendation algorithm. And optimized the performance of the entire client content loading, interface initialization, interaction
Third, Weex maintains a flexible release mechanism close to HTML5 to achieve dynamic rendering on the client side, operators can adjust the main venue floor position through configuration in real time, and “pit” layout, as well as the interface layout display and style adjustment.
Fourth, excellent performance, based on the number of content rendering, we also broke through the traditional 120 “pit” limit, the performance of the double tenth the maximum number of “pit” final actual the close to 180, and the performance is very perfect, want to know what team still in the early 300 “pit” all of them are “limit test” violence. Flat for the venue to further provide a guarantee.
More Weex project practice sharing and summary
At present Weex has been in Alibaba Group and more business partners to carry out cooperation, including Taobao Double 12 projects (as I write on Double 12, Weex is receiving a new round of business baptism!) , we hope that there will be more practical experience and experience to continue to share.
For Weex goals and planning
In the future Weex in addition to continue to serve the needs of the venue (such as double Twelve, New Year festival, etc.), but also hope to support more dynamic scenes, and around Weex’s core advantages continue to solve more problems, even not only to solve the historical problem of dynamic, It can also further solve problems such as cross-end repetitive development, user experience consistency, and common container technical specifications. It can not only solve the problems of mobile Taobao and Mobile Tmall, but also solve the common problems of Alibaba brothers team, domestic and even the industry. Show greater value! Of course, all these seemingly unimaginative dreams require us to step by step, keep a clear head, focus on the core issues around Weex’s core values, and also hope to make use of the strength of the whole team, the whole group and even the entire technical community.
Weex team will focus on the key proposition of mobile terminal dynamics, and carry out periodic iteration and improvement centering on Weex’s three characteristics: lightweight, high performance, and easy expansion. We will continue to make breakthroughs and innovations in simpler and more direct practices, higher loading/startup/rendering/interaction performance, stronger decentralized customization and horizontal scalability. And regularly open the latest version and documents, supporting tools, surrounding ecology, etc.
With the continuous iteration of Weex new versions, we will also adopt more open communication and service strategies for businesses within the group. We will go deep into businesses to understand their real demands and pain points in practice, and provide Weex technical support. In order to ensure the practical effect and output of Weex, we will also draw more information and inspiration as an important reference for the follow-up Weex efforts and improvement.
The team will gradually find a steady rhythm with long iterations and business support, and be prepared for the long haul. With the progress and deepening of the work, we believe Weex can come out of a “fan”, and step by step to achieve the kind of grand blueprint and vision we expect.
Open source: The team has always embraced the idea that open source is not a simple act, but a process and an end result. The team hopes that Weex can gradually solve more common business problems, ensure project quality and code quality as much as possible, and develop into a technical solution that can be accepted, participated in, and trusted by the community. Embody greater value, get more support and faster development at the same time. This is what we hope, and what we hope 🙂
“Experts such as Zhao Jinjiang (Hook stock) and Gold Yong (Yiqi) participated in the creation of this article. This article appears in InfoQ.
MTT is the Abbreviation of Mobile Taobao Tech Team, welcome to pay attention to Mobile Taobao technology team, exchange and share wireless technology together, create a boundless future of Mobile development! Scan the WECHAT QR code to follow us! We will share more exclusive technical details!
