Неожиданное поведение одних и тех же методов в разных потоках

Мой первоначальный вопрос был: проект Android GraphView зависает с обновлениями в реальном времени. В этом я спрашивал о возможном параллелизме в потоке пользовательского интерфейса из 3 графиков. На графике распределения памяти это выглядит так:

введите описание изображения здесь

Я получал данные прямо из моего ProcessThread в основном действии и передавал их, используя onEventMainThread из EventBus библиотеки, обратно в GraphFragment. Все передаваемые данные поступают от ProcessThread, который собирает данные из службы прослушивания Bluetooth и затем обрабатывает их для получения значимых чисел.

Моя идея заключалась в том, чтобы проверить, произойдет ли то же самое с тестовым потоком, который только генерирует данные и отправляет их onEventMainThread. Поскольку это также приводит к некоторым ошибкам, я был вынужден задать другой вопрос: Сложность понимания сложной многопоточности в приложении для Android. Через некоторое время я получил отличный ответ от @AsifMujteba, в котором объясняется, что мой тестовый поток слишком быстр.

Зная, что я смог вернуться к своей основной проблеме и своему настоящему потоку, чтобы проверить правильность всех таймингов. Как я уже сказал, происходит много всего, поэтому поститься не проблема (однако я добавил ту же самую механизацию, чтобы проверить, не пересылаются ли данные быстро). Я был бы больше обеспокоен медленной работой этой ветки.

Мой текущий onEventMainThread выглядит так:

public void onEventMainThread(float[] data) {
            mSeries1.appendData(new DataPoint(counter,data[0]),true,100);
            mSeries1.appendData(new DataPoint(counter,data[1]),true,100);
            mSeries1.appendData(new DataPoint(counter,data[2]),true,100);
            counter++;
        }

К сожалению, когда я вернулся к началу, проблема возникла снова. После длительного тестирования я могу сказать, что данные, похоже, отправляются правильно. Я проверил это двумя маркерами:

public void onEventMainThread(float[] data) {
                Log.d("LOG","marker1");
                mSeries1.appendData(new DataPoint(counter,data[0]),true,100);
                mSeries1.appendData(new DataPoint(counter,data[1]),true,100);
                mSeries1.appendData(new DataPoint(counter,data[2]),true,100);
                counter++;
                Log.d("LOG","marker2");
            }

Сообщения Logcat отображаются правильно. К сожалению, ошибка появляется, хотя отправка выглядит так же, как в моей тестовой ветке:

if((System.currentTimeMillis()-start)>10) {
    values[0] = (float) getRandom();
    values[1] = (float) getRandom();
    values[2] = (float) getRandom();
    EventBus.getDefault().post(values);
    start = System.currentTimeMillis();
}

Более того, я уверен, что данные все время отправляются правильно, потому что, когда я тестировал другой фрагмент с визуализацией OpenGL, все работает.

Итак, подведем итоги:

При отправке значений фрагменту с использованием EventBus из одного (очень простого) потока все работает отлично, а отправка из другого (более сложного) потока заканчивается зависанием отображения и отображением графика распределения памяти. Важно знать, что если один поток работает, второй закомментирован.

Может кто-нибудь посоветуйте мне, в чем может быть проблема? Или что еще проверить?

ИЗМЕНИТЬ

Я провел еще один тест, закомментировав все, что касается добавления данных серии, оставив только Log.d(), и никаких ошибок не появилось. Интересно то, что блокировка (или замораживание) обновлений графиков не влияет на сам пользовательский интерфейс, поэтому я все еще могу нажимать все кнопки и так далее.


person sebap123    schedule 26.05.2015    source источник
comment
если вы можете нажимать кнопки, то откуда вы знаете, что приложение зависает?   -  person Asif Mujteba    schedule 26.05.2015
comment
также попробуйте увеличить время немного 10 мс все еще слишком много .. попробуйте около 100 мс   -  person Asif Mujteba    schedule 26.05.2015


Ответы (1)


Вы пробовали использовать пользовательскую шину событий, а не стандартную? Сегодня у меня была похожая проблема, и я исправил ее, создав собственный evenbus с отдельным ThreadPool, и это сработало как шарм.

person EE66    schedule 07.06.2015