Grande amélioration!

cela aiderait avec socket.io qui garde une minuterie de 85000ms par défaut. Sur RN master, le seuil est de 60000ms .

Et Firebase qui utilise également des minuteries longues.

Je reçois l'avertissement suivant lors de l'utilisation de la bibliothèque Firebase

Setting a timer for a long period of time, i.e. multiple minutes, is a performance and correctness issue on Android as it keeps the timer module awake, and timers can only be called when the app is in the foreground. See https://github.com/facebook/react-native/issues/12981 for more info. (Saw setTimeout with duration 111862ms)

Comment se débarrasser de cet avertissement ...

Je reçois également l'avertissement suivant lorsque j'utilise la bibliothèque Firebase. Quelqu'un sait comment résoudre ce problème?

Je reçois également cet avertissement avec Firebase.

"firebase": "^3.9.0",
"react-native": "0.44.0"

Même problème ( 85000ms ) mais sans firebase . Ma liste de forfaits:

  "dependencies": {
    "apisauce": "0.11.0",
    "format-json": "1.0.3",
    "lodash": "4.17.4",
    "markdown-it": "^8.3.1",
    "native-base": "^2.1.3",
    "normalizr": "^3.2.2",
    "prop-types": "^15.5.10",
    "querystringify": "1.0.0",
    "ramda": "0.23.0",
    "react": "16.0.0-alpha.6",
    "react-markdown": "^2.5.0",
    "react-native": "0.44.0",
    "react-native-animatable": "1.2.0",
    "react-native-config": "0.4.2",
    "react-native-device-info": "0.10.2",
    "react-native-drawer": "2.3.0",
    "react-native-htmlview": "0.9.0",
    "react-native-i18n": "1.0.0",
    "react-native-linear-gradient": "^2.0.0",
    "react-native-photo-view": "^1.2.0",
    "react-native-router-flux": "3.39.1",
    "react-native-scrollable-tab-view": "*",
    "react-native-share": "^1.0.20",
    "react-native-vector-icons": "4.1.1",
    "react-navigation": "^1.0.0-beta.9",
    "react-redux": "5.0.4",
    "redux": "3.6.0",
    "redux-persist": "4.6.0",
    "redux-saga": "0.15.3",
    "reduxsauce": "0.4.1",
    "seamless-immutable": "7.1.2"
  },
  "devDependencies": {
    "ava": "^0.18.2",
    "babel-eslint": "^7.1.1",
    "babel-preset-es2015": "^6.18.0",
    "enzyme": "^2.6.0",
    "husky": "^0.13.1",
    "ignite-animatable": "^0.3.1",
    "ignite-dev-screens": "^2.0.0-beta.9",
    "ignite-i18n": "^0.1.1",
    "ignite-ir-boilerplate-2016": "^0.2.2",
    "ignite-vector-icons": "^0.2.1",
    "mockery": "^2.0.0",
    "nyc": "^10.1.2",
    "react-addons-test-utils": "^15.3.1",
    "react-dom": "^15.4.0",
    "react-native-mock": "^0.3.1",
    "reactotron-apisauce": "^1.7.0",
    "reactotron-react-native": "^1.7.0",
    "reactotron-redux": "^1.7.0",
    "reactotron-redux-saga": "^1.7.0",
    "snazzy": "^6.0.0",
    "standard": "^8.6.0"
  }

Je rencontre un problème similaire en utilisant 0.44.0 sur Android. Je n'utilise pas non plus Firebase:

Setting a timer for a long period of time, i.e. multiple minutes, is a performance and correctness issue on Android as it keeps the timer module awake, and timers can only be called when the app is in the foreground. See https://github.com/facebook/react-native/issues/12981 for more info. (Saw setTimeout with duration 85000ms)

Salut les gars .. se demandait Y a-t-il un travail rapide pour cela. J'utilise:

react-native 0.44 react 16.0.0-alpha.6 feathers-socketio 1.6.0

Son très ennuyeux apparaît pendant que je développe ... est-ce que je peux cacher l'avertissement pour le moment?

Même problème ici avec Firebase 3.9.0

Si cela vous dérange, ajoutez simplement console.ignoredYellowBox = ['Setting a timer'];

@ Avis skv-headless entrant. :)

À mon avis, cette attitude face aux problèmes doit disparaître. Je l'ai vu apparaître plus souvent et cela pousse les gens à ignorer les avertissements. Ce sont des avertissements. Ils vous préviennent. Ne les ignorez pas, faites quelque chose. J'ai vu des applications où tous les avertissements sont simplement ignorés, même les avis d'obsolescence. Ensuite, votre application s'arrête et vous vous demandez pourquoi.

Dans ce cas, vous pouvez configurer ces délais et les réduire, ou configurer une approche différente pour les gérer. Peut-être même piquer les responsables des bibliothèques et leur demander de vous aider à trouver une solution.

Mon conseil est de suivre ce fil jusqu'à ce que quelqu'un d'intelligent trouve une solution réelle, afin que vous puissiez ensuite vous renseigner avec cette réponse. Et puis peut-être, en attendant (si vous ne pouvez / ne voulez pas résoudre le problème), ignorez les avertissements.

TL, DR;

Oui, vous pouvez ignorer temporairement les avertissements. Vérifiez simplement de temps en temps quel est le statut et si une action est requise.

@imamatory je pense que c'est par Rectotron

Je pense que c'est par Rectotron

Si tel est le cas, cet avertissement peut être simplement ignoré.
... Cependant, mon émulateur Android devient parfois lent, c'est peut-être l'une des raisons.

@imamatory J'espère que la vraie solution est tout aussi simple

Salut, je pense avoir trouvé la solution:
Tout d'abord, vous devez trouver le fichier suivant dans votre projet: bibliothèques / Core / Timers / JSTimer; js
Ouvrez-le et il vous suffira de modifier cette const MAX_TIMER_DURATION_MS, pour l'augmenter au dessus de votre durée, écrit en fin d'avertissement!

@nicolasZZ salut, Merci pour la solution. mais est-ce une bonne pratique de modifier la bibliothèque JSTimer plutôt que notre propre code?

@nicolasZZ @AmroAly Dans mon esprit cette solution n'est pas une bonne pratique car elle est très instable, le mieux est d'ignorer l'alerte pendant que la solution officielle est publiée.

console.ignoredYellowBox = [
    'Setting a timer'
]

la solution de @ skv-headless est bonne mais dans mon cas ne fonctionne qu'avec "enter" entre les parenthèses

@rigobcastro Merci qui cache les alertes ennuyeuses.

@ DZuz14 ce serait génial si vous pouviez envoyer un PR ou au moins lancer la conversation. Merci 👍

salut ~
J'ai utilisé socket.io. nodejs and RN44 or RN 45
J'ai vu avertir ces minuteries.

J'ai trouvé cette solution
reference reactotron PR

serveur personnel nodejs et scoket.io

const express = require('express')
const app = express()
const server = require('http').Server(app)
const io = require('socket.io')(server, {pingTimeout: 30000})

Merci!

J'ai un projet natif de réaction simple pour Android et j'utilise l'authentification Firebase avec React native pour la connexion et l'inscription, mais j'ai cette erreur jaune, que dois-je faire? Lien de ma question dans stackoverslow (https://stackoverflow.com/questions/44603362/setting-a-timer-for-a-long-period-of-time-ie-multiple-minutes)

Merci @ DZuz14
J'ai cette erreur lorsque j'exécute react-native run-android

D:\Projects 2016\Web\Android\mohajerkade-android\android\app\src\main\java\com\mohajerkade\AlarmManagerModule.java:40: error: cannot find symbol
       Intent intent = new Intent(context, AlarmReceiver.class);
                                           ^
  symbol:   class AlarmReceiver
  location: class AlarmManagerModule
1 error
:app:compileDebugJavaWithJavac FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:compileDebugJavaWithJavac'.
> Compilation failed; see the compiler error output for details.

Je veux utiliser l'authentification firebase avec react native pour la connexion et l'inscription mais j'ai cette erreur jaune
1: Qu'est-ce que ce module exactement?
2: Pourquoi mon projet a-t-il besoin de ce module?

