Android-приложение закрывается до того, как Mixpanel сможет сбросить данные

Я вызываю MixPanel.flush в своем методе onDestroy, но похоже, что приложение завершается до того, как MixPanel успевает отправить/сбросить свои данные.

Я не вижу никаких данных на моем экране аналитики MixPanel, если я не приостанавливаю свое приложение для Android с помощью точки останова в onDestroy сразу после вызова MixPanel.flush().

Есть ли способ оставить мое приложение открытым для завершения работы MixPanel?


person Paul Nikonowicz    schedule 20.11.2013    source источник
comment
в каком методе onDestroy() вы это вызываете?   -  person Martin Marconcini    schedule 20.11.2013


Ответы (1)


Вы должны вызвать 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
comment
Вы уверены, что это работает для вас, когда это последнее действие в вашем стеке? Другими словами, когда приложение закрывается? Это не работает для меня. - person Paul Nikonowicz; 20.11.2013
comment
Mix Panel SDK действительно плохой и может не работать… Я рекомендую вызывать флеш как можно раньше. Вы даже можете вызвать flush onStop() (до super.onStop()), и таким образом вы убедитесь, что каждое действие сбрасывает свои события каждый раз, когда оно останавливается. Я знаю… ;) - person Martin Marconcini; 21.11.2013
comment
стоит попробовать. Спасибо :) - person Paul Nikonowicz; 21.11.2013
comment
Я потратил некоторое время на просмотр исходного кода и добавил дополнительную информацию, которая может вам помочь, а может и не помочь :) - person Martin Marconcini; 21.11.2013