I'm happy that FB is releasing these tools. I really am, but you know what I want? I want to use the FB app with out it DESTROYING my phone's usability. Anytime FB is installed on any of my devices, the device degrades day after day until the phone is virtually unusable. Next step: Uninstall Facebook. Phone is usable again. I only use Nexus devices with a lot of space on them, so ... it's not like I'm using a cheap burner.
Unfortunately, due to this problem, I've been using the FB mobile website for a very long time. Every 3-6 months I'll re-install the FB Android app in hopes that things are better, only to be let down once again.
Something tells me that all this bit flipping that FB is doing is not making things better, but worse. Sure, it may be better for the FB app, but worse for the device general. This is just my speculation at this point though ...
I think the Facebook engineers have a tendency to fix symptoms rather than causes. A lot of their engineering creations are trying to shrink the binary while they might want to consider revisiting all the dependencies that their application depends on, because that graph (and the size of their apk) is really absurdly large for such an app.
Of course, there's also the fact that such a tool is already partially obsolete because of Jack and Jill.
I've never been comfortable with the FB app phoning home so I too use the mobile website. The thing about it is that the text fields don't work well at all. Slow response times, no way to go back and correct my errors without erasing everything, and repetition of words. Over the years and across browsers the issues change but they've never worked like most other text fields on mobile websites. I wish I knew what they were doing to make them behave so poorly.
I've actually got to sit down and debug my Nexus 5. I don't run the FB app but it's degrading in the same kind of way. No real easy cause that I can see. I'm hoping adb can shed some light for me.
It's honestly pretty difficult to believe that any kind of optimization has taken place on the Facebook app. I don't have the time or the bandwidth to keep up with the updates
It is indeed out of control. They have so much stuff in their app that an update takes over 2 minutes to run on Marshmallow on a total high-end device (Snapdragon 810). No other app comes even close to taking that long to precompile for ART.
Which is surprising really, considering their Messenger app is excellent, fast and lean.
How are you handling the Gradle experimental plugin and Jack/Jill (no problems because you operate at dex level?)? I heard Proguard and other class/dex transformations were having trouble adopting the new model. Supposedly Google is working on adding extension points to the API.
We should work fine with Jack & Jill since, as you said, we work at the dex level. That said, it'll be interesting to see how our optimizations interact.
Yep, we actually see perf benefits overall with ART. Starting with redex-optimized bytecode actually helps dex2oat generate faster/smaller native code.
Actually I'm pretty interested to see what we can do with jack, since it has an API to hook into various stages of the code generation pipeline. We haven't invested much time in it yet though, since it's still in a somewhat experimental phase. Looking forward to investigating it more, though.
Maybe you could stop inventing things and .. you know .. make your software better for the end user. The Facebook app is one of the most hated apps in my household, and we've all stopped using it.
Yes, it's a well-known fact that everyone contributing to a piece of software is working on the same problem and that multiple problems can't be worked on in parallel.
He is working on the very problem we need him to work on. I'm telling him to get back to work and stop dorking around on HN, because there is tons, and tons, more work to do - and I fail to see how HN is anything but a distraction for someone working on this issue.
It's conceptually similar, but we've focused on optimizations that add value on top of ProGuard - we do use ProGuard internally, so the improvements we're seeing from ReDex are on top of that.
We get a lot of leverage out of operating on dex directly, as the final step in the build. For instance we can make really good inlining decisions because we know how many virtual registers the caller and callee use.
Do I need to care about any more configurations when using it along with proguard? Like extra lines in proguard.txt or change of mapping files when uploading to my crash reporting tools?
You shouldn't need to change your proguard config to use redex. For mapping files, the one thing that can trip people up is that we strip out source file names. After you run redex there should be a /tmp/filename_mappings.txt to do the back-mapping, similar to proguard.
If anything it sounds like it would be faster because there is less byte code which needs to be compiled.
Most likely the problem is the Facebook app has a lot of bytecode. That's probably why the wrote redex in the first place, so they would have less bytecode in their final APK.
There was a post on HN [0] a few years back about the Dalvik patch that Facebook used for their Android app, due to the large number of methods [1] the app had. This was causing issues on the older Gingerbread devices, so their solution was to modify the internals of the Dalvik VM while it was running their code to increase the buffer size.
Their ios app has over 18000 classes (https://www.reddit.com/r/programming/comments/3h52yk/someone...), so I can easily believe the android app is similarly bloated as well. (To be fair, most of the 18K classes seem to be auto generated, but that still doesn't lessen the compiler's burden.)
I heard there are something like 400 mobile developers working on the FB apps. I don't know there's any way to keep a team that size from producing bloat with every revision.
That seems like a useful engineering problem for Facebook to try to solve, rather than this bullshit rocket science optimization stuff that adds yet more complexity for only incremental gains.
My take: If you can't write it fast enough in Java, it is probably not a good mobile app candidate in the first place. The Dalvik optimizer and the JIT yield a regularly reasonable experience for me.
Unfortunately, due to this problem, I've been using the FB mobile website for a very long time. Every 3-6 months I'll re-install the FB Android app in hopes that things are better, only to be let down once again.
Something tells me that all this bit flipping that FB is doing is not making things better, but worse. Sure, it may be better for the FB app, but worse for the device general. This is just my speculation at this point though ...