Development and release of native apps and hybrid apps
1. Native application
We all know that for traditional native apps, the entire development cost is very high and the release cycle is relatively long. For enterprises that need to iterate their business content frequently, whether it is updating functional modules or repairing defective versions, they need to retest, republish, resubmit to third-party app stores for review and listing, and require users to cooperate to install new versions , to overwrite the old version.
I organized the development and release process of native applications into a flow chart, which should be clearer and more intuitive:
In fact, the entire development and release process is to compile the developed source code into a binary package and then put it on the Android and iOS app stores.
2. Mixed application
However, in recent years, more and more hybrid applications have been developed, because most developers are still interested in the hot update capability of Hybrid APP. Let's look at the release process of hybrid applications.
The biggest difference from the native application is that the code contains HTML5 code, and this part of the code can be updated online directly through the update mode on the server.
Hybrid application hot update principle
And a more in-depth look at how the Hybrid APP hot update is implemented, you can find that its working principle is as follows:
Usually, the server side of the APP needs to monitor the update of these contents, and then send a content update notification to the APP on the device side by some technical means, and then some components in the APP need to synchronize some page content fragments to the client through the network, and send these The downloaded content, typically HTML and JavaScript, is injected into these previously dug holes.
Here I also want to explain that there are many technical solutions for network synchronization, such as through two-way Web-Socket, or through HTTPlongpolling, or through SSE, or through PushtoPull, or other custom technical means such as CMS to achieve.
On the device side, HMR hot module replacement and code injection are usually used to make the updated code take effect and display locally to avoid APP restart.
Potential issues with hot updates
In theory, any updated source code downloaded from the Internet cannot be assumed to be safe and credible. When these codes are injected into your APP to run, how to detect their security and protect the security of local applications and local data on the device?
Here is an explanation of the small program technology widely respected by major manufacturers. The solution of this small program is to detect and audit in the cloud, and use the technical mechanism of a security sandbox on the device side to lock the downloaded and updated code in a cage and run it in isolation. .
In addition, the applet also has a management background to manage the removal and removal of shelves, and the entire online method will be more flexible.
As mentioned above, this is the technical direction advocated by major manufacturers. Most developers still cannot enjoy the convenience brought by the small program technology, but there are also small program container technologies like FinClip to help developers create a Small programs can be run in the middle of the cloud, and the full-cycle management of small programs from development to launch can be realized through the cloud-side management background, so that it can have the small program hot update capability that only major manufacturers have.
This method will have a better effect than the currently widely used HTML5. First, the development method will be more convenient, and second, the user experience will be significantly improved.