TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Solving Android’s 65K Limit: The Unbearable Lightness of Multidexing

37 pointsby shiraabelalmost 10 years ago

3 comments

Zigurdalmost 10 years ago
The first, second, and third thing I would try is dividing up the app. I suppose there are things that might be better off as a monolith, like maybe a really powerful CAD app with an in-memory data model.<p>But in most cases, where the data model is in a SQLite database, you can put that in a ContentProvider and have multiple apps access it.<p>&quot;But that&#x27;s not how we designed it.&quot; OK. OK. Just saying. It&#x27;s a mobile device. It has constraints. It also has benefits for implementers who don&#x27;t try to just steamroll the limitations.
on_and_offalmost 10 years ago
MultiDex brings its own problems with it. First it makes compilation times even worse, but it can also lead to unpredictable crashes during class load for Android &lt; 5.0. Before using it, you really need to try to get under the 65k limit instead.
offericoalmost 10 years ago
Good post. I am using Proguard and still have more than 50K methods. Good to know there are other solutions