40 Dynamic Implementation How to Choose the Right Solution for Yourself

40 Dynamic Implementation How to Choose the Right Solution for Yourself #

In the 36th article of this column, “The Current Situation and Application of Cross-platform Development,” I shared several common cross-platform development methods: H5, React Native/Weex, and mini-programs. From a developer’s perspective, although cross-platform development is more efficient than native development, this is not the main reason for the popularity of front-end development in China.

Compared to cross-platform capabilities, China has a stronger emphasis on dynamic capabilities in front-end development. Why is that? The mobile Internet has been developing for ten years. As businesses mature and features become relatively stable, the overall focus shifts towards operations. The strong operational demands require higher requirements for client architecture and release patterns. If every modification requires a long process of development, deployment, and version upgrades, it is impossible to meet the requirements for quick responses.

Therefore, the popularity of H5, React Native/Weex, and mini-programs in China can be attributed to the importance of dynamic capabilities over cross-platform capabilities. So, which dynamic solution should we choose? As I’ve mentioned in the previous article on cross-platform development, these solutions currently have some performance issues to varying degrees. If you must use native development, are there any dynamic solutions available? Today, let’s learn how to choose the right dynamic solution for yourself.

Background of Dynamicization Practices #

A few days ago, I saw a post in my friend circle about an update to the Taobao iOS client, which happened over two months ago. It was hard to imagine such a release schedule for Taobao, considering that it is a business with an exceptionally large and complex e-commerce platform.

Taobao

Nowadays, even without releasing a new version, we are able to implement various operational activities and personalized recommendations. Through the dynamicization capabilities of the client, we no longer need to wait for application store reviews or rely on user-initiated updates. As the product iterates rapidly, it also has a powerful ability to make trial-and-error attempts.

1. Common Dynamicization Solutions

Mobile dynamicization solutions have been a focal point of attention in recent years. Although they have been developed for many years, there are always new changes every year. Let us first take a look at the well-known dynamicization solutions of major companies.

Dynamicization Solutions

At the 2018 Beijing QCon conference, engineers at Meituan shared their dynamicization practices in the 《Meituan Client Dynamicization Practices》 (Chinese only). As a heavily operated application, Meituan has a strong demand for dynamicization and rich practical experience. They classify dynamicization solutions into the following four types:

Dynamicization Types

  • Web Container Enhancement: Based on H5 implementation, with various optimization methods such as offline packages, representative solutions include PWA, Tencent’s VasSonic, Taobao’s zCache, and most mini program solutions.

  • Virtual Execution Environment: Runs using an independent virtual machine, but ultimately renders using native controls. Representative solutions include React Native, Weex, and Quick app, among others.

  • Business Pluginization: Based on native component-based development, this approach is very common in carrier applications such as Taobao, Alipay, Meituan, Didi, and 360. Representative solutions include Alibaba’s Atlas, 360’s RePlugin, Didi’s VirtualAPK, among others. In addition, I believe that various hotfix frameworks should also be considered as a type of business pluginization, such as WeChat’s Tinker, Meituan’s Robust, and Alibaba’s AndFix.

  • Layout Dynamicization: Although pluginization or hotfixing can achieve dynamic modification of page layout and data, it comes at a high cost and is not easily capable of personalized operations. To achieve “a thousand faces for a thousand people,” both Taobao and Meituan’s homepage structures can be dynamically configured and updated. Representative solutions include Alibaba’s Tangram and Facebook’s Yoga.

2. Choosing a Dynamicization Solution

Of the four major dynamicization solutions, which one is the strongest, and how should we choose? Before answering this question, let us take a look at their differences.

Differences

Currently, we cannot find a “perfect” dynamicization solution. Each solution has its own advantages, disadvantages, and corresponding usage scenarios. For example, the Web container enhancement solution has significant advantages in dynamicization capabilities and development efficiency, but its stability and smoothness leave something to be desired. Conversely, the layout dynamicization solution performs well in terms of performance but has limitations in dynamicization capabilities and development efficiency.

Therefore, when choosing a dynamic solution, we need to consider the following factors:

  • Business Type: Mainly considering factors such as the importance of the business, complexity of interactions, performance requirements, and long-term iteration.

  • Team’s Technical Stack and Code Legacy: When selecting a solution, it is also necessary to consider the team’s current technical stack and code legacy. Taking WeChat as an example, as a highly interactive IM application, the team mainly focuses on native development and there is not much demand for operational activities. Therefore, at the time, only Tinker was used for dynamicization. Of course, the team’s technical stack is not immutable. After the launch of WeChat mini programs, some internal businesses also tried to use mini programs for transformation.

