Какова хорошая стратегия при работе с Proguard, MultiDex, Testing и Product Flavors?

Question

У меня есть приложение, которые ссылаются на ~ 100K методы, с мин Sdk = 16

здесь 2 вариант для сборки:

• Proguard термоусадочной эту кучу методов только 44K методов
• Использование нескольких Dex

Теперь у меня есть некоторые общие случаи использования:

1. Запуск и отладка на эмуляторе и устройств
   • Это требует, чтобы быть как можно быстрее
2. Do тесты (интеграции и UI)
   • Это требует, чтобы запустить (у меня есть некоторые проблемы работает Эспрессо с MultiDex)
3. Сделать Prod APK
   • Это требует, чтобы быть надежным и усаживается как можно

У вас есть ребята, некоторые recommandation о стратегии сборки?

3/Prod

• Используйте Proguard, чтобы уменьшить размер APK
• Использование Proguard запутать
• Не используйте Multidex как большинство, как это возможно (это может не удалось)

2/Испытание

• Использовать minSdkVersion 21 (я прочитал, что начиная с 21 разрешить предварительную дезинфекцию, что экономит время)
• ???

1/отладки

• Использование minSdkVersion 21 (я прочитал, что, начиная с 21 позволяют предварительно Dexing, что экономит время)
• ???

Вот файл Gradle:

productFlavors { 
     dev { 
      minSdkVersion 21 
      multiDexEnabled ??? 
      testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" 
     } 
     prod { 
      // The actual minSdkVersion for the application. 
      minSdkVersion ANDROID_BUILD_MIN_SDK_VERSION 
      multiDexEnabled false 
     } 
    } 
    defaultConfig { 
     applicationId "xxxx" 
     targetSdkVersion ANDROID_BUILD_TARGET_SDK_VERSION 
     minSdkVersion ANDROID_BUILD_MIN_SDK_VERSION 
     versionCode ANDROID_BUILD_VERSION_CODE 
     versionName ANDROID_BUILD_APP_VERSION_NAME 
    } 

    buildTypes { 
     release { 
      debuggable false 
      ext.enableCrashlytics = true 
      renderscriptOptimLevel 3 
      signingConfig android.signingConfigs.release 
      zipAlignEnabled true 
      minifyEnabled true 
      // shrinkResources true 
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' 
     } 
     debug { 
      debuggable true 
      renderscriptOptimLevel 3 
      applicationIdSuffix ".debug" 
      versionNameSuffix "debug" 
      minifyEnabled false 
     } 
    } 

Answer 1

на основе предложения @Muzikant, что я в основном согласен, я кратко мое видение сегодня

• Не используйте MultiDex если можно.
  • Это может случиться, чтобы достичь число 65K с погона метод приносит с тестовыми библиотеками (поэтому используйте MutliDex)
  • Может случиться так, что MultiDex быстрее, чем процесс Proguard (для проверки), так что это может быть интересно для отладки
• Попробуйте использовать APK для тестирования, который ближе к выпуску APK

Мои рекомендации:

1. как есть 3 строит дела, просто сделать 3 buildTypes:

   • релиз
   • отладки
   • проверка (тест зарезервированное слово)

2. использование 2 ароматизаторов :

   • один для выпуска с minSdkVersion вашего приложения
   • и один для разработки, который использует более современный minSdkVersion (более быстрое построение, больше возможностей для тестирования, более простой в использовании эспрессо ...)

3. не затемнять для отладки

4. для использования Proguard во время фазы тестирования, конкретное ключевое слово в Gradle DSL необходимо testProguardFile('proguard-rules-test.pro')

5. точка сборки, которая будет использоваться для отладки с testBuildType = "validation"

6. делать обфускацию для тестирования (по крайней мере, для системы пользовательского интерфейса и функциональных тестов в вашей системе CI)

7. использовать правила оптимизации Proguard только для выпуска getDefaultProguardFile('proguard-android-optimize.txt'), для тестирования и отладки просто использовать getDefaultProguardFile('proguard-android.txt')

Архитектура моих файлов Proguard является следующее:

1. один главный файл для релизproguard-rules-release.pro, который включает в себя набор выделенных файлов Proguard с -include proguard-rules-fabric.pro

