51–60 of 66 posts
I wonder if this 65k limit is part of the reason they made messenger its own app?
> 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
There's a weird and arbitrary limitation in Dalvik, and the Facebook guys needed to work around it. The author makes it sound like it's some horrible sin. How about shaming the Google developers who thought 65k methods was enough for anyone? Wouldn't be good proper either, because they probably had a good reason for it. Software development isn't always stacking neat abstractions on top of each other. Sometimes you h…
I imagine the devs and management don't care much as they're going to migrate to ART soon, which I imagine does not have Dalvik's circa 2003 design decisions. Google hasn't been investing in Dalvik because its days are numbered. edit: why is this being downvoted? Do we really think ART will have these limitations? Android has been hot to get off Dalvik for many reasons and they're finally doing it in L. This is very…
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.ycombinat…
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/
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.ycombinat…
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.
Earlier quoted context omitted.
I imagine the devs and management don't care much as they're going to migrate to ART soon, which I imagine does not have Dalvik's circa 2003 design decisions. Google hasn't been investing in Dalvik because its days are numbered. edit: why is this being downvoted? Do we really think ART will have these limitations? Android has been hot to get off Dalvik for many reasons and they're finally doing it in L. This is very…
I believe ART still uses DEX as an intermediate format, so it's possible the limitations will still exist.
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.ycombinat…
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 tha…
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.
Maybe it would have helped missing out in the mandatory spying features, and providing only the required customer features. Those features really take a lot of memory: * “Record audio with the microphone … at any time without your confirmation” * Take videos and photos using the camera * Access the phone’s call log * Read data about contacts stored on the phone, “including the frequency with which you’ve called, emai…
> * “Record audio with the microphone … at any time without your confirmation” There's no way in Android to record audio with the microphone at only certain times with your confirmation. Facebook needs microphone access for video and voice calling. > * Take videos and photos using the camera The Facebook app lets you take photos and videos to post on your feed. How else would they be able to do that without camera ac…
Open gallery, click share, select facebook from list.
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.ycombinat…
There's a weird and arbitrary limitation in Dalvik, and the Facebook guys needed to work around it. The author makes it sound like it's some horrible sin. How about shaming the Google developers who thought 65k methods was enough for anyone? Wouldn't be good proper either, because they probably had a good reason for it. Software development isn't always stacking neat abstractions on top of each other. Sometimes you h…
And those limits were later changed and will surely be changed in the future as smartphones get more powerful.
All kinds of limitations are in place both on Android and iOS, particularly when it's about the amount of memory an application can access or the amount of background processing an app can make.
If you don't have these limitations, then apps could affect not only the functioning of other apps, by grabbing and keeping all available memory, but also that of the phone itself, by draining the battery in 1 hour.
That's not something that the average smartphone user would expect or desire his phone to do.
Edit: I'd also like to add, that almost anything a developer creates is usually created with some limit, or at least some expectancy of costs in mind.
For example I couldn't imagine that someone creates a memory cache, where the limit = infinite without a really good reason. Or an API where the request limit/sec for any client = infinite.
You usually develop something in a way, that reduces the cost of some computation as far as possible, and when it still causes problem - introduce hard limits. Especially when it's a whole ecosystem where many companies/developers participate.