Principle of Offline Package
Taking the process of starting offline package at one time as an example, the loading process of offline package is divided into two scenarios. The first is the scenario where the offline package has been downloaded, as shown in Figure 1; the second is the scenario where the offline package has not been downloaded, as shown in Figure 2:
Figure 1: Mainstream offline package loading
Figure 2: Offline package download process
We can track the specific loading process of offline packages from buried points * :
-
Check whether offline packages exist on the local PC. If yes, perform the fourth step to decompress the packages and then verify the packages. If the packages have been installed on the local PC, you do not need to decompress them and go to the decompressed process
-
The network requests offline packet information. This step is asynchronous with the previous step, and the corresponding buried point is H5_APP_REQUEST
-
Determine whether to download the offline package after comparing the requested offline package information. The corresponding buried point is H5_APP_DOWNLOAD
-
Decompress the offline package, and the corresponding buried point is H5_APP_UNZIP
-
If the offline package check function is enabled to verify the validity of the offline package, the corresponding buried points are H5_APP_VERIFY and H5_AL_SESSION_VERIFYTAR_FAIL
-
The local offline package is loaded, and the corresponding buried points are H5_AL_SESSION_MAP_SUCCESS and H5_AL_SESSION_FALLBACK
The fallback + mainUrl returned after the asynchronous request callback is returned determines the URL at which the Webview is opened.
* Resources: Offline packet log burial point
Case 1: The offline package displays a blank screen for the first time
**STEP1: ** According to the analysis of offline package loading process, it must be the online fallback that needs to be opened for the first time. Since there is no local offline package, the online address (URL) of offline package must be known before going online. Therefore, it is necessary to check whether there is an error in the step of requesting offline package information in log analysis.
**STEP2: ** Analyze the log to open the online offline package when the URL is empty, the offline package is opened before the offline package request callback back, so a white screen appears.
STEP3: ** check the code
The problem was caused when the offline package controller created was used as the root view too early.
**STEP4: ** Give suggestions based on customer requirements. You can use local prefabricated offline package to solve the problem of white screen when opening offline package prematurely for the first time.
Case 2: An error occurs when opening the preset offline package (-1009)
Repetition demo
**STEP1: ** failed to open the prefabricated offline package, so I went online, because there is no network, so the network cannot be connected, the problem is the local prefabricated offline package.
**STEP2: ** according to the offline package loading process analysis, there are two cases of offline package verification signature failure and loading local offline package failure respectively in the case of local prefabricated package.
**STEP3: ** Log analysis
Failed to check was observed.
**STEP4: ** check whether the code client has closed the check, which is enabled by default. If not, the client needs to set the corresponding public key or close the check.
**STEP5: ** Close the check and try again to continue analyzing the log:
The H5_AL_SESSION_FALLBACK failed to load the local offline package and finally went to the line. The offline package decompression was successful. The fault occurred when loading the offline package, and the abnormal burial point of the H5_APP_EXCEP offline package was found in the log.
**STEP6: ** the problem may appear on the offline package. A normal offline package is provided for the customer to make a local prefabricated offline package. There is no problem when the network is disconnected and the verification is opened.
**STEP7: ** unlock the prefabricated offline package and observe whether the total length of path characters in the offline package exceeds the limit, leading to data reading failure.
The JS file name is too long, resulting in the total character length exceeds the limit, requiring the customer to modify the offline package *.
* Resources: Generate offline packages
Thinking and summarizing
Through introducing the above two cases, we can see clear case is one reason for the ultimate problems request offline package information no callback back this request, the customer will open the offline package without access to the URL, problems appeared in the request for offline package that step, and the second case ultimately positioning to load the local package failure that step.
Understanding the offline package loading process, combined with the Nebula Container Automation buried point log, can help you locate the problem at the offline package loading stage.
Author: Ali Cloud mPaaS TMA team (Yang Qiang Rongyang)
END
Next Tuesday (8.24) ali Cloud Feitian membership day will open, and 10% discount for resource packs such as message push. Click for more discount details.