2. один второй файл для отладкиproguard-rules-debug.pro, которые включают в себя proguard-rules-release.pro

3. один третий файл для отладкиproguard-rules-dontobfuscate.pro что отключить запутывания

4. один вперед файл для тестированияproguard-rules-test.pro, которые включают в себя proguard-rules-debug.pro и в правила, необходимые для тестирования

Вот Gradle файл:

android { 
    ... 
    compileSdkVersion ANDROID_BUILD_SDK_VERSION 
    buildToolsVersion ANDROID_BUILD_TOOLS_VERSION 

    productFlavors { 
     // Define separate dev and prod product flavors. 
     dev { 
      // dev utilizes minSDKVersion = 21 to allow the Android gradle plugin 
      // to pre-dex each module and produce an APK that can be tested on 
      // Android Lollipop without time consuming dex merging processes. 
      minSdkVersion 21 
      multiDexEnabled false 

     } 
     prod { 
      // The actual minSdkVersion for the application. 
      minSdkVersion ANDROID_BUILD_MIN_SDK_VERSION 
      multiDexEnabled false 
     } 
    } 
    defaultConfig { 
     applicationId "x.y.app.z" 
     targetSdkVersion ANDROID_BUILD_TARGET_SDK_VERSION 
     minSdkVersion ANDROID_BUILD_MIN_SDK_VERSION 
     versionCode ANDROID_BUILD_VERSION_CODE 
     versionName ANDROID_BUILD_APP_VERSION_NAME 
     testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" 
    } 
    // point thge build for testing 
    testBuildType = "validation" 

    buildTypes { 
     release { 
      debuggable false 
      ext.enableCrashlytics = true 
      renderscriptOptimLevel 3 
      signingConfig android.signingConfigs.release 
      zipAlignEnabled true 
      minifyEnabled true 
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules-release.pro' 
     } 
     debug { 
      debuggable true 
      renderscriptOptimLevel 3 
      applicationIdSuffix ".debug" 
      versionNameSuffix "debug" 
      minifyEnabled true 
      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules-debug.pro', `proguard-rules-dontobfuscate.pro` 
     } 

     validation.initWith(debug) 
     validation { 
      signingConfig android.signingConfigs.release 
      debuggable false 
      renderscriptOptimLevel 3 
      applicationIdSuffix ".test" 
      versionNameSuffix "test" 
      minifyEnabled true 
      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules-debug.pro' 
      testProguardFile('proguard-rules-test.pro') 
     } 
    } 
... 
} 

Я до сих пор есть некоторые открытые точки, чтобы решить:

• Как использовать автоматические отладки подписание Android Studio для сборки проверки ? (но я не уверен в ударе)

• Мне еще нужно добавить атрибут proguardFiles в валидацию BuildType, в то время как у меня есть testProguardFile('proguard-rules-test.pro'), которые включают отладку!

Answer 2

Я использую ProGuard на обоих отладки и выпуска версии для того, чтобы избежать multidex.

моего build.gradle файл выглядит следующим образом:

debug { 
    minifyEnabled true 
    proguardFiles 'proguard_debug.pro' 
    signingConfig signingConfigs.debug 
    debuggable true 
} 
release { 
    minifyEnabled true 
    proguardFiles 'proguard_release.pro' 
    signingConfig signingConfigs.release 
    debuggable false 
} 

, чтобы minimze различия между отладкой и выпуском, а также для обеспечения надлежащей отладки отладки сборки, файл proguard_debug.pro содержит следующие инструкции Proguard:

-include proguard_release.pro 

-dontobfuscate 
-dontoptimize 
-keep class my.package.name.** {*; } 

Таким образом, я поддерживаю только одну конфигурацию proguard (в proguard_release.pro), а версия отладки построена с использованием той же конфигурации, но без обфускации кода.

Этой конфигурация решает все упомянутые вопросы:

1. не требуется multidex (поэтому не дилеммы ли использовать его с API 21+, и вы можете использовать Espresso)
2. отладки и релиз сборки являются то же самое, за исключением того, что отладочная сборка не запутывать код