Сервис и процессы, касающиеся производительности для доставки данных в режиме реального времени - PullRequest
2 голосов
/ 30 декабря 2011

У меня есть сервис, который считывает данные датчика в режиме реального времени.Данные считываются последовательно, 4 разных типа, каждый с интервалом около 50 мс.На самом деле данные датчика поступают через bluetooth, но сервис считывает их из inputStream.

Теперь крайне важно, чтобы данные были доставлены с максимальной точностью при получении, и именно там у меня возникла проблема сдс.Если gc переместится между чтением данных и отметкой времени, даже 20 мс приведут к ужасным результатам.Также крайне важно, чтобы у данных никогда не было больших промежутков, поскольку у меня уже есть 200 мс между одними и теми же типами данных.

С другой стороны, я хочу, чтобы данные передавались в реальном времени в приложение (мини-задержкавсе в порядке).Мне удалось написать сервис так, чтобы он распределял все свои объекты в начале и никогда не создавал мусор для GC.Но для IPC мне нужно создать разлагаемые объекты для отправки их в приложение.

Вопрос 1: если я создаю такие объекты и отправляю их через приложение IPC, на чьей памяти они существуют?Поскольку 2 процесса не разделяют память.

Вопрос 2: стоит ли мне производительность при использовании IPC?потому что я мог бы просто заставить службу работать в одном и том же процессе и делиться данными в 10 раз проще.

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

Служба работает только для одного приложения, но должна работать как можно непрерывнее и доставлять свои данные.в режиме реального времени, насколько это возможно.Так поставить его в свой процесс или нет?

1 Ответ

1 голос
/ 31 декабря 2011

Теперь крайне важно, чтобы данные были помечены с момента их прибытия с максимально возможной точностью, и именно там у меня возникли проблемы с gc.

Пожалуйста, используйте RTOS для этой степени точности. Android не является ОСРВ.

Вопрос 1: если я создаю такие объекты и отправляю их через IPC в приложение, на чьей памяти они существуют?

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

Вопрос 2: стоит ли мне использовать IPC?

Абсолютно. МПК стоит дорого.

потому что я мог бы просто сделать так, чтобы служба работала в одном и том же процессе и делиться данными в 10 раз проще

Пожалуйста, сделайте.

Приложение будет иметь GC, поэтому, если служба работает в том же процессе, существует опасность, что GC нарушит обработку данных в реальном времени.

Любой GC в любом процессе может «нарушить обработку данных в реальном времени». Любая работа в любом процессе может «нарушить обработку данных в реальном времени». Подавляющее большинство устройств Android, используемых сегодня, являются одноядерными, и это одно ядро ​​может одновременно выполнять только одно действие. Даже для многоядерных устройств вы не контролируете процесс и планирование потоков по отношению к ядрам, потому что это управляется исключительно микропрограммой.

Опять же, ваш проект требует RTOS, а Android не является RTOS.

Значит, поставить его в свой процесс или нет?

Вы должны использовать подходящую ОСРВ, а не Android.

Если по какой-либо причине вы решили придерживаться Android, не включайте его в свой собственный процесс, поскольку он не поможет вам, а только тратит время ОЗУ и ЦП. Но ваши задержки обычно превышают уровень 20 мс, который вы считаете «безобразным».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...