J'ai demandé à stackoverflow via ce lien: (https://stackoverflow.com/questions/44603362/setting-a-timer-for-a-long-period-of-time-ie-multiple-minutes)
J'ai signalé à l'équipe Google Firebase via ce lien: (https://github.com/firebase/firebase-js-sdk/issues/97)

@ DZuz14 J'ai la même question que @saeedhei .

Fondamentalement, nous utilisons le module de nœud firebase qui utilise ces minuteries à longue période.

Ajouter votre module ne suffit pas, je suppose, nous devons en fait réécrire le code dans le module de nœud firebase pour utiliser vos alarmes plutôt que des minuteries Javascript, non?

Merci @ DZuz14

Donc, si vous regardez dans le package npm appelé firebase vous constaterez qu'il utilise setTimeout dans de nombreux endroits. C'est correct car la bibliothèque a été écrite pour les sites Web et les serveurs node.js. react-native est une sorte de serveur node.js mais il fonctionne sur un téléphone - et comme l'avertissement le souligne correctement - les minuteries Javascript de longue durée ne sont pas bonnes dans cet environnement et peuvent vider la batterie et avoir d'autres effets secondaires indésirables .

Je suppose donc que nous devons convaincre les gars de Firebase de changer votre approche et de distribuer un paquet spécialement conçu pour react-native .

@BerndWessels https://www.npmjs.com/package/react-native-firebase Avez-vous regardé cela? Dit qu'il permet à Firebase de fonctionner sur le thread natif. Je ne sais pas à quel point c'est vrai, mais cela vaut peut-être le coup d'œil. Vous l'utilisez peut-être même, je ne suis pas sûr.

@ DZuz14 Merci, je vais vérifier ça.

console.ignoredYellowBox = [
'Réglage d'une minuterie'
]

@rigobcastro Où puis-je saisir ou coller ce code?

@ Jazz747 En haut de votre fichier d'installation, par exemple app.js, index.android.js ou index.ios.js

console.ignoredYellowBox = [ 'Setting a timer' ]
Ce code ne masque que l'avertissement à l'intérieur de react native.

Qu'en est-il de l'avertissement dans la console du navigateur?

Est-ce que quelqu'un sait si quelqu'un de l'équipe RN ou de la communauté travaille sur une solution à ce problème?

La fenêtre contextuelle d'avertissement redirige vers ce problème, mais je ne trouve aucune solution appropriée ici autre que de masquer l'avertissement, ce qui n'est pas du tout une solution. Des idées ou des suggestions?

@SuhairZain Tout semble indiquer que ce sont des erreurs de bibliothèques externes à RN

@rigobcastro Cet avertissement peut être facilement reproduit avec un appel setInterval() avec un temps assez long (qui était de 5 minutes dans mon cas). Je dirais donc que ce n'est pas quelque chose causé par des bibliothèques tierces.

BTW, j'ai depuis trouvé une bibliothèque ici: react-native-background-timer qui m'aide à faire le travail.

@SuhairZain oui vous setInterval() ) et l'avertissement a disparu.

Bonne recommandation, merci.

j'ai le même problème ici. Et je pouvais toujours comprendre comment dois-je gérer ce problème.

rn: 0,45,1
base de feu: 4.1.3

Cher @escalepion, j'ai signalé à l'équipe Firebase: (https://github.com/facebook/react-native/issues/12981#issuecomment-309595327)

@escalepion Si votre problème concerne la configuration de minuteries de longue durée, veuillez consulter mon commentaire ci-dessus et voir si cela vous aide.

@SuhairZain désolé, je ne pourrais pas comprendre que comment utiliser setInterval ou react-native-background-timer :( Où et comment vais-je écrire le code? Avez-vous un exemple?

Quelqu'un a-t-il un conseil sur la façon de déterminer quelle bibliothèque est à l'origine du dommage? J'ai récemment mis à niveau RN à 0,46 et soudainement cette erreur est apparue. J'ai pas mal de bibliothèques dans mon projet et je ne peux penser à les étudier qu'une par une, ce qui n'est évidemment pas idéal.

À votre santé!

@ abeltje1 , si vous trouvez comment résoudre ce problème, pourriez-vous, s'il vous plaît, mettre à jour ici

@liketurbo c'est sûr que je le ferai

Je rencontre ce problème avec redux-saga pour revalider le jeton API toutes les 30 minutes.

Par conséquent, dans ce cas, attendre aussi longtemps est en fait correct. Et j'imagine qu'il existe d'autres scénarios dans lesquels une longue attente est attendue.

Alors ma question est, pourquoi est-ce un avertissement? Qu'est-ce qui peut casser / arriver? Ne suis-je pas censé pouvoir utiliser des LLT (transactions de longue durée)?

Si LLT est ok. Quelle serait la meilleure approche pour traiter ce problème? Extension de la durée d'AlarmManager?

Merci d'avance ;)

J'ai le même problème que @sospedra. J'utilise redux-saga et j'ai une saga qui actualise certaines données de l'application en arrière-plan toutes les 3 minutes, donc la saga inclut le code yield call(delay, 3 * 60000); . En conséquence, j'obtiens l'erreur "Réglage d'une minuterie pendant une longue période de temps ...".

Je me demande également quelle est l'approche suggérée pour quelque chose comme ça. Quels problèmes vais-je rencontrer si je laisse simplement mon code fonctionner de cette façon. Le message d'erreur implique qu'il pourrait y avoir des problèmes de performances, et peut-être que le minuteur ne sera pas déclenché au bon moment si l'application est en arrière-plan?

S'il y a probablement des problèmes avec ce code définissant une minuterie de 3 minutes, quelle solution alternative permettrait d'obtenir la même fonctionnalité et de ne pas rencontrer ces problèmes?

toujours le même problème.

Je pense que la seule solution est de passer au développement Android natif

Le problème ne peut toujours pas être résolu? Quelqu'un a trouvé la solution?

Je reçois un avertissement lorsque j'utilise Firebase.

Si le problème ne provient pas d'une bibliothèque tierce, mais que vous définissez vous-même un long délai d'expiration, une bonne solution consiste à utiliser la bibliothèque react-native-background-timer . Son README contient également un exemple simple.

Malheureusement , si le problème provient d'une bibliothèque tierce, vous n'avez probablement pas de solution autre que de trouver l'endroit où le setTimeout est appelé et de soulever un problème / soumettre un PR pour utiliser la bibliothèque susmentionnée à la place , veuillez essayer ma solution possible ci-dessous à https://github.com/facebook/react-native/issues/12981#issuecomment -331074444 et essayez si cela fonctionne pour vous.

Veuillez également faire un bon timeout sur Android.

react-native-background-timer est une bonne solution de contournement comme l' a dit

Je reçois cet avertissement lors de l'utilisation de socket.io

car socket.io a un timer de 85ms

FWIW cela ne m'arrive que lorsque j'utilise Reactotron pendant le développement ...

M'a rendu fou pendant un moment, je dois admettre mais je savais que je ne pouvais pas ignorer le message

Je ne travaille plus sur le projet avec lequel j'ai eu ce problème, donc je ne peux pas vraiment tester si cette approche fonctionne, mais elle devrait, du moins en théorie. Si l'erreur provient d'un module tiers utilisant setTimeout ou setInterval avec un long délai, cela devrait permettre de résoudre votre problème. Ce qu'il fait, c'est monkey patch le global setTimeout et setInterval pour utiliser à la place des react -native-background-timer :

import BackgroundTimer from 'react-native-background-timer';

setTimeout = BackgroundTimer.setTimeout;
setInterval = BackgroundTimer.setInterval;
clearTimeout = BackgroundTimer.clearTimeout;
clearInterval = BackgroundTimer.clearInterval;

Écrivez ce code quelque part dans votre première initialisation, de préférence index.android.js ou index.ios.js le plus tôt possible. Si quelqu'un peut tester cela, ce serait très apprécié.

@SuhairZain : votre suggestion fonctionne pour moi jusqu'à présent, avec quelques ajustements:

setTimeout = BackgroundTimer.setTimeout.bind(BackgroundTimer)
setInterval = BackgroundTimer.setInterval.bind(BackgroundTimer)
clearTimeout = BackgroundTimer.clearTimeout.bind(BackgroundTimer)
clearInterval = BackgroundTimer.clearInterval.bind(BackgroundTimer)

@levity J'ai ajouté votre code à mon app.js, mais j'ai ceci

undefined n'est pas un objet (évaluation de 'RNBackgroundTimer.setTimeout')

@realtebo semble que vous n'avez peut-être pas terminé l'installation de react-native-background-timer comme décrit dans leur README en exécutant react-native link ou en utilisant CocoaPods.

@levity : voulez-vous dire exécuter react-native link ?

npm install -g react-native-cli
lien natif de réaction
Analyse des dossiers pour les liens symboliques dans C: \ Users \ realtebo \ Downloads \ manager2 \ node_modules (54ms)
react-native link ne peut pas être utilisé dans les projets Create React Native App. Si vous devez inclure une bibliothèque qui repose sur du code natif personnalisé, vous devrez peut-être d'abord l'éjecter. Voir https://github.com/react-community/create-react-native-app/blob/master/EJECTING.md pour plus d'informations.

Je ne veux pas éjecter ... alors, que puis-je faire?

Oh, désolé, je ne sais pas comment vous aider avec un projet Create React Native App. Je n'ai jamais utilisé ça moi-même.

Salut,
J'ai eu des problèmes avec react-native: ^0.49.3 ...

cf. https://github.com/ocetnik/react-native-background-timer/issues/65

J'espère que vous pouvez aider, merci pour votre temps;)

Bonjour, j'ai le même problème que j'utilise 0.49 , il est apparu après avoir fait cela

export function saveUserData(userInfo){
  return (dispatch) => {
    dispatch(saveDataRequest())
    const userId = firebase.auth().currentUser.uid;
    return firebase.database().ref('users/' + userId).set(userInfo)
      .then(() => {
        dispatch(saveDataSuccess());
        dispatch(NavigationActions.navigate({ routeName: 'TabContactNavigation' }))
      })
      .catch((error) => {
        dispatch(saveDataFailure(error))
      });
  }
}

Ce qui précède est Action dans redux, qui utilise également redux-thunk .. Lorsqu'un bouton est cliqué pour enregistrer les données d'un formulaire dans firebase lorsque l'enregistrement a réussi, il envoie saveDataSuccess() , puis accédez à l'onglet suivant.
Maintenant, je soupçonne que le problème semble être ici const userId = firebase.auth().currentUser.uid mais je ne suis pas sûr. Voici une capture d'écran du problème. (l'application fonctionne bien mais cet avertissement apparaît, je ne sais pas si je dois simplement l'ignorer) ou peut-être que je fais quelque chose de mal ici, j'ai besoin de votre aide, merci

hé, l'avertissement concerne setTimeout l'utilisez vous dans votre composant?
et oui, la ligne const userId = firebase.auth (). currentUser.uid; ne fonctionne pas, c'est une promesse et lorsque vous utilisez userId, il ne vient toujours pas.
une meilleure façon de le faire est d'obtenir le userId de l'actionCreator, vous envoyez déjà la variable userInfo, essayez ceci:

Je suppose que userInfo provient de la connexion d'authentification de firebase, donc vous avez l'uid dedans

fonction d'exportation saveUserData (userInfo) {
return (expédition) => {
dispatch (saveDataRequest ())
// const userId = firebase.auth (). currentUser.uid;
retourne firebase.database (). ref ('utilisateurs /' + userInfo.uid) .set (userInfo)
.then (() => {
dispatch (saveDataSuccess ());
dispatch (NavigationActions.navigate ({routeName: 'TabContactNavigation'}))
})
.catch ((erreur) => {
dispatch (saveDataFailure (erreur))
});
}
}
j'espère que cela pourrait aider, et désolé pour mon mauvais anglais = P

Félicité

El 23/10/2017, à 23h59, Yasir [email protected] escribió:

Salut, j'ai le même problème que j'utilise 0.49, il est apparu après avoir fait cela

fonction d'exportation saveUserData (userInfo) {
return (expédition) => {
dispatch (saveDataRequest ())
const userId = firebase.auth (). currentUser.uid;
retourne firebase.database (). ref ('utilisateurs /' + userId) .set (userInfo)
.then (() => {
dispatch (saveDataSuccess ());
dispatch (NavigationActions.navigate ({routeName: 'TabContactNavigation'}))
})
.catch ((erreur) => {
dispatch (saveDataFailure (erreur))
});
}
}
Ce qui précède est Action dans redux, qui utilise également redux-thunk .. Lorsqu'un bouton est cliqué pour enregistrer les données d'un formulaire dans Firebase lorsque la sauvegarde est réussie, il envoie saveDataSuccess () puis navigue vers l'onglet suivant.
Maintenant, je soupçonne que le problème semble être ici const userId = firebase.auth (). CurrentUser.uid mais je ne suis pas sûr. Voici une capture d'écran du problème. (l'application fonctionne bien mais cet avertissement apparaît, je ne sais pas si je dois simplement l'ignorer) ou peut-être que je fais quelque chose de mal ici, j'ai besoin de votre aide, merci

