Operation mechanism
When will applets be destroyed
When the small program enters the background, the client will maintain the running state for a period of time, after a certain period of time (currently 5 minutes) will be actively destroyed by wechat.
If the system receives more than two memory alarms in a short period of 5 seconds, the system destroys the small program.
Open the logic again
Users are expected to open applets in the following two scenarios:
- A. Open the home page: the scenario value is 1001,1019,1022,1023,1038,1056
- B. Open A page specified by the applet: the scenario value is other than A
When opening a small program again the logic is as follows:
The last scene | The currently open scenario | The effect |
---|---|---|
A | A | Keep the original state |
B | A | Clear the original stack and open the home page (equivalent to wx.reLaunch to the home page) |
A or B | B | Clear the original page stack and open the specified page (equivalent to wx.reLaunch to the specified page) |
The life cycle of a small program
The App() function registers a small program. Accepts an Object parameter that specifies the life cycle callback of the applet, etc. The life cycle here is for the entire applet project, not the page.
Object Parameter Description:
Definition of foreground and background:When the user clicks the upper left corner to close, or press the device Home button to leave wechat, the small program is not directly destroyed, but entered the background; When you enter wechat or open the small program again, you will enter the foreground from the background.
Here is an example with the following code:
//app.js
App({
onLaunch: function (options) {
// Triggered when the applet initialization is complete.
// options description:
// path: the path to open the applet
// query Opens the query of the applet
// scene Opens the scene value of the applet
// shareTicket Indicates the forwarding information
ReferrerInfo This field is returned when the scene is opened by another applet or public number or App
console.log('app >> onLaunch, options::',options);
},
onShow: function(options){
// Triggered when the small program starts, or enters the foreground display from the background
// Same as onLaunch
console.log('app >> onShow, options :: ',options);
},
onHide:function(){
// Triggered when a small program enters the background from the foreground.
console.log('app >> onHide');
},
onError:function(error){
// Triggered when a script error occurs in the applet, or an API call fails.
// Error String Error information, including stack information
console.log('app >> onError, error::'+error);
},
onPageNotFound(Object) {// Base library 1.9.90 is now supported
// Triggered when the page the applet wants to open does not exist.
// Object Parameter Description:
// path String Non-existent page path
// Query Object Opens query for pages that do not exist
// isEntryPage Boolean Specifies whether to start the first page
console.log('app >> onPageNotFound , Object :: '.Object);
// Note: If the developer does not add onPageNotFound listener, when the jump page does not exist, will be pushed into the wechat client native page does not exist prompt page.
// If the onPageNotFound callback is redirected to another page that does not exist, the wechat client's native page does not exist prompt page, and onPageNotFound will not be called again.}});Copy the code
When you start the applet, you can see the console print the following information in developer tools
Page life cycle
The Page(Object) function registers a Page. Accepts an Object parameter that specifies the page’s initial data, life cycle callback, time handler, and so on.
Here’s an example to try out the life cycle flow of a small program
The example has four pages pageA/pageB/pageC/pageD, where pageA and pageB are two TAB pages, that is, pages that are switched by the bottom TAB. PageC and pageD are two normal pages. The following is an example page:
The four pages are shown in the figure, with some buttons indicating different route jump modes.
Here is the code for some of the pages related to pageA, and the other pages are similar
Page({
data:{
},
onLoad:function(options){
// Triggered when the page loads. A page is called only once, and you can get the parameters to open the current path in the onLoad argument.
// Parameter Options Object Opens the parameters in the current page path
console.log('pageA >> onLoad , options ::',options);
},
onReady:function(){
// Triggered when the first rendering of the page is complete. A page is called only once, indicating that the page is ready to interact with the view layer.
console.log('pageA >> onReady');
},
onShow:function(){
// Triggered when the page is displayed/cut to the foreground
console.log('pageA >> onShow');
},
onHide:function(){
// The page is hidden/the background is triggered.
console.log('pageA >> onHide');
},
onUnload:function(){
// Triggered when the page is uninstalled.
console.log('pageA >> onUnload');
},
// Custom methods
navigateToC:function(){
// Leave the current page and jump to a page in the app, but not to the tabbar page. Use wx.navigateBack to return to the original page.
console.log('%cpageA==========navigateToC==========='.'color:red');
wx.navigateTo({
url:'/pages/page-c/index'
});
},
redirectToC:function(){
// Close the current page and jump to a page in the app, but not to the tabbar page
console.log('%cpageA==========redirectToC==========='.'color:red');
wx.redirectTo({
url:'/pages/page-c/index'
});
},
reLaunchToC:function(){
// Close all pages to open a page within the app
console.log('%cpageA==========reLaunchToC==========='.'color:red');
wx.reLaunch({
url:'/pages/page-c/index'}}}));Copy the code
Here are the results in each case:
The current page | Post route page | Jump way | Trigger lifecycle (in order) | instructions |
---|---|---|---|---|
A | A | For the first time open | Execute a small programonlaunch>onShow And then execute the page’sonLoad>onShow>onReady |
|
A | B | Click TAB | PageA hidden, pageB loaded | |
A | B(Open again) | Click TAB | PageA is hidden, pageB is displayed | |
A | C | navigateTo | PageA hidden, pageC loaded | |
A | C | redirectTo | PageA unloads, pageC loads | |
A | C | reLaunchTo | Unmount all pages and pageC loads | |
C | A | switchTabTo | Unmount all non-tab pages and pageA is displayed | |
D | C | navigateBack | PageD is unmounted and pageC is displayed | |
D | B | switchTabTo | Unmount all non-tab pages, pageC is displayed, and pageA remains | |
D | Close applets | Open A/B/C/D, close the applet from pageD, you can see the execution of D and ApponHide The applets didn’t really quit |
The above mentioned cases are relatively simple processes, from the official documentation can be understood, the following experiment with some complex processes.
The first kind of
A->C->D-B
In fact, this process can be understood by normal thinking. The following figure shows the whole process:
The picture above shows the entire life cycle of the applet from opening to completing the process. The rest is easy to understand. It is worth noting that DswitchTabTo
When B, all other non-Tabbar pages will be destroyed, so pageC and pageD will both fireonUnload
The second,
A->C->C->C
In this case, we continue to jump from page C to page C. In order to see whether the applet is creating a new page C or reusing the previous page C, we add an input to the page C to identify whether the page has been reused. The test results are shown as follows:
It turns out that each time we open a new page, our input fields are blank, and I typed 1/2/3 each time. We can also see from the lifecycle function that C did not execute onHide each timeonUnload
The previous page is still open, but each time C is executedonLoad/onShow/onReady
It indicates that we open a new page, but open the console to see the page stack information, as shown in the screenshot below:
There are only A and C in the page stack tree, but if we open this up when we jump, we can see C__webviewId__
It’s changing, and it proves that we’re opening a new page. Although the Tree from console AppData looks like there are two, we are actually limited by the wechat page depth limit of 10 layers if we jump 10 times. Press the back button in the upper left corner of wechat to see the life cycle process:
You can see that the C pages are executed in sequenceonUnload/onShow
, that is, the previous multiple C pages are unloaded one by one. NavigateBake unloads the current page using navigateBake or wechat’s own back button, so if you leave the page only with navigateTo, the current page will be retained. Otherwise, the current page will be uninstalled. Self-summary: For secondary pages, onLoad is triggered only if you return yourself from the next page without calling onLoad. No other circumstances have occurred to me, so I conclude.
Component lifecycle functions
Applets support custom components. Components are defined using the Component constructor, which defines their properties, data, methods, and so on. So let’s rearrange the life cycle function.
Component lifecycle functions come in two forms, both outside and in the same formlifetimes
As you can see in the sample code remarks below.
Component({
properties: {innerText: {type:String}},data:{
},
methods:{
},
created:function(){
// The component lifecycle function is executed when the component instance enters the page node tree. Note that setData cannot be called at this time
console.log('Component-1 >> created');
},
attached:function(){
// Component lifecycle function, executed when the component instance enters the page node tree.
console.log('Component-1 >> attached');
},
ready:function(){
// Execute after component layout is complete to obtain node information
console.log('Component-1 >> ready');
},
moved:function(){
Execute when the component instance is moved to another location in the node tree
console.log('Component-1 >> moved');
},
detached:function(){
// Executed when the component instance is removed from the page node tree
console.log('Component-1 >> detached');
},
lifetimes: {// Component life cycle declaration object, the component life cycle is declared in this field. The original declaration method is still valid. If there are two declaration methods, the declaration method in the LifeTimes field has the highest priority
created:function(){
console.log('Component-1 lifetimes >> created');
},
attached:function(){
console.log('Component-1 lifetimes >> attached');
},
ready:function(){
console.log('Component-1 lifetimes >> ready');
},
moved:function(){
console.log('Component-1 lifetimes >> moved');
},
detached:function(){
console.log('Component-1 lifetimes >> detached'); }},pageLifetimes: {// The life cycle of the page where the component is located. Currently, only the show and hide life cycles of the page are supported
show:function(){
console.log('Component-1 pageLifetimes >> Show');
},
hide:function(){
console.log('Component-1 pageLifetimes >> Hide'); }}});Copy the code
Introduce this component on page B and page C respectively, and look at the execution process of the lifecycle function in the following cases
NavigateTo switch from A to B, and then from B to C via navigateTo.
You can see that only the component executeslifetimes
The outer lifecycle function is not executed. And you can see that the component executes firstcreated/attached
Function, which then executes the page’sonLoad/onShow
, and then execute betweenready
, and finally execute the page’sonReady
, which is the order in which component lifecycle functions are executed when they are introduced to the page.
The lifeTimes life cycle function is executed, the outer life cycle function is not executed, so when both exist, the lifeTimes has higher priority.
In this componentpageLifetimes
It is not implemented, I don’t know the specific reason, the official website says that version 2.2.3 and above support, I still did not execute in 2.3.0 environment, I don’t know the specific reason, solve!
In the second case, the life cycle function of LifeTimes is not introduced, only the outer life cycle function is used, and the execution result is shown in the figure below:
As you can see, the order of execution of the lifecycle functions remains the same, and the outer lifecycle takes effect.
In the third case, two components are used in page B. Here, I comment out the Created lifecycle in LifeTimes to see the execution of the lifecycle. Here, the code of component 1 and component 2 is the same, and the execution result is as follows:
From the execution result, the execution sequence of the whole life cycle remains unchanged, but the corresponding life cycle of all components should be executed at each stage. As shown in the figure above, created of all components should be executed, attached of all components should be executed, onLoad and onShow of the page should be executed, and ready of all components should be executed. Finally, execute onReady for the page.
Conclusion: Through these experiments, a basic understanding of the life cycle of applets is gained.
1. The applets life cycle hook function will be executed when the applets are opened for the first time:onLaunch->onShow
And these hook functions are executed only once. Close the applet, the applet doesn’t really exit, so the execution just goes ononHide
.
2. The first opening of the page executes the page lifecycle hook function:onLoad->onShow->onReady
Through thenavigateTo
If you leave the page, the page remainsonHide
Any other way to leave (including navigateBack) will kill the current page, which is executed at this pointonHide>onUnload
. Special circumstances:switchTabTo
It kills all non-tab pages, but keeps all TAB pages that have been loaded.
3, the page containing components, execute all components firstcreated
, and then execute all of the componentsattached
And then execute the page’sonLoad>onshow
, and then execute all of the componentsready
, and then execute the page’sonReady
. When a page is unmounted, execute the page firstonUnload
, and then execute the componentdetached
. The page does not uninstall and does not trigger componentsdetached
.
First contact with small procedures, limited ability, welcome correction! [/ fuels]
Reference: developers.weixin.qq.com/miniprogram…