130

I am involved in the development of Android application which is a rather "thick" mobile client for a Web service. It heavily communicates with the server but also has a lot of inner logic too. So, I decided to use some features of Google Guava library to simplify development process. Here is a list of features I'm very interested in: immutable collections, base utils, collection extensions, functional programming sugar and idioms (common.collect and common.base), primitives utilities (common.primitives), hashing utilities (common.hash), concurrent utils (futures and AsyncFunction). Things I don't want to use in Android: common.cache (see question below), common.eventbus (we have better Android specific libs for this, such as Otto), common.io (we can use okio for Android now).

I read that using Guava for Android can significantly slow down compilation process and also decrease the whole runtime performance: Bad performance with Guava Cache on Android (in this case it is reasonable and there is no need to use Guava's cache for Android) and Adding Google Guava to Android project - significantly slows down the build

So, is it efficient to use Guava library in Android project or this library is designed to be used only for the server-side development, and I should go with standard solutions? Any explanations will be very appreciated.

Ümañg ßürmån
  • 9,695
  • 4
  • 24
  • 41
Oleksandr Karaberov
  • 12,573
  • 10
  • 43
  • 70
  • 2
    "_But I heard that [...]_" what are your sources? – jlordo Feb 20 '13 at 11:31
  • IMHO, there are good answers in the questions you have linked, and you are asking nothing else. – jlordo Feb 20 '13 at 11:37
  • @jlordo In these questions answers and theme are too specialised. I need more common analysis and explanation from experts – Oleksandr Karaberov Feb 20 '13 at 11:39
  • 2
    It's safe to use, but of course: You need to check for each class of the library if it fit's your needs. Guava Cache was implemented for Server side (which is propably written in the docs), so don't use it on android. Build time is usually not really a problem, run time is more important. – John Smith Feb 20 '13 at 11:48
  • 4
    http://www.appbrain.com/stats/libraries/details/guava/google-guava indicates that Guava is used in a _lot_ of Android apps. – Louis Wasserman Feb 20 '13 at 18:06
  • Guava-jdk5 is included in the google-API-services libraries; it has guava's ListenableFutures, and since a lot of apps are targeting Google's platform, you get a lot of these things for free (or as added backage) that you might as well make use of. I initially excluded the jdk5 version, because it conflicted with normal Guava, but I found it had everything I really needed -- so i tossed guava. – NameSpace Jun 25 '15 at 09:02
  • 3
    Shame that new answers cannot be posted (I for one voted for reopening). There are some real and interesting issues e.g. related to the [65k method limit](http://stackoverflow.com/questions/14978699/is-it-a-good-idea-to-use-google-guava-library-for-android-development#comment51472335_14979043) that deserve attention. – Jonik Nov 05 '15 at 12:15

1 Answers1

124

(Too big for comment, so I post an answer.) Personally I use whole Guava library in every Java project and when I don't have significant and properly profiled performance problems. If you do have, for example, memory concerns like in Android environment, you can use ProGuard to get only these parts of Guava you really need.

Moreover, there are many Android apps using Guava - not only small ones, i.e. Google Search and Youtube, which directly come from Google.

(You should also see compatibility note.)

Samir Alakbarov
  • 1,120
  • 11
  • 21
Grzegorz Rożniecki
  • 27,415
  • 11
  • 90
  • 112
  • Thanks - that is the answer I needed.So if I for instance will use only collections, functional idioms, ranges (because cache and concurrent features designed for server side dev.) - I won't have an overhead at all? – Oleksandr Karaberov Feb 20 '13 at 11:53
  • If you 'remove' them using ProGuard you won't. – anthonyms Feb 21 '13 at 06:38
  • 111
    I was curious about Guava & **APK size**. Simple testing revealed the following: "Hello world" & not much else (debug): **27KB**; "Hello world" with Guava (15.0) dependency and minor Guava usage (debug): **705KB**; the same, release build, optimised with ProGuard: **22KB**. This test, together with having used Guava while developing a large real-world app, confirmed my belief that Guava is totally fine on Android too! – Jonik Jan 05 '14 at 16:15
  • 2
    Also, if you run into problems getting ProGuard to work with the Guava dependency, see [this answer](http://stackoverflow.com/questions/9120338/proguard-configuration-for-guava-with-obfuscation-and-optimization/20935044#20935044) I just posted. – Jonik Jan 05 '14 at 16:18
  • 2
    Just an observation on the link for top apps using Guava. I'm a heavy user of Facebook, Spotify, Google Translate and they are not the fastest apps running out there right? In fact they're bad. FB I don't need to tell you, Spotify with latest updates made me go from Premium to Grooveshark. Facebook and Spotify really struggle with user experience on mobile, and curiously I find Google Translate has slowed down a lot for such a simple thing it does. Now I haven't tried Guava. But I'll think twice before I do. This is the link: http://www.appbrain.com/stats/libraries/details/guava/google-guava – albertpeiro Mar 12 '14 at 12:52
  • @albertpeiro FB, Spotify and Google Translate with lots of data. Images, Streaming Music and sending over large pieces of text to translate. I'd doubt that Guava is the bottleneck! As long as you play ball with the GC and use your memory efficiently, Guava cant really hit your app performance. – Vikram Bodicherla Apr 07 '14 at 01:24
  • Fair point @VikramBodicherla. You are probably right, as said it was only an observation, maybe a biased one as I'm casually disappointed at those apps. In my experience playing with GC in Android is not so much fun and I prefer cutting trees from the roots instead of letting them grow a bit if you get what I mean. Memory is not controllable, so act like if it weren't - and that will determine your design, yes. – albertpeiro Apr 07 '14 at 21:45
  • Facebook uses Guava for its FB android app: https://code.facebook.com/videos/223453284445682/how-facebook-builds-facebook-for-android-mobile-devcon-2013/ – Daniel B Feb 21 '15 at 16:51
  • 7
    Something to be aware of with Guava is the Android 65k method limit, as Guava lib contains over 13k methods. Reaching the limit *shouldn't* be a problem as you can go [Multidex](https://developer.android.com/tools/building/multidex.html) (but I have no first hand experience of that). See [related discussion](https://github.com/futurice/android-best-practices/issues/26) at Futurice Android best practices guide. – Jonik Aug 02 '15 at 09:55
  • 3
    @Jonik I don't know why I don't see more people mentioning that. Sure you have proguard, but is it really worth it? What about debug builds, you'll have to run proguard on those as well. I don't consider multidexing to be a solution either. It adds easily 2-5 seconds loading time to the app. In really big projects it's not that hard to hit the 65k limit. Imo Guava is such a monolith that I'm not really a fan. I'd rather use smaller, focused libraries that bring in a specific set of functionality. – Joao Sousa Nov 05 '15 at 11:20
  • 1
    @JoaoSousa: Those are valid points*. If multidex really has such effect on load time, that's definitely something to take into consideration! Still, I do think there are cases where Guava use is well justified on Android. (*Except that running Proguard on debug builds is not necessary nor a good idea IMO.) – Jonik Nov 05 '15 at 12:13
  • @Jonik if you hit the 65k limit you'd still need proguard, right? Maybe I'm missing something. What's the alternative? – Joao Sousa Nov 05 '15 at 13:04
  • @JoaoSousa proguard won't solve all your problems. You will need to multi-dex if you exceed. – frostymarvelous Feb 17 '16 at 09:53
  • @frostymarvelous I know it won't. You'd need multi-dex if you hit the limit after proguard, but that should be rare. – Joao Sousa Feb 17 '16 at 12:08
  • @JoaoSousa indeed, that should be rare. In most cases, it's okay to use it. I was just answering your last question. – frostymarvelous Feb 17 '16 at 12:32
  • If you are using Dagger you will end up having the library in your project because they used the ImmutableList and ImmutableMap from it. – Benny Jun 16 '21 at 19:56