I have a service that reads real-time sensor data. The data is read in sequence, 4 different types each about 50 ms apart. Actually the sensor data comes via bluetooth but is read out of the inputStream by the service.
Now it is crucial that the data is timestamped at its arrival with the most precision possible and thats where i have a problem with the gc. Should the gc kick in between reading data and timestamping it, even 20 ms lead to ugly results. Also it is crucial that the data never has larger gaps as i already have 200 ms between the same data types.
On the other hand i want the data to be transfered in real-time to an app (mini delay is ok).
I managed to write the service so that it allocates all its objects in the beginning and never ever produces any trash for the GC. But for IPC i need to create parcelable objects to send them to the app.
Question 1: if i create such objects and send them via IPC to the app, on whos memory do they exist ? As 2 processes dont share memory.
Question 2: does it cost me performance to use IPC ? because i could simply make the service run in the same process and share the data 10 times more easily.
The app will have GC, so if the service runs in the same process there is the danger of the GC disrupting the real-time data handling. However if i divide them into 2 processes im afraid that the IPC costs me some performance that may outweigh the GC trouble.
The service only works for one single app, but should run as uninterrupted as possible AND deliver its data as real-time as possible. So put it in its own process or not ?
Please use a RTOS for that degree of precision. Android is not an RTOS.
In both processes. Which is why you should get rid of the second process, as you do not need it.
Absolutely. IPC is expensive.
Please do.
Any GC in any process could “disrupt the real-time data handling”. Any work in any process could “disrupt the real-time data handling”. The vast majority of Android devices in use today are single-core, and that one core can only do one thing at a time. Even for multi-core devices, you are not in control over the process and thread scheduling with respect to the cores, because that is managed exclusively by the firmware.
Again, your project seems like it calls for an RTOS, and Android is not an RTOS.
You should use a suitable RTOS and not Android.
If, for whatever reason, you elect to stick with Android, do not put it in its own process, as it will not help you and only wastes RAM and CPU time. But your delays will routinely exceed the 20ms level you deem as “ugly”.