https://user-images.githubusercontent.com/12644122/31925375-94b7c464-b89d-11e7-889d-e9d00866ff73.png
https://user-images.githubusercontent.com/12644122/31925386-9e9bf3c4-b89d-11e7-9eaa-65147879629f.png
-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, visualisez-le sur GitHub https://github.com/facebook/react-native/issues/12981#issuecomment-338874018 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/ AHhM1oYWKrWSOZsm-8hjp4Q6qJSfqraUks5svW6-gaJpZM4Mf0Z0 .

Habituellement, j'enregistre dans un magasin redux le userinfo.
Donc, je resuse simplement au besoin.
... mais ... dans une situation similaire, j'ai le même problème avec le timeout

Même problème avec la bibliothèque react-native-signalr (300000ms)

Options du serveur socket.io
pingTimeout (60000) + pingInterval (25000) <= 60000

Une mise à jour sur la façon dont nous devrions gérer cela sur Android? Toujours en train de l'obtenir, sans utiliser setTimeout non plus ...

Juste pour faire suite à mon commentaire précédent (d'août) qui, je crois, résume les sentiments de toutes les personnes ici: nous sommes d'accord avec ce truc d'AlarmManager, c'est juste que nous voulons connaître la meilleure approche pour gérer les transactions de longue durée.

cc @shergin @cpojer @javache @hramos

Un correctif pour react-native-signalr (ms-signalr-client) sur Android consiste à remplacer l'intervalle de ping par défaut (300000):
connection.start({ pingInterval: 5000, jsonp: true, transport: ['webSockets', 'serverSentEvents', 'longPolling']}).done(() => { console.log('Now connected, connection ID =' + connection.id) })

Même problème avec react-native-pomelo (80000ms)

console.ignoredYellowBox = ['Setting a timer'];

C'est une solution de contournement assez sûre car vous recevrez toujours l'avertissement dans la console de Chrome lorsque vous déboguez à distance

Où est exactement le meilleur endroit pour mettre le code d'ignorer la console?

- tant pis, j'ai obtenu un indice du stackexchange lié, ajouté à mon App.js comme suit:

class App extends Component {
  constructor() {
    super();

    console.ignoredYellowBox = [
      'Setting a timer'
    ];
  }
...
}
````

and also tried in my index.js as <strong i="8">@haikyuu</strong> just recommended..

import {AppRegistry} depuis 'react-native';
importer l'application depuis './App';

console.ignoredYellowBox = [
'Réglage d'une minuterie'
];

AppRegistry.registerComponent ('manager', () => App);
`` ``

travaillé dans les deux

@CopyJosh vous pouvez le mettre dans votre fichier d'entrée: index.js

il n'y a donc pas encore de solution réelle à cela? ça fait plus de 8 mois maintenant ..

?

Laissons cela résolu alors. Il faudrait probablement comprendre:

A.) Une API extensible facile qui peut être appelée via le code React. Je pense qu'il serait sage de s'attaquer peut-être à la mise en œuvre d'une seule des méthodes AlarmManagers. Par exemple, appeler la méthode suivante dans votre code React Native définirait une alarme avec le AlarmManager natif des appareils Android.
AlarmMgr.setInexactRepeating(arg1, arg2...)

B.) La mise en œuvre effective de faire fonctionner cela. Pour autant que je sache, le réglage d'une alarme avec AlarmManager envoie ce qu'on appelle une «intention en attente» au service AlarmManager. Vous dites à AlarmManager que vous souhaitez exécuter un certain type de "tâche" à l'avenir. Il me semble que vous auriez besoin que AlarmManager (ou une méthode Java React personnalisée) renvoie un type de données à votre code JavaScript, lui indiquant le code à exécuter après le déclenchement de l'alarme.

Quelqu'un est-il prêt à résoudre ce problème? Vous pouvez en savoir plus sur AlarmManager ici .

btw - cette inefficacité (liée à de longs délais d'attente de plusieurs minutes) est-elle un nouveau problème uniquement pour les versions RN> 0,43? Ou est-ce simplement que l'avertissement est émis depuis RN> 0,43? J'ai migré de 0.43.x vers 0.47.x et j'ai commencé à voir l'avertissement. J'ai supposé que l'inefficacité avait toujours été là et que l'infirmière venait de commencer à m'en avertir maintenant.

cependant, depuis la migration il y a quelques jours, j'ai également remarqué que mon application consomme beaucoup plus de batterie sur mon téléphone! (et les autres fonctionnalités du diff ne sont pas des coupables évidents)

Hé @astreet , vous souvenez-vous peut-être encore de ce à quoi vous https://github.com/facebook/react-native/commit/3637bce479 ?

Cela m'est récemment devenu assez ennuyeux après avoir commencé à utiliser une bibliothèque qui définit une minuterie récurrente de 2 minutes, alors j'ai commencé à creuser dessus pour comprendre pourquoi cet avertissement a été ajouté en premier lieu.

Maintenant, je suis préoccupé par cette phrase: "garde le module de synchronisation éveillé". Ce à quoi je pense que vous faites peut-être référence, c'est que le module Timer définit le rappel du chorégraphe. Bien que le rappel semble être défini, que nous ayons le minuteur ou non. Voir la partie de code correspondante ici: https://github.com/facebook/react-native/blob/1e8f3b11027fe0a7514b4fc97d0798d3c64bc895/ReactAndroid/src/main/java/com/facebook/react/modules/core/Timing.java#L
Il n'y a pas de code pour arrêter le rappel lorsqu'il n'y a pas de minuteries programmées et il n'y a pas de code pour démarrer la planification lorsque la minuterie est ajoutée. Le rappel est suspendu uniquement lorsque l'application passe en arrière-plan et restaurée lorsqu'elle est replacée au premier plan.

En conséquence, le rappel du chorégraphe est mis en file d'attente pour chaque image, que nous ayons une minuterie pour une longue période, une courte période ou pas de minuterie du tout définie. Je ne vois pas comment le réglage d'une longue minuterie peut affecter les performances dans ce cas. Alors, cela signifie-t-il que l'avertissement n'est pas nécessaire?

En ce qui concerne le fait de définir une longue minuterie comme un "problème d'exactitude", je pense que vous faites référence au fait que les minuteries ne seront appelées que dans l'état de l'application au premier plan (donc lorsque vous la définissez pendant longtemps dans le futur et que l'application entre dans bg il ne s'exécutera pas ou s'exécutera lorsque l'application sera au premier plan, ce qui peut être beaucoup plus tard que prévu). Bien que je pense que c'est le même cas pour iOS où nous ne montrons pas l'avertissement

Dans socket.io, la boucle ping par défaut est de 85000 ms, = pingInterval (25000ms) + pingTimeout (60000ms). et vous devez réinitialiser ces options dans le serveur et vous assurer que la somme de pingInterval et pingTimeout <= 60000ms.

par exemple:

var socket = require('socket.io')(12345, {
  pingInterval: 20000, 
  pingTimeout: 40000
})

Juste curieux - je dois être en mesure de définir un délai d'attente d'environ 5 minutes dans mon application. Quelle est la gravité de ce problème et dans quelle mesure cela m'affecterait-il?

@ntomallen Si l'application est

J'utilise laravel echo avec React Native sur les options du serveur de changement de socket android pingTimeout à 30000. Cela fonctionne

@sospedra gotcha. Je vais devoir faire quelques tests pour m'assurer que ce n'est pas trop mal!

Y a-t-il une raison de ne pas toujours utiliser Handler.postDelayed?

une solution rapide pour ce problème? Je viens de commencer à utiliser RN avec Firebase.

J'ai essayé plusieurs solutions de minuterie différentes, mais je n'ai pas eu la chance d'en faire fonctionner une en arrière-plan (de manière cohérente).

J'ai utilisé un setInterval pour envoyer un ping à mon serveur toutes les 10 minutes - je viens de remarquer ce message d'erreur car je fais un setInterval(myFunction, 60000) . Est-ce quelque chose dont je dois m'inquiéter?

Mon comportement attendu est que lorsque l'application est ouverte, elle peut envoyer les demandes, mais une fois l'application suspendue (une seule pression sur le bouton d'accueil), les demandes devraient cesser de se déclencher. Est-ce le comportement auquel je peux m'attendre, et la durée de vie de la batterie sera-t-elle affectée lorsque l'application est suspendue?

Il n'y a rien à craindre ici, et l'avertissement est incorrect et doit être supprimé. Il n'y a pas de "module de minutage" pour rester éveillé, il y a juste un rappel de chorégraphe qui vérifie les minuteries à chaque image (ce qui rend également la granularité minimale des minuteries d'environ 16 ms).

Il y a un problème d'exactitude dans le sens où les minuteries ne se déclenchent pas en arrière-plan sur iOS ou Android. Cet avertissement semble cependant concerner spécifiquement Android et ne semble pas être exact. Tous les minuteurs devraient éventuellement se déclencher lorsque l'application revient au premier plan.

Avez-vous l'intention de régler ce problème bientôt? Le journal est ennuyeux chaque fois que nous testons sur les téléphones Android.

Mon problème…

J'obtenais cette erreur car mon délai d'attente était d'environ 59 minutes. Le code pour appeler une méthode en haut de l'heure et avait un setTimeout pour créer un setInterval au début de l'heure suivant.

Ma solution…

1. mettez à jour le setTimeout pour démarrer le setInterval en haut de la minute.
2. mettre à jour la fonction appelée par setInterval pour n'exécuter la fonction que si les minutes en cours étaient 0 .

Cette fonction tourne désormais toutes les minutes au lieu de toutes les heures… mais comme elle ne fait rien 59 fois sur 60, elle semble inoffensive.

hey @beausmith , est-ce vraiment une solution pour régler simplement 60 minuteries? À ma connaissance, il maintient toujours le timerModule actif pendant la même heure, mais n'affiche pas l'avertissement :)

