Службы Google Play (поставщик плавного определения местоположения) значительно увеличивают размер приложения?

Я только что добавил в свое приложение информацию о местоположении на основе простой функции "получить последнее известное местоположение", описанной здесь, который использует объединенный поставщик местоположения.

Я пытался сделать свое приложение как можно более легким, поэтому разочаровывает то, что в процессе добавления простого определения местоположения размер моего apk увеличился с 185 КБ до 2,1 МБ. Сам фактический код, конечно, не увеличился на эту величину, поэтому я предполагаю, что он откуда-то извлекает большую библиотеку.

Есть идеи, как я могу снова уменьшить размер apk?

Спасибо.


android google-play-services geolocation fusedlocationproviderapi
person drmrbrewer    schedule 27.12.2014    source источник
comment
Библиотека сервисов Google Play продолжает расти и расти, и это, безусловно, увеличит размер вашего приложения. Включите proguard, как предлагает @Mike, но чем больше классов из сервисов Google Play вы используете, тем больше будет ваше приложение.   -  person rupps    schedule 27.12.2014

Ответы (2)


arrow_upward
3
arrow_downward

Пара вещей может помочь:

  1. Используйте ProGuard, чтобы удалить неиспользуемый код. , чтобы избежать дополнительного времени сборки и включить выпускные сборки.

  2. Используйте новое детальное управление зависимостями, представленное в Play Services 6.5< /а>. Вы можете выбрать, какие из компонентов Play Services вам нужны, и исключить остальные. Из документации:

В версиях сервисов Google Play до 6.5 вам нужно было скомпилировать весь пакет API в свое приложение. В некоторых случаях это усложняло удержание количества методов в вашем приложении (включая API-интерфейсы фреймворка, библиотечные методы и ваш собственный код) в пределах 65 536.

Начиная с версии 6.5, вместо этого вы можете выборочно скомпилировать сервисные API Google Play в свое приложение.

Список отдельных API, которые вы можете включить, можно найти здесь.

person stkent    schedule 27.12.2014
comment
Отличный ответ. Сначала я попробовал (2), заменив компиляцию «com.google.android.gms:play-services:6.5.+» компиляцией «com.google.android.gms:play-services-location:6.5.+» в зависимостях. часть моего файла build.gradle. Это уменьшило размер SDK до 1,5 млн... хорошо, но не блестяще. Затем я также попробовал (1), заменив minifyEnabled false на minifyEnabled true в части buildTypes›release build.gradle. Это уменьшило размер SDK до 880K. Все еще намного больше, чем мои первоначальные 185K, но намного лучше, чем 2,1M. Спасибо! Я думаю, это примерно так низко, как я могу пойти? - person drmrbrewer; 27.12.2014
comment
Я думаю, что да. Здесь на SO есть еще один открытый вопрос, который указывает на то, что включение сервисов Play, а затем не использование какого-либо API, по-прежнему не позволяет ProGuard удалить весь код сервисов Play. Я не уверен, почему это так. - person stkent; 27.12.2014

arrow_upward
2
arrow_downward

Эта проблема должна быть решена при использовании proGuard перед публикацией приложения. Что я и Android настоятельно рекомендую вам. proGuard поставляется с Android SDK и запутывает (чтобы его было труднее читать после обратного проектирования вашего приложения) и сжимает ваш код. Это означает, что он убивает мертвый код, который вы не используете, и вы используете right now всего лишь небольшую часть сервиса Google Play. Чем больше классов вы используете, тем больше будет ваше приложение. Логично, что Proguard может отрезать только неиспользуемый код. Надеюсь, поможет

Подробнее об использовании proguard в Android можно прочитать здесь: http://developer.android.com/tools/help/proguard.html

И что он вообще здесь делает: http://proguard.sourceforge.net/

person Mike    schedule 27.12.2014
comment
Спасибо за этот ответ. Это точно, и мне жаль, что я могу отметить только один ответ как правильный, но в ответе stkent было два предложения, каждое из которых само по себе помогло уменьшить размер. - person drmrbrewer; 27.12.2014
comment
Но я был почти на час быстрее, чем он..... И я думаю, что вы все равно будете использовать proguard, поэтому другое предложение на самом деле не имеет большого значения, потому что оно делает то, что proguard делает автоматически.... они оба работали только потому, что вы сначала сделал второй. Если бы вы использовали proguard напрямую, вы бы логически достигли того же размера, что и сейчас ... так что мне тоже сейчас плохо ;) @drmrbrewer - person Mike; 27.12.2014
comment
Использование гранулярных зависимостей может избавить вас от необходимости включать ProGuard для отладочных сборок — в противном случае он будет принудительно включен, когда вы достигнете предела методов в 64 КБ, что ускорит процесс сборки во время разработки, поэтому совместное использование обоих методов имеет преимущество. - person stkent; 27.12.2014
comment
@stkent, ты прав, это может быть важно, если ты действительно достигнешь предела. Это произойдет только в том случае, если вы используете большие внешние библиотеки. Но в любом случае я бы тоже придерживался этого: developer.android.com/tools/building /multidex.html - person Mike; 27.12.2014