[JAVA] Verwenden Sie ProGuard mit Gradle

Ich habe ProGuard in Gradle noch nie verwendet. Notieren Sie sich daher, wie es geht.

Hinweis: In diesem Artikel geht es * nicht * um Android. Wenn es um ProGuard in Gradle geht, gibt es nur Artikel für Android, aber das ist nicht der Fall.

build.gradle

buildscript {
    dependencies {
        classpath(
                'net.sf.proguard:proguard-gradle:6.0.3'
        )
    }
}

//Unterlassung...

jar {
    manifest {
        attributes 'Main-Class': 'rip.deadcode.Main'  //Ändern Sie entsprechend Ihrer Hauptklasse
    }
    //Machen Sie Fat Jar
    from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA'
}

task proguard(type: proguard.gradle.ProGuardTask, dependsOn: jar) {

    def javaHome = System.getProperty('java.home')

    //JAR für Shrink
    injars jar.archivePath

    libraryjars files(
            "${javaHome}/lib/rt.jar",  //Java SE-Laufzeit
            "${javaHome}/lib/jce.jar"  //Kryptomodul
    )

    //Wenn Sie Fat JAR nicht verwenden, fügen Sie abhängige Bibliotheken zu Bibliotheksjars hinzu
//    libraryjars configurations.compile.files

    //Ausgabeziel bitte nach Belieben
    outjars("${jar.destinationDir}/proguarded.jar")

    //Klassen, die nicht schrumpfen
    keep("public class ${jar.manifest.attributes['Main-Class']} { public static void main(java.lang.String[]); }")

    dontwarn("ch.qos.logback.**")
    dontwarn('afu.org.checkerframework.**')
    dontwarn("org.checkerframework.**")
    dontwarn('org.slf4j.**')
}

//ProGuard beim Zusammenbau
assemble.dependsOn(proguard)

Punkt

• Fügen Sie dem Buildscript-Klassenpfad net.sf.proguard: proguard-gradle: 6.0.3 hinzu. Die offizielle Stichprobe bezog sich auf die lokale JAR, aber das stimmt ... Ich konnte nicht herausfinden, ob dies die offizielle JAR war. Wenn Sie sich also Sorgen machen, überprüfen Sie Ihr eigenes Repository.
• Kann mit proguard.gradle.ProGuardTask ausgeführt werden. In den meisten Fällen ist das zu verkleinernde Ziel die JAR des Projekts, daher verlassen wir uns hier auf die JAR-Aufgabe.
• Geben Sie jar.archivePath in injars an, um auf die von der jar-Task generierte JAR abzuzielen.
• Sie müssen die JDK-JAR zu "libraryjars" hinzufügen. Hier wird der Pfad von JAR von JAVA_HOME abgerufen, aber wenn Sie ihn auf einer JVM ausführen möchten, die sich zur Erstellungszeit von der JVM unterscheidet, müssen Sie darauf verweisen.
• Dieses Mal sind die Bibliotheken usw. auch in einem JAR zusammengefasst. Wenn Sie die abhängige Bibliothek nicht in die Gebäude-JAR aufnehmen, müssen Sie die abhängige Bibliotheks-JAR auch in "Bibliotheks-Jars" angeben. Beim Erstellen einer Bibliothek muss jedoch nicht verkleinert werden ...
• Sie können "Outjars" verwenden, um das Ausgabeziel anzugeben. Im Beispiel wird es an derselben Stelle wie die Eingabe-JAR ausgegeben.
• Geben Sie eine Klasse an, die nicht mit "keep" verkleinert werden soll. In den meisten Fällen ist die Hauptmethode das Ziel. Wenn bei der Reflexion ein Problem auftritt, geben Sie es hier an.
• dontwarn unterdrückt Warnungen, wenn eine Klasse nicht im Klassenpfad gefunden wird. Ich frage mich, ob es normalerweise passiert, aber es gibt einige Bibliotheken wie SLF4J, die das Verhalten "wenn sich XX im Klassenpfad befindet" haben.
• Stellen Sie die diesmal erstellte Aufgabe von der Aufgabe "Zusammenstellen" abhängig, damit ProGuard zur Erstellungszeit ausgeführt wird.
• Quelle

ProGuard auf AWS Lambda

Ich möchte unnötigen Code so weit wie möglich entfernen, um die Geschwindigkeit beim Kaltstart zu verbessern, aber verschiedene Einstellungen sind erforderlich.

keep("public class rip.deadcode.bot.Application { *; }")  //Methode zur Implementierung von RequestHandler
keep("public interface com.amazonaws.services.lambda.runtime.RequestHandler { *; }")
keep("class com.amazonaws.** { *; }")
keep("class com.fasterxml.** { *; }")
keepattributes("Signature,*Annotation*")

• Es ist notwendig, in keep verschiedene Angaben zu machen
• Eine Methode, die RequestHandler implementiert. Notwendig, weil es ein Einstiegspunkt sein wird.
• Die RequestHandler Schnittstelle selbst. Es scheint, dass wenn sich der Name ändert, er nicht korrekt als Lambda-Funktion erkannt wird.
• org.apache.commons.logging. Konflikt mit dem Logger des an den Handler übergebenen Kontexts.
• com.amazonaws. ** und com.fasterxml. **. Probleme treten in Bezug auf die Serialisierung auf. Ich denke, der Umfang wird weiter verkürzt, aber ich habe viele Fehler aufgegeben, die schwer zu debuggen waren. Eine Untersuchung durch einen Experten wird erwartet. In der Tat ist es traurig, dass die Dateigröße aus diesem Grund ziemlich groß ist.
• Org.apache.commons.logging. ** undorg.joda.time. **zu dontwarn hinzugefügt. Ich möchte, dass Joda Time auf Java 8 umsteigt, aber ich frage mich, ob dies bei einem riesigen Service wie AWS nicht der Fall sein wird.

Mit RequestStreamHandler scheinen viele Teile dieser Zeit kein Problem zu sein, daher ist es möglicherweise besser, es zu verwenden, anstatt es seitlich zu tragen.