The introduction
Since 2017, the GMTC Mobile Technology Conference has been renamed the Big Front-End Technology Conference. Up to now, mixed development, native development, front-end development and other concepts are deeply integrated to form a “big front-end” team.
How does a large front end team choose technology? How to get started quickly? How to collaborate effectively? Let’s take a look at how Kuacheng solves this problem.
It started with two places and three teams
Kuaisheng Technology is a leading technology enterprise in the field of online freight transportation, ranking the top three in the market. The platform has 3W + bulk commodity shippers, who issue the order to the platform, and the truck drivers with 60W + will take the order and carry the goods, generating 12 billion yuan of freight transaction volume every year.
Take the driver side as an example, it needs to undertake a series of services with strong correlation and long process chain, from the issue of orders to the entry and exit management, from the in-route monitoring to the financial white strip refueling and gas filling. These tasks are completed by three research and development teams in the two places.
In the 7*24 hour uninterrupted customer service and the high iteration of 2-3 releases per month, the bottleneck of the technical framework has gradually become prominent, specifically including:
- In terms of system framework, the initial framework is native APP +HTML5. Traditional Web has white screen and poor performance response, which greatly reduces user experience.
- In terms of release cycle, there are many R & D departments and long product chains. Some enterprises need more personalized customized services, leading to inconsistent expected release cycle. Frequent delivery updates not only reduce operational efficiency, but also bring customers trouble of frequent updates.
- In terms of experience consistency, native development depends on the system framework. Due to the different native characteristics, the multi-channel platforms of various manufacturers are highly differentiated, and the performance and experience of multi-platform are greatly different.
- In terms of multi-department collaboration, common development languages and front-end JavaScript frameworks are not the same, and technical personnel cannot be flexibly deployed for collaborative development according to the requirements of tension and DDL.
Under the background of rapid development of Kuaisheng Technology business, excellent technical architecture is the guarantee of “improving quality and efficiency”, so system restructuring is imperative. Soon becoming friends began to look for a good architecture to solve the problem of the scene.
Four Dimensions of Selection
In view of the problems found, four selection dimensions are discussed:
- Framework maturity: to put it simply, is whether the new technology is reliable, billions of business pressure, there is not too much room for trial and error;
- Migration cost: if we want to gain benefits from new technology, what cost should we pay, such as the learning cost of new technology, the transformation cost of original architecture, etc.;
- Community atmosphere: it mainly depends on whether there are enough people to follow up the technology, whether the documentation is rich, whether the problems can be helped, etc.
- Considerations are based on performance, cross-platform and dynamics.
After setting the goal of technology selection, the team conducted a series of surveys and demos on common cross-platform solutions such as React Native, Weex, Flutter and applet. Horizonwise comparisons are as follows:
| Technology selection | Research results |
|---|---|
| The React Native and Weex | • Slow startup time, frame rate is not as good as native; • The cost of migration is high, and developers need to encapsulate a heavy intermediate layer, which requires higher requirements on R&D personnel. |
| Flutter | Performance and efficiency are Paramount but dynamism is very limited. |
| Small program | It is not a cross-platform development solution, and it cannot use its own APP to open. It pays more attention to the channel advantage. |
When entering the dilemma of technology selection, Kuacheng Logistics Technology accidentally came into contact with MPaaS from Alipay technology framework. By using MpaaS applet container, integrating MpaaS framework, offline package and reusing H5 plug-in, relying on the Web rendering engine with strong performance, Perfect in line with our expectations and requirements for technical selection.
Give it a try
After the selection of technology, in the early stage of reconstruction, we carried out a fierce brainstorming among our colleagues on the establishment and division of the project project, and finally selected the scheme of lightweight componentization, parallel development of multiple small programs and dynamic distribution under the premise of multi-department cooperation.
The Kuaicheng team gradually introduced the framework from multiple perspectives, such as collaboration and technology.
🎞 For full details, watch CodeHub#5 in full replay
1. Multi-team cooperation
2. Real-world testing
The problem of real machine preview and debugging, first of all, to set the whitelist, the setting method can refer to the document, and then in the native end according to the document of the corresponding configuration and code writing, finally need to pay attention to is that the two-dimensional code generated by the IDE needs to use our APP scanning ability scanning (can access the MPAAS scanning component), Pay treasure scan is not open.
ScanService service = LauncherApplicationAgent.getInstance().getMicroApplicationContext() .findServiceByInterface(ScanService.class.getName()); ScanRequest scanRequest = new ScanRequest(); scanRequest.setScanType(ScanRequest.ScanType.QRCODE); service.scan(this, scanRequest, new ScanCallback() { @Override public void onScanResult(boolean success, Intent result) { if (result == null || ! success) { showScanError(); return; } Uri uri = result.getData(); if (uri == null) { showScanError(); return; } // Start the preview or debug applet with the second parameter mptinyHelper.getInstance ().launchIdeQRCode(URI, new Bundle()); }});3. Core problem solving
In the same small program when different pages jump to pass parameters, we encountered the problem of large parameter transmission was truncated.
After analysis, it is the small program that limits the length of parameters carried by the routing jump API. Later, we choose to use the cache my.setStorage to access and use large quantities of parameters. It should be noted here that the same small program cache is limited to 10MB. It is especially important to clear the cache using my.clearStorage where appropriate.
4. Elegant interaction
In the UI development, we want the small program page closer to the native, so we carried out a small program of the development of the custom navigation bar, this part is the need to achieve the native end, it is recommended to download the official Demo with the document to develop.
One of the more impressive UI problems we encountered was when we typed the wrong line in a multi-input component page of a form class on an iOS device:
After reviewing the documentation, it is found that this is a compatibility problem. For components that need to start the keyboard, such as Input, TextArea, etc., the default is the native keyboard.
If there is an abnormal interaction between the keyboard and the component, you can revert to the keyboard using WKWebView by adding enableNative=”{{false}}” property to the component.
At the same time, the system keyboard is used, so the number keyboard provided by MPAAS cannot be used, so the keyboard is no longer specially adapted.
It should be a future
With the continuous evolution and upgrading of technology, it seems that development is becoming more and more simple and convenient, reducing repetitive and meaningless work. In fact, it especially tests the ability of developers to analyze, position, solve problems, innovate and learn.
However, there is still a gap between MPAAS applet and Alipay applet at present, and there are still some minor problems in compatibility and H5 framework. I also hope that MPAAS and applet framework can continue to evolve and be expected in the future!
E. N. D.
