Comment résoudre le problème avec Dalvik limitation de compilateur sur 64 KO méthodes?

Mon équipe et moi avons hérité d'un grand projet Android à partir d'une autre équipe. L'ensemble de l'application avec toutes les bibliothèques incluses aurait environ 35000 méthodes. Nous avons maintenant la tâche de mettre en œuvre un nouveau service dans l'application, où nous avons besoin d'utiliser des Tampons de Protocole.

Le problème est que le générés .fichier jar avec tout le nécessaire .proto fichiers crée un autre couple de 35000 méthodes, c'est 70000 méthodes. Et si vous n'êtes pas au courant, l'Android compilateur a une limitation de 65536 méthodes par .dex fichier. Nous sommes clairement au-dessus de cette limite et nous obtenons l'erreur suivante en essayant de compiler l'application:

Unable to execute dex: method ID not in [0, 0xffff]: 65536
Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536

Oui, l'architecture de l'application doit probablement être restructuré, mais cela prendra du temps. Et pour l'instant nous essayons de trouver une solution pour contourner temporairement ce problème.

Des suggestions?

  • Le Facebook de l'équipe vient de poster un message sur ce problème précis, l'autre jour. facebook.com/notes/facebook-engineering/...
  • Si votre application contient que de nombreuses méthodes (et vous ne pouvez pas vous débarrasser de certains d'entre eux), la solution sera probablement de la séparation de l'application dans les plus petites pièces qui peuvent être intégrées à séparer dex fichiers. Voir ce billet de blog pour un exemple de comment faire cela.
  • le Facebook problème était dû à un trop petit "LinearAlloc" tampon dans les anciennes versions d'Android (froyo, gingerbread). Les 64 KO de la méthode de référence limite est cuit dans le Dalvik instructions elles-mêmes.
  • Voir ce post [stackoverflow.com/questions/15209831/... [1]: stackoverflow.com/questions/15209831/...
InformationsquelleAutor Ricardo Amaral | 2013-03-15
  1. 12

    Vous pouvez utiliser un autre fichier DEX. C'est comment vous le faites:

    http://android-developers.blogspot.co.il/2011/07/custom-class-loading-in-dalvik.html

    • Voici un script pour compter le nombre de méthodes dans chaque pot: gist.github.com/toms972/c83504df2da1176a248a
    • Le message lié est un peu dépassé, il montre comment charger plusieurs fichiers DEX dans une Fourmi en fonction du projet. Il utilise également la DexClassLoader directement, une chose qui n'est plus nécessaire depuis android.de soutien.multidex vous aide à cela et il est disponible dans la bibliothèque de prise en charge (révision 21). Explication détaillée de la façon d'intégrer MultiDex dans votre app est ici: contentful.com/blog/2014/10/30/...
    • similaire à @TomSusel script, nous avons écrit un petit gradle plugin qui vous donne une meilleure idée sur votre méthode de comptage et d'où il vient sur chaque build - github.com/KeepSafe/dexcount-gradle-plugin
    InformationsquelleAutor Udinic
  2. 7

    Permettre Proguard (http://developer.android.com/tools/help/proguard.html) à supprimer les méthodes. Le protobuf générateur crée des milliers de méthodes qui ne sont jamais réellement utilisé.

    Micro-protobuffers (https://code.google.com/p/micro-protobuf/) peut également être utile.

    • J'ai été regarder dans l'aide de proguard pour cela, mais je ne suis pas sûr de la façon de l'activer pour le debug/configuration d'exécution construit au sein d'Eclipse. Tous les conseils sur ce?
    • Il y a quelques posts sur stackoverflow qui peuvent être utiles, tels que stackoverflow.com/questions/4732656/... .
    • Je n'arrive pas à trouver quoi que ce soit sur cette question, qui mentionne l'utilisation de proguard avec le debug/run configurations au sein de l'Éclipse...
    InformationsquelleAutor fadden
  3. 4

    Carré eu des problèmes similaires et ils ont construit Fil à traiter avec la méthode de l'explosion provoquée par protobufs. Ils prétendent avoir tué 10,000 méthodes.

    InformationsquelleAutor Abhay Buch
  4. 4

    Dans les versions de Google Play services avant 6.5, vous avez eu à compiler l'ensemble des Api dans votre application. Dans certains cas, ce faisant, il est plus difficile de garder le nombre de méthodes dans votre application (y compris le cadre d'Api, de la bibliothèque de méthodes, et votre propre code) sous la limite de 65 536.

    À partir de la version 6.5, vous pouvez au lieu de compiler de manière sélective Google Play service Api dans votre application. Par exemple, pour inclure uniquement les Google Fit et Android Wear Api, remplacez la ligne suivante dans votre construction.gradle fichier:

    compile 'com.google.android.gms:play-services:6.5.87'

    avec ces lignes:

    compile 'com.google.android.gms:play-services-fitness:6.5.87'
compile 'com.google.android.gms:play-services-wearable:6.5.87'

    pour plus d'information, vous pouvez cliquer sur ici

    InformationsquelleAutor akshay
  5. 1

    Si c'est la première utilisation de tampons de Protocole, vous pourriez envisager d'autres JavaME
    les implémentations c'est à dire

    il y a les autres personnes mentionnées dans Tiers add-ons. Si n'avez pas utilisé l'un d'eux, mais ils semblent être plus petits et n'ont pas toutes les méthodes créées par le protocole standard de tampons.

    InformationsquelleAutor Bruce Martin
  6. 1

    Nous avons récemment ajouté Nano Protobufs pour Android, ce qui réduit considérablement le nombre de méthodes générées.

    • Plus de détails, s'il vous plaît, si vous le fera?
    • Oui, s'il vous plaît... Plus de détails sur exactement ce que nous avons à faire pour commencer à utiliser Nano Protobufs...
    InformationsquelleAutor Wink Saville
  7. 0

    Si vous utilisez eclipse c'est le plus facile de travailler autour de Cliquez Ici!

    InformationsquelleAutor mboy