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

Question

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

1

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

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

machinery 13 фев. 2019, в 17:28

Источник

Теги:

android

android-sqlite

text-files

android-sensors

1 ответ

Ещё вопросы

Sebastiaan Alvarez Rodriguez · Accepted Answer · 2019-02-13T16-37-00.000Z

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 и сохранение его в базе данных, вероятно, займет больше времени, чем быстрая запись содержимого в какой-либо текстовый файл, если это все еще означает быструю работу.

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

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

Спасибо за Ваш ответ. Но нельзя ли вызывать onSensorChanged () несколько раз одновременно? Я думаю, что если, например, onSensorChanged () требуется 10 секунд для завершения операции, но onSensorChanged () вызывается каждые 50 мсек, то одновременно происходит много вызовов методов. Это не правда?
Я почти уверен, что в вашем примере 1 вызов onSensorChanged () выполнен (для завершения требуется 10 секунд). Через 50 мс вызовы onSensorchanged () не будут вызываться, поскольку программа все еще занята первым вызовом и не вернулась к системной функции Android, вызывающей onSensorChanged. Вкратце: нет вызовов методов до 10 секунд
Я проверял это. Ты прав. Как вы думаете, хорошей альтернативой будет создание нового потока для каждого вызова onSensorChanged (), а затем обработка извлечения метки времени в миллисекундах и наносекундах и хранения в потоке? Это имеет тот недостаток, что, возможно, создается много потоков.
Я боюсь, что эта стратегия будет продолжать создавать больше потоков, чем она закрывается за единицу времени (например, одну минуту). Это может привести к проблеме, при которой количество потоков продолжает расти (до тех пор, пока ОС Android не подключится или телефон не выйдет из строя. Вы хотите избежать обоих).
Теперь то, что я выяснил: очевидно, что SensorEvent имеет временную метку в наносекундах, которую вы можете получить, выполнив long nanosecs = mEvent.timestamp; , Это означает, что вам не нужно получать время от системы, что экономит время в вашей функции.
Кроме того, базы данных в PHP предлагают подготовленные операторы, где вся база данных готова принять ≥1 операторов одинакового типа. Это также может быть доступно в Android! Возможно, ваша реализация базы данных тоже это поддерживает. Таким образом, ваша база данных не должна готовиться каждый раз, когда вы хотите нажать.
Нет способа полностью избавиться от этой проблемы, так как «всегда медленный телефон». Тем не менее, его можно уменьшить, насколько это возможно, за счет сокращения затрат времени (требуется меньше времени) и дать больше времени (больше времени = больше шансов быть выполненным в рамках лимита и без проблем). В конце концов, на самом деле не имеет значения, есть ли где-то очень очень старый медленный телефон, который не справится с ним, если он прекрасно работает почти на всех телефонах по всему миру, верно?