Вы должны вызвать flush()
в своей деятельности onDestroy()
Как это:
@Override
protected void onDestroy() {
mMixpanel.flush();
super.onDestroy();
}
Обратите внимание, что вы вызываете flush() до вызова super.onDestroy();
, в противном случае жизненный цикл активности будет продолжаться, и ваш вызов никогда не будет своевременным, поэтому процесс уничтожения начнется, по крайней мере, после сброса.
Меня устраивает.
Это немного неуклюже (MixPanel должен был бы работать лучше), потому что вы можете не знать, из какой активности пользователь покидает ваше приложение, и для противодействия этой проблеме вы должны поместить этот код в свою базовую активность (унаследованную всеми вашими действиями), поэтому, вызывая флеш каждый раз, когда вы меняете действия, что, в свою очередь, противоречит цели постановки событий в очередь…
ОБНОВЛЕНИЕ: Это правда, что события last могут не сбрасываться, даже если Mixpanel рекомендует сделать это выше (они, вероятно, никогда не думали об этом, но, поскольку SDK является открытым исходным кодом, может быть, посмотрим)
Несмотря на качество Mixpanel, я рекомендую звонить flush()
как можно раньше. Вы даже можете вызывать метод flush в методе onStop()
каждого действия (до super.onStop()
), и таким образом вы убедитесь, что каждое действие сбрасывает свои события каждый раз, когда оно останавливается.
Несмотря на то, что это может свести на нет цель удобной для сети организации очередей в Mixpanel, это может быть единственным способом (не прибегая к странным хакам) поддерживать синхронизацию событий.
Из-за всего этого я взглянул на исходный код mixpanel (который я проверил), и у них также есть метод для определения частоты сброса:
/**
* Sets the target frequency of messages to Mixpanel servers.
* If no calls to {@link #flush()} are made, the Mixpanel
* library attempts to send tracking information in batches at a rate
* that provides a reasonable compromise between battery life and liveness of data.
* Callers can override this value, for the whole application, by calling
* <tt>setFlushInterval</tt>.
*
* @param context the execution context associated with this application, probably
* the main application activity.
* @param milliseconds the target number of milliseconds between automatic flushes.
* this value is advisory, actual flushes may be more or less frequent
*/
public static void setFlushInterval(Context context, long milliseconds);
Возможно, уменьшение этого числа может помочь.
Значение по умолчанию выглядит следующим образом:
// Time interval in ms events/people requests are flushed at.
public static final long FLUSH_RATE = 60 * 1000;
Что делает flush()
, так это просто отправляет сообщение постоянно работающему рабочему потоку.
Рабочий поток перехватывает это здесь:
else if (msg.what == FLUSH_QUEUE) {
logAboutMessageToMixpanel("Flushing queue due to scheduled or forced flush");
updateFlushFrequency();
sendAllData();
}
После обновления FlushFrequency (на основе текущего системного времени) он отправляет данные с использованием HTTP.
Я понимаю, почему, если ваш основной процесс умирает (последнее действие), этот код может не выполниться вовремя…
И последнее, но не менее важное: если вы переключитесь на использование библиотеки в исходном коде (а не просто на использование jar), вы можете изменить в MPConfig значение:
public static final boolean DEBUG = false;
чтобы получить много журналов (среди них сбросы и сообщения на сервер). Может помочь увидеть, какие события на самом деле отправляются на сервер (и когда).
Существует также верхний предел количества элементов в очереди, прежде чем очередь будет принудительно очищена:
// When we've reached this many track calls, flush immediately
public static final int BULK_UPLOAD_LIMIT = 40;
Это видно в коде очереди:
if (queueDepth >= MPConfig.BULK_UPLOAD_LIMIT) {
logAboutMessageToMixpanel("Flushing queue due to bulk upload limit");
updateFlushFrequency();
sendAllData();
}
Удачи :)
person
Martin Marconcini
schedule
20.11.2013