@newah - ouais, c'est un peu hacky… pouvez-vous suggérer une meilleure solution?

@beausmith , j'ai essayé d'utiliser https://github.com/ocetnik/react-native-background-timer qui utilise des minuteries natives qui sonne comme une solution - j'ai simplement écrasé setTimout et setInterval avec l'implémentation de cette lib.

La prise en charge des minuteries en arrière-plan peut être un avantage ou un inconvénient selon vos besoins :))

Cela semble bien fonctionner, mais n'a pas résolu mes problèmes :)

J'ai le même avertissement si j'utilise react-intl FormattedRelative. Parce qu'à l'intérieur du composant FormattedRelative est utilisé le timer:

scheduleNextUpdate(props, state) {
    // Cancel and pending update because we're scheduling a new update.
    clearTimeout(this._timer);

    const {value, units, updateInterval} = props;
    const time = new Date(value).getTime();

    // If the `updateInterval` is falsy, including `0` or we don't have a
    // valid date, then auto updates have been turned off, so we bail and
    // skip scheduling an update.
    if (!updateInterval || !isFinite(time)) {
      return;
    }

    const delta = time - state.now;
    const unitDelay = getUnitDelay(units || selectUnits(delta));
    const unitRemainder = Math.abs(delta % unitDelay);

    // We want the largest possible timer delay which will still display
    // accurate information while reducing unnecessary re-renders. The delay
    // should be until the next "interesting" moment, like a tick from
    // "1 minute ago" to "2 minutes ago" when the delta is 120,000ms.
    const delay =
      delta < 0
        ? Math.max(updateInterval, unitDelay - unitRemainder)
        : Math.max(updateInterval, unitRemainder);

    this._timer = setTimeout(() => {
      this.setState({now: this.context.intl.now()});
    }, delay);
  }

Voici un exemple d'utilisation dans mon code:

<FormattedRelative value={date}>
    {(message: string) => <Text>{message}</Text>}
</FormattedRelative>

Quelqu'un sait comment résoudre cet avertissement?

C'est toujours un problème. C'est particulièrement ennuyeux lors de l'utilisation des services Firebase sur Android. S'il-vous-plaît, réparez.

Il s'agit d'un très mauvais bogue pour les services Firebase et lorsque vous êtes dépendant d'applications tierces. Parce que Firebase ne fonctionne pas si vous basculez entre les applications pour vérifier quelque chose pour continuer le processus.

Un exemple est que nous utilisons un système de connexion tiers / facteur, et que nous utilisons Firebase pour déplacer des jetons. Mais depuis que nous nettoyons, le jeton a disparu avant que la personne ne soit de retour dans notre application. Je peux donc changer les mécanismes de nettoyage, ou vous pouvez corriger ce bogue.

@vongohren non pas que je comprenne parfaitement votre cas d'utilisation, mais une stratégie de contournement pourrait être de stocker la date d'arrière-plan dans votre application lors de l'entrée en arrière-plan, puis de revenir au premier plan, de comparer la date actuelle avec la date d'arrière-plan stockée et d'effectuer un nettoyage si un certain laps de temps s'est écoulé ...

Pour élaborer mon cas d'utilisation. Disons que vous dépendez de dire oui dans une autre application pour accepter la connexion. Feks passe à l'application Facebook pour dire oui à une demande de connexion chez un tiers. L'exemple concret avec lequel je travaille est uPort, https://www.uport.me/. Ensuite, lorsque nous comptons sur un moyen d'envoyer un message à notre application, maintenant en arrière-plan pour dire que tout va bien, cela ne fonctionne pas avec Firebase à moins que nous n'adoptions votre approche pour nettoyer ultérieurement.

Je suppose que j'étais juste coincé sur le fait que le nettoyage pouvait avoir lieu juste après l'émission des informations, car alors les informations étaient déjà émises, et nous n'en aurions pas besoin. Mais pourquoi est-ce que l'approche Firebase ne fonctionne pas dans React native? Qu'il arrête ses travailleurs d'arrière-plan.

J'ai besoin d'un délai de 30 minutes dans mon application. Chaque fois que l'utilisateur interagit avec l'écran, il sera réinitialisé (supprimer l'ancien délai, en créer un nouveau).

Une alternative sur la manière de procéder de la bonne manière? Est-il préférable de gérer cela avec du code natif et de transmettre quelque chose à React une fois terminé?

wow, donc c'est toujours un problème

@nbennink vérifiez la réponse ici . Actuellement, il n'y a aucune garantie pour exécuter la tâche en arrière-plan car il y a plusieurs facteurs en jeu (économiseur de batterie, interaction de l'utilisateur, etc.)

J'obtiens également le même avertissement après avoir utilisé socket.io.
L'avertissement est ci-dessous:

Setting a timer for a long period of time, i.e. multiple minutes, is a performance and correctness issue on Android as it keeps the timer module awake, and timers can only be called when the app is in the foreground. See https://github.com/facebook/react-native/issues/12981 for more info.
(Saw setTimeout with duration 85000ms)

Les détails de mon forfait sont ci-dessous:

• "réagir": "^ 16.3.0-alpha.1",
• "natif réactif": "0,54,4",
• "socket.io": "^ 2.1.1",
• "socket.io-client": "^ 2.1.1",

Une solution permanente à découvrir?

J'obtiens également le même avertissement après avoir utilisé socket.io.
L'avertissement est ci-dessous:

Setting a timer for a long period of time, i.e. multiple minutes, is a performance and correctness issue on Android as it keeps the timer module awake, and timers can only be called when the app is in the foreground. See https://github.com/facebook/react-native/issues/12981 for more info.
(Saw setTimeout with duration 85000ms)

Les détails de mon forfait sont ci-dessous:

"réagir": "^ 16.3.0-alpha.1",
"natif réactif": "0,54,4",
"socket.io": "^ 2.1.1",
"socket.io-client": "^ 2.1.1",

Une solution permanente à découvrir?

Idem, il n'y a aucun moyen de contourner cela?

Vous recevez toujours cet avertissement sur react-native 0.57, ce problème est-il censé être ouvert à la place?

Presque un an et React Native ont toujours le même problème !!!

Face au même problème, le même avertissement apparaît 3 à 4 fois. Très ennuyant.

Existe-t-il une solution pour résoudre ce problème?

Débarrassez-vous du message d'avertissement par cette solution https://stackoverflow.com/a/48778011/7427111

Il s'agit essentiellement de cacher le message et non de résoudre le problème, je suppose.

