使用Google Guava库进行Android开发是一个好主意吗?

Ole*_*rov 122 java android guava

我参与了Android应用程序的开发,这是一个相当"厚"的Web服务移动客户端.它与服务器进行了大量的通信,但也有很多内部逻辑.所以,我决定使用Google Guava库的一些功能来简化开发过程.以下是我非常感兴趣的功能列表:不可变集合,基本工具,集合扩展,函数编程糖和习语(common.collectcommon.base),原语实用程序(common.primitives),散列实用程序(common.hash),并发工具(期货和AsyncFunction).我不想在Android中使用的东西:( common.cache见下面的问题),common.eventbus(我们有更好的Android专用库,比如Otto),common.io(我们现在可以使用okio for Android).

我读到使用Guava for Android可以显着减慢编译过程并降低整个运行时性能: Android上的Guava Cache性能不佳 (在这种情况下它是合理的,不需要使用Guava的Android缓存)和 添加Google Guava到Android项目 - 显着减慢了构建速度

那么,在Android项目中使用Guava库是否有效,或者这个库用于服务器端开发,我应该使用标准解决方案?任何解释都将非常感激.

Xae*_*ess 117

(评论太大了,所以我发布了一个答案.)就个人而言,我在每个Java项目中使用整个Guava库,当我没有重要且适当分析的性能问题时.例如,如果您有Android环境中的内存问题,则可以使用ProGuard仅获取您真正需要的Guava部分.

此外,还有许多使用Guava的Android应用程序 - 不仅是小型的,即谷歌搜索和Youtube,它们直接来自谷歌.

(您还应该看到兼容性说明.)

  • 我很好奇Guava&**APK size**.简单测试揭示了以下内容:"Hello world"并没有多少(调试):**27KB**; 具有Guava(15.0)依赖性和次要番石榴使用(调试)的"Hello world":**705KB**; 同样的发布版本,使用ProGuard优化:**22KB**.这个测试,以及在开发大型真实应用程序时使用Guava,证实了我相信Guava在Android上也完全没问题! (103认同)
  • 使用Guava需要注意的是Android 65k方法限制,因为Guava lib包含超过13k的方法.达到极限*不应该是一个问题,因为你可以去[Multidex](https://developer.android.com/tools/building/multidex.html)(但我没有第一手经验).请参阅Futurice Android最佳实践指南中的[相关讨论](https://github.com/futurice/android-best-practices/issues/26). (7认同)
  • @Jonik我不知道为什么我没有看到更多的人提到这一点.当然你有进步,但它真的值得吗?那么调试构建,你还必须在那些上运行proguard.我不认为multidexing是一个解决方案.它可以轻松地为应用程序添加2-5秒的加载时间.在非常大的项目中,达到65k的限制并不难.Imo Guava是如此的巨石,我不是真正的粉丝.我宁愿使用更小,更集中的库来引入一组特定的功能. (3认同)
  • 此外,如果您在使ProGuard使用Guava依赖关系时遇到问题,请参阅[此答案](http://stackoverflow.com/questions/9120338/proguard-configuration-for-guava-with-obfuscation-and-optimization/ 20935044#20935044)我刚发布. (2认同)
  • 只是观察使用番石榴的顶级应用程序的链接.我是Facebook,Spotify,谷歌翻译的重度用户,他们不是那里最快的应用程序吗?事实上他们很糟糕.FB我不需要告诉你,Spotify的最新更新让我从Premium到Grooveshark.Facebook和Spotify在移动设备上的用户体验非常困难,奇怪的是我发现谷歌翻译对于这么简单的事情已经放慢了很多.现在我还没有尝试过番石榴.但在我做之前我会三思而行.这是链接:http://www.appbrain.com/stats/libraries/details/guava/google-guava (2认同)