プログラムでNinePatchDrawableを作成する

新しいAndroid Lollipopには、 VectorDrawableなどの興味深いコンポーネントがあります。 賢く使用すれば、アプリケーションのボリュームを大幅に削減し、グラフィックリソースを節約できます。また、ベクターグラフィックを使用することで、さまざまな画面密度の画像を作成する面倒なプロセスから解放されます。 VectorDrawableを見たときに最初に訪れたのは、「すごい！ NinePatchのように引っ張ることはできますか？」 不可能だった。 ここでは、少なくともアイコンをベクターに保持できるという事実に少し動揺し、満足するかもしれません。 しかし、私はそこで止まらないことに決めました。 結果は、あらゆるDrawableからNinePatchDrawableを作成できる汎用ユーティリティです。



表示される画像はベクトルを使用していますが、中央に配置されています。 これはすごい！ 特定の領域でのみベクトルを引き伸ばす機能は、実際には大きな機会を提供します。 そして、Androidの以前のバージョンでベクターを使用できるようにするプロジェクトがあると考えると、ベクター画像はすべての素晴らしさを見せ始めます。

すばらしい変換を開始する前に、詳細をもう少し詳しく見て、目的の結果を得る方法を見つけましょう。 最初に、NinePatchDrawableとは何かを理解してみましょう。 また、2つの主要部分で構成されます。最初の部分はビットマップで、2番目は「チャンク」と呼ばれるバイトの配列で、このビットマップのストレッチ方法に関する情報が含まれています。 したがって、任意のビットマップと対応する「チャンク」を使用して、標準モデルをバイパスしてNinePatchDrawableを作成できます。9.pngを作成し、プロジェクトに配置して、コンパイルします。

ただし、実際にはそれほど単純ではありません。 事実、実際には、「チャンク」がどのように形成されるかに関するドキュメントを見つけることは現実的ではありません。 aaptユーティリティは、コンパイル段階でもその生成に関与しており、Android APIには「チャンク」の生成に役立つクラスはありません。 アレイの大部分が何であるかを把握できました。 率直に言って、私はどのバイトが何に責任があるのか​​を完全には理解していませんでしたが、これで十分であることがわかりました。

「チャンク」とは何ですか？

この配列をバイト単位で解析しましょう。 私が知らないバイトは、その謎と謎のために「魔法」と呼ぶことにしました。 だから：

• [0]-フラグwasDeserialized。
• [1]-XDivs配列内のポイントの数を示します。
• [2]-YDivs配列内のポイントの数を示します。
• [3]-Colors配列のポイント数を示します。
• [4-11]-8個の「マジック」バイト。
• [12-27]-パディング用の16バイト。
• [28-31]-4つの「マジック」バイト。
• [32-〜]-次は、XDivs、YDivs、およびColors配列のリストです。

ゼロバイトにはブール値「wasDeserialized」が格納されます。 私が見つけたすべての例では、0x01である必要がありますが、代わりに他の値を指定してもひどいことは何も起こらず、「チャンク」配列をネイティブオブジェクトに変換するときに自動的にtrueに設定されます。

パディング、XDivs、YDivs、および色は、int（4バイト）に格納されます。 ちなみに、サイドの数に応じて、パディングが4バイトを占有するのではなく、16バイトを占有するのはこのためです。

XDivsとYDivsには、X軸とY軸に沿ってストレッチする領域が含まれています。 最初の番号は、最初の領域の始まりを示し、その次の領域のように続きます。 次に、次の配列を同様に説明します。

例として、6 x 6のNinePatch画像を見てみましょう。



ここで、X軸に沿った伸縮可能な領域は2から3ピクセルまで、Y軸に沿って2から4までです。したがって、XDivsは[0x02、0x00、0x00、0x00、0x03、0x00、0x00、0x00]と[ 0x02、0x00、0x00、0x00、0x04、0x00、0x00、0x00]。 XDivsとYDivsのサイズを決定する「チャンク」配列の最初の（2番目の）バイトと2番目（3番目の）バイトとして、0x02を指定する必要があります。これは、それぞれ4バイトの2ポイントを意味します。

Colors配列に何を保存すべきかをよりよく理解するために、前の画像に小さな変更を加えました。もう一度見てみましょう。



