Rebuilding Facebook for Android | Hacker News Reader

Rebuilding Facebook for Android

facebook.com

67 pointsnileshd34 comments

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 - 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.

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.

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.

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.

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/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.

Looks like they could get a lot of improvement in their render times too if they eliminate all that overdraw in the app.

The news feed is mostly light red (3x overdraw): http://ara.sh/private/facebook_news_feed_overdraw.png

The side bar is simple enough that it shouldn't be overdrawn 2x (green) all over either: http://ara.sh/private/facebook_sidebar_overdraw.png

Compare this to the Google+ feed view which has significantly less overdraw (and scrolls a lot better): http://ara.sh/private/google_plus_news_feed_overdraw.png

I've been using m.facebook.com in the browser because the Android app is just so horrible. But I refuse to get my hopes up.

like the browser app performs much better , yeah right...

At least on iOS it performed better, at least before they introduced the more performant one a few months back.

The new app is much better. The scroll performance is up to standards on the Galaxy Nexus (which is to say, it's usable, but abysmal compared to any iPhone released in the last 3 or so years).

That's not up to standard then. I can't make an app have bad scroll performance on my Galaxy Nexus. It scrolls through my feed very speedily, as fast as my eyes can perceive certainly.

That's not my experience at all. Even the barest and most native scroll views (like in settings) are noticeably unresponsive and occasionally drop frames when scrolling quickly.

Font size on my Nexus 7 is still too small for me, does not seem to obey the global Android OS "large" setting like other apps do (or provide a font size slider control)…

I hope it's not lost on people how long it took for Facebook to come out with fully native apps for iPhone and Android. There are costs to going full native, even if you have as many resources as Facebook does.

OTOH the overall costs to them would have been much lower if they went native to begin with and not dicked around with HTML-based apps for years.

While true I don't think that diminishes the previous point.

HUGE improvement on this app. At first glance theres nothing different, maybe the news feed loads a little faster. You really see it, though, when you click on an item or picture in the newsfeed. The expansion is instant. Clicking on a picture gives you an instant larger view and the ability to like/comment, same with a post (including comment history). That means in the same/less time it took the HTML5 app to just load the news feed preview, the native app can do the same AND cache all of the expanded content for each post. I'm impressed.

For all their effort, it doesn't look like they even bothered to read Google's design guidelines.

Can you elaborate on this?

I suspect mtgx is referring to the fact that the Facebook app doesn't follow Google's Holo design guidelines. They have instead opted to make the iOS and Android apps mirror each other as closely as possible.

Oh, UI design. I thought he meant engineering design.

I'm not particularly fond of Holo, so I'm ok with this.

They could at least add a menu button somewhere that makes sense instead of sending it to the soft button panel.

I like holo, but people definitely go way too overboard in demanding that all apps use it. wanting android apps that exist only as android apps to be holo-style is fine, but something like facebook that has their own identity above and beyond the android app should style their apps to fit in with their own identity first, and making them fit the platform should be a secondary concern. I think that facebook has done a good job of balancing the two.

The app is still ridiculously slow for me on WiFi. Start up takes ~10 seconds to bring up the Facebook logo/splash screen. Then another 3 - 5 to bring up my feed and load the images.

Scroll is laggy and there are only ~5 articles before I have to refresh.

I end up using the mobile version because it isn't as laggy and doesn't require location services and the potential to track me as easily.

The Facebook app should be like the Google+ app if they want to make Android users happy.

What phone/tablet are you using ?

I'm able to get into the pictures loaded feed under 5 seconds on 3G and under 4 seconds on WiFi. And I get about 10 articles before I have to refresh (which takes less than a second) to see more.

I'm using a HTC One X.

I am using a Galaxy Nexus.

I was able to bring the loading times down to something reasonable but it isn't consistent. Out of 10 times, only 30 or 40 percent were < 5 seconds.

There are anywhere from 5 to 10 articles at any given time on the first page of my feed. It still takes a second or two to reload and after about 6 pages, the scrolling is so laggy so I can't be bothered to use the app.

It's a shame, really, that a platform that popular with all the resources, still has massive performances problems and still has legacy stuff lying around (like the three dot menu in the bottom right on 4.0+ devices).

Awesome blog post guys. I hope you plan on open sourcing the event bus and the listview. They would be very useful.

I just reinstalled the app and see no difference at all. Have they actually rolled out the new version?

Whoa, there are some nice improvements here. The general look is more of the same, but photos, comments, Likes are all a much better experience. Cool!

Yet another app that's too big to fit on my Galaxy Ace.

more and more companies are stripping their desktop framewoks for native code on mobile. Mozilla ditched XUL for native in mobile ff a while back because of performance too. Android already has so many layers.

wonder what B2G perf will be like. excited.

Android doesn't really have that many layers. It often comes off more complex than it really is, mostly from pretty good design work on the Android designers side.

  Calculations:
  CPU
  - Dalvik VM doing JIT into ARM ASM
  
  Graphics:
  GPU
  - OpenGL/Drivers
  -- (a) Directly running OpenGL calls (native)
  -- (b) Dalvik VM doing JIT
  --- Semi-lightweight translation of 2D drawings

You don't really lose more than a couple percent on the 'many layers' compared to writing raw assembler, aside from using Android's View framework which is about as performant as most GUI toolkits in most situations.

I think the Facebook article throws around the word "native" a little liberally.

It sounds like they are doing bitmap processing in the true "native" sense (i.e. C). The earlier references to "native" make me think they are referring to standard Android/Java code as opposed to WebViews.

Next: Native Facebook for desktop!

Reply on news.ycombinator.com