3 ms·

Pretty interesting stuff... have to wonder how much of that is necessary (especially the native bitmap stuff) considering Google+ for Android appears to be all

by RyanZAG 14y ago

Pretty interesting stuff... have to wonder how much of that is necessary (especially the native bitmap stuff) considering Google+ for Android appears to be all java code and runs exceptionally smoothly. a) Reducing Garbage Collection - Very standard, not creating new objects in tight loops should be in the 'very obvious' category, regardless of GC or not. b) Writing a Custom Event Bus - Would be great if they released theirs so we could compare it to the existing ones - https://github.com/greenrobot/EventBus https://github.com/greenrobot/EventBus - http://square.github.com/otto/ http://square.github.com/otto/ c) Moving Photos to the Native Heap - Feels like this would have very heavy costs in transferring the photo back into the dalvik VM for display? Possibly control of allocation/de-allocation + absolute memory tracking makes this net positive for the Facebook app - but what about multitasking? Will the Facebook app free up this memory when swapped to the background? d) Writing a Custom ListView Recycler - This one is genuinely interesting, and hopefully Facebook can commit this back into Android AOSP! If not, hopefully some Google devs can take a look at the default recyclers and see if they can implement the same improvements.

martythemaniak 14y ago
I'm curious about the need for a "Custom Event Bus" - I just use Intents and BroadcastRecievers to let my activities and services notify each other and send info.
- georgemcbay 14y ago
  I'm also curious about this. Seems like virtually all apps would be better off using what is already built into Android. Intents & BroadcastReceivers as you mentioned and LocalBroadcastManager to route broadcasts that are in-app only. I wonder if this is pure NIH or if they have some interesting special case. IME the built-in Android stuff works great once you warp your brain to Android thinking.
guelo 14y ago
On the event bus, there is also the support library's LocalBroadcastManager which uses the Intent API but removes the overhead of the interprocess system. On rewriting the ListView recycler, I'm doubtful how much improvement they could get considering that code works fine for thousands of apps including Google's. If there were any gains to be had google's engineer's would have found them.
luke_s 14y ago
With the native bitmap stuff, they are not writing any native code. They are referring to using this flag: http://developer.android.com/reference/android/graphics/BitmapFactory.Options.html#inPurgeable http://developer.android.com/reference/android/graphics/Bitm... When creating bitmaps. It seems to act as a hint to the BitmapFactory to allocate the bitmap in a different memory space to where it would create a stock standard java object. There seems to be some pros and cons to this approach - namely the memory allocated to the bitmap could be disposed at any time, meaning the bitmap would have to be reloaded from disk, or wherever it came from. I will try out the flag in my own app, and see what impact it has.

by RyanZAG 14y ago

martythemaniak 14y ago

I'm curious about the need for a "Custom Event Bus" - I just use Intents and BroadcastRecievers to let my activities and services notify each other and send info.

georgemcbay 14y ago
I'm also curious about this. Seems like virtually all apps would be better off using what is already built into Android. Intents & BroadcastReceivers as you mentioned and LocalBroadcastManager to route broadcasts that are in-app only. I wonder if this is pure NIH or if they have some interesting special case. IME the built-in Android stuff works great once you warp your brain to Android thinking.

guelo 14y ago

On the event bus, there is also the support library's LocalBroadcastManager which uses the Intent API but removes the overhead of the interprocess system. On rewriting the ListView recycler, I'm doubtful how much improvement they could get considering that code works fine for thousands of apps including Google's. If there were any gains to be had google's engineer's would have found them.

luke_s 14y ago

With the native bitmap stuff, they are not writing any native code. They are referring to using this flag: http://developer.android.com/reference/android/graphics/BitmapFactory.Options.html#inPurgeable http://developer.android.com/reference/android/graphics/Bitm... When creating bitmaps. It seems to act as a hint to the BitmapFactory to allocate the bitmap in a different memory space to where it would create a stock standard java object. There seems to be some pros and cons to this approach - namely the memory allocated to the bitmap could be disposed at any time, meaning the bitmap would have to be reloaded from disk, or wherever it came from. I will try out the flag in my own app, and see what impact it has.