図からわかるように、画像は9つの領域に分割できます。 そのため、Colorsはこれらの領域の描画方法を決定します。 2つのオプションがあります。

1. 0x00000000（TRASPARENT）領域は透明になります。
2. 0x00000001（NO_COLOR）領域が表示されます。

名前が思われるかもしれませんが、Colorsは特定の色を担当しますが、この場合、その目的はより簡単です-領域の可視性を示すことです。
指定された画像について、すべての領域を表示したままにする場合は、[0x01、0x00、0x00、0x00]を9回指定し、「チャンク」配列の3バイト（順序4）に0x09に等しい値を設定する必要があります。

不思議な発言：描画に関係するネイティブコードは依然としてColors配列のサイズであり、彼自身が画像にいくつの領域があるかを知っており、Colorsに設定したサイズに関係なくそれらを受け取ります。 その結果、アレイの外側のメモリ領域にアピールが行われ、その結果、ある描画から別の描画へと消えたり現れたりするセクターが得られます。

最初は、これで本格的なNinePatchを作成するのに十分かどうか疑問に思いました。 十分に判明しました。 実際、NinePatchは、「チャンク」を使用する前に、validateNinePatchChunkメソッドを使用してネイティブのRes_png_9patchオブジェクトに変換します。 ソースを見ると、コードを見るとわかりにくいバイトが使用されていないことがわかります。つまり、ゼロなどの値で埋めることができます。

NinePatchBuilder

「チャンク」を生成する方法がわかったので、最初にビットマップに描画する場合、Drawableを含む任意の画像からNinePatchを作成することは難しくありません。 これらの手順を簡素化するために、 NinePatchBuilderクラスを作成することにしました。

次のコードは、通常のビットマップの場合に使用する方法を示しています。

NinePatchBuilder ninePatchBuilder = new NinePatchBuilder(getResources()) .addStretchSegmentX(0.49f, 0.51f) .addStretchSegmentY(0.49f, 0.51f) .setBitmap(bitmap); Drawable drawable = ninePatchBuilder.build(); 

addStretchSegmentメソッドは、ストレッチする領域を指定します。 NinePatchを作成するときに、サイズが事前にわからない画像を使用できるため、[0、1]の範囲の相対サイズを使用することにしました。 ビルドを呼び出すと、設定されたパラメーターとビットマップのサイズに応じて、「チャンク」の配列が形成され、NinePatchDrawableが作成されます。

NinePatchBuilderの内部では次のことが行われます。

 //   NinePatchBuilder. private Drawable buildFromBitmap(Bitmap bitmap) { return new NinePatchDrawable(mResources, bitmap, getChunkByteArray(bitmap), getPaddingRect(bitmap.getWidth(), bitmap.getHeight()), mSrcName); } 

getChunkByteArrayメソッドコードは提供しません。その実装の大部分は、前述の「チャンク」生成アルゴリズムに従うためです。

Drawableについても同様です。 ここでは、VectorDrawableを含め、何でもDrawableとして機能できます。 その結果、ベクトル画像が1つしかないため、すべての画面密度に対してNinePatchDrawableの完全なセットが得られます！
ベクター画像があるとしましょう。


NinePatchに変換することは大したことではありません。

 NinePatchBuilder ninePatchBuilder = new NinePatchBuilder(resources) .addStretchSegmentX(0.49f, 0.51f) .addStretchSegmentY(0.49f, 0.51f) .setDrawable(R.drawable.android, (int) resources.getDimension(R.dimen.android_width), (int) resources.getDimension(R.dimen.android_height)); 

さらに、すべてのDrawableが固定サイズではないため、サイズをピクセル単位で指定する必要があります。 buildの呼び出し時に、Drawableがビットマップに描画され、このビットマップは既にNinePacthDrawableを作成するために使用されています。

特別な場合

