refer:https://stackoverflow.com/questions/6510467/android-compiling-9-patch-files-to-be-used-outside-of-the-drawable-folder

    在drawable文件夹之外使用的.9.png文件？

    我需要从drawable文件夹外部加载9补丁文件。这样一来，我的应用程序便可以从服务器下载新皮肤。我发现制作.apk时会编译存储在drawable文件夹中的9补丁图像。从资产文件夹读取的完全相同的文件没有9修补程序块。因此，制作.apk的行为是在可绘制文件夹中而不是在Assets目录中编译源9补丁文件。

    我如何自己编译一个9补丁文件，以便可以将其安装在资产目录中？是否有一个（批处理）工具可以将源代码转换为带有9个补丁的块的编译版本？我真的非常希望不必使用Eclipse / Ant来构建.apk，然后尽可能地将其拆开以提取编译的9补丁文件。

    现在，我只希望能够从assets目录读取（例如，每个皮肤都有一个子目录）以保持简单。下一步是编译源映像，以添加到9修补程序块中。之后，我会担心会即时下载到/ data文件夹-如果我无法编译9-patch文件，那么增加服务器端的工作量毫无意义。

    没有简单的方法可以做到这一点。 9补丁编译完成通过aapt进行，非常简单：它会丢弃黑色边框并进行编码
    它们的内容在PNG块中。 对您来说，这是微不足道的编写执行类似操作的工具。 请注意，您甚至不需要使用相同的格式。 如果您看一下NinePatch API中的各种 doc，您会看到您可以提交自己的“块”（伸展区域和填充。）chunk byte []数组的结构在这里解释：

    1. /**
    2.  * This chunk specifies how to split an image into segments for
    3.  * scaling.
    4.  *
    5.  * There are J horizontal and K vertical segments.  These segments divide
    6.  * the image into J*K regions as follows (where J=4 and K=3):
    7.  *
    8.  *      F0   S0    F1     S1
    9.  *   +-----+----+------+-------+
    10.  * S2|  0  |  1 |  2   |   3   |
    11.  *   +-----+----+------+-------+
    12.  *   |     |    |      |       |
    13.  *   |     |    |      |       |
    14.  * F2|  4  |  5 |  6   |   7   |
    15.  *   |     |    |      |       |
    16.  *   |     |    |      |       |
    17.  *   +-----+----+------+-------+
    18.  * S3|  8  |  9 |  10  |   11  |
    19.  *   +-----+----+------+-------+
    20.  *
    21.  * Each horizontal and vertical segment is considered to by either
    22.  * stretchable (marked by the Sx labels) or fixed (marked by the Fy
    23.  * labels), in the horizontal or vertical axis, respectively. In the
    24.  * above example, the first is horizontal segment (F0) is fixed, the
    25.  * next is stretchable and then they continue to alternate. Note that
    26.  * the segment list for each axis can begin or end with a stretchable
    27.  * or fixed segment.
    28.  *
    29.  * The relative sizes of the stretchy segments indicates the relative
    30.  * amount of stretchiness of the regions bordered by the segments.  For
    31.  * example, regions 3, 7 and 11 above will take up more horizontal space
    32.  * than regions 1, 5 and 9 since the horizontal segment associated with
    33.  * the first set of regions is larger than the other set of regions.  The
    34.  * ratios of the amount of horizontal (or vertical) space taken by any
    35.  * two stretchable slices is exactly the ratio of their corresponding
    36.  * segment lengths.
    37.  *
    38.  * xDivs and yDivs point to arrays of horizontal and vertical pixel
    39.  * indices.  The first pair of Divs (in either array) indicate the
    40.  * starting and ending points of the first stretchable segment in that
    41.  * axis. The next pair specifies the next stretchable segment, etc. So
    42.  * in the above example xDiv[0] and xDiv[1] specify the horizontal
    43.  * coordinates for the regions labeled 1, 5 and 9.  xDiv[2] and
    44.  * xDiv[3] specify the coordinates for regions 3, 7 and 11. Note that
    45.  * the leftmost slices always start at x=0 and the rightmost slices
    46.  * always end at the end of the image. So, for example, the regions 0,
    47.  * 4 and 8 (which are fixed along the X axis) start at x value 0 and
    48.  * go to xDiv[0] and slices 2, 6 and 10 start at xDiv[1] and end at
    49.  * xDiv[2].
    50.  *
    51.  * The array pointed to by the colors field lists contains hints for
    52.  * each of the regions.  They are ordered according left-to-right and
    53.  * top-to-bottom as indicated above. For each segment that is a solid
    54.  * color the array entry will contain that color value; otherwise it
    55.  * will contain NO_COLOR.  Segments that are completely transparent
    56.  * will always have the value TRANSPARENT_COLOR.
    57.  *
    58.  * The PNG chunk type is "npTc".
    59.  */
    60. struct Res_png_9patch
    61. {
    62.     Res_png_9patch() : wasDeserialized(false), xDivs(NULL),
    63.                        yDivs(NULL), colors(NULL) { }
    64.     int8_t wasDeserialized;
    65.     int8_t numXDivs;
    66.     int8_t numYDivs;
    67.     int8_t numColors;
    68.     // These tell where the next section of a patch starts.
    69.     // For example, the first patch includes the pixels from
    70.     // 0 to xDivs[0]-1 and the second patch includes the pixels
    71.     // from xDivs[0] to xDivs[1]-1.
    72.     // Note: allocation/free of these pointers is left to the caller.
    73.     int32_t* xDivs;
    74.     int32_t* yDivs;
    75.     int32_t paddingLeft, paddingRight;
    76.     int32_t paddingTop, paddingBottom;
    77.     enum {
    78.         // The 9 patch segment is not a solid color.
    79.         NO_COLOR = 0x00000001,
    80.         // The 9 patch segment is completely transparent.
    81.         TRANSPARENT_COLOR = 0x00000000
    82.     };
    83.     // Note: allocation/free of this pointer is left to the caller.
    84.     uint32_t* colors;
    85.     // Convert data from device representation to PNG file representation.
    86.     void deviceToFile();
    87.     // Convert data from PNG file representation to device representation.
    88.     void fileToDevice();
    89.     // Serialize/Marshall the patch data into a newly malloc-ed block
    90.     void* serialize();
    91.     // Serialize/Marshall the patch data
    92.     void serialize(void* outData);
    93.     // Deserialize/Unmarshall the patch data
    94.     static Res_png_9patch* deserialize(const void* data);
    95.     // Compute the size of the serialized data structure
    96.     size_t serializedSize();
    97. };