Comparison

Regardless of which dynamicization type we choose, I recommend that the same solution be used for the same dynamicization type within a company. This not only allows for a unified technical stack but also enables code migration between different businesses. For example, Alibaba internally uses Weex as the unified solution for virtual execution environment. If a business performs well on the Taobao app, it can be quickly migrated to other applications such as Fliggy and Tmall, thus realizing the traffic matrix of the applications.

The same applies to operational activities. Alibaba has a component called PopLayer, which can deploy an H5 container on any Native page (which can even be a browser) to display a translucent overlay without affecting the Native page’s interaction. With this approach, we do not need to develop code in the client app one or two months in advance for an activity. The same activity can also be quickly launched in various applications within the company.

Native Dynamic Solution #

Web container enhancement and virtual runtime environment solutions bridge native modules through independent runtime and JS-SDK, while business pluginization directly utilizes plugin framework and interface capabilities. Compared with the former, the latter is more abstract and less likely to cause code confusion, which is why major companies are gradually moving towards “de-pluginization”.

图1

In the past two years, the development of front-end has become more and more intense. Does the traditional native dynamic solution still have value, and where should it go? How will the future of hotfix and pluginization evolve?

1. Hotfix and Pluginization

In 2016, two things about open-source Tinker surprised me. One is the huge response to hotfix in China, and the other is that it is so full of “pitfalls”.

From the article “Tinker: The Original Intention and Persistence of Technology”, you can see a small part of the pitfalls we encountered in the past, but unfortunately, the road to filling these pits has not yet ended. Every time a new version of Android is released, we are like facing a final exam, step by step.

图2

WeChat once hoped to use Tinker to replace version releases and implement proxying for the four components based on hotfix. However, the introduction of Android P’s private API restrictions basically dispelled this idea. Hotfix cannot replace version releases, but we can use it to implement some functions that app stores do not support, such as accurate control of gray audience, channel and user attribute selection, and whole-package A/B testing, etc.

On the other hand, hotfix has also brought some negative impacts to the Android ecosystem in China, such as increased ROM space usage, 15% slower app loading, and first-time OTA lag. Especially after Android Q, dynamically loaded Dex files are executed only in an interpreted mode, which exacerbates the impact on startup performance. Due to performance issues, major companies have basically paused hotfix for all users and only use it for gray tests.

The same goes for pluginization. Heavy plugin framework not only affects the startup speed of an app, but also does not work as harmoniously as imagined in multi-team collaborations. There are issues such as interface confusion, poor repository management, and slow compilation speed. Pluginization is reverting back to modularization and componentization, which is also being gradually promoted by major companies.

Not long ago, Xu Chuan reviewed the past and present of hotfix and pluginization in the article “The Romantic Extinction History of Mobile Development”. Three years have passed since then, and as someone who once participated in this trend, all I can do is go with the flow.

图3

The Future of Hotfix

When designing Tinker, we referenced the compilation solution of Instant Run, but as mentioned in the 26th article of this column “What Do You Need to Know About Compilation?”, after Android Studio 3.5, Google will use Apply Changes to replace the previous Instant Run solution for devices running Android 8.0 and above.

图4

Apply Changes no longer uses the approach of inserting PathClassLoader, but instead uses JVM TI, which we have discussed several times before. After Android 8.0, JVM TI began to gradually support the ClassTransform and ClassRedefine interfaces, which allow the virtual machine to dynamically modify classes at runtime, achieving dynamic bytecode weaving during runtime. In fact, this technology is already very mature in the JVM. Java servers utilize these two interfaces to achieve capabilities such as hot deployment, remote debugging, and dynamic tracing. For more details, you can refer to the article “Exploration of Java Dynamic Tracing Technology”.

So, where will hotfix go in the future? Originally, I was very pessimistic about the future of hotfix, but Android Q surprised me. We know that Android P had many compatibility issues with Chinese apps, and most of them were caused by hotfix, pluginization, and reinforcement (according to data provided by Google, 43% of compatibility issues were caused by these three issues).

