我需要从drawable文件夹外部加载9-patch文件。这样我的应用程序就可以从服务器下载新的皮肤。我发现在制作.apk时会编译存储在drawable文件夹中的9补丁图像。从assets文件夹读取的完全相同的文件没有9补丁块。因此,制作.apk的行为是在可绘制文件夹中编译源9补丁文件,但不在资源目录中编译。
如何自己编译9补丁文件,以便将其安装在assets目录中?是否有(批量)工具将源转换为带有9补丁块的编译版本?我真的非常非常喜欢不必使用Eclipse / Ant来构建.apk,然后选择它来提取已编译的9补丁文件(如果可能的话)。
现在我只想从资源目录中读取(例如,每个皮肤有一个子目录)以保持简单。下一步是编译源映像以添加到9补丁块中。之后我会担心即时下载到/ data文件夹 - 如果我无法编译9补丁文件那么添加服务器端的工作就没什么意义了。
答案 0 :(得分:10)
没有简单的方法可以做到这一点。 9-patch编译由aapt完成并且相当简单:它丢弃黑色边框并在PNG块内编码其内容。编写一个类似的工具对你来说是相当微不足道的。请注意,您甚至不需要使用相同的格式。如果你看一下doc中的各种NinePatch API,你会看到你可以提交你自己的“块”(它对扩展区域和填充进行编码)。这里解释了一个块byte []数组的结构:
/**
* This chunk specifies how to split an image into segments for
* scaling.
*
* There are J horizontal and K vertical segments. These segments divide
* the image into J*K regions as follows (where J=4 and K=3):
*
* F0 S0 F1 S1
* +-----+----+------+-------+
* S2| 0 | 1 | 2 | 3 |
* +-----+----+------+-------+
* | | | | |
* | | | | |
* F2| 4 | 5 | 6 | 7 |
* | | | | |
* | | | | |
* +-----+----+------+-------+
* S3| 8 | 9 | 10 | 11 |
* +-----+----+------+-------+
*
* Each horizontal and vertical segment is considered to by either
* stretchable (marked by the Sx labels) or fixed (marked by the Fy
* labels), in the horizontal or vertical axis, respectively. In the
* above example, the first is horizontal segment (F0) is fixed, the
* next is stretchable and then they continue to alternate. Note that
* the segment list for each axis can begin or end with a stretchable
* or fixed segment.
*
* The relative sizes of the stretchy segments indicates the relative
* amount of stretchiness of the regions bordered by the segments. For
* example, regions 3, 7 and 11 above will take up more horizontal space
* than regions 1, 5 and 9 since the horizontal segment associated with
* the first set of regions is larger than the other set of regions. The
* ratios of the amount of horizontal (or vertical) space taken by any
* two stretchable slices is exactly the ratio of their corresponding
* segment lengths.
*
* xDivs and yDivs point to arrays of horizontal and vertical pixel
* indices. The first pair of Divs (in either array) indicate the
* starting and ending points of the first stretchable segment in that
* axis. The next pair specifies the next stretchable segment, etc. So
* in the above example xDiv[0] and xDiv[1] specify the horizontal
* coordinates for the regions labeled 1, 5 and 9. xDiv[2] and
* xDiv[3] specify the coordinates for regions 3, 7 and 11. Note that
* the leftmost slices always start at x=0 and the rightmost slices
* always end at the end of the image. So, for example, the regions 0,
* 4 and 8 (which are fixed along the X axis) start at x value 0 and
* go to xDiv[0] and slices 2, 6 and 10 start at xDiv[1] and end at
* xDiv[2].
*
* The array pointed to by the colors field lists contains hints for
* each of the regions. They are ordered according left-to-right and
* top-to-bottom as indicated above. For each segment that is a solid
* color the array entry will contain that color value; otherwise it
* will contain NO_COLOR. Segments that are completely transparent
* will always have the value TRANSPARENT_COLOR.
*
* The PNG chunk type is "npTc".
*/
struct Res_png_9patch
{
Res_png_9patch() : wasDeserialized(false), xDivs(NULL),
yDivs(NULL), colors(NULL) { }
int8_t wasDeserialized;
int8_t numXDivs;
int8_t numYDivs;
int8_t numColors;
// These tell where the next section of a patch starts.
// For example, the first patch includes the pixels from
// 0 to xDivs[0]-1 and the second patch includes the pixels
// from xDivs[0] to xDivs[1]-1.
// Note: allocation/free of these pointers is left to the caller.
int32_t* xDivs;
int32_t* yDivs;
int32_t paddingLeft, paddingRight;
int32_t paddingTop, paddingBottom;
enum {
// The 9 patch segment is not a solid color.
NO_COLOR = 0x00000001,
// The 9 patch segment is completely transparent.
TRANSPARENT_COLOR = 0x00000000
};
// Note: allocation/free of this pointer is left to the caller.
uint32_t* colors;
// Convert data from device representation to PNG file representation.
void deviceToFile();
// Convert data from PNG file representation to device representation.
void fileToDevice();
// Serialize/Marshall the patch data into a newly malloc-ed block
void* serialize();
// Serialize/Marshall the patch data
void serialize(void* outData);
// Deserialize/Unmarshall the patch data
static Res_png_9patch* deserialize(const void* data);
// Compute the size of the serialized data structure
size_t serializedSize();
};
答案 1 :(得分:1)
这是一种适用于我的解决方法。
我的应用程序中有默认的9色块图像,用作消息气泡。我想创建可下载的themes
来更改气泡和字体颜色等其他内容。
可绘制文件夹中包含的*.9.png
图像是默认图像,它们在图像周围包括黑色像素:
“自定义” /主题气泡的尺寸完全相同,但位置进行了细微更改,仍然使用默认的“块”区域,但是这些区域中不包含黑色像素或.9
文件名:
那么自定义商品如何工作并且仍然看起来不错?以下是一些代码,可用来获取自定义图像,从默认的9补丁图像中获取一些值并将其应用于自定义位图:
//Get the custom replacement image
Bitmap bitmap = BitmapFactory.decodeFile(folderpath + File.separator + "pink_round_outgoing.png");
//Get padding from the default 9-patch drawable
Drawable existingDrawable = ContextCompat.getDrawable(this, R.drawable.default_outgoing);
Rect padding = new Rect();
if (existingDrawable != null) {
existingDrawable.getPadding(padding);
}
//Get 9-patch chunk from the default 9-patch drawable
Bitmap existingBitmap = BitmapFactory.decodeResource(getResources(), R.drawable.default_outgoing);
byte[] chunk = existingBitmap.getNinePatchChunk();
//Finally create your custom 9-Patch drawable and set it to background
NinePatchDrawable d = new NinePatchDrawable(getResources(), bitmap, chunk, padding, null);
view.setBackground(d);