6 ms·

I'm an engineer on the project. Would be happy to take questions.

by tyronen 12y ago

realrocker 12y ago
Hey. Quote, "Our breakthrough came when we realized we didn't have to do that. If we called lockPixels without a matching unlockPixels, we created an image that lived safely off the Java heap and yet never slowed down the UI thread. A few lines of C++ code, and we were home free." That doesn't sound complete. It's off the Java heap, true but doesn't mean it's either safe or won't slow down the UI or is even home free. Allocation in ashmem will still count towards the PSS[1] of the app. The image data won't be unpinned right until it throws an OutofMemory exception. And if you have handled the exception, the UI thread will wait around for the unpin/unlock of data. This would be ok if you could make an educated guess of how much ashmem can be allocated to your app. You can't make that guess easily as it depends a lot on OEM implementation of Gralloc/HWComposer and the GPU. But since you are Facebook, :), you can probably test this on all device/gpu variants. And when you do please publish the results. And while you are doing that, please test this too: http://developer.android.com/reference/android/os/MemoryFile.html http://developer.android.com/reference/android/os/MemoryFile... [1]https://developer.android.com/tools/debugging/debugging-memory.html#ViewingAllocations https://developer.android.com/tools/debugging/debugging-memo... Thoughts? Edit: Incorrect link
- georgemcbay 12y ago
  As someone who has written a lot of code (including driver level) in the DirectX realm, that line (about not unlocking surfaces) gave me a minor aneurysm though I admittedly do not know enough about the Android ashmem internals to know if the reaction is actually warranted or not on the Android platform.
  - realrocker 12y ago
    Well allocating on ashmen does reduce the UI lag since its just a memory pool and espaces GC reprimand but it's definitely not safe. Such operations are better handled at Gralloc/HWComposer Layer where you have a better handle on what's going on. Someone's gotta unlock that surface!
  - on_and_off 12y ago
    I have written my fair share of code in the Android realm and that line gave my an aneurysm as well. To be fair, I think that Bitmap handling is one of Android's weaknesses and that it is far too easy to fragment or overflow your heap with Bitmaps.
- tyronen 12y ago
  The key, explained in the blog post, is that every Bitmap that lives in ashmem needs to have an explicit .recycle call to unpin and free the memory. Fresco's DraweeViews automatically do this when they go off-screen. Fresco limits the total amount of memory an app can allocate to bitmaps, even in ashmem. But although ashmem does count towards total PSS, it doesn't count towards the Dalvik heap limit, which is the bound that most Java apps have to deal with.
smrtinsert 12y ago
Once you go ndk aren't you opening up the library to all sorts of compatibility issues with specific devices? The Java api always seems safer to me.
- tyronen 12y ago
  Fresco is compiled natively to support ARM, ARMV7, and x86 CPUs. Almost all Android devices are using one of those three.
tlarkworthy 12y ago
If the app crashes is the mem freed?
joezydeco 12y ago
Could you ask your marketing staff to stop spamming android developers on LinkedIn?

I'm an engineer on the project. Would be happy to take questions.

by tyronen 12y ago

I'm an engineer on the project. Would be happy to take questions.

Hey. Quote, "Our breakthrough came when we realized we didn't have to do that. If we called lockPixels without a matching unlockPixels, we created an image that lived safely off the Java heap and yet never slowed down the UI thread. A few lines of C++ code, and we were home free." That doesn't sound complete. It's off the Java heap, true but doesn't mean it's either safe or won't slow down the UI or is even home free. Allocation in ashmem will still count towards the PSS[1] of the app. The image data won't be unpinned right until it throws an OutofMemory exception. And if you have handled the exception, the UI thread will wait around for the unpin/unlock of data. This would be ok if you could make an educated guess of how much ashmem can be allocated to your app. You can't make that guess easily as it depends a lot on OEM implementation of Gralloc/HWComposer and the GPU. But since you are Facebook, :), you can probably test this on all device/gpu variants. And when you do please publish the results. And while you are doing that, please test this too: http://developer.android.com/reference/android/os/MemoryFile.html http://developer.android.com/reference/android/os/MemoryFile... [1]https://developer.android.com/tools/debugging/debugging-memory.html#ViewingAllocations https://developer.android.com/tools/debugging/debugging-memo... Thoughts? Edit: Incorrect link

georgemcbay 12y ago
As someone who has written a lot of code (including driver level) in the DirectX realm, that line (about not unlocking surfaces) gave me a minor aneurysm though I admittedly do not know enough about the Android ashmem internals to know if the reaction is actually warranted or not on the Android platform.
- realrocker 12y ago
  Well allocating on ashmen does reduce the UI lag since its just a memory pool and espaces GC reprimand but it's definitely not safe. Such operations are better handled at Gralloc/HWComposer Layer where you have a better handle on what's going on. Someone's gotta unlock that surface!
- on_and_off 12y ago
  I have written my fair share of code in the Android realm and that line gave my an aneurysm as well. To be fair, I think that Bitmap handling is one of Android's weaknesses and that it is far too easy to fragment or overflow your heap with Bitmaps.
tyronen 12y ago
The key, explained in the blog post, is that every Bitmap that lives in ashmem needs to have an explicit .recycle call to unpin and free the memory. Fresco's DraweeViews automatically do this when they go off-screen. Fresco limits the total amount of memory an app can allocate to bitmaps, even in ashmem. But although ashmem does count towards total PSS, it doesn't count towards the Dalvik heap limit, which is the bound that most Java apps have to deal with.

smrtinsert 12y ago

Once you go ndk aren't you opening up the library to all sorts of compatibility issues with specific devices? The Java api always seems safer to me.

tyronen 12y ago
Fresco is compiled natively to support ARM, ARMV7, and x86 CPUs. Almost all Android devices are using one of those three.

tlarkworthy 12y ago

If the app crashes is the mem freed?

joezydeco 12y ago

Could you ask your marketing staff to stop spamming android developers on LinkedIn?