Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dalvik patch for Facebook for Android

facebook.com

Post reply on HN
Print view View original

51–60 of 95 posts

Re: Dalvik patch for Facebook for Android

#51

Post by chucknthem »

chuinard wrote: post #25

"choose between cutting significant features from the app or only shipping our new version to the newest Android phones (ICS and up)" The ICS move wouldn't have been a bad option. It would've helped a lot of users convert to ICS+ devices, which Google probably would've loved. The APIs from 4+ are much more robust than pre-ICS, and it probably would've saved more headaches while building the new version in addition to…

Android 2.2 and 2.3 devices are still being released on low end phones, especially in developing countries, so the number of pre-ICS users are actually growing, not shrinking.

Re: Dalvik patch for Facebook for Android

#52

Post by zurn »

MichaelGG wrote: post #43
zurn wrote: post #38

Earlier quoted context omitted.

In order to elide the out-of-line method the compiler must statically prove that it is impossible call outside the visibility of its optimization scope. I'm not familiar with Java compilers but I'd hazard a guess that to exploit this optimization (if it were possible at all) they would probably have to significantly rework their code.

For a shipped app it shouldn't be too hard to perform it across all packages involved, right?

The compiler would have to see all code that is linked with the app, including the Android runtime that calls into the app's code in various ways.

In Java land these kinds of fancy optimizations usually happen in the JVM JIT at runtime. Would this help the size of those tables in Android's Dalvik/dexopt setup? In any case you can't ship a custom version of Dalvik with your app.

Re: Dalvik patch for Facebook for Android

#53

Post by georgemcbay »

Xuzz wrote: post #36
georgemcbay wrote: post #29

Earlier quoted context omitted.

Three million methods? Having both programmed for Android and having used the Facebook App for Android, I find it very difficult to believe that app has anywhere near 3 million methods, even if each one is basically a one-liner. If the number is correct, that really is some kind of crazytown code.

I think the actual number is 65536 or similar — the 3 million may have been a misquote by TechCrunch.

Still seems like a ridiculous number, though of course far less ridiculous especially for Java code with its legacy of setters and getters for even basic properties and FactoryOfFactoriesFactory classes.

Re: Dalvik patch for Facebook for Android

#54

Post by buster »

From my experience the FB app is one of the worst apps on my phone. The messaging notifications are crap, the reloading of my feed is crap (aka doesn't load notifications or in an unpredeictable manner). I have much more complex apps on my phone which show no such behaviour, yet it somehow is a Dalvik problem? Mhhh... How many Twitter apps and FB apps are there that are snappy and behave well ( = much better then the FB app!)..

Re: Dalvik patch for Facebook for Android

#55

Post by mich41 »

MichaelGG wrote: post #43
zurn wrote: post #38

Earlier quoted context omitted.

In order to elide the out-of-line method the compiler must statically prove that it is impossible call outside the visibility of its optimization scope. I'm not familiar with Java compilers but I'd hazard a guess that to exploit this optimization (if it were possible at all) they would probably have to significantly rework their code.

For a shipped app it shouldn't be too hard to perform it across all packages involved, right?

It becomes hard when the app uses reflection. When you want to remove some method foo, you not only have to make sure that it isn't referenced by some code, but also make sure that no code is passing the string "foo" to reflection API. This may be hard for many apps and is undecidable in general.

Actually, even in plain, reflection-less java it may be quite complicated because subclass methods can be invoked by superclass-typed variables. For every method invocation you need to find all possible subclasses whose objects can be assigned to variable on which the method is invoked. You need to know which subclasses are ever passed as superclass/interface arguments to methods. You need to know which subclasses are assigned to superclass/interface member/static variables. You need to know which subclasses are stored in superclass collections. And so on.

Re: Dalvik patch for Facebook for Android

#56

Post by kalleboo »

pbiggar wrote: post #22

This seems like it will paint the Android core developers into a corner, supporting this particular hack for years to come, like the way Microsoft had to for Windows. If I were android core developers, this would not be a good day.

In addition to what others said about this only applying to already dead versions of Android, this is one of the upsides of distributing apps online. Nobody is installing an old boxed copy of Facebook 2.0 - google can just ask facebook to remove the hack when they've fixed it, and instantly everyone who installs the app it has the fix, and for anyone else the update is a tap away. This wasn't possible with the hacks to keep old Windows/DOS apps running.

Re: Dalvik patch for Facebook for Android

#57

Post by mborsuk »

jmillikin wrote: post #19

According to http://techcrunch.com/2013/03/04/facebook-google-dalvik/ and http://venturebeat.com/2013/03/04/google-facebook-android/ , the specific limit being hit was a cap of three million methods per instance of the Dalvik VM. Wisdom of a three-million-method app aside, I wonder why they didn't fix this in the compilation toolchain rather than by poking around in native memory areas during app startup. Facebook wr…

I'll just paste the same thing here that I wrote in response to commenters on FB misunderstanding the problem:

"Even though I disagree with most of your comments (to the extent that it is any more than unrelated editorializing) and everyone talking about "too many methods" etc, the actual bug that was triggered is here and provides a test case: https://code.google.com/p/android/issues/detail?id=22586 showing that multiple interface inheritance triggers this easily."

Issue 22586 - android - Dexopt fails with "LinearAlloc exceeded" for deep interface hierarchies

https://code.google.com/p/android/issues/detail?id=22586

Re: Dalvik patch for Facebook for Android

#58

Post by kristianp »

no_more_death wrote: post #41

Uninstalled. I checked, and Facebook took up more memory than any other application I have installed, even more than TSF Shell. (By the way, a MUCH more "feature-rich," useful, and snappy app than facebook!) Facebook isn't doing anything comparable to what TSF Shell does, not for me anyway. I bet this is why my phone recently started taking 30 seconds to make a phonecall (!). I can't believe an app requires 8M RAM ju…

Yes, I'm in the same boat. On my Android 2.2 phone (HTC Legend) it is hard to fit some current apps and facebook is a system app so I can't uninstall it. However I can uninstall the updates, so my facebook is the original factory version. I won't be trying out this latest version.

It would be interesting to know what it is doing to be that complex. I'm guessing lots of third party libraries for ads, logging, etc?

Re: Dalvik patch for Facebook for Android

#59

Post by ansible »

nuclear_eclipse wrote: post #32
imrehg wrote: post #14

"We were certainly glad and grateful that Android is open source—otherwise, this change wouldn’t have been possible." In return, maybe you could open-source some of your app, for example?

We do already open source a wide variety of projects, for those who aren't already aware: https://github.com/facebook

We use flashcache on one of our build servers. It has been good so far. Thanks!

Re: Dalvik patch for Facebook for Android

#60

Post by mbetter »

gingerjoos wrote: post #39

>>> It seemed like we would have to choose between cutting significant features from the app or only shipping our new version to the newest Android phones (ICS and up). Neither seemed acceptable. We needed a better solution. This . "There has to be a better solution", a quality which defines hackers - is it not? It's that pushing the boundaries for the sake of getting things done that drive progress, isn't it? It's t…

Problem: You can't develop your film outside at night because the moon is too bright.

Solution: Destroy the moon.

Post reply on HN