handler thread published and proguard added

Author: maciej-nowak

_drafts/2019-09-16-gradle.md

@@ -111,11 +111,13 @@ android {
     productFlavors {
         free {
             dimension "version"
-            applicationId 'pl.androidcode.app.free'
+            applicationIdSuffix ".free"
+            versionNameSuffix "-free"
         }
         paid {
             dimension "version"
-            applicationId 'pl.androidcode.app.paid'
+            applicationIdSuffix ".paid"
+            versionNameSuffix "-paid"
         }
     }
 

_drafts/2019-09-23-proguard.md

@@ -0,0 +1,84 @@
+---
+layout: post
+title: "ProGuard"
+date: 2019-09-23
+categories: ["Budowanie"]
+image: build/proguard
+github: build/tree/master/proguard
+description: "Budowanie"
+keywords: "budowanie, kompilacja, konfiguracja, build, proguard, apk, properties, configuration, shrink, code, resource, keep, obfuscate, optimize, android, programowanie, programming"
+---
+
+## Wstęp
+Podczas procesu budowania projektu warto zadbać o optymalizację rozmiaru pliku wyjściowego. W tym celu `Android Gradle plugin` wykorzystuje kompilator `R8` wraz z zasadami `ProGuard`. Pozwala on na zmniejszanie rozmiaru poprzez wycinanie nieużywanego kodu i zasobów oraz zaciemnianie kodu dodatkowo utrudniającego dekompilacje. Użycie kompilatora `R8` powinno być nieodłącznym elementem budowania wersji produkcyjnej.
+
+## Pliki
+Definiowanie zasad w plikach `ProGuard` pozwala na konfigurację i nadpisanie domyślnego zachowania kompilatora `R8`. `Android Studio` dla każdego modułu automatycznie tworzy pusty plik `proguard-rules.pro` w którym definiowane są zasady dla danego modułu natomiast `Android Gradle plugin` generuje `proguard-android-optimize.txt` zawierający zasady optymalizacji użyteczne dla projektów Android takie jak np. zachowanie adnotacji. Jeśli zewnętrzna biblioteka zawiera własne zasady `ProGuard` opisane w pliku `proguard.txt` i lokalizacji `META-INF/proguard` są one również addytywnie aplikowane dla całego projektu i nie mogą zostać usunięte co może w sposób niepożądany znacząco zmienić oczekiwaną konfiguracje. Ponadto po pozytywnym zakończeniu budowania projektu w podkatalogu wariantu budowania może zostać wygenerowany plik `aapt_rules.txt` zawierający zasady `keep` dla klas opisanych w manifeście, plikach layout i innych zasobach oznaczonych jako potencjalne punkty wejścia.
+
+## Konfiguracja
+Podstawowa konfiguracja pliku `build.gradle` definuje zastosowanie lub pominięcie procesu zmniejszania, zaciemniania i optymalizacji zarówno dla kodu jak i zasobów za pomocą wpisów `minifyEnabled`, `shrinkResources` oraz `proguardFiles` dla ścieżki plików. Domyślnie są one jednak wyłączone ponieważ wydłużają czas kompilacji i mogą powodować występowanie błędów w przypadku niepełnej konfiguracji.
+
+{% highlight gradle %}
+android {
+
+    buildTypes {
+        release {
+            // Enable code shrinking, obfuscation, optimization
+            minifyEnabled true
+
+            // Enable resource shrinking, requires minifyEnabled to be applied
+            shrinkResources true
+
+            // Specify ProGuard rules files
+            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
+        }
+        debug {
+            // don't need to enable minifyEnabled and shrinkResources for debug purpose
+        }
+    }
+
+    flavorDimensions "version"
+    productFlavors {
+        free {
+            //...
+            dimension "version"
+            proguardFile 'free-rules.pro' //add extra rules for flavors
+        }
+        paid {
+            //...
+            dimension "version"
+        }
+    }
+}
+{% endhighlight %}
+
+## Zmniejszanie kodu
+Zmniejszanie kodu (`code shrinking`) wykrywa i bezpiecznie usuwa nieużywane klasy, pola i metody z aplikacji oraz zewnętrznych zależności. W wyniku tego procesu plik `APK` zawiera tylko rzeczywiście używany kod co w niektórych sytuacjach może znacznie przyczynić się do redukcji rozmiaru. Cały proces jest jednak dość kosztowny i wydłuża czas kompilacji spowodowany analizą wszystkich `punktów wejścia` tzn. klas które mogą zostać użyte przez platformę do uruchomienia aktywności czy usługi. Na ich podstawie tworzony jest `graf` wszystkich metod, zmiennych i innych klas do których aplikacja może uzyskać dostęp w czasie działania. Kod niezawierający się w grafie jest traktowany jako nieosiągalny i może zostać usunięty z aplikacji. Przykładowo aplikacja wykorzystuje tylko kilka metod oraz klas z zewnętrznej biblioteki w związku z czym pozostała jej nieużywana przez aplikacje część może zostać zignorowana i niedołączona do plików `DEX`. Punkty wejścia są określane na podstawie automatycznie generowanego pliku `aapt_rules.txt` oraz ręcznie opisanych zasad `keep` w plikach `ProGuard`. Przeważnie `R8` usuwa tylko rzeczywiście nieużywany kod jednakże w przypadku użycia mechanizmu `refleksji` czy wywołań `JNI` (`Java Native Interface`) może nie być w stanie poprawnie zbudować grafu. W takim przypadku należy dodać odpowiednie zasady `keep` do pliku `ProGuard` lub oznaczyć fragmenty kodu adnotacją `@Keep`.
+
+{% highlight pro %}
+-keep class CustomClass
+-keep class * implements CustomInterface
+-keep public class models.** { *; }
+{% endhighlight %}
+
+## Zmniejszanie zasobów
+Podczas analizy dokonywanej przez kompilator poza budowaniem grafu oraz operacjami zmniejszania, zaciemniania i optymalizacji kodu następuje także identyfikacja i oznaczanie zasobów pod kątem wykorzystania w osiągalnym kodzie. Następnie w procesie zmniejszania zasobów (`resource shrinking`) te nieużywane zostają usunięte. Zasada ta nie dotyczy jednak zasobów alternatywnych np. inna gęstość czy język. Jeśli zasoby o tej samej nazwie, typie i kwalifikatorze występują w wielu lokalizacjach wówczas tylko jeden zostaje przekazany zgodnie z priorytetem (`build type > build flavor > main > library`). W przypadku budowania różnych wariantów aplikacji mogą występować różnice w rzeczywistym użyciu zasobów. W takiej sytuacji należy określić własne zasady zachowania zasobów definiowanych w pliku `xml` w folderze `raw`. 
+
+{% highlight xml %}
+<resources 
+    xmlns:tools="http://schemas.android.com/tools"
+    tools:keep="@layout/used1, @drawable/used2"
+    tools:discard="@menu/unused1" />
+{% endhighlight %}
+
+## Zaciemnianie
+Celem zaciemniania (`obfuscation`) kodu jest redukcja rozmiaru aplikacji oraz utrudnienie procesu dekompilacji. Realizowane jest to poprzez skrócenie nazw klas, metod i pól. Konfiguracja może być definiowana w zasadach `ProGuard`.
+
+{% highlight pro %}
+-keepattributes SourceFile, LineNumberTable
+-keepattributes *Annotation*
+-keeppackagenames package.name
+{% endhighlight %}
+
+## Optymalizacja
+W trakcie procesu redukcji kodu kompilator `R8` dokonuje także analizy na głębszym poziomie w celu zastosowania optymalizacji. Jeśli kod nigdy nie osiągnie pewnego warunku wówczas cała przypisana mu gałąź może zostać usunięta. Ponadto kod może zostać także przepisany do krótszej formy, np. metoda wywoływana w jednym miejscu może zostać usunięta i jej ciało przeniesione w miejsce wywołania. Dodatkowe ustawienia optymalizacji deklarowane są w pliku `gradle.properties`.