Android開発のベストプラクティス

FuturiceでAndroidアプリケーションの開発中に得た経験を共有したいと思います。 これらのヒントが、あなた自身の自転車の作成からあなたを救うことを願っています。 iOSまたはWindows Phoneの開発に興味がある場合は、当社のWebサイトにある関連ドキュメントに注意してください。

主なものについて簡単に

• Gradleビルドシステムと標準プロジェクト構造を使用する
• gradle.propertiesファイルにパスワードとその他の重要なデータを保存します
• 独自のHTTPクライアントを作成しないでください。VolleyまたはOkHttpライブラリを使用してください。
• Jacksonデータを使用してJSONデータを解析する
• Guavaの使用を避け、通常は節約します-65kメソッドの制限を超えないようにしてください
• スニペットを使用して、ユーザーインターフェイスを表示します。
• アクティビティを使用してフラグメントのみを管理する
• XMLマークアップはコードであるため、慎重に記述してください
• スタイルを使用して、XMLマークアップで属性が重複しないようにします
• 読みにくい1つの大きなファイルよりも複数のスタイルファイルの方が優れています。
• colors.xmlの重複を避け、短くするようにしてください-主にカラーパレットを保存するため
• diameter.xmlについても同じことが言え、そこで基本的な定数のみを定義します
• ViewGroup要素の階層を深くしすぎないでください
• WebViewの使用時にクライアント側のマイニングを避け、漏れの可能性に注意してください
• ユニットテストにはRobolectricを、UIのテストにはRobotiumを使用します
• Genymotionをエミュレーターとして使用する
• 常にProGuardまたはDexGuardを使用します

Android SDK

Android SDKをホームディレクトリまたはアプリケーションに関係のない他の場所に配置します。 一部のIDEはSDKにバンドルされており、ディレクトリにインストールできます。 これにより、IDEを更新（または再インストール）したり、別のIDEに切り替えたりすることができなくなります。 IDEを管理者ではなくユーザーとして実行する場合、管理者特権が必要になる可能性があるため、SDKを別のシステムディレクトリにインストールしないでください。

ビルドシステム

デフォルトの選択はGradleです。 Antは機能がはるかに控えめであり、その指示もコンパクトではありません。 Gradleを使用すると、次のことが簡単にできます。

• アプリケーションのさまざまなバリエーションとビルドを作成する
• スクリプトとして簡単なタスクを作成する
• 依存関係を管理して自動的にダウンロードする
• キーストアを構成する
• そして、他の多くの有用なもの。

また、AndroidのGradleプラグインは、ビルドシステムの新しい標準としてGoogleによって積極的に開発されていることにも注意してください。

プロジェクト構造

2つの一般的なオプションがあります：古いAntとEclipse ADTプロジェクト構造-または新しいGradleとAndroid Studio。 2番目のオプションを選択することをお勧めします。 プロジェクトで古い構造を使用している場合は、移植することをお勧めします。







主な違いは、新しい構造が明示的に「リソースセット」（ main



、 androidTest



）を共有していることです。これはGradleの概念の1つです。 たとえば、フォルダ「src」にフォルダ「paid」と「free」を追加すると、アプリケーションの有料版と無料版のソースコードが含まれます。



階層の最上位にapp



アプリケーションフォルダーがあると、アプリケーションが使用するライブラリー（ library-foobar



）から分離するのに役立ちます。 次に、 settings.gradle



ファイルには、 app/build.gradle



が参照できるこれらのライブラリプロジェクトのリストが格納されます。

Gradle設定

一般的な構造。 GoogleのGradle for Androidの指示に従ってください。



小規模なビルドタスク。 他のスクリプト言語（シェル、Python、Perlなど）とは異なり、Gradleでビルドタスクを作成できます。 詳細については、 Gradleのドキュメントを参照してください。



パスワード build.gradle



アプリケーションbuild.gradle



、リリースビルドの署名パラメーター（ signingConfigs



