1. Overview of Flutter abnormalities
There are many articles about Flutter anomaly types and capture on the web. This article will not go into details, but only summarize them to ensure the integrity of the article.
Flutter abnormalities can be classified into the following categories:
- The Dart abnormal
- Abnormal App
- Synchronous abnormal
- Asynchronous exception
- Framework is abnormal
- Abnormal App
- Abnormal Engine
Dart exceptions can be divided into App exceptions and Framework exceptions based on their source, and App exceptions refer to. According to the execution sequence of the exception code, App exceptions can be divided into two types, namely synchronous and asynchronous exceptions:
- Synchronization exceptions can be caught using a try-catch mechanism
- Asynchronous exceptions need to be caught using the catchError statement provided by the Future
Dart uses the zone. runZoned method. In Dart, a Zone represents an environment in which code is executed. Because both synchronous and asynchronous exceptions can be intercepted, we often catch all App exceptions in the runApp layer.
runZoned<Future<Null> > (()async {
runApp(MyApp());
}, onError: (error, stackTrace) async {
//Do sth for error
});
Copy the code
Framework exceptions are typically thrown by widgets during build time github.com/flutter/flu… , where the default ErrorWidget is the red screen page that reports an error, and it can also be overwritten.
We can register FlutterError. OnError callback to intercept exceptions thrown outside the Flutter framework:
FlutterError.onError = (FlutterErrorDetails details) {
reportError(details.exception, details.stack);
};
Copy the code
The so-called error of the Flutter Engine, for example, is the error of libflutter. So on Android, and the error of the Flutter. Such as Firebase Crashlytics, Bugly, etc., more on this later.
2. Gray strategy
Due to our reverence for online business and certain operational requirements, we also need to provide a complete set of gray strategy and downgrade scheme for the online Flutter business in order to ensure the stability of operation. First, the gray strategy is discussed in this section.
The logical process of gray scale is relatively simple: configure gray scale strategy – background distribution configuration & client loading configuration – client processing configuration.
2.1 Gray Policy Configuration
We have defined some configuration fields required by the Flutter grayscale on our internal configuration platform, including:
key
: Corresponding Flutter page (route)appkey
: The host App corresponding to this configurationminVersion
: Indicates the minimum valid versionmaxVersion
: Indicates the largest valid versiontype
: Gray policy, including tail gray, region gray, device disabled, system disabled, mixed mode, whitelist mode, etc. Whitelist mode is for testing purposes, while mixed mode supports the combination of various policies to take effect.action
: Effective range, such as full effect, full effect, gray effect, etc.url
The client can concatenate the entry parameters of the Flutter route into URL Query parameters.
2.2 Background Delivery and Client Loading Configuration
Pull configurations for both hot and cold startup. Considering that there will be three retries after a failure, a singleton is maintained locally. When a Flutter page is to be opened on the service side, check the gray configuration to decide whether to open the Flutter page. Of course, in case of three failed attempts, a local Map of the degradation configuration of all Flutter pages is saved during release. In extreme scenarios, degradation is automatically enabled.
2.3 Client Processing Configuration
To open a Flutter page on the service side, check the gray configuration to determine whether to open the Flutter page. If it is judged to be non-gray scale, that is, it matches downgrade, then pull the configured downgrade link and use WebView to open the degraded H5 after setting URL parameters.
It should be noted that our current business basically changes FROM H5 to Flutter, so there are degraded versions by default, and the reliability of degraded versions can be guaranteed. For future new businesses only on Flutter, we are also prestudying the isomorphism solution of Flutter Web.
3. Downgrade scheme
We need timely downgradation to ensure the reliability of the Flutter service. The grayscale and downgradation are essentially used to distinguish between Flutter and H5 services. The former is manually configured and the latter automatically takes effect. Local maintenance will maintain a degrade configuration according to the App version, before opening the page will check whether the need to degrade. There are several scenarios that need to be degraded in time:
3.1 No hit grayscale degradation
As mentioned above, if a business is configured with a gray policy, the corresponding Flutter page can be opened when gray degradation is not matched. This page needs to be degraded and reported.
3.2 Abnormal framework degradation
If a Flutter Framework exception is caught, the page is set to “Need to degrade”. A custom ErrorWidget is provided to alert the user that the page is in error and needs to be re-entered. The degradation is triggered the next time the user accesses the page and is directed to the H5 page.
Dart exceptions use an event loop mechanism to run tasks, so the running status of each task is independent of each other. In other words, if an exception occurs, the subsequent code of the current task will not be executed, and users can continue to use other functions on the page. The impact is not too large.
3.3 Engine Crash Degraded
However, if there is an error in the Engine, App Crash will definitely occur. In this case, not only the log needs to be reported, but also the flag bit will be set to stop starting the Flutter Engine when the user opens the App next time, and all the pages of the Flutter will be completely degraded.
3.4 Degradation of product loading failure
Technically, we used a customized engine and clipped the Flutter products. Each time a version is issued, a corresponding MD5 value of the package reduction ZIP will be stored in the App. When the user starts the App for the first time, the package reduction products will be downloaded and then the engine will be started. Custom engine to load the decrement product. However, there is a situation where the product download fails. In addition to periodic retries, this situation also cannot start the Flutter Engine and do a full degradation of all pages and report it.
3.5 Degradation of Flutter related collapse
In addition, we have also experienced a Flutter crash, which is not an engine crash, nor a product loading problem, nor a Flutter abnormality, but simply a problem with the Flutter Plugin, such as a crash caused by an implementation logic problem on the native side of the Plugin. This is also a Flutter related crash. Bugly could not find the word “Flutter” in his logs, because it was not interrupted inside the Flutter or on the engine side when the program quit.
In this case, we will record the topViewController when the crash or ANR is reported and trace the source path. If there is a Flutter Activity or FlutterViewController in the current routing stack, the crash will still be degraded to be safe.
4. Run a daily newspaper
Flutter operation report data sources are performance reports and exceptions reports. As for crash monitoring and alerting, we left it to Bugly on the client. The Daily paper records the performance of Flutter pages in different App versions. There are several indicators for readers to refer to:
- pv
- Access success rate
- Crash rate. Crash affects the number of users
- Second opening rate (300ms limit)
- Degradation rate, gray rate
- …
Finally, the startup flow chart combining dynamic product loading and degradation strategy is as follows:
[image:BF00167C-0418-41DD-B837-F57C28C2C054-57904-000150D1B3F35050/flutter-start-flowchart-bg.png]
Refer to the article
- A Flutter of exception handling | Flutter developer
- Capture flutter app crash log and report to | Yrom ‘s