ランタイム再描画アプリケーション

こんにちは、Habr！



最近、サーバーから取得したJSONオブジェクトを使用してアプリケーションを再描画するという興味深いタスクがありました。 Googleは、すべての色/テーマがxmlで記述されているという考えを指示します。 そのため、手首を軽く動かすだけでは、R.color.primary_buttonを青から緑に置き換えるためにどこでも機能しません。



リソースに関する毎週の冒険の短い改作に興味があるなら、猫へようこそ。

少しの背景

このアプリケーションにはいくつかのバリエーションがあり、それぞれがproductFlavorsを使用して登録されます。 小さなこと（たとえば、テキストの色）を変更するには、開発者の介入が必要なので、アプリケーションとそのリソースを分離するために多くの手段が取られました。 このタスクの一環として、配色の変更にはPlayMarket / AppStoreでのアプリケーションの更新が必要になることにも気付きました。 そのため、開発者の1人は「サーバーからカラースキームを引き出し、実行時にアプリケーションを再描画しましょう」というアイデアを提案しました。



アクションフィールドとは何ですか：

• 47種類のスクリーン。
• 〜50の形状とセレクター。
• 〜70の異なる色（グラデーションと境界線を持つ要素もあれば、特定の画面に固有のものもあります）。

既存の経験に基づいて、次のソリューションが特定されました。

1. 各アクティビティで、UIを再描画するコードを記述します（額の決定、idはすべてのビューに割り当てられ、色は各アクティビティでプログラムで設定されます）。
2. 使用されているすべてのUI要素からの継承（アクティビティへの変更を除く最初のソリューションの開発、xmlはこのために記述されています）。
3. リソースまたはビューまたはシェイプの作成中に必要なタスクを実装できる他の何かのラッパー。

次に、3番目のソリューションの研究に進みます。

実験番号1。 リソースをラップしようとしています

Androidはすべてのリソースを独占しています。これらはリソースです。 ビューまたはシェイプを作成すると、コンストラクターに渡されたコンテキストからこのクラスのインスタンスが取得されます。 そして、コンストラクタに干渉する唯一の方法は、コンテキストを置き換えることです。



Googleはこれに対して何もせず、完全なラッパーであるContextWrapperへのアクセスを提供します。 コンテキストの置換は、オーバーロードattachBaseContextで発生します。 ここで複雑なことはありません。

次に、Resourcesクラスについて

このクラスを勉強すると、オーバーロードしたいメソッドの多くがバッチであることがわかりました。 getColorなどのオーバーロードを気にする人はいませんが、ビューの構築にもTypedArrayにも使用されません（転送された属性セットに対応するリソース値のセットを取得するために必要です）。 そして、使用されるものは隠されています。 したがって、最初の単純なアイデアは失敗しました。



しかし、同時に、TypedValueとTypedArrayの豊富な使用が注目されました。 一般に、リソースとその作業は、これら2つのクラスを介したアクティブな作業に基づいて構築されます。



最初のものには問題はありません;リソースにはgetValueメソッドがあります。 このメソッドをオーバーロードすることにより、すぐにgetColor（色の場合）およびgetDrawable（ColoredDraawbleの場合）が正しく機能するようになります。



また、TypedArrayを使用すると、すべてがさらに悪化します。 このクラスは、コンストラクターがプライベートであるためラップできません。 彼のフィールドは閉じられており、それらを変更する方法がありません。 充填に介入することも失敗します。これは、最終クラスのAssetManagerを介して行われるためです。 彼と一緒に私に起こった唯一のことは、反射を通して所望のフィールドにアクセスすることでした。



その結果、このメソッドは実行可能です。 少なくとも最初の画面は完全に塗り直されました。 TypedValueとTypedArrayの作業に介入することで、リソースの点でほとんど何でも変更できます。 しかし、リフレクションは危険であると考え、極端な場合にはそれに頼るので、私は最後までそれを終えませんでした。



すでに2回目の実験で、Resourcesラッパーに関する別の問題に遭遇しました。 android.support.v7.widget.ResourcesWrapperがすでにAndroidに存在することが判明しました。 その実装は、一部のコンポーネントのクラスをラップし、まったく異なる結果を生成できます。 ところで、ResourcesWrapperはバッチであり、単なる人間には隠されています。

実験番号2

すべてを一元的に行うことができないため、タスクは2つの部分に分けられました。

1. Viewのリソースを置き換えます。
2. Shape and Selectorのリソースを置き換えます。

Oビュー。 置換レイアウト

おそらく多くの人がgithub.com/chrisjenx/Calligraphyに精通しています 。 2番目の実験では、このライブラリで使用されるアイデア、つまりLayoutInflaterの代替が選択されました。 LayoutInflaterの置換もContextWrapperを介して行われます。 ビューを処理するファクトリーは、LayoutInflater内で再定義されます（残念ながら、そのうちの1つはリフレクション経由です）。 また、ファクトリー内にコードが実装され、ビューと属性に応じて、必要なリソースの置換が行われます。

形状について

もっと複雑です。 それらのための工場はありません。 作成は、送信されたxmlファイルを解析し、TypedArrayを使用する静的createFromXmlメソッドを介してリソース内で行われます。 ColorStateListでも同じことが起こります。



作成作業の妨害は機能しません（最初の実験で説明した方法を除く）。 また、作成されたオブジェクトはリソースのIDを保存しないため、作成後に再描画することはできません。 しかし、バイパスすることはできます。 リソースには、getXmlメソッドがあります。 任意のxmlを取得し、自分で解析できます。 したがって、IDとリソースがあると、Drawableを取得して必要な変更を加えることができます。



ColorStateListは（Drawbleの実装とは異なり）そのコンテンツの変更を許可しません。 ここで、リフレクションを使用するか、新しいインスタンスを作成して、キャッシュを実装します。

リソースキャッシュについてもう少し

最初の希望は、目的のDrawableとColorStateListを変更するだけで、リソースキャッシュを使用することでした。 しかし、これは2つの理由で放棄されなければなりませんでした。



1つ目は上記で説明されており、ColorStateListに影響します。 リフレクションがなければ、そのインスタンスのプロパティは変更できません。つまり、リソースにキャッシュされたインスタンスは使用できません。



2番目は、ColorDrawableと単一のColorStateListのキャッシュに関連しています（これは、ColorStateListがセレクターではなく、色に対して要求された場合です）。 キャッシュは最適化され、リソースIDではなく、リソースが参照する色によって発生します。

結果

その結果、アプリケーションには以下が含まれます。

1. ビューに変更を加える独自のLayoutInflater。
2. getDrawable（int resId、Resources baseResource）という形式の一連のメソッドを備えたグレートシングルトーン。カラースキーム、Drawables、ColorStateListsの格納に従事しています。
3. バーのステータスとコンテキストラップの再描画を含む基本アクティビティ。

この問題は、既存のコードをわずかに変更することで解決しました（たとえば、計算の結果に応じてテキストの色がプログラムで変更される場合）。 そして、それはさらなる開発に特に影響を与えるべきではありません。



これに対する料金：シェイプとセレクターの場合、少なくともビューの作成時の負荷の増加-ダブル。 APIの次のバージョン（現在24を使用しています）に切り替える際に起こりうる問題、およびデバイス固有のバグ。



あなたの中には、同様の問題に直面している人がいると思います。 そして、コメントでランタイムの再描画のトピックに関するあなたの考えを見るのは面白いでしょう。



ご清聴ありがとうございました！