I'm reading a Bluetooth data stream on a background thread and passing that data to the UiThread for processing and display via a Message Handler. A more detailed description of the process can be found here.
Currently I'm reading the InputStream to a byte[]
and using Handler.obtainMessage() to get a message with the byte array as an object arguement.
I ran into a problem with packets over开发者_运维技巧writing each other because the array is not locked across threads and is being overwritten in the background before the UiThread can process it. The obvious solution is to copy the array to a new array and pass that new object.
The problem is this is very expensive on Android and I am going to be getting a fairly continuous stream of data. Is there a better way to pass this data to the main UiThread? Perhaps by synchronizing the byte array or a more memory efficient way of copying the array?
The typical way this is done in Android is to have a pool of allocated objects. Make this class:
class DataBuffer {
DataBuffer next;
byte[] data;
}
And you can manage them like this:
final Object mLock = new Object();
DataBuffer mPool;
DataBuffer obtain() {
synchronized (mLock) {
if (mPool != null) {
DataBuffer res = mPool;
mPool = res.next;
return res;
}
return new DataBuffer();
}
}
void recycle(DataBuffer buffer) {
synchronized (mLock) {
buffer.next = mPool;
mPool = buffer;
}
}
It sounds like what you want to is pool of byte arrays that you can check out for use and check in when finished with. An implementation might look like
public class BytePool {
private class PoolObject {
public byte[] buffer = byte[1024];
public boolean available = false;
}
ArrayList<PoolObject> pool = new ArrayList<PoolObject>();
public synchronized byte[] checkOut() {
boolean found = false;
for (PoolObject obj : pool) {
if (obj.available) {
obj.available = false;
return obj.buffer;
}
}
PoolObject newObj = new PoolObject();
pool.add(newObj);
return newObj.buffer;
}
public synchronized void checkIn(byte[] finished) {
for (PoolObject obj : pool) {
if (obj.buffer == finished) {
obj.available = true;
}
}
}
}
Disclaimer: I haven't actually tested or even compiled this code, its just meant to convey the basic idea.
With this you hopefully have the minimum number of byte[] objects allocated at any given time. Ideally you also want to add in some code to reduce the pool size if for some reason it expanded a bunch and now required pool size is smaller.
Personally I think you might be worrying a little too much about micro-optimizations before its clear whether you need it or not. (Or maybe you've already profiled your application and know that you need it.)
UPDATE: Hackbod's solution is actually more efficient than the one I suggested, although it still possibly suffers from having too many objects in the pool.
How quickly is the data coming in vs. being consumed?
Why not allocate a 2nd array, one for reading one for writing, switching as needed.
When the stream is done writing to array 1, release its mutex and wait for array 2 to become available. Then you can pass array 1 via your handler to the UI Thread which will obtain a lock on that array. By switching the arrays like this you can ensure data is not lost because access to each is controlled via mutual exclusion.
A problem may arrise however if your data is coming in faster than it is being read. (Can the blue tooth data steam afford to block and wait?)
Don't know android, but it's usual to read such data into a dynamically-allocated buffer, post its reference off in the message and immediately allocate a new one, ready for the next lot of data. This eliminates the copying and ensures that the two threads are always operating on different data.
Rgds, Martin
精彩评论