）を定義する必要があります。 次のエラーは回避する必要があります。



そうしないでください。 この情報はバージョン管理システムに表示されます。

 signingConfigs { release { storeFile file("myapp.keystore") storePassword "password123" keyAlias "thekey" keyPassword "password789" } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

gradle.properties



ファイルを作成すると、バージョン管理システムの制御下で追加されなくなります。

 KEYSTORE_PASSWORD=password123 KEY_PASSWORD=password789
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このデータは自動的にgradleにインポートされ、次のようにbuild.gradle



使用できます。

 signingConfigs { release { try { storeFile file("myapp.keystore") storePassword KEYSTORE_PASSWORD keyAlias "thekey" keyPassword KEY_PASSWORD } catch (ex) { throw new InvalidUserDataException("You should define KEYSTORE_PASSWORD and KEY_PASSWORD in gradle.properties.") } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

jarファイルをインポートするのではなく、Mavenの依存関係を使用してください。 プロジェクトに外部jarファイルを含めると、インポートが発生したバージョン（2.1.1など）で保持されます。 jarファイルを手動でダウンロードして更新するのは時間のかかる操作であり、Mavenは結果をアセンブリに含めることでこの問題を完全に解決できます。 例：

 dependencies { compile 'com.squareup.okhttp:okhttp:2.2.0' compile 'com.squareup.okhttp:okhttp-urlconnection:2.2.0' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

動的なMaven依存関係の使用を避ける動的に生成されたバージョン（ 2.1.+



など）の指定を避ける 2.1.1



などの静的バージョン番号を使用すると、予測可能な動作でより安定したビルドを作成できます。

開発環境（IDE）およびテキストエディター

好みのエディターを使用しますが、プロジェクト構造との互換性が十分でなければなりません。 エディターは個人的な選択であり、プロジェクト構造およびビルドシステムの一部として作業するのに便利なエディターを選択する必要があります。



現時点で最も人気のあるIDEはAndroid Studioです。Googleによって開発され、Gradleと統合され、デフォルトで新しいプロジェクト構造を使用し、安定したアセンブリ状態にあり、Android開発用に調整されているためです。



Eclipse ADTは必要に応じて使用できますが、古いプロジェクト構造とAntビルドシステムでデフォルトで機能するため、構成する必要があります。 Vim、Sublime Text、またはEmacsテキストエディターを使用することもできます。 この場合、コマンドラインからGradleとadbを使用する必要があります。 Eclipse Gradleと友達になれない場合は、コマンドラインを使用してビルドする必要もあります。 ADTプラグインが最近廃止されたことを考えると、Android Studioにアップグレードすることをお勧めします。



使用するものは何でも、Gradleと新しいプロジェクト構造は公式に推奨されるアプリケーション構築方法であり、エディター依存の構成ファイルをバージョン管理システムに追加しないことに注意してください。 たとえば、Ant build.xml



ファイルを追加しないでください。 また、Antでビルド構成を変更するときは、 build.gradle



を更新することを忘れないでください。 一般に、他の開発者に異常なツールの使用を強制しないでください。

図書館

Jacksonは、オブジェクトをJSONに、またはその逆に変換するためのJavaライブラリです。 Gsonはこの問題を解決する最も一般的な方法ですが、私たちの観察によると、JacksonがJSONを処理する代替方法（ ストリーミング 、RAMのツリーモデル、および従来のJSON-POJO形式の通信）をサポートするため、生産性が向上します。 ただし、ジャクソンのサイズはGSONよりも大きいため、GSONを使用して65kの制限を回避することをお勧めします。 他のオプションはJson-smartとBoon JSONです。



ネットワーキング、キャッシュ、および画像。 独自のクライアントを開発する前に考慮する必要があるバックエンドサーバーへの生産的なクエリのための実証済みのソリューションがいくつかあります。 ボレーまたはレトロフィットを使用します。 Volleyは、イメージをロードおよびキャッシュするためのツールも提供します。 Retrofitを選択した場合、画像をアップロードまたはキャッシュするにはPicassoを使用し、効率的なHTTP要求を取得するにはOkHttpを使用します。 これらのライブラリ（Retrofit、Picasso、OkHttp）はすべて1つの会社によって開発されているため、互いに完全に補完されます。 OkHttpはVolleyでも使用できます。



RxJavaは、リアクティブプログラミング、つまり非同期イベントを処理するためのライブラリです。 これは、その異常性と混同される可能性がある強力で有望な概念です。 このライブラリをアプリケーション全体のアーキテクチャの基盤として使用する前に、慎重に検討することをお勧めします。 RxJavaを使用して作成されたプロジェクトがあり、Timo Tuominen、Olli Salonen、Andre Medeiros、Mark Voit、Antti Lammi、Vera Izrailit、Juha Ristolainenのいずれかから支援を求めることができます。 このことについて、ブログでいくつかの記事を書きました： [1] 、 [2] 、 [3] 、 [4] 。



Rxを使用したことがない場合は、APIを使用して開始してください。 または、クリックして検索フィールドに入力するなどの単純なユーザーインターフェイスイベントを処理するために使用することから開始できます。 Rxを使用するスキルに自信があり、Rxをアーキテクチャ全体で使用したい場合は、最も難しい点に関するJavadocを作成してください。 RxJavaを使用した経験のないプログラマーはあなたをののしり、プロジェクトのサポートに大きな問題があるかもしれないことに注意してください 。 彼があなたのコードとRxを理解できるようにしてください。



Retrolambdaは、Androidおよびその他のプラットフォームでラムダ式を使用するためのJavaライブラリで、バージョン8以下のJDKを使用します。 特にRxJavaなどの機能的なスタイルを使用する場合、コードをコンパクトで読みやすくするのに役立ちます。 使用するには、JDK8をインストールし、プロジェクト構造を説明するダイアログのAndroid StudioのSDKへのパスで指定し、環境変数JAVA8_HOME



およびJAVA7_HOME



を設定してbuild.gradle



プロジェクトのルートbuild.gradle



書き込みます。

 dependencies { classpath 'me.tatarka:gradle-retrolambda:2.4.1' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各モジュールのbuild.gradle



ファイルに追加します

 apply plugin: 'retrolambda' android { compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } retrolambda { jdk System.getenv("JAVA8_HOME") oldJdk System.getenv("JAVA7_HOME") javaVersion JavaVersion.VERSION_1_7 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Android Studioはラムダ式の構文のサポートを開始します。 以前にそれらを使用したことがない場合は、次のステートメントを理解することから開始できます。

• 1つのメソッドを持つインターフェイスはラムダ式と互換性があり、記述を簡素化できます
• パラメーターの記述方法がわからない場合は、通常の内部クラスを作成し、Android Studioでラムダ式に変換します。

dexファイルをメソッドの数に制限し、多数のライブラリを使用しないようにしてください。 Androidアプリケーションは、dexファイルにパッケージ化されている場合、65,536個の参照メソッド[1] [2] [3]の厳密な制限があります。 制限を超えると、致命的なコンパイルエラーが発生します。 そのため、可能な限り最小限のライブラリを使用することをお勧めします 。また、dexファイル内のメソッドの数を計算するユーティリティに注意してください。 制限を超えずに使用できるライブラリのセットを決定するのに役立ちます。 13kを超えるメソッドを含むGuavaライブラリを使用する場合は特に注意してください。

アクティビティとフラグメント

Android開発者コミュニティ（Futuriceなど）では、フラグメントとアクティビティの使用に関してAndroidアプリケーションのアーキテクチャをどのように構築するのが最適であるかについてのコンセンサスはありません。 Squareは、主にビューを使用してアーキテクチャを構築するためのライブラリをリリースし、フラグメントの必要性を最小限に抑えましたが、この方法はまだ一般的に受け入れられていません。



Android APIの開発履歴に基づいて、画面のユーザーインターフェイスの一部としてフラグメントを検討できます。 つまり、フラグメントは通常UIを指します。 アクティビティは通常、コントローラーと見なされます。ライフサイクルの観点から、および状態管理にとって特に重要です。 ただし、別の方法もあります。アクティビティはUI（画面間の状態遷移）に関連する機能を実行でき、フラグメントはコントローラーとしてのみ使用できます。 フラグメントのみ、またはアクティビティのみ、またはビューのみの使用に基づくアーキテクチャには、多くの欠点があることに留意して、バランスの取れた決定を行うことをお勧めします。 以下に、注意を払うべきいくつかのヒントを示しますが、重要なことです。

• 「 ネストされた 人形」などのエラーが表示される可能性があるため、ネストされたフラグメントの集中的な使用は避けてください。 ネストされたフラグメントは、意味がある場合（たとえば、画面のフラグメント内で水平にスクロールするViewPagerのフラグメント）、または何をしているのかをよく理解している場合にのみ使用してください。
• アクティビティにコードを入れすぎないでください。 可能であれば、主にAndroid APIのライフサイクルやその他の重要な機能を管理するために、アプリケーションに存在する軽量コンテナとして使用します。 フラグメントが1つだけのアクティビティは、単なるアクティビティよりも優れています-ユーザーインターフェイスに関連するコードをフラグメントに配置します。 これにより、タブを使用してレイアウトに配置したり、複数のフラグメントを使用してタブレット画面に配置する必要がある場合に、再利用できます。 意図的に行わない限り、関連するフラグメントなしでアクティビティを作成しないでください。
• たとえば、アプリケーションの内部操作を意図的にIntentメカニズムに依存するなど、AndroidレベルのAPIを悪用しないでください。 Androidオペレーティングシステムまたは他のアプリケーションに影響を与え、エラーやフリーズを引き起こす可能性があります。 たとえば、アプリケーションがアプリケーションパッケージ間の内部通信にインテントメカニズムを使用している場合、オペレーティングシステムをロードした直後にアプリケーションを開いた場合、数秒でフリーズする可能性があることが知られています。

Javaパッケージアーキテクチャ

AndroidアプリケーションのJavaアーキテクチャは、 Model-View-Controllerパターンに似ています 。 Androidでは、 フラグメントとアクティビティはConrollerのクラスを表します 。 一方、これらはユーザーインターフェイスの一部であるため、ビューの一部でもあります。



そのため、フラグメント（またはアクティビティ）をコントローラーまたはビューに一意に関連付けることは困難です。 独自のfragments



パッケージに入れた方が良いでしょう。 この場合のアクティビティは、最上位パッケージに残すことができます。 2つまたは3つ以上のアクティビティがある場合は、それらを別のパッケージに入れることもできます。



一方、アーキテクチャは通常のMVCのように見え、 models



パッケージにはAPI応答からJSONパーサーによって生成されたPOJOが含まれ、 views



パッケージには作成者のビュー、通知、アクションバーに関連付けられたビュークラス、ウィジェットなどが含まれますd。 アダプタは、データとビューの間のリンクです。 通常はgetView()



メソッドを介してエクスポートされたViewを使用するため、ビューのアダプターの子としてアダプターを含めることができviews



。



一部のコントローラークラスはアプリケーション全体で使用され、Androidオペレーティングシステムで直接動作します。 これらは、 managers



パッケージに配置できます。 DateUtilsなど、データを処理するためのさまざまなクラスをutils



パッケージに格納できます。 バックエンドとのやり取りを担当するクラスは、 network



パッケージにあります。



上記のすべてのパッケージ、バックエンドからユーザーインターフェイスへの順序：

 com.futurice.project ├─ network ├─ models ├─ managers ├─ utils ├─ fragments └─ views ├─ adapters ├─ actionbar ├─ widgets └─ notifications
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

資源

命名。 type_foo_bar.xml



ように、オブジェクト名をファイル名のプレフィックスとして使用する規則に従ってください。 例： fragment_contact_details.xml



、 view_primary_button.xml



、 activity_main.xml



。



XMLマークアップ構造。 XMLマークアップをフォーマットする方法がわからない場合は、次のヒントが役立つ場合があります。

• 1行に1つの属性、4つのスペースでインデント
• android:id
  
  
  
  常に最初に来る
• android:layout_****
  
  
  
  冒頭の属性
• 最後のstyle
  
  
  
  属性
• 属性の順序付けと追加を容易にするために、終了タグ/>
  
  
  
  がその行にあります。
• android:text
  
  
  
  を手動でandroid:text
  
  
  
  代わりに、Android Studioの視覚属性エディターを使用できます。

経験からわかるように、 android:layout_****



属性はXMLマークアップで定義する必要があり、他のandroid:****



属性はXMLスタイルで定義する必要があります。 この規則には例外がありますが、全体的にはうまく機能します。 ポイントは、マークアップ属性（位置、マージン、サイズ）とコンテンツ属性のみをマークアップファイルに保存することであり、ビジュアルコンポーネントの表示詳細（色、インデント、フォント）はスタイルファイルにある必要があります。



例外：

• android:id
  
  
  
  もちろんandroid:id
  
  
  
  マークアップファイルにあるべきです
• android:orientation
  
  
  
  LinearLayoutオブジェクトのandroid:orientation
  
  
  
  は通常、マークアップファイルで意味があります
• android:text
  
  
  
  コンテンツを説明するため、 android:text
  
  
  
  はマークアップファイルに含まれている必要があります
• 一般的なスタイルのandroid:layout_width
  
  
  
  and android:layout_height
  
  
  
  で定義するのが理にandroid:layout_height
  
  
  
  場合がありますが、デフォルトではこれらの属性はマークアップファイルにある必要があります

スタイルを使用します。 通常、ビューの表示属性は重複しているため、ほとんどすべてのプロジェクトでスタイルを正しく使用する必要があります。 少なくとも、アプリケーションのほとんどのテキストコンテンツに共通のスタイルが必要です。たとえば、次のとおりです。

 <style name="ContentText"> <item name="android:textSize">@dimen/font_normal</item> <item name="android:textColor">@color/basic_black</item> </style>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TextViewに適用：

 <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="@string/price" style="@style/ContentText" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おそらくボタンについても同じことをする必要がありますが、そこで止まらないでください。 このコンセプトを開発し、特定の種類の視覚コンポーネントに関連するandroid:****



属性を繰り返すandroid:****



すべてのグループをスタイルに入れます。



スタイルのある大きなファイルをいくつかの小さなファイルに分けます。 すべてのスタイルを1つのstyles.xml



に保存する必要はありません。 Android SDKはデフォルトでさまざまなファイル名をサポートしているため、スタイル付きのファイルの命名に問題はありません。XML「style」タグを含めるだけで問題ありません。 したがって、 styles_home.xml



、 styles_item_details.xml



、 styles_forms.xml



、 styles_forms.xml



。 ビルドシステムにとって重要なディレクトリ名とは異なり、 res/values



ファイル名は任意です。



colors.xml



はカラーパレットです。 colors.xml



は、色名とRGBA値を関連付ける以外のものを入れないでください。 さまざまなタイプのボタンのRGBA値を決定するために使用しないでください。





このアプローチでは、重複したRGBA値を作成するのは非常に簡単で、色の変更ははるかに困難です。 さらに、これらの色は特定のコンテンツ、「ボタン」または「コメント」をcolors.xml



、 colors.xml



ではなく、ボタンのスタイルで記述する必要があります。





カラーパレットは、アプリケーション設計者が決定します。 色は緑、青などと呼ばれる必要はありません。 「brand_primary」、「brand_secondary」、「brand_negative」などの名前もかなり受け入れられます。 この色の書式設定により、色の変更やリファクタリングが簡単になり、使用されている色の数も簡単に理解できるようになります。 美しいユーザーインターフェイスを作成するには、可能な限り使用する色の数を減らすことが重要です。



variable.xmlをcolors.xmlとしてスタイルします 。 同じ理由で、オブジェクトとフォントの典型的なサイズの「パレット」を定義する価値もあります。





繰り返しマークアップ属性（マージンとインデント）に数値を書き込まず、フォームspacing_****



定数を使用することをお勧めします（通常、文字列値をローカライズする場合とほぼ同じです）。

これにより、マークアップがより明確になり、変更しやすくなります。



strings.xml



パッケージの命名のように、行の命名でキーを使用します-これにより、同じ定数名で問題を解決し、それらの使用のコンテキストをよりよく理解できます。



悪い例

 <string name="network_error">Network error</string> <string name="call_failed">Call failed</string> <string name="map_failed">Map loading failed</string>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

良い例

 <string name="error.message.network">Network error</string> <string name="error.message.call">Call failed</string> <string name="error.message.map">Map loading failed</string>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

文字列値を小文字で書き込まないでください。 通常のテキスト変換（最初の文字を大文字に変換することを含む）を使用できます。 文字列全体を小文字で書きたい場合は、 TextViewオブジェクトのtextAllCaps属性を使用します。



悪い例

 <string name="error.message.call">CALL FAILED</string>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

良い例

 <string name="error.message.call">Call failed</string>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

深いビュー階層を避けてください 。 ビューの説明の問題を解決するために、別のLinearLayoutを追加したくなることがあります。





マークアップファイルでネストが明らかに増加していなくても、（Javaで）ビューを他のビューに含めると、ネストが発生する可能性があります。



いくつかの問題があるかもしれません。プロセッサがユーザーインターフェイスコンポーネントツリーの複雑な記述を処理することを余儀なくされるため、パフォーマンスの問題が発生する可能性があります。別のより深刻な問題は、StackOverflowErrorエラーの可能性です。



だから、可能な限りフラットとして、あなたのビュー階層を作ってみる：使用方法を参照してくださいRelativeLayoutをする方法を、あなたのレイアウトを最適化し、使用タグを。



WebViewを使用するときは注意してください。 web-, , HTML, backend- «» HTML. WebView Activity, ApplicationContext. WebView , TextView Button.

Android SDKテストフレームワークは未完成の状態のままです（Espresso 2.1 についてですか？！ -約Per。）。特にユーザーインターフェイステストに関しては。 Android Gradleには、デフォルトで、JUnit拡張機能とAndroidユーティリティを使用して作成したJUnitテストを実行するconnectedAndroidTestタスクが含まれています。つまり、デバイスまたはエミュレーターでテストを実行する必要があります。テストには公式の指示[1] [2]を使用してください。Robolectricは、UIではなく、単体テストにのみ



使用してください。このフレームワークは、デバイスなしでテストを実行し、実行速度を向上させる機能を提供し、データモデルとビューの単体テストに最適です。ただし、Robolectricユーザーインターフェイスは完全ではなく、不正確ではありません。アニメーション、ダイアログなどに関連するユーザーインターフェイス要素をテストすると問題が発生し、テストプロセスは（画面を見ずに）「盲目的に」進みます。



Robotiumは、ユーザーインターフェイスのテストを簡単にします。RobotiumなしでUIテストを実行できますが、ビューの分析と画面の制御のためのユーティリティがあるため、非常に便利です。テストスクリプトは非常に単純に見えます。

 solo.sendKey(Solo.MENU); solo.clickOnText("More"); // searches for the first occurence of "More" and clicks on it solo.clickOnText("Preferences"); solo.clickOnText("Edit File Extensions"); Assert.assertTrue(solo.searchText("rtf"));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エミュレーター

プロのAndroid開発者である場合は、Genymotionエミュレーターのライセンスを購入してください。通常のAVDエミュレータよりも高速に動作します。Genymotionエミュレーターを使用すると、アプリケーションの動作を示すビデオを録画したり、さまざまな品質のネットワーク接続、GPS信号などをエミュレートできます。テストの実行に最適です。Androidデバイスの多くの（すべてではありませんが）イメージにアクセスできるため、Genymotionライセンスのコストは、多くのデバイスを購入するよりもはるかに安くなります。



落とし穴：Genymotionでは、アプリケーションでGoogle PlayストアやマップなどのGoogleサービスを使用できません。また、Samsung API機能をテストする必要がある場合は、実際のデバイスを購入する必要があります。

Proguardの構成

ProGuardは一般的にAndroidプロジェクトでコードの圧縮と難読化に使用されます。



ProGuardを使用するための条件は、プロジェクトの設定によって異なります。通常、ProGuardを使用してリリースバージョンをビルドするようにgradleを構成します。

 buildTypes { debug { minifyEnabled false } release { signingConfig signingConfigs.release minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードのどの部分を処理する必要があるかを示すには、1つ以上のエントリポイントをマークする必要があります。通常、これらは基本的なメソッド、アプレット、ミッドレット、アクティビティなどを持つクラスです。Androidフレームワークが使用するデフォルトの構成はにありSDK_HOME/tools/proguard/proguard-android.txt



ます。ProGuardの構成に独自のルールを定義するには、それらをファイルに配置しmy-project/app/proguard-rules.pro



ます。これらのルールはデフォルトの構成を補完します。



ProGuardに関連する最も一般的な問題は、起動時にエラーが発生しClassNotFoundException



たりNoSuchFieldException



、プロジェクトビルドチーム（たとえばassembleRelease



）がエラーなしで動作した場合でも、アプリケーションがクラッシュすることです。これは、次の2つのいずれかを意味します。

• ProGuardは、クラス、列挙型、メソッド、フィールド、または注釈を削除しましたが、それらは必要ないと考えていました。
• ProGuardはクラス、列挙型、またはフィールドの名前を変更しましたが、Javaリフレクションメカニズムを含め、古い名前を使用して呼び出されます。

app/build/outputs/proguard/release/usage.txt



リモートオブジェクトの言及については、ファイルを確認してください。名前が変更されている場合、その名前はファイルにありますapp/build/outputs/proguard/release/mapping.txt



。ProGuard によって



必要なクラスとメソッドが削除されないように保護するために、構成にオプションを追加しますkeep



。

 -keep class com.futurice.project.MyClass { *; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

名前の変更を防ぐには、オプションを使用しますkeepnames



：

 -keepnames class com.futurice.project.MyClass { *; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、ProGuard構成に対する他の可能な変更を見つけることができます。その他のProguard構成の例はこちら。



プロジェクトの開始時に、リリースビルドを作成して、 ProGuardのルールが正しく記述されていることを確認します。新しいライブラリを接続するとき、リリースビルドを作成し、デバイス上の実行可能ファイルを確認します。バージョン“ 1.0”がリリースビルドを作成するのを待たないでください。そうしないと、修正する時間がないために不愉快な驚きを感じるかもしれません。



ヒント。各リリースのmapping.txtファイルを保存します。各アセンブリのmapping.txtファイルのコピーがあれば、問題を確実に見つけることができます。ユーザーはバグをキャッチし、難読化されたエラーログを送信します。



DexGuard。コードを突然最適化し、特別な方法で難読化する場合は、ProGuardの商用アナログであるDexGuardを使用してみてください。Dexファイルをいくつかに簡単に分割して、65kメソッドの制限を回避できます。

謝辞

Antti Lammi、Joni Karppinen、Peter Tackage、Timo Tuominen、Vera Izrailit、VhitoriMäntylä、Mark Voit、Andre Medeiros、Paul Houghton、およびその他のFuturice開発者がAndroidの知識を共有しています。

免許

Futurice Oy Creative Commons Attribution 4.0 International（CC BY 4.0）