To solve this problem and reduce our reliance on private APIs, Google introduced the AppComponentFactory API in Android P, and added the interface instantiateClassloader in Android Q to replace the ClassLoader. After Android Q, it is possible to replace existing ClassLoaders and the four components at runtime. The pioneers of hotfix in China have finally obtained support from Google with their “sacrifices”. We can now use Google’s official API to achieve hotfix, so we no longer need to worry when upgrading Android versions. The romance of mobile development has not died, and the hotfix of Native has ushered in a new spring.

图5 The Future of Pluginization

For the future of pluginization, we need to think about how to “return to the official road”. Google introduced Android App Bundles in 2018, which can achieve dynamic module downloading. However, unlike pluginization, it does not support the ability to proxy the four major components.

However, the Android App Bundles solution relies on Play Service, which we cannot use in China. iQiyi’s Qigsaw may provide some inspiration, as it is based on Android App Bundles (supports dynamic updates but not component proxying) and completely mimics the plugin loading interface provided by AAB. Companies with internationalization requirements can seamlessly switch between the domestic and international versions. This solution not only allows the use of the compilation toolchain provided by Google but also supports both international and domestic tracks. It is like Google maintaining the entire componentization framework for us, and we only need to implement our own “Play Service” in China.

Of course, similar to hotfixing, if we use the AppComponentFactory API, we can also achieve component proxying in pluginization. However, in terms of specific implementation, we still need to pre-register the four major components in the AndroidManifest, and then the specific replacement rules can be buried in our custom AppComponentFactory implementation.

Taking Activity replacement as an example, we can replace certain class names of Activity with other Activities, which can be in the patch or other plugins.

As native dynamicization solutions, both hotfixing and pluginization have their limitations. With the development of mobile technology, some functionalities may be replaced by mini-programs or other dynamicization solutions. However, from the current perspective, they still have a great value and use cases.

2. Layout Dynamicization

As mentioned earlier, in scenarios such as the homepage of Taobao and Meituan, we have very high performance requirements, so we can only use native implementation. However, the homepage is also the gathering place for traffic, and “increase growth, increase retention, and increase conversion” all require us to have strong operational capabilities. In the past two years, Taobao and Tmall have been promoting “thousands of personalized homepages”, where each user may see a different layout and content.

Layout dynamicization has emerged under this background. In my opinion, layout dynamicization needs to have the following three capabilities.

  • UI containerization. It should be able to dynamically add and adjust UI interfaces without the need for release.

  • Capability interfaceization. Common abilities such as clicking and jumping can be provided externally through routing protocols to meet the invocation needs after UI containerization.

  • Data channelization. Data reporting can also be configured via fields to achieve automatic client reporting according to the configuration.

In terms of specific practices, Tangram, open-sourced by Tmall, is a good choice. However, the overall solution of Tangram may be relatively complicated. We can also do secondary development based on the underlying VirtualView.

Overall, compared to virtual runtime environments, layout dynamicization not only achieves dynamic addition and modification of UI, but also has a good experience and performance. At the same time, the cost of access and learning is relatively low.

Summary #

“Although the road ahead is long and winding, I will seek for solutions from all directions.” Our exploration of dynamic practices has never stopped. This year, Flutter has also made a strong entry into this “battlefield”. In the next issue of this column, we will reveal how Flutter performs in the aspects of cross-platform and dynamism.

Dynamic practices are currently a hot research field in China. Although each company has reluctantly developed their own solutions, there are still many unsolved problems in dynamic practices. Therefore, as we solve these problems, various new solutions will continue to emerge.

Currently, different types of dynamic solutions have found their own application scenarios. Mobile technology is developing rapidly, and we cannot accurately predict the future. For example, just when we were preparing to abandon hot patching in Android P, Android Q brought it back to life. However, we firmly believe that no matter which solution is adopted in the future, it is all aimed at providing users with a better experience, enabling businesses to iterate faster, and continuously experimenting to provide users with better products.

Homework #

What are your thoughts on dynamicization? Which method of dynamicization have you used in your application? Feel free to leave a comment and discuss with me and other classmates.

Cross-platform and dynamicization can be said to be the two biggest characteristics of the era of front-end development, and they are also the focus of technology conferences every year. Today’s homework is to carefully read the following conference presentations, learn from the practical experiences of major companies in the field of front-end development, and leave a comment with your insights and experiences.

Feel free to click on “Invite Friends to Read” to share today’s content with your friends and invite them to learn together. I have also prepared rich “Study Booster Packs” for students who think deeply and actively share, and I look forward to learning and improving together with you.