Content Source:On April 8, 2017, Ele. me senior front-end engineers gave a speech on Weex practice in Ele. me front End at the second China Front-end Developer Conference – Efficient Front-end Development Practice and Innovation. IT big said as the exclusive video partner, by the organizers and speakers review authorized release.
Words of Reading:1888 | 3 minutes to read
Abstract
The Weex solution is lightweight, high-performance, and scalable, which can improve the experience of some services of Ele. me. Therefore, we have made some attempts and accumulation, to share with you ele. me in Weex development, documentation, caching, monitoring related experience.
Guest speech video and PPT address: t.cn/R0wvUjj
The front-end scene of Ele. me
A lot of WebView pages, Vue developers more than React developers. The page is more related to the store page and the activity page, and the activity update will be a little more than the store update.
Most of the mobile terminal services pursue the lightweight and smooth page, the PERFORMANCE bottleneck of HTML5 has been criticized for a long time, the most obvious problem is the loading performance.
React Native?
Use React Native in apps like Hummingbird Delivery to quickly update apps and accumulate experience.
For our scenario, the React Native list takes up too much memory and has no reuse mechanism, which will consume more and more resources.
There are too many breaking changes between different versions of ReactNative, and the later maintenance cost is too high, so it is not suitable for the APP with the size of Ele. me.
Weex
Weex architecture is a JavaScript Runtime, underlying the iOS, Android, and H5 rendering engines, through events between the JavaScript Runtime and Native rendering engine communication.
The top layer is JS bundles, JavaScript code packaged by Webpack. The developer wrote mostly Vue syntax up front.
Weex is a cross-platform development solution for building high-performance and scalable native applications. It is characterized by lightweight, scalable and high performance.
Weex is small in size, simple in syntax, and easy to master through Vue. You can also use Native code to customize Native components and functionality by writing Native components to call extensions in JavaScript. Deep optimization of load time and resource usage will be more obvious to listView optimization and the speed of launching the page, and overall its experience will be relatively better.
Develop Weex pages
After some exploration, we tried to replace a WebView page made with H5 with a Weex page.
Weex trial page
The Weex page is relatively simple, with less interaction and a large number of visits, which facilitates feedback collection. Since the page was originally written based on Vue, migration is easier.
The specific work
Implementation of the business: Based on the Vue version, invested one person and took about 3 days.
Weex error reporting and performance monitoring: it takes about two weeks for the front-end to cooperate with the APP side.
Weex’s downgrading strategy: This is the downgrading plan after discussion with the APP side, which is mainly implemented by the APP side.
The whole process took about three weeks from project approval to launch. In view of the effect, the Weex version of the page has excellent performance. Compared with the original H5 version, the page opening speed becomes very fast. We also plan to add more pages gradually.
Weex development experience
Because Weex is a Web-based technology, the barrier to learning is much lower than native development.
Weex only Flexbox layout, text can not be nested, it is difficult to achieve long text style mix.
NoCookies. Only storage can be used to store corresponding information.
The three-terminal consistency is incomplete, especially the HTML5 support is incomplete.
There are differences between CSS and the Web.
DevTools is not mature enough and hot replacement is not powerful enough.
Components are not rich enough compared to the Web.
Overall Weex has a lot of Web development habits, but in many ways it only supports a subset or reinforces its own.
Weex page performance
{” JSLibInitTime “:” 157 “, “JSTemplateSize” : “65”, “SDKInitInvokeTime” : “7”, “SDKInitTime” : “231”, “communicateTime” : “146”, “networkTime” : “0”, “totalTime” : “184”, “fromCache” : true}
SDKInitInvokeTime is also the time when the SDK initialization method is called. The initialization is asynchronous, so SDKInitTime is large.
SDKInitTime is the SDK startup initialization time. It should be a one-time cost, not the cost of each Weex instance.
CommunicateTime is the time when a Weex instance is created. Current usage A new instance is created each time a new page is created.
ScreenRenderTime is the first screen rendering time.
TotalTime is the full render time.
NetworkTime Indicates the time consumed by the network.
Whether the FromCache code comes from the cache (self-implemented).
Render time on Android is around 450ms, while on iOS the performance is better and the page is relatively simple, rendering time is only 160ms.
Demotion scheme
Our downgrade plan is controlled in the APP. We give an APP a profile, and it decides whether the page will be displayed through Weex based on that profile.
In order not to affect the use of users, we adopt the grayscale strategy is to turn on the switch during the business peak period after the grayscale release of Weex supported APPS.
Through the monitoring platform, we can monitor errors in the Weex in a timely manner. If a large number of errors occur, we turn off the Weex switch immediately.
Switch profile
{” url “:” https://www.example.com/discover/index.html “, “weex – url” : “Https://www.example.com/discover/weex.js”, “weex – enabled” : true, “weex – minimal – version” : “0.8.0}”
Url: Web page address used by Windows. If Weex-Enabled is false, a WebView is opened using this url.
Weex-url: indicates the location of Weex resources. In normal cases, this URL is used to download JavaScript files used by Weex.
Weex-enabled: Boolean. The default value is false. When this attribute is true, a WeexView will be loaded using weex-URL.
Weex-minimal-version: indicates the lowest version of the Weex required to load the WEEX-URL. This parameter is mandatory. If this parameter is not specified, weex-enabled does not take effect. When the Weex SDK version in the APP is lower than this version, it will fallback to the WebView form.
Weex version compatibility is excellent and we have not had to downgrade from 0.8.0 to 0.10.0.
React Native has higher learning costs than H5 and Weex.
In terms of testing, React Native and Weex have better weak interaction performance. However, React Native has the best performance in terms of strong interaction. H5 can achieve, poor performance; Weex also has some relatively weak aspects, some drag related effects cannot be achieved.
ReactNative isn’t all that great in terms of compatibility.
React Native requires you to be familiar with the React family bucket, which is much more expensive than Vue.
Github has a React Native Eleme APP that emulates most of the effects. Based on our understanding of Weex, implementing drag part interaction in Weex is difficult or even impossible in current versions.
About the Breaking Changes of React Native, you can search “React Native Give up” on Google, and you can find a large number of articles.
From our practice, Weex is stable and has excellent performance. After doing a good job in monitoring the degradation mechanism, it can be put into production at ease.
That’s all for today. Thank you for listening!
Recommend the article
V8 performance optimization for front-end developers
Baidu takeout how to achieve front-end development configuration
Recent activities
Live | learned practices: the conversation with a high availability architecture best practices
Live | LiveVideoStackCon 2017 audio and video technology will begin in a big lie prone
Live | password in the future – from the Internet after transfer protocol to the era of quantum cryptography
Live | hj technique salon – evolving architecture practice