2015-07-14 10 views
5

Ho un APK Android che utilizza una libreria nativa (snappydb). Le librerie native occupano molti spazi, quindi voglio conservare solo il snappydb per le architetture armeabi-v7a?È sicuro conservare solo armeabi-v7a per un apk per Android.

So che non è sicuro al 100% rimuovere snappydb per altre architetture, quindi la mia domanda è: quanto è pericoloso? (quanti dispositivi/utenti ho perso?)

Solo per riferimento, la versione sdk minima supportata dal supporto dell'app è 16 (JELLY_BEAN).

+0

La tua domanda non è chiara: la tua formulazione è imprecisa e poco chiara. Vuoi dire che vuoi solo compilare e raggruppare 'snappydb' per armeabi-v7a, e non includere la stessa lib per altre architetture? Cosa intendi con "rimuovere altre lib" native? Quali altre librerie? – Laogeodritt

+0

Ci scusiamo per l'inconveniente, voglio dire non includere 'snappydb' per altre architetture. – huangcd

+0

Lascerò questo come commento perché non posso dare una risposta ben supportata. Per quanto ne so, quasi tutti i dispositivi Android sono ARMv5 o ARMv7 (non sono sicuro quanti siano v5). Ci sono un paio di tablet x86 (Intel) a partire dall'anno scorso, e penso che alcuni dispositivi MIPS abbiano iniziato a venire i nostri anni fa, ma non ne sento molto e, a mia conoscenza, non sono popolari. Sarei sorpreso se il non-ARM fosse più del 5-10% della quota di mercato (ma ancora una volta, questo è aneddotico, non ho dati in questo momento). Si noti tuttavia che alcuni dei dispositivi x86 sono dispositivi Samsung. – Laogeodritt

risposta

0

probabilmente non guadagnare troppo dall'ottimizzazione braccio-V7A, e attualmente non v'è alcun motivo valido per includere 64-bit di compilazione . Ma i proprietari di MIPS e X86 ti ringrazieranno se manterrai i loro dispositivi coperti.

+0

Ciao Alex, cosa intendi con "non guadagnare troppo dall'ottimizzazione di arm-v7a"? – huangcd

+0

Normalmente, il codice nativo compilato per ** armeabi ** funzionerà correttamente su dispositivi che supportano ** armeabi-v7a **, ma non altrimenti. Gli algoritmi di crunching dei numeri possono essere molto più efficienti quando compilati per ** armeabi-v7a **, ma questo è molto meno rilevante per la libreria di database. –

+0

Grazie @ alex-cohn – huangcd

2

Io suggerisco di usare productFlavors di Gradle di produrre diversi APK per ABI, come alcuni ABI può includere qualche ottimizzazione codice assembly (SSE4, SSE5, Braccio Neon ecc,)

android { 
    ... 

    flavorDimensions "abi", "version" 

    productFlavors { 
     freeapp { 
      flavorDimension "version" 
      ... 
     } 

     x86 { 
      flavorDimension "abi" 
      ... 
     } 
    } 
} 

Oppure, se si sta utilizzando sperimentale plug Gradle 'com.android.tools.build:gradle-experimental:0.1.0'

android.productFlavors { 
     create ("arm7") { 
      ndk.abiFilters += "armeabi-v7a" 
     } 
     create ("arm8") { 
      ndk.abiFilters += "arm64-v8a" 
     } 
     create ("x86-32") { 
      ndk.abiFilters += "x86" 
     } 
     // for detailed abiFilter descriptions, refer to "Supported ABIs" @ 
     // https://developer.android.com/ndk/guides/abis.html#sa 
     // build one including all productFlavors 
     create("fat") 
    } 
+0

Molto vero. Il costo del jiggling con poche architetture è minimo, ma in caso contrario per alcuni utenti non è possibile utilizzare l'app. –

+0

@ nabil-hachicha diversi APK per ABI è davvero una buona soluzione per Google Play. Tuttavia, per altri mercati che non supportano più apk, sembra difficile trovare un modo per distribuire correttamente la mia app. E l'aggiornamento è anche un problema difficile – huangcd