Hacker News Reader

Comment by j_s | Hacker News Reader

Below are some choice quotes from the last time this came up almost 1.5 years ago; interesting how the peanut gallery has mellowed over time. https://news.ycombinator.com/item?id=5321634

> I can't believe an app requires 8M RAM just for method names! - https://news.ycombinator.com/item?id=5323153

> They bloated the app so badly, they would have had to monkey patch the OS to let it run at all -- https://news.ycombinator.com/item?id=5323930

> Basically these engineers decided to be really clever, painted themselves into a corner, smashed a hole in the wall so as to escape from said corner, and then bragged about how great they are. -- https://news.ycombinator.com/item?id=5322286

Also, the bug that was filed was also referenced: Dexopt fails with "LinearAlloc exceeded" for deep interface hierarchies https://code.google.com/p/android/issues/detail?id=22586

View on HN

I don't think we've mellowed, just that we have become more sympathetic to Facebook's problem. I think the reality is that the 65k method limit problem has turned into something Android Developers put squarely at Google's feet. At the time I thought, what the hell is Facebook doing? Now, I've run into the 65k limit myself on an app written by 4 people over 18 months. Sure it's not a throwaway weekend project, but that is a pretty standard app.

Google either needs to blow away the 65k method limit, or figure out a way to make Google Play Services a lot lighter. As it stands right now, if you want just push notifications you are giving up ~20k methods of your 65k limit for that alone.

Just look at this post from Jake Wharton (leading Android open source developer): http://jakewharton.com/play-services-is-a-monolith/

Slimming down Play Services just punts on the problem for a while. My view is that Google needs to do two things with this:

1) Split up the Play Services client libraries. 2) Figure out some solution for developers hitting the 65K limit.

I'm sort of assuming that the solution would come in the form of a framework or tooling that we'd have to implement. Such a solution should allow us to build fully working apps with multiple dex files, with some decent documentation. It should also work fine for debug builds without proguard, and also without bumping build times up beyond a two minutes. What's more, we should be able to split off pieces that are defined in the manifest into secondary dex files, and fire intents at them.

That, to me, seems like a reasonable response to this problem by Google. The company I work for has been hitting the limit for the last few months, and some of our other dependencies are becoming more and more expensive with newer releases (things that our users actually like.) So far, we've been able to build with a stripped down Play Services jar, but I'm not terribly happy about that approach.

Regardless, I'm not going to blame Facebook for a problem that Google caused. If Facebook can find a solution, and tell the community how they did it, I'm all ears.

I think it's quite common for developers to expect restrictions on APIs to ease as the API matures. I've also heard, anecdotally, about more developers hitting this method limit since facebook first talked about it.

Personally, I think it's silly that Android apps work one way up to 65k methods, and then require you to re-think how your app is architected due to packing limits. I think Google is just as guilty as Facebook of selfish engineering choices.

Its almost as if requirements went up over time. Google Play Services has also made the problem worse over that time.

Reply on news.ycombinator.com