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.
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 wonder why they cannot start from scratch a new one which has a better architecture and does not slow down your phone.
Which is surprising really, considering their Messenger app is excellent, fast and lean.
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.
They don't really do any major optimizations - they're not a real SSA/CSE/eta-form optimizer, like what llvm does to its bytecode.
