Wir haben eine große App, die immer im Dread-Method-Count-Limit läuft. Ich wurde gebeten, einen Weg zu finden, wie ich viel mehr tun kann, einschließlich der Unterstützung von Plugins. Auf der Suche nach Möglichkeiten, Code zu entladen, lief ich überJNI-Tipps was sagt

Klassen werden nur dann entladen, wenn alle Klassen, die mit einem ClassLoader verknüpft sind, über den Müll gesammelt werden können. Dies ist selten, aber in Android nicht unmöglich.

Dies schien zu implizieren, dass ein Plugin entladen werden kann, wenn Sie sagen,

benutze eine neueDexClassLoader für jede .jar-DateiVerweisen Sie immer nur über eine Schnittstellenreferenz auf das PluginLöschen Sie alle Kopien dieser Schnittstellenreferenz, wenn Sie fertig sind.

Also habe ich einen Testfall erstellt:

Ich habe ein paar einfache Plugins erstellt, die jeweils einen eigenen Loader verwenden.Ich habe eineReferenceQueue<ClassLoader> und erstellt schwache Verweise auf meine zwei Lader, mit dieser Warteschlange; Ich habe einen Thread erstellt / gestartet, der eine Endlosschleife durchführt und eine Warteschlange erstellt.remove() und Berichterstattung.Ich habe in ähnlicher Weise eineReferenceQueue<Class<?>> und erstellt schwache Verweise auf jedes PlugingetClass() Verwenden der Warteschlange; Ich habe einen anderen Thread erstellt / gestartet, der die Klassenreferenzwarteschlange überwacht.Ich erstelle tausend 1000x1000xARGB_8888-Bitmaps, um gc gründlich zu erzwingen.

Meine Überwachungsthreads scheinen zu funktionieren - ich habe gesehenloader2 werde gc-ed wenn ich es benutzt habeloader1 beide plugins versehentlich laden ;-) - aber ansonsten schweigen meine threads auch bei 4.3. Vermisse ich vielleicht etwas Offensichtliches in diesem Testfall, oder ist es immer noch so, dass der

Dalvik VM entlädt derzeit keine Klassen

als Google-Mitarbeiterverblasst sagt inAndroid: Wann werden Klassen vom System entladen?