Хранение данных датчика и дамп файла событий на Android - PullRequest
Новая
       28

Хранение данных датчика и дамп файла событий на Android

0 голосов
/ 13 февраля 2019

Я написал приложение для Android 7 для хранения сенсорных данных моего смартфона в базе данных SQLite.Например, для акселерометра я получаю значения следующим образом: 

mSensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
Sensor mAccelerometer = mSensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
mSensorManager.registerListener(this, mAccelerometer, SensorManager.SENSOR_DELAY_UI);
public final void onSensorChanged(SensorEvent event) {
        long timeNano = System.nanoTime();
        long timeMilli = System.currentTimeMillis();
        // Save to database
}

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

Это проблема, когда я получаю метку времени для каждого полученного значения датчика?Меня беспокоит только то, что я добавляю искусственные задержки (постановку в очередь) к значениям датчика в случае, если значения датчика поступают быстрее, чем получение миллисекундной и наносекундной отметки времени.

Во-вторых, я также хочу сбросить /dev/input/event7файл (на рутированном телефоне).Я могу либо сохранить его непосредственно в базе данных (как с данными датчика), либо просто выгрузить его в текстовый файл.

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

1 Ответ

0 голосов
/ 13 февраля 2019

SENSOR_DELAY_UI = 60 000 микросекунд = 60,0 миллисекунд задержки.

Мы не можем быть уверены в скорости выборки временных меток.На дорогих устройствах это может занять 10 миллисекунд.На дешевых устройствах может быть 100 миллисекунд.

Кроме того, хранение данных в базе данных / файле добавляет много миллисекунд, как и загрузка нового потока для офшорного процесса.

Краткое напоминание: не забывайте, что указанная вами задержка составляет только рекомендуемая задержка , поэтому задержка может быть ниже указанной задержки. Источник

Итак: ваш сверхбыстрый ультрафон может не вызывать эти временные метки, поскольку он достаточно быстр, чтобы получить временную метку и сохранить ее в базе данных / файле, ноэто может быть проблемой на других, более медленных телефонах.

Вы получите пробелы в своих показаниях.Если один вызов на onSensorChanged() занимает, например, 10 секунд, и каждые 50 микросекунд функция является заданной задержкой, то будет происходить вызов между каждыми 10 секундами и каждые 10 секунд плюс 50 микросекунд.

Вы можете принятьтот факт, что вам иногда приходится «пропускать» вызов onSensorChanged().Чтобы снизить вероятность этого, вы можете указать большую задержку.Вы можете указать пользовательское время задержки в микросекундах с помощью mSensorManager.registerListener(this, mAccelerometer, 1000*1000);

На ваш второй вопрос: я не знаю много о корневых телефонах, но я знаю о файлах.

Чтение / dev / input / event7 и сохранение его в базе данных, вероятно, займет больше времени, чем быстрая запись содержимого в какой-либо текстовый файл, если это все еще происходит быстро.

Повреждениеtextfile произойдет, если у вас есть 2 операции записи, записывающие в 1 файл одновременно.Вы должны всегда закрывать свой первый выходной поток перед открытием второго.Обычно при обнаружении ошибок записи всегда закрывайте outputtream.Выполняя эти две вещи, убедитесь, что файл не поврежден.

Как правило, запись в базу данных более безопасна, чем запись в текстовый файл, поскольку базы данных предназначены для обработки нескольких записей, потенциально опасных записей и т. Д.

...