Как я уже упоминал в комментариях, это сводится к проблеме разрешения таймера.Я использовал класс таймера, который должен был получить доступ к системному таймеру с самым высоким разрешением, кроссплатформенному.Все работало отлично, за исключением того, что когда дело дошло до Android, некоторые версии работали, а некоторые версии - нет.Галактика Tab 10.1 был одним из таких случаев.
В итоге я переписал свой метод getSystemTime(), чтобы использовать новое дополнение к C ++ 11 под названием std::chrono::high_resolution_clock.Это также прекрасно работало (везде, кроме Android) ... за исключением того, что оно еще не реализовано ни в одном NDK для Android.Предполагается, что он будет реализован в 5-й версии crystax NDK R7, который на момент написания этой статьи завершен на 80%.
Я провел некоторые исследования различных методов доступа к системному времени или что-то, с помощью которых яможет основывать надежный таймер на стороне NDK, но все сводится к тому, что эти различные методы поддерживаются не на всех платформах.Я прошел через болезненный процесс написания своего собственного движка с нуля просто для того, чтобы я мог поддерживать каждую версию Android, поэтому делать ставки на непоследовательные методы бессмысленно.
Единственное разумное решениедля любого, кто сталкивается с этой проблемой, на мой взгляд, стоит просто отказаться от идеи реализации такого кода на стороне NDK .Вместо этого я собираюсь сделать это на стороне Java, поскольку до сих пор во всех моих тестах это было достаточно надежно для всех устройств, на которых я тестировал.Подробнее об этом здесь:
http://www.codeproject.com/Articles/189515/Androng-a-Pong-clone-for-Android#Gettinghigh-resolutiontimingfromAndroid7
Обновление
Теперь я реализовал предложенное мной решение, чтобы выполнить синхронизацию на стороне Java, и оно сработало.Я также обнаружил, что обработка любого относительно большого числа, независимо от типа данных (числа, такого как наносекунды от вызова монотонных часов) на стороне NDK, также приводит к серьезному отставанию в некоторых версиях Android.Поэтому я максимально оптимизировал это, передав указатель на системное время, чтобы гарантировать, что мы не передаем копию.
И последнее: мое утверждение о том, что называть монотонные часы со стороны NDK ненадежно, однако, может показаться ложным.Из доков Android на System.nanoTime () ,
... и System.nanoTime ().Эти часы гарантированно являются монотонными и являются рекомендуемой основой для определения временных интервалов общего назначения событий пользовательского интерфейса, измерений производительности и всего, что не требует измерения истекшего времени во время сна устройства.
Так что, если верить этому, может показаться, что вызов часов является надежным, но, как уже упоминалось, возникают и другие проблемы, такие как обработка выделения и сброса огромного числа, которое в результате само по себе почти урезало мою частоту кадров вдвое.Galaxy Tab 10.1 с Android 3.2. Окончательный вывод: поддержка всех устройств Android в равной степени либо чертовски близка, либо невозможна, а использование нативного кода, похоже, ухудшает ситуацию .