Интерпретация трассировки многоядерной производительности (Eclipse/Android)

Я работаю над игрой для Android, и я начал замечать небольшую медлительность во время разработки, поэтому я хотел попробовать использовать многопоточность для развлечения и обучения.

Мое приложение имеет 3 потока:

1. Поток пользовательского интерфейса (должен быть в основном бездействующим)
2. Поток игровой логики
3. Поток графики

Я минимизировал критическую секцию между потоками 2 и 3, насколько это было возможно, с идея, что игровая логика может обновляться независимо от потока рендеринга, и тогда в конце обоих потоков у меня может быть максимально короткое окно, в котором я проталкиваю все графические обновления из потока логики в игровой цикл. Это должно позволить двум потокам работать независимо большую часть времени. Теоретически звучит как выигрыш в производительности.

Однако как только я приступил к реализации, моя производительность сильно упала. Это намного хуже, чем раньше, один цикл обновления и рендеринга занимает около 50 мс (20 кадров в секунду), так что это выглядит как мусор. Это всего лишь рендеринг примерно 20 треугольников и, возможно, 20 текстурированных четырехугольников, очень простая рабочая нагрузка (боюсь представить, какой она будет, когда я реализую правильную графику).

Так или иначе, я взял трассировку DDMS в Android, чтобы профилировать, где что-то идет не так или может быть улучшено.

http://i.stack.imgur.com/DDUYE.png

Это примерно 3 кадра моей игры.Пока что, кажется, он делает примерно то, что я ожидал. Части, выделенные синим цветом, — это заблокированная секция, которая выглядит примерно так (заставляет glThread в основном ждать, пока она заблокирована). Однако, как только я разблокирую его, я должен увидеть, что оба потока работают одновременно, и похоже, что они работают, но если я присмотрюсь:

http://i.stack.imgur.com/vukXQ.png

Я делаю свою разработку на двухъядерном телефоне, но, если я правильно понимаю трассировку, это не похоже на то, что она когда-либо делала что-то параллельно, и, что еще хуже, кажется, что активный поток переключается сотни раз в миллисекунду! (если я не правильно интерпретирую). Все это переключение контекста кажется ужасным для производительности, поэтому я не уверен, почему он так быстро переключается туда и обратно.

Итак, после моего длинного объяснения, я задаюсь вопросом о нескольких вещах:

1. Правильно ли я понимаю, что заштрихованные прямоугольники на трассе — это активные потоки, а цветные линии — это спящие потоки? Иначе что они означают?
2. Почему я никогда не вижу, чтобы мои потоки выполнялись одновременно на предположительно двухъядерном телефоне?
3. Почему активные потоки переключаются так быстро?
4. В DDMS я получаю предупреждение «ВНИМАНИЕ: активен отладчик; результаты трассировки методов будут искажены». Стоит ли об этом беспокоиться? Как я могу избавиться от этого предупреждения? (Я запустил приложение через Run, а не через Debug, если это имеет значение)