1. Cross-platform, which platforms do you want to cross?
At present (2020/7/18), the cross-platform requirements of mobile terminals mainly focus on:
- cross-PC and mobile terminals: In the early stage of PC-to-wireless transition, we hope to reuse the same code PC Web and mobile Web.
- Cross-Native and Web pages: a set of Web pages with similar functions are required to be accessible outside the terminal. Cross-Native App and Web pages are required.
- Cross-Native dual-end: for development efficiency and other reasons, we want to reuse a set of business code on both Android and iOS
- cross-App: some product features are expected to be launched through multiple channels, focusing on tool requirements, such as taking a taxi, buying tickets, and ordering meals.
In the foreseeable future, there may be these cross-platform requirements:
- cross-lightweight applications: system-level out-of-the-box lightweight applications, such as Android fast applications and iOS App Clips
- cross-IoT devices: all kinds of devices with display screens will become new "Terminals", such as vehicle-mounted devices and smart home devices.
- Cross all clients: it may be a pseudo demand. The focus of the same product on different platforms is different, and it may not be necessary to completely move all functions to various client devices/platform channels, for example, the positioning of fast applications is obviously different from that of Native App.
Under such an era background, cross-platform development is a strong demand in terms of resource costs, development efficiency, product iteration, and technology evolution. , so there are various cross-platform solutions to explore
2. Emerging cross-platform technologies
in recent years, the mainstream cross-platform solutions for mobile terminals in the industry can be roughly divided into three categories:
- web-generated cross-platform: with browsers or WebView, you can easily cross-platform with Web technology, such as Web App, PWA(Progressive Web Apps), Hybrid App, and PHA(Progress Hybrid App).
- Containerized Native cross-Terminal: The Native App is transformed into a standardized container, allowing a set of code to run across multi-terminal standard containers, such as React Native, Weex, and Flutter.
- Mini programs can be invested across apps in one code: in the domestic market, more and more super apps support mini programs, but their respective mini program frameworks do not have a unified standard, so Taro, kbone, uni-app and a series of cross-mini program frameworks to meet the needs of cross-App product delivery functions.
Cross-platform: Web is born
cross-platform is an inherent advantage of Web. Browsers and WebView are standardized Web containers under W3C specifications. Therefore, Web pages can be easily delivered to out-of-terminal browsers, in-terminal WebView, and WebView provided by other apps
from the perspective of cost alone, the Web solution is the best choice for cross-platform :
- no additional learning costs: a set of basic technologies can be used inside and outside the terminal, even PC browsers and TV set-top boxes.
- Do not rely on special supporting facilities: all engineering links such as development, debugging, construction, release, monitoring, and operation and maintenance are common.
- There is a huge existing ecosystem: npm million modules, everything
- Web based on open standards: it is not difficult to go out and introduce
in addition, the Web itself is a platform that can be refunded and defended, with lower technical risks.
However, in other aspects, cross-terminal relying on Web technology also exists limitations :
- platform capability: limited by Web standard containers, it cannot meet the requirements related to platform capability, such as cameras, Bluetooth, multimedia, etc.
- Experience: The Web experience on the mobile terminal is far less than that on the Native terminal, which is mainly reflected in scenarios such as slow loading of the first screen, lagging animation, and long page scrolling and flashing.
- Performance: high memory consumption and low GPU utilization
in addition to the slow change of Web standards and poor compatibility of new features (for example, Push API have been used for many years and still cannot be used safely), the basic Web capabilities are difficult to meet the needs of the Native end. Therefore, on the basis of traditional Web App, more exploration has been carried out:
- PWA(Progressive Web Apps): Native App that support offline caching, system notifications, home screen icons, and other Web App, but compatibility is not optimistic.
- Hybrid App: A Hybrid Web and Native solution that injects the platform capabilities implemented by Native (such as scanning two-dimensional codes) into WebView environment for Web App to expand the platform capabilities of the Web.
- PHA(Progressive Hybrid App): the combination of PWA and Hybrid ideas makes Web performance and experience close to Native through Hybrid methods
PWA standardization seems to fail. Even if it is connected, it may be several years later if it can be used safely. Hybrid App solves some problems (platform capability expansion), but it is not enough. PHA is a continuation of these two ideas, realizing PWA's dream with Native technology
however, no matter PHA or HA, the introduction of Native dependencies means the loss of Web openness, which leads to cross-terminal and cross-App problems.
Cross-end: containerized Native
However, due the containerized Native solution starts from Native and has no cross-end talent. , in addition to finding ways to support the Web, it also faces a more difficult problem-Cross-App
cross-App: small program a yard more
from a technical perspective, the cross-Native App of mini programs still relies on Web solutions, so why not directly use Web App?
Due to commercial competition and other factors, Web App breaking into other people's territory are usually subject to some restrictions, such as security warnings, permission control, even simply forbid access (that's why there is a way of twisting and winding such as password sharing)
applets are different, and their original intention is open. Welcome to join in (of course, we must abide by the rules), and many large domestic apps have also opened their applets in succession, mini programs have gradually become a formal cross-App approach. . However, after the number of mini program platforms has increased, the problem of inconsistent framework standards has also been exposed. They are all called mini programs, but they are all similar. Therefore, how to quickly produce a variety of small programs has become a technical topic worth exploring
there are two implementation principles: compilation conversion and runtime adaptation, the former can achieve the same performance as the native mini program, but it brings many limitations (writing methods that are difficult to identify at compile time are not supported). The existing Web App are not easy to migrate to cross-App mini programs, for example, Taro and uni-app. The latter sacrifices performance for more possibilities. Existing Web App can be migrated relatively easily, such as Taro Next and kbone.
P.S. Of course, there can also be a combination of dynamic and static ideas. Ideally, most of the basic services are migrated at runtime, and some high-performance requirements are compiled and converted.
3. What is invariant in the heavy changes?
Channels, terminals, platforms, business codes, and engineering supporting facilities seem to be changing rapidly, and none of them remains stable.
Now that everything is changing, let's look at it from another angle, which part will definitely change?
- Containers: new channels, terminals, and platforms are all new containers.
- Cross-container technology: the emergence of new containers means new cross-container technology requirements.
Which part does not need to be changed?
- Business Code: the change of technical solutions and the emergence of new channels, terminals, and platforms are usually accompanied by the migration of business code. Native React Native Flutter...... However, from the perspective of cost, the business code does not necessarily and should not change accordingly.
- Engineering supporting facilities: most of them are related to strong technology stacks. For example, there are many differences between the development, debugging, construction, release, monitoring, operation and maintenance of Web App and Native App, however, the more basic part is technology-independent, and process-related, such as the build-release process and monitoring and O & M services, do not need to be changed accordingly.
- Platform capabilities in containers: Regardless of the cross-container solution, the requirements for platform capability expansion are consistent, and the corresponding Native module encapsulation should not change accordingly.
The cost of business code migration is very high (it is more painful when technology stack changes are involved), and the replacement and reconstruction of supporting facilities is definitely a large project, so, is there any way to fix these parts that should not be changed?
Yes, abstract The changed parts . Depending on abstraction but not specific, the upper layer does not need to change:
标准框架 \ --------- | 配套设施 标准容器 /
in this abstract model, the upper-layer business code depends on the standard business framework instead of the container capability, allowing the following parts of the business framework to be replaced. The business framework relies on abstract standard containers and is not bound to specific containers. It can be replaced with other containers that comply with container standards.
Based on the standard framework, it can provide supporting development tools such as scaffolding, Component Library, visual construction, etc. Based on standard containers, supporting debugging capabilities such as performance diagnosis and event tracking can be established to cover the entire engineering link, and supporting facilities hardly need to be changed.
4. The future of cross-platform technology
we can't predict the future, so here are several possibilities:
- mobile cross-terminal only cross-Native end: for many mobile products, Native App with exquisite experience and excellent performance is still the most important application form at present, and the two-terminal functions are identical and equally important. , so it is a relatively reasonable solution to unify mobile Native development only across Android and iOS
- mini Programs are self-integrated across apps: If mini programs cannot be truly standardized, the cross-mini program framework solution generated by cross-App delivery needs is necessary.
- The Web is still the Web, and Hybrid will continue: the change cycle of Web features is too long, and the change of mobile devices is too slow to wait for the evolution speed of Web in years, the Hybrid transition solution that relies on Native to enhance the Web is likely to be "transitioned" for a long time.
P.S. mini programs are already in the process of standardization. It is not impossible for the mini program framework to become a standardized container. After all, the mini program framework does not have the slow cycle resistance like WebView and browsers.
I am not optimistic about a cross-end solution that can be used all over the world, because both universal components and universal API are the smallest intersection and cannot meet the actual needs. And, do you really need to run a set of code on all channels, terminals, and platforms?
The same product has different emphases on different platforms, and it may not need to completely move all functions to various client devices/platform channels. For example, the positioning of fast applications and Native App is obviously different.
- Why Rax?