Writing a Hybrid Framework that is easy to maintain, convenient to use and reliable in performance (I) — Idea Construction
“Write a Hybrid Framework that is easy to maintain, convenient to use and reliable in performance (II) — Plug-in”
“Write a Hybrid Framework that is easy to maintain, convenient to use and reliable in performance (III) — Configuration Plug-in”
“Write a Hybrid Framework that is easy to maintain, convenient to use and reliable in performance (IV) — Framework Construction”
preface
I told myself that this would be the last post I would write about Cordova and web containers. Unfortunately, after I finished my last post on Cordova, I started to lose myself. I didn’t want to go that far, but I couldn’t stop.) So I asked myself, what if I was designing a Hybrid framework, because I’m summarizing the ideas of Cordova. And so I thought again… Because I originally intended to focus on the implementation of dynamic UI in weeX,RN and other aspects in the future, to be sure, I am not sure whether our Web container is better or weex based dynamic UI is better after the analysis of MSG big guy, so I got into a meditation again… After deep thought, I think the latter is the trend of the big front end, what is the big front end, is a variety of front-end clients mixed together, cross and extend everywhere, regardless of you and me.
Without further discussion, based on this idea, I decided to summarize my own Hybird framework. On the one hand, it is a summary of knowledge, which I will forget when I get older. On the other hand, it is an extension of my knowledge, hoping to learn more like a great god. In addition, MSG big guy’s idea is that the framework does not build their own webView, but developers can completely use their own webView, so I am also struggling, should developers control their own webView or control within the framework? So I first on the basis of the big guy to do an extension, decided that the framework does not provide a webView, the creation of webView by the developer’s own control.
So now there are two premises: one is that the webView uses WKWebView, the other is that the framework does not provide a webView, webView needs to be created by the developer. Let’s get down to business:
What are the characteristics of a good Hybrid framework?
1. Plug-in, this is necessary, decoupling is fine, what is plug-in, is pluggable, when you use it, drag it out, the rest do not have to do anything. To be honest, this is a good Cordova. Plugins and subdivisions:
- 1. The proxy method of webView is specifically implemented as a plug-in, so that no matter which webView proxy method can be set at will without affecting business.
- 2. Interactive plug-in of JS and Native is what we call JS plug-in and native plug-in. They are collectively called plug-in (fetch, IO, etc.).
2. Configurability, that is, everything can be configured. All plug-ins are handled by a configuration file, that is, a configuration file can handle all the plug-ins mentioned above. The configuration can be subdivided:
- 1. Plugins can be configured, which can be further divided into native plugins and JS plugins.
- 2. Whether the plug-in is loaded into the cache when the webView is loaded or it is loaded when the webView is called depends on the specific business. Personally, I think the commonly used plug-ins, such as FETCH plug-in and JS network request, are all made by Native. They may be used once in a while or may not be needed by the user for a while, but such plug-ins can be instantiated and cached at the time of invocation.
3. Unified interface for front-end developers, and how to change within the framework does not need js to change, for the front-end, is always a set of interface, he does not need to care about what webView is.
- A set of front-end interfaces needs to be provided to front-end developers.
4. WKWebView must be used in communication, because it is obvious to improve performance, and have to use, webView this piece is going to refer to MSG big guy’s choice of communication. Please refer to
“Clean up a Hybrid Framework from Scratch (I) — From selecting JS Communication Solutions”
5. Performance optimization of INTERACTION between JS and Native plug-in. This can be subdivided into three parts:
- 1. Does JS need to set up a queue to call native? As I mentioned in my last article, does it not need to go through webView every time? Do native apps need to be queued as well (don’t ask me why, I don’t know)?
- 2. Do I need to put the plug-in callback into a background thread once it takes time?
- 3. I mentioned in my iOS source Code — cordova-ios that if the plugin is running for too long and causes a lag, we can add a timer to the runloop to wake up the runloop and stop it from sleeping.
The next thing I need to do is to solve the five problems step by step. The main idea is to separate the first two articles and add the framework idea of Cordova. After all, Cordova is a bit heavy and some of them are not used in our daily development. Moreover, it is difficult to integrate. Based on this, we intend to build a Hybrid framework with reliable performance, convenient use, easy maintenance and lightweight. At present, I have constructed the idea, and the concrete implementation is ready to be written in the next article (PS: because I have not decided on it now, it is too late, SO I will leave it here).