@dhavaljardosh Oui, vous avez raison.

J'ai créé un minuteur natif avec Java et Objective C. Cela fonctionne pour moi et il cache le message. Je ne sais pas si cela améliore réellement les performances. Comme mentionné ci-dessus: il est toujours mauvais pour la batterie, etc. car il y a une longue minuterie en arrière-plan.

Une question à se poser est de savoir si vous avez vraiment besoin d'une fonction de sondage. Je pensais l'avoir fait, mais à cause de ce problème, je me suis rendu compte que je n'avais besoin d'exécuter que sur une période semi-fréquente. Alors maintenant, je l'exécute sur l'arrière-plan de l'application et évite totalement ce problème. YMMV.

même problème lors de l'utilisation de Pusher ...

Je vais tester mon application pour voir quel est l'impact sur les performances lors du réglage d'une minuterie toutes les 60 secondes.
Je suppose cependant que certains d'entre vous en ont l'expérience. Pouvez-vous partager cette expérience, s'il vous plaît? L'impact est-il significatif?

toujours le même problème avec la dernière version.
Toute solution?

Je suis également confronté à ce problème.
L'application fonctionnait bien, ce n'est que lorsque j'ai commencé à utiliser Firebase que l'avertissement est venu.
Toute solution?

Je veux comprendre la signification de ce message car nous avons commencé à l'obtenir après une fonctionnalité récente que nous avons ajoutée à notre produit. Le problème est-il uniquement lié au fait que le minuteur continue de fonctionner pendant que l'application est en arrière-plan? Serait-ce une solution appropriée pour s'abonner aux événements d'état de l'application et arrêter le minuteur si l'application est en arrière-plan? Ou est-ce qu'un minuteur de longue durée avec l'application dans le _foreground_ est également problématique?

Je veux comprendre la signification de ce message car nous avons commencé à l'obtenir après une fonctionnalité récente que nous avons ajoutée à notre produit. Le problème est-il uniquement lié au fait que le minuteur continue de fonctionner pendant que l'application est en arrière-plan? Serait-ce une solution appropriée pour s'abonner aux événements d'état de l'application et arrêter le minuteur si l'application est en arrière-plan? Ou est-ce qu'un minuteur de longue durée avec l'application dans le _foreground_ est également problématique?

J'aimerais aussi savoir cela.

De plus, que se passe-t-il avec setInterval? Je ne reçois pas d'avertissement de celui-ci, mais a-t-il le même problème?

Je veux comprendre la signification de ce message car nous avons commencé à l'obtenir après une fonctionnalité récente que nous avons ajoutée à notre produit. Le problème est-il uniquement lié au fait que le minuteur continue de fonctionner pendant que l'application est en arrière-plan? Serait-ce une solution appropriée pour s'abonner aux événements d'état de l'application et arrêter le minuteur si l'application est en arrière-plan? Ou est-ce qu'un minuteur de longue durée avec l'application dans le _foreground_ est également problématique?

Le message jaune indique "... et les minuteries ne peuvent être appelées que lorsque l'application est au premier plan."
Le module de minuterie reste éveillé mais les minuteries ne peuvent pas fonctionner lorsque l'application est en arrière-plan? Le problème est donc de maintenir le module de minuterie éveillé lorsqu'une application est en arrière-plan? Combien d'effet performance / batterie cela aurait-il je me demande ...

@BerndWessels https://www.npmjs.com/package/react-native-firebase Avez-vous regardé cela? Dit qu'il permet à Firebase de fonctionner sur le thread natif. Je ne sais pas à quel point c'est vrai, mais cela vaut peut-être le coup d'œil. Vous l'utilisez peut-être même, je ne suis pas sûr.

Pensez-vous que si je passe à cette bibliothèque, je devrai changer mon code existant? Je veux dire, ce ne serait pas très gentil ...

même problème avec Pusher sur la dernière RN0.59, et l'interface utilisateur peut rester bloquée quelques secondes ...

Il semble que je ne rencontre ce problème que lorsque je passe un appel à la base de données en temps réel de Firebase.

await firebase.database().ref('users/' + id).set(data);

RN 0,57,1

Je n'ai pas confirmé avec 0,59.

@swushi J'obtiens le même problème avec RN 0.59

Je reçois l'avertissement suivant lors de l'utilisation de la bibliothèque Firebase

Setting a timer for a long period of time, i.e. multiple minutes, is a performance and correctness issue on Android as it keeps the timer module awake, and timers can only be called when the app is in the foreground. See https://github.com/facebook/react-native/issues/12981 for more info. (Saw setTimeout with duration 111862ms)

Comment se débarrasser de cet avertissement ...

Quelqu'un sait-il comment se débarrasser de cet avertissement sans le cacher?
J'utilise la bibliothèque firebase non la react-native-firebase, mais semble avoir le même problème et je ne sais pas comment cela va m'affecter quand il sera en production.

Je suis vraiment inquiet alors si quelqu'un pouvait m'aider s'il vous plait ...

J'utilise le code suivant pour contourner ce problème (pour le moment):

voir https://github.com/firebase/firebase-js-sdk/issues/97#issuecomment -427512040

fixtimerbug.js

/////////////////////////////////////////////////////////////////////////////
////// temporary fix to bug about 'Setting a timer' /////////////////////////
////// See: https://github.com/pusher/pusher-js/issues/248 //////////////////
////// See: https://github.com/facebook/react-native/issues/12981 ///////////
////// See: https://github.com/firebase/firebase-js-sdk/issues/97 ///////////
/////////////////////////////////////////////////////////////////////////////
import { Platform, InteractionManager } from 'react-native';
const _setTimeout = global.setTimeout;
const _clearTimeout = global.clearTimeout;
const MAX_TIMER_DURATION_MS = 60 * 1000;
if (Platform.OS === 'android') {
  const timerFix = {};
  const runTask = (id, fn, ttl, args) => {
    const waitingTime = ttl - Date.now();
    if (waitingTime <= 1) {
      InteractionManager.runAfterInteractions(() => {
        if (!timerFix[id]) {
          return;
        }
        delete timerFix[id];
        fn(...args);
      });
      return;
    }
    const afterTime = Math.min(waitingTime, MAX_TIMER_DURATION_MS);
    timerFix[id] = _setTimeout(() => runTask(id, fn, ttl, args), afterTime);
  };
  global.setTimeout = (fn, time, ...args) => {
    if (MAX_TIMER_DURATION_MS < time) {
      const ttl = Date.now() + time;
      const id = '_lt_' + Object.keys(timerFix).length;
      runTask(id, fn, ttl, args);
      return id;
    }
    return _setTimeout(fn, time, ...args);
  };
  global.clearTimeout = id => {
    if (typeof id === 'string' && id.startsWith('_lt_')) {
      _clearTimeout(timerFix[id]);
      delete timerFix[id];
      return;
    }
    _clearTimeout(id);
  };
}
/////////////////////////////////////////////////////////////////////////////

@cpmech
Vous implémentez cela dans un fichier .js indépendant, ou vous le faites dans le script qui crée l'exception du minuteur

Salut, oui, le code ci-dessus va dans un fichier nommé «fixtimerbug.js». Ensuite, je le charge dans mon App.js comme ceci:

import './src/fixtimerbug'; // <<<<<<<<<<<<<<<<<<

import React from 'react';
import { Platform, View, StatusBar } from 'react-native';
import AppNavigator from './src/navigation/AppNavigator';
import Store from './src/model/Store';

const store = new Store();

const App = () => (
  <View style={{ flex: 1, backgroundColor: '#fff' }}>
    {Platform.OS === 'ios' && <StatusBar barStyle="default" />}
    <AppNavigator screenProps={{ store }} />
  </View>
);

export default App;

Il semble que cela fonctionne bien, que fait-il exactement?

Merci beaucoup @cpmech

