从Android后台恢复时,带有Firestore的Flutter应用遇到非常慢的查询 [英] My Flutter app with Firestore experiences very slow queries when it is resumed from the background on Android

查看:63
本文介绍了从Android后台恢复时,带有Firestore的Flutter应用遇到非常慢的查询的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

使用Flutter 1.20.2.

Using Flutter 1.20.2.

我的Flutter应用程序将Firestore用作后端数据库.对于当前使用的版本,在整个移动应用程序的开发过程中,我注意到,如果我的应用程序在后台运行了一段时间(可能是几分钟),那么当我将该应用程序重新放到前台时,查询返回数据非常慢.在iOS上不会发生这种情况.它仅在Android上发生.

My Flutter app uses Firestore as it's backend database. For the current version I am using and throughout the development of this mobile app I have noticed that if my app is in the background for a period of time (could be a few mins) then when I bring the app back into the foreground the queries are very slow to return data. This does not happen on iOS. It only happens on Android.

当我的应用程序正忙于从Firestore检索数据时,我使用CircularProgressIndicators.我使用的是固态管理设置,其中每个视图都有一个扩展BaseModel的模型:

I use CircularProgressIndicators when my app is busy retrieving data from Firestore. I am using a solid state management setup where each of my Views have a model that extends a BaseModel:

class BaseModel extends ChangeNotifier {
  ViewState _state = ViewState.Idle;
  ViewState get state => _state;
  bool isDisposed = false;

  void setState(ViewState viewState) {
    _state = viewState;
    if (!isDisposed) {
      notifyListeners();
    }
  }

  @override
  void dispose() {
    isDisposed = true;
    super.dispose();
  }
}

然后,我的视图通过以下方式使用我的视图特定模型:

My views then use my view specific models in the following way:

  @override
  Widget build(BuildContext context) {
    return BaseView<MyProfileModel>(
        //onModelReady: (model) => model.initialise(Provider.of<User>(context, listen: false)),
        onModelReady: (model) => model.initialise(),
        builder: (context, model, child) => Scaffold(
              resizeToAvoidBottomInset: false,
...

当应用程序在后台或从后台恢复时,我还没有使用AppLifecycleState类做任何特殊的事情.

I do not use the AppLifecycleState class yet to do anything special when the app is in the background or is resumed from the background.

当我的模型忙于检索数据时,我会显示忙碌的循环进度指示器.

When my model is busy retrieving data I show busy circular progress indicators.

问题是,当我从后台将应用程序恢复到前台时,有时应用程序可能会忙于长达1分钟的时间才检索数据-但只有在回到前台后才是第一次.随后的所有通话都是正常的.有时,它甚至挂在回到前台后第一次尝试获取数据.

The issue is that when I resume my app from the background into the foreground, sometimes the app could be busy for up to 1 minute before it retrieves the data - but only the first time after being back in the foreground. All subsequent calls are normal. Sometimes, it even hangs on first attempt to get data after coming back to the foreground.

我觉得我没有实现有关将应用程序恢复到使用Firestore数据库的前台的最佳实践.我怀疑它与重新建立Firestore连接和/或本地缓存有关.我的应用程序使用默认设置.

I feel like I am not implementing a best practice in relation to resuming an app into the foreground that uses the Firestore database. I have a suspicion that it has something to do with re-establishing the Firestore connection and/or local cache. My App uses the default settings for these.

我所有的Firestore API调用都包含在其自己的类中,并且每次都以相同的方式调用它:

All of my Firestore API calls are contained in it's own class and I call it the same way each time:

    await Firestore.instance
        .collection(DBStrings.COLLECTION_AD_MESSAGES)
        .document(ad.adId)
        .collection(DBStrings.COLLECTION_CHILD_AD_MESSAGES)
        .document()
        .setData({
        // Set fields...
    }).catchError((e) {
      res = false;
    });

有人可以给我一些有关此问题的见解,什么可能导致它发生?

Can someone give me some insight into this issue and what could be potentially causing it?

推荐答案

在我看来,您的应用失去了连接,并且从缓存中检索到的数据.我的建议是,当您的应用程序在后台运行时,尝试从Firebase控制台更改后端数据,然后测试以查看检索到的数据是更新的数据还是旧的数据.

It seem to me that your app is loosing the connection and the data retrieved is from the cache. My suggestion is for you to try to change the backend data from the Firebase console while your app is in the background, then test to see if the retrieved data is the updated or the old one.

如果数据是旧数据,则意味着您的应用无法恢复连接.要解决此问题,您需要检查身份验证状态(如果使用)并检查连接状态.识别连接状态并且不让应用花费很长时间才能进入缓存的一种简单方法是强制应用从远程询问数据并提供超时,例如:

If the data is the old one, it means your app could not restore the connection. To overcome this problem you need to check the auth status (if used) and to check the connection status. A simple way to identify connection status and not allow the app to take a very long time before going cache, is to force the app to ask data from remote and provide a timeout, like this:

QuerySnapshot snapshot = await query.getDocuments(source: Source.server).timeout(
        _timeoutDuration,
        // this or any other callback to handle timeout
        onTimeout: () => query.getDocuments(source: Source.cache));

如果您使用的是身份验证,则可以通过以下方式检查身份验证状态:

If you are using auth, you can check the auth status by calling:

FirebaseUser currentUser = await _auth.currentUser();
if (currentUser != null) {
  // Handle your auth problem here
}

如果您不使用auth,并且该应用程序在此长时间后正在从服务器中检索数据,请检查该应用程序是否在没有Firebase查询的情况下恢复得更快.

If you are not using auth and the app is retrieving the data from the server after this long period, check if the app would come back faster without the firebase query.

这篇关于从Android后台恢复时,带有Firestore的Flutter应用遇到非常慢的查询的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