当然、 DrawableContainerとその子孫が存在するため、描画されたDrawableを盲目的に使用することは必ずしも良い解決策ではありません。 このような複雑なオブジェクトをサポートするには、特定のトリックを行う必要がありました。

 //   NinePatchBuilder. if (drawable instanceof DrawableContainer) { final XmlPullParser parser = mResources.getXml(drawableId); final AttributeSet attrs = Xml.asAttributeSet(parser); int type = XmlPullParser.START_DOCUMENT; try { while ((type=parser.next()) != XmlPullParser.START_TAG && type != XmlPullParser.END_DOCUMENT) { // Empty loop } } catch (XmlPullParserException | IOException e) { e.printStackTrace(); } if (type == XmlPullParser.START_TAG) { Drawable result = null; try { result = drawable.getClass().newInstance(); } catch (InstantiationException | IllegalAccessException e) { e.printStackTrace(); } if (result != null) { try { result.inflate(new ResourceWrapper(mResources), parser, attrs); return result; } catch (XmlPullParserException | IOException e) { e.printStackTrace(); } } } } 

これはNinePatchBuilderのコードの一部であり、Class.newInstance（）を使用して元のクラスと同じクラスの新しいDrawableを作成し、inflateメソッドでそれを埋めます。 これはすべて、ResourceWrapperを除いて、LayoutInflater内で発生するものに似ています。 エッセンス全体が潜んでいます。 inflateメソッドの動作を見ると、パラメーターとして転送されたリソースからgetDrawableメソッドによってDrawableの子が取得されていることがわかります。 目的の結果を取得するには、このメソッドをオーバーライドします。

 //   NinePatchBuilder. private class ResourceWrapper extends Resources { public ResourceWrapper(Resources resources) { super(resources.getAssets(), resources.getDisplayMetrics(), resources.getConfiguration()); } @Override public Drawable getDrawable(int id) throws NotFoundException { return buildFromDrawable(id, mDrawableWidth, mDrawableHeight); } @Override public Drawable getDrawable(int id, Theme theme) throws NotFoundException { return buildFromDrawable(id, mDrawableWidth, mDrawableHeight); } } 

この「耳のフェイント」のおかげで、あらゆるレベルのネストを持つすべてのDrawableContainer子孫の完全なサポートを実装し、StateListDrawableを変換すると、出力はNinePatchDrawableで構成されるStateListDrawableになります。

XMLとキャッシング

あるビルダーでは十分ではなかったため、XMLファイルからNinePatchを収集するNinePatchInflaterクラスを作成することにしました 。 その結果、Drawableは次のように記述できます。

 <nine-patch-plus xmlns:auto="http://schemas.android.com/apk/res-auto" auto:src="@drawable/android" auto:width="@dimen/android_width" auto:height="@dimen/android_height" auto:stretchX="0.49, 0.51" auto:stretchY="0.49, 0.51" /> 

ファイルは「xml」フォルダーにある必要があります。 現在、このようなDrawableの作成に関係するコードは1行に削減できます。

 Drawable drawable = NinePatchInflater.inflate(resources, R.xml.vector_drawable_nine_patch); 

ほとんどのコードを別のファイルに配置することに加えて、inflater-aには別の大きな利点があります-リソースIDによるキャッシュです。 実際、Drawableの作成は非常に費用のかかる操作になる可能性があります。特に私たちの場合、1つのDrawableを取得する場合、将来必要のないオブジェクトの束を作成する必要があります。 さいわい、必要な作業のほとんどは既にConstantStateクラスで行われているため、キャッシュで作成されたDrawableのConstantStateを保存し、必要に応じてConstantState.newDrawable（）メソッドを使用して新しいDrawableを作成するだけです。 詳細は説明しませんが、記事は広範囲にわたることが判明しました。さらに、私は新しいことを思いつきませんでした。これがリソースクラスでキャッシュが発生する方法です。

おわりに

ただし、リソースの完全なラッパーを作成して、プログラムコードを記述せずにXMLマークアップにこれらのファイルへのリンクを直接挿入できるようにすることは悪くありませんでしたが、うまくいきませんでした。 判明したように、ビューを作成するとき、場所では、デフォルトのアクセス修飾子を持つメソッドが使用され、Drawableクラスの静的メソッドが直接呼び出されることもあります。 それにもかかわらず、私は、完全な範囲ではないが、望ましい結果が達成されたと信じています。

GitHubプロジェクト： NinePatchBuildUtils


私が興味を持っているので特に頑固なリンク：
NinePatchソース： NinePatch.javaおよびNinePatch.cpp
Res_png_9patchについて読むことができる場所： ResourceTypes.hおよびResourceTypes.cpp

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