Bonjour, le code (à partir d'ici: https://github.com/firebase/firebase-js-sdk/issues/97#issuecomment-427512040) enveloppe simplement la fonction setTimeout (global) pour l'empêcher d'être utilisé avec une longue période.

Dans notre fonction global.setTimeout modifiée, si la durée est supérieure au seuil MAX_TIMER_DURATION_MS , nous sauvegardons un id dans une carte locale ( timerFix ) puis appelez runTask qui divise la durée en plus petites valeurs. runTask définit un timeout (en utilisant le _setTimeout ) avec les petits morceaux qui seront exécutés en continu jusqu'à ce que waitingTime soit trop petit. Lorsque waitingTime est assez petit, nous appelons runAfterInteractions de React Native pour une exécution fluide et, en même temps, nous supprimons l'entrée id de notre carte locale parce que nous avons gagné n'appelle plus _setTimeout dans ce cas. Notez que afterTime est introduit dans _setTimeout pour éviter qu'il ne soit appelé avec une longue période.

Sinon, dans notre fonction global.setTimeout modifiée, si la durée est inférieure au seuil MAX_TIMER_DURATION_MS , nous appelons directement le setTimeout global (enregistré dans _setTimeout ).

Le global clearTimeout est également encapsulé pour effectuer un processus de nettoyage en supprimant le id de la carte locale.

J'espère que cela aide!

Face au même problème .. Il semble que nous devions cacher l'avertissement pour le moment. Voici le moyen le plus court de le faire:
componentDidMount() { console.disableYellowBox = true; ... }

Bonjour, le code (à partir d'ici: firebase / firebase-js-sdk # 97 (commentaire) ) setTimeout (globale) pour l'empêcher d'être utilisée avec une longue période.

Dans notre fonction global.setTimeout modifiée, si la durée est supérieure au seuil MAX_TIMER_DURATION_MS , nous sauvegardons un id dans une carte locale ( timerFix ) puis appelez runTask qui divise la durée en plus petites valeurs. runTask définit un timeout (en utilisant le _setTimeout ) avec les petits morceaux qui seront exécutés en continu jusqu'à ce que waitingTime soit trop petit. Lorsque waitingTime est assez petit, nous appelons runAfterInteractions de React Native pour une exécution fluide et, en même temps, nous supprimons l'entrée id de notre carte locale parce que nous avons gagné n'appelle plus _setTimeout dans ce cas. Notez que afterTime est introduit dans _setTimeout pour éviter qu'il ne soit appelé avec une longue période.

Sinon, dans notre fonction global.setTimeout modifiée, si la durée est inférieure au seuil MAX_TIMER_DURATION_MS , nous appelons directement le setTimeout global (enregistré dans _setTimeout ).

Le global clearTimeout est également encapsulé pour effectuer un processus de nettoyage en supprimant le id de la carte locale.

J'espère que cela aide!

Merci beaucoup! A fonctionné comme un charme.

Bonjour, le code (à partir d'ici: firebase / firebase-js-sdk # 97 (commentaire) ) setTimeout (globale) pour l'empêcher d'être utilisée avec une longue période.

Dans notre fonction global.setTimeout modifiée, si la durée est supérieure au seuil MAX_TIMER_DURATION_MS , nous sauvegardons un id dans une carte locale ( timerFix ) puis appelez runTask qui divise la durée en plus petites valeurs. runTask définit un timeout (en utilisant le _setTimeout ) avec les petits morceaux qui seront exécutés en continu jusqu'à ce que waitingTime soit trop petit. Lorsque waitingTime est assez petit, nous appelons runAfterInteractions de React Native pour une exécution fluide et, en même temps, nous supprimons l'entrée id de notre carte locale parce que nous avons gagné n'appelle plus _setTimeout dans ce cas. Notez que afterTime est introduit dans _setTimeout pour éviter qu'il ne soit appelé avec une longue période.

Sinon, dans notre fonction global.setTimeout modifiée, si la durée est inférieure au seuil MAX_TIMER_DURATION_MS , nous appelons directement le setTimeout global (enregistré dans _setTimeout ).

Le global clearTimeout est également encapsulé pour effectuer un processus de nettoyage en supprimant le id de la carte locale.

J'espère que cela aide!

Cela règle-t-il réellement le problème ou supprime-t-il simplement l'avertissement?

Bonjour, le code (à partir d'ici: firebase / firebase-js-sdk # 97 (commentaire) ) setTimeout (globale) pour l'empêcher d'être utilisée avec une longue période.

Dans notre fonction global.setTimeout modifiée, si la durée est supérieure au seuil MAX_TIMER_DURATION_MS , nous sauvegardons un id dans une carte locale ( timerFix ) puis appelez runTask qui divise la durée en plus petites valeurs. runTask définit un timeout (en utilisant le _setTimeout ) avec les petits morceaux qui seront exécutés en continu jusqu'à ce que waitingTime soit trop petit. Lorsque waitingTime est assez petit, nous appelons runAfterInteractions de React Native pour une exécution fluide et, en même temps, nous supprimons l'entrée id de notre carte locale parce que nous avons gagné n'appelle plus _setTimeout dans ce cas. Notez que afterTime est introduit dans _setTimeout pour éviter qu'il ne soit appelé avec une longue période.

Sinon, dans notre fonction global.setTimeout modifiée, si la durée est inférieure au seuil MAX_TIMER_DURATION_MS , nous appelons directement le setTimeout global (enregistré dans _setTimeout ).

Le global clearTimeout est également encapsulé pour effectuer un processus de nettoyage en supprimant le id de la carte locale.

J'espère que cela aide!

Merci beaucoup! Cela n'affectera pas les performances globales de l'application, n'est-ce pas?

Bonjour, le code (à partir d'ici: firebase / firebase-js-sdk # 97 (commentaire) ) setTimeout (globale) pour l'empêcher d'être utilisée avec une longue période.
Dans notre fonction global.setTimeout modifiée, si la durée est supérieure au seuil MAX_TIMER_DURATION_MS , nous sauvegardons un id dans une carte locale ( timerFix ) puis appelez runTask qui divise la durée en plus petites valeurs. runTask définit un timeout (en utilisant le _setTimeout ) avec les petits morceaux qui seront exécutés en continu jusqu'à ce que waitingTime soit trop petit. Lorsque waitingTime est assez petit, nous appelons runAfterInteractions de React Native pour une exécution fluide et, en même temps, nous supprimons l'entrée id de notre carte locale parce que nous avons gagné n'appelle plus _setTimeout dans ce cas. Notez que afterTime est introduit dans _setTimeout pour éviter qu'il ne soit appelé avec une longue période.
Sinon, dans notre fonction global.setTimeout modifiée, si la durée est inférieure au seuil MAX_TIMER_DURATION_MS , nous appelons directement le setTimeout global (enregistré dans _setTimeout ).
Le global clearTimeout est également encapsulé pour effectuer un processus de nettoyage en supprimant le id de la carte locale.
J'espère que cela aide!

Cela règle-t-il réellement le problème ou supprime-t-il simplement l'avertissement?

Non, cela ne résout pas le problème. C'est juste un bon travail.

Bonjour, le code (à partir d'ici: firebase / firebase-js-sdk # 97 (commentaire) ) setTimeout (globale) pour l'empêcher d'être utilisée avec une longue période.
Dans notre fonction global.setTimeout modifiée, si la durée est supérieure au seuil MAX_TIMER_DURATION_MS , nous sauvegardons un id dans une carte locale ( timerFix ) puis appelez runTask qui divise la durée en plus petites valeurs. runTask définit un timeout (en utilisant le _setTimeout ) avec les petits morceaux qui seront exécutés en continu jusqu'à ce que waitingTime soit trop petit. Lorsque waitingTime est assez petit, nous appelons runAfterInteractions de React Native pour une exécution fluide et, en même temps, nous supprimons l'entrée id de notre carte locale parce que nous avons gagné n'appelle plus _setTimeout dans ce cas. Notez que afterTime est introduit dans _setTimeout pour éviter qu'il ne soit appelé avec une longue période.
Sinon, dans notre fonction global.setTimeout modifiée, si la durée est inférieure au seuil MAX_TIMER_DURATION_MS , nous appelons directement le setTimeout global (enregistré dans _setTimeout ).
Le global clearTimeout est également encapsulé pour effectuer un processus de nettoyage en supprimant le id de la carte locale.
J'espère que cela aide!

Merci beaucoup! Cela n'affectera pas les performances globales de l'application, n'est-ce pas?

Non, cela n'affecte pas du tout les performances.

Un petit mot sur

Si cela vous dérange, ajoutez simplement console.ignoredYellowBox = ['Setting a timer'];

et

Face au même problème .. Il semble que nous devions cacher l'avertissement pour le moment. Voici le moyen le plus court de le faire:
componentDidMount () {console.disableYellowBox = true; ...}

Ce n'est pas une solution viable. Les erreurs se produisent toujours, vous ne recevez tout simplement pas de notification.

Résultat? L'analyse des erreurs doit encore se produire.

Dans le cas de l'utilisation d'écouteurs Firebase, par exemple, vous masquerez un grand nombre d'erreurs, mais votre environnement de développement les traitera toujours.

Exemple concret: mon projet basé sur l'expo n'arrêtait pas de planter car il essayait de cartographier chaque erreur de minuterie.

Je ferme cela car je ne pense pas que React Native ajoutera la prise en charge d'AlarmManager dans le noyau. Cela peut être fait avec des modules tiers ou du code natif personnalisé.

La solution de @cpmech fonctionne encore? Je l'ai essayé sur RN60.4, mais je reçois encore un avertissement de longue durée.

Salut, je pense avoir trouvé la solution:
Tout d'abord, vous devez trouver le fichier suivant dans votre projet: bibliothèques / Core / Timers / JSTimer; js
Ouvrez-le et il vous suffira de modifier cette const MAX_TIMER_DURATION_MS, pour l'augmenter au dessus de votre durée, écrit en fin d'avertissement!

augmenter la minuterie, mais de combien?

@dulmandakh y a-t-il des projets open source qui résolvent ce problème que vous connaissez?

@dulmandakh y a-t-il des projets open source qui résolvent ce problème que vous connaissez?

RNFirebase peut-être? @dulmandakh

Vous pouvez replanifier le minuteur avec une durée fixe jusqu'à ce qu'il expire:

const setLogoutTimer = expirationTime => {

  return dispatch => {
    timer = setTimeout(() => {
        if (expirationTime>60000)
        {
            console.log(`set new exp:${expirationTime-60000}`);
            dispatch(setLogoutTimer(expirationTime-60000));
        }
        else
        {
            console.log('logout');
            dispatch(logout());
        }
    }, 60000); 
  };
};

Cela fait 2 ans que React-Native ou Firebase résoudra correctement ce problème. :(

ok après quelques heures de longue enquête, tout ce que je veux savoir, c'est si j'ai causé le problème d'une manière ou d'une autre.
Je ne sais pas quand il est apparu.
apparaît-il dès que j'appelle Firestore?
Je n'utilise aucun minuteur dans mon application

@luismasg Je n'utilise pas setTimeout dans mon code car c'est une mauvaise pratique mais je connais la source de l'erreur et je ne peux pas l'arrêter et il semble que cela provienne de l'établissement d'une connexion à distance avec ma base de données apparemment la bibliothèque que j'utilise ensembles le Time out pour garder le TTL en vie, vérifiez votre bibliothèque de dépendances et voyez si vous pouvez identifier celui qui cause le problème

Honnêtement, je ne pense pas que l'utilisation des minuteries / intervalles JS soit de toute façon une bonne idée pour les minuteurs longs, l'avertissement est là pour une raison.

Utilisez plutôt les événements du cycle de vie pour ajouter / supprimer des minuteries courtes. Si vous avez besoin d'une exécution en arrière-plan réelle, utilisez du code natif avec des services de premier plan (Android) et des tâches en arrière-plan (iOS).

Honnêtement, je ne pense pas que l'utilisation des minuteries / intervalles JS soit de toute façon une bonne idée pour les minuteurs longs, l'avertissement est là pour une raison.

Comme mentionné en détail ci-dessus, de nombreuses personnes ont du mal avec les bibliothèques qui utilisent des minuteries plus longues. "N'utilisez pas Firebase" n'est pas une solution.

De toute évidence, c'est un problème souvent rencontré, le gérer améliorerait l'expérience des développeurs de react-native ce qui semble être l'objectif ultime ...

Je ne dirais pas que "ne pas utiliser firebase" est la réponse, plutôt "réparer Firebase pour ne pas utiliser de longs temporisateurs et utiliser les blocs de construction natifs appropriés pour la tâche w / e pour laquelle ils utilisent des temporisations longues".

Mais vous avez raison, il serait idéal pour RN de prendre en charge les longs délais, mais compte tenu de toutes les mises en garde qu'il y a (comme une consommation de batterie plus élevée, un temps d'exécution inutile en arrière-plan, etc.), cela ne fera que pousser les développeurs à se tirer dessus. Si quoi que ce soit, il doit s'agir d'une primitive de temporisation / d'intervalle distincte.

Si quoi que ce soit, il doit s'agir d'une primitive de temporisation / d'intervalle distincte.

Ma compréhension de ce qu'est ce problème est l'absence d'un tel primitif 😄

utilisez la minuterie à l'intérieur de la minuterie, c'est tout!

@dulmandakh pourquoi ce problème est-il clos? Le problème persiste et la discussion est en cours?

J'ai ajouté ceci à App.js, et cela l'a corrigé (temporaire jusqu'à ce qu'il y ait un correctif officiel)

const _setTimeout = global.setTimeout;
const _clearTimeout = global.clearTimeout;
const MAX_TIMER_DURATION_MS = 60 * 1000;
if (Platform.OS === "android") {
  // Work around issue `Setting a timer for long time`
  // see: https://github.com/firebase/firebase-js-sdk/issues/97
  const timerFix = {};
  const runTask = (id, fn, ttl, args) => {
    const waitingTime = ttl - Date.now();
    if (waitingTime <= 1) {
      InteractionManager.runAfterInteractions(() => {
        if (!timerFix[id]) {
          return;
        }
        delete timerFix[id];
        fn(...args);
      });
      return;
    }

    const afterTime = Math.min(waitingTime, MAX_TIMER_DURATION_MS);
    timerFix[id] = _setTimeout(() => runTask(id, fn, ttl, args), afterTime);
  };

  global.setTimeout = (fn, time, ...args) => {
    if (MAX_TIMER_DURATION_MS < time) {
      const ttl = Date.now() + time;
      const id = "_lt_" + Object.keys(timerFix).length;
      runTask(id, fn, ttl, args);
      return id;
    }
    return _setTimeout(fn, time, ...args);
  };

  global.clearTimeout = id => {
    if (typeof id === "string" && id.startWith("_lt_")) {
      _clearTimeout(timerFix[id]);
      delete timerFix[id];
      return;
    }
    _clearTimeout(id);
  };
}

Il s'agit d'une solution de contournement, pas d'un correctif.

J'ai ajouté ceci à App.js, et cela l'a corrigé (temporaire jusqu'à ce qu'il y ait un correctif officiel)

...
    if (typeof id === "string" && id.startWith("_lt_")) {
...

«startWith» devrait être «startsWith» si vous comptez utiliser ce code.

J'éprouve cela avec AWS Amplify Datastore. Au lieu d'une solution appropriée, je désactive l'avertissement avec

import { YellowBox } from 'react-native';
YellowBox.ignoreWarnings(['Setting a timer']);

Je ne sais pas si le problème sous-jacent est quelque chose que RN doit résoudre, Amplify doit corriger ou si je dois corriger. Evidemment, je ne veux pas de problèmes de performances.

Si cela vous dérange, ajoutez simplement console.ignoredYellowBox = ['Setting a timer'];

Où dois-je ajouter ceci que j'ai essayé dans le fichier d'écran et le fichier d'action, ne fonctionnant toujours pas

Placez-le simplement quelque part dans votre fichier App.js. Je l'ai mis dans mon constructeur par exemple.
Je ne sais pas si c'est le meilleur endroit, alors si quelqu'un sait quelque chose de mieux, j'aimerais l'entendre!

Je pense que quiconque utilise Firebase peut résoudre ce problème en configurant la persistance de l'application après (signIn / signUp)

* après avoir créé un nouvel utilisateur, il se connectera automatiquement

https://firebase.google.com/docs/auth/web/auth-state-persistence

donc ... après avoir authentifié un utilisateur, une variable de temps est créée.

la valeur par défaut pour Firebase est un local . "firebase.auth.Auth.Persistence.LOCAL"

vous pouvez changer en utilisant:
firebase.auth.Auth.Persistence.SESSION
firebase.auth.Auth.Persistence.NONE

ou en utilisant un localStorage ...

Jusqu'à ce qu'ils le résolvent de manière définitive ...

importer {YellowBox} depuis "react-native";
importer _ de "lodash";
YellowBox.ignoreWarnings (["Réglage d'une minuterie"]);
const _console = _.clone (console);
console.warn = (message) => {
if (message.indexOf ("Réglage d'un minuteur") <= -1) {
_console.warn (message);
}
};

Une fois résolu, le code indésirable est supprimé et le tour est joué!

Cela peut être résolu avec RxJS.

Divise essentiellement votre minuteur 5200 minuteurs 5 * 1000 + 200 .

import { of, range } from 'rxjs';
import {
  concatMap,
  delay,
  filter,
  mapTo,
  switchMap,
  tap,
} from 'rxjs/operators';

// ~ setTimeout(..., 5200);

const source = of(5200).pipe(
  switchMap(duration => {
    const times = Math.floor(duration / 1000); // = 5
    const remainder = duration % 1000; // = 200

    return range(1, times).pipe(
      concatMap(i => of(i).pipe(delay(1000))),
      tap(console.log),
      filter(i => i === times),
      delay(remainder),
      tap(console.log),
      mapTo('Done !'),
    );
  }),
);

source.subscribe(console.log);

1 // After 1s
2 // After 2s
3 // After 3s
4 // After 4s
5 // After 5s
5 // After 5s + 200 ms
'Done !'

Je pense que quiconque utilise Firebase peut résoudre ce problème en configurant la persistance de l'application après (signIn / signUp)

* après avoir créé un nouvel utilisateur, il se connectera automatiquement

https://firebase.google.com/docs/auth/web/auth-state-persistence

donc ... après avoir authentifié un utilisateur, une variable de temps est créée.

la valeur par défaut pour Firebase est un local . "firebase.auth.Auth.Persistence.LOCAL"

vous pouvez changer en utilisant:
firebase.auth.Auth.Persistence.SESSION
firebase.auth.Auth.Persistence.NONE

ou en utilisant un localStorage ...

Génial! Et pour Firestore?

Je pense que quiconque utilise Firebase peut résoudre ce problème en configurant la persistance de l'application après (signIn / signUp)
* après avoir créé un nouvel utilisateur, il se connectera automatiquement
https://firebase.google.com/docs/auth/web/auth-state-persistence
donc ... après avoir authentifié un utilisateur, une variable de temps est créée.
la valeur par défaut pour Firebase est un local . "firebase.auth.Auth.Persistence.LOCAL"
vous pouvez changer en utilisant:
firebase.auth.Auth.Persistence.SESSION
firebase.auth.Auth.Persistence.NONE
ou en utilisant un localStorage ...

Génial! Et pour Firestore?

si vous utilisez l'ancien SDK Firebase, migrez vers le SDK d'administration Firestore.

la plupart des problèmes seront résolus

https://firebase.google.com/docs/reference/admin

Personne n'est encore capable de résoudre ce problème. # honte à vous les développeurs; p

Personne n'est encore capable de résoudre ce problème. # honte à vous les développeurs; p

Ne faites jamais honte aux contributeurs open source. C'est dommage que cela n'ait pas été corrigé mais la source est ouverte, si vous savez comment le résoudre, je suis sûr qu'ils apprécieraient une pull-request.

Cela dit pourquoi diable ce problème est-il clos .

Parce qu'il devrait être corrigé dans les bibliothèques incriminées. Et les bibliothèques fautives ne voient pas de problème avec la façon dont il a été mis en œuvre.

Personne ne le réparera parce que les deux côtés ne pensent pas qu'il est cassé.

Ils peuvent être humiliés un peu pour cela 😄

Les gars, je pense que cela n'a pas été "résolu" pour la simple raison que c'est une très mauvaise idée d'utiliser des minuteurs longs.

Si vous souhaitez exécuter des minuteries en arrière-plan / événements à l'avenir, vous aurez besoin d'une bibliothèque native pour le faire. Ceci est également particulièrement difficile sur les deux plates-formes en raison des contraintes d'exécution en arrière-plan.

Sur la base du commentaire de delay , timeout & interval .

Encore une question demeure, quelqu'un peut-il expliquer si le "module Timer" reste verrouillé lors de l'utilisation d'intervalles plus petits? Fondamentalement, il suffit de provoquer l'arrêt du minuteur lorsque l'application n'est pas au premier plan. Ou est-ce que cela cache simplement le problème?

import { switchMap, concatMap, delay as nativeDelay, mapTo, filter, switchMapTo, repeat } from 'rxjs/operators'
import { range, of, race, throwError, TimeoutError } from 'rxjs'

const TIMER_INTERVAL = 1000
const reactNativeTimer = (duration) => {
  const times = Math.floor(duration / TIMER_INTERVAL)
  const remainder = duration % TIMER_INTERVAL
  if (times < 1) {
    return of(true).pipe(nativeDelay(remainder))
  }
  return range(1, times).pipe(
    concatMap(i => of(i).pipe(nativeDelay(TIMER_INTERVAL))),
    filter(i => i === times),
    nativeDelay(remainder)
  )
}

/**
 * React Native compatible version of delay pipe
 * <strong i="11">@param</strong> {number} duration in ms
 */
export const delay = (duration) => {
  return (source) => {
    return source.pipe(
      switchMap(next =>
        reactNativeTimer(duration).pipe(mapTo(next))
      )
    )
  }
}

/**
 * React Native compatible version of timeout pipe
 * <strong i="12">@param</strong> {number} duration in ms
 */
export const timeout = (duration) => {
  return (source) => {
    const timeoutTimer = reactNativeTimer(duration).pipe(
      switchMapTo(throwError(new TimeoutError()))
    )
    return race(source, timeoutTimer)
  }
}

/**
 * React Native compatible version of interval
 * <strong i="13">@param</strong> {number} duration in ms
 */
export const interval = (duration) => {
  return reactNativeTimer(duration).pipe(
    repeat()
  )
}

La chose amusante à ce sujet, que tout le monde dans ce fil discutant d'une solution de contournement pour ignorer cet avertissement.
Lorsque j'ai été redirigé vers ce "problème" à partir d'avertissement, j'ai espéré trouver la documentation appropriée, expliquant "comment?" pour le gérer et un peu plus de raisonnement sur "pourquoi?".

front-end #millennials

Ce #millenial tient à souligner que:

• Cette erreur ne nécessite pas de documentation, elle est explicite: vous définissez une longue minuterie.
• Ce fil est plein de personnes qui désactivent l'avertissement pour les bibliothèques dont elles ne sont pas propriétaires (par exemple, Firebase)
• Comme l'indique la discussion (productive) de ce fil de discussion, il s'agit d'un problème plus complexe à résoudre dans react-native

Cela dit, je soulignerai à nouveau que ce problème ne doit pas être fermé, il est marqué known-issue et Help Wanted .

Réponses Millenial à Millenial :)

Cette erreur ne nécessite pas de documentation, elle est explicite: vous définissez une longue minuterie.

• Ce n'est pas une erreur, c'est un avertissement (ne me demandez pas la différence, sinon nous devons entamer une conversation philosophique profonde :))
• Il fait déjà semblant d'être documenté en raison de la référence fournie à ce ticket, où j'ai besoin de lire des tonnes de commentaires au lieu d'un résumé exécutif (comme un problème connu comme vous l'avez déjà suggéré):
  
• Je ne dirais pas que c'est «explicite». Pas assez de contexte fourni. Littéralement, il y a deux phrases dans une description.

Cela dit, je soulignerai à nouveau que ce problème ne doit pas être fermé, il est marqué comme problème connu et aide recherchée.

Entièrement d'accord. Cela fera gagner du temps à de nombreuses personnes provenant de la référence URL dans l'avertissement.

Pour les utilisateurs de firebase / firestore: je suis simplement revenu à l'utilisation des points de terminaison REST directement pour les appels firestore. Comme je n'avais besoin que d'authentification et de firestore, cela a résolu mes problèmes assez facilement. Extrait ici:

https://stackoverflow.com/a/62446792

Je l'ai fait dans App () comme suit:

import {YellowBox} de 'react-native';
Exporter la fonction par défaut App () {
YellowBox.ignoreWarnings (['Réglage d'une minuterie']);
...
...
..
}

Souvenez-vous

Ce que j'ai fait et ça travaille avec moi mais je ne sais toujours pas si c'est une bonne pratique ou pas

Navigué vers le fichier

node_modulesreact-native \ Libraries \ Core \ TimersJSTimers.js

il y a une fonction const MAX_TIMER_DURATION_MS = 60 * 1000 et j'ai augmenté le temps à 60 * 100000 et il a cessé d'apparaître

Héy,
Ce problème date d'environ 3 ans et nous avons toujours cet avertissement;)
comme @RWOverdijk l'a dit, ignorer l'avertissement n'est pas une solution.
Y a-t-il déjà une solution que j'ai manquée?

Merci <3

Salut à tous, nous décidons de verrouiller ce problème. Je sais que ce problème est frustrant pour beaucoup d'entre vous et je veux prendre le temps de comprendre pourquoi nous prenons cette décision.

Fonctionnement des minuteries sur Android dans React Native

React Native a une implémentation personnalisée des minuteries JS comme setTimeout . Sur Android, la façon dont cela fonctionne est que les minuteries JS sont suivies du côté natif, et le côté natif décide quand déclencher ces minuteries. Cela permet à React Native d'être plus intelligent sur le moment où les minuteries sont déclenchées, et en particulier sur leur relation avec le cycle de vie et le rendu de l'application.

Que se passe-t-il si je règle une minuterie avec un long intervalle?

Voici ma compréhension, en lisant le code et en le testant un peu:

1. Si vous définissez une longue minuterie et que l'application reste ouverte pendant que la minuterie est active, la minuterie devrait toujours fonctionner.
2. Si vous définissez une longue minuterie et que le téléphone est en arrière-plan avant la fin de la minuterie, la minuterie ne sera pas activée avant la prochaine ouverture de l'application.
3. Il existe une exception pour les tâches JS sans tête, qui peuvent faire fonctionner les minuteries même si l'application est en arrière-plan.

Pourquoi ne pas appeler des minuteries avec de longs intervalles?

Je pense que c'est avant tout un problème de correction et moins de performances. Le problème est que vous ne pouvez pas compter sur de longs délais si l'utilisateur crée l'arrière-plan de votre application.

Si cela ne vous dérange pas que votre minuterie soit activée plus tard lorsque l'application est à nouveau au premier plan, je pense que ignorer l'avertissement YellowBox est une bonne idée.

D'autre part, si votre minuterie s'attend à être appelée pendant la durée de vie d'une session et ne doit pas être déclenchée à nouveau au premier plan, vous devrez faire quelque chose pour vous assurer que la minuterie est ignorée au premier plan.

Comment utiliser des bibliothèques tierces comme Socket.io et Firebase qui définissent des minuteries longues?

Je ne connais pas les détails de ces bibliothèques tierces. Cela revient finalement à la question ci-dessus. Si ces bibliothèques tierces rencontrent des problèmes de résolution des minuteries au premier plan, vous devrez trouver un moyen de résoudre ce problème. Certains commentaires ci-dessus proposent des moyens de le faire pour Firebase, par exemple. En fin de compte, cependant, vous serez peut-être mieux servi en vous appuyant sur une bibliothèque développée spécifiquement avec React Native à l'esprit.

D'un autre côté, si la bibliothèque tierce n'a aucun problème avec les minuteries résolues au premier plan, vous pouvez ignorer l'erreur.

Pourquoi setTimeout ne peut-il pas passer par AlarmManager , comme suggéré initialement?

AlarmManager réveillera l'application si elle est en arrière-plan, et nous ne pensons pas que des minuteries comme setTimeout devraient réveiller l'application. La plupart de ces longs délais sont définis pour des choses comme les délais d'expiration, et ceux-ci ne sont pertinents que lorsque l'application est ouverte. Réveiller une application en arrière-plan est coûteux et ne doit être fait que si le développeur a explicitement cette intention.

En même temps, de nombreuses personnes ont probablement besoin de quelque chose comme ça. Nous pourrions développer une API pour cela qui ne passe pas par setTimeout . Mais en raison de l'effort Lean Core en ce moment, nous essayons en fait d'éviter d'augmenter la surface d'API pour React Native. Nous pensons que c'est une tâche mieux gérée par une bibliothèque tierce comme react-native-background-timer .

Pourquoi ne supprimez-vous pas entièrement l'avertissement alors?

Nous voulons que les développeurs soient conscients de ce qui se passe. Si quelqu'un installe une bibliothèque qui repose sur l'exactitude de setTimeout , nous pensons que le développeur doit être conscient que nous ne pouvons pas garantir cette exactitude. Nous voulons laisser aux développeurs individuels le soin de décider si cet avertissement est important dans leur cas d'utilisation particulier.