mirror of
https://github.com/zlgopen/awtk.git
synced 2025-05-09 12:01:19 +08:00
update docs
This commit is contained in:
parent
f2f48473c4
commit
d836643daa
@ -94,7 +94,7 @@ PointerAlignment: Left
|
|||||||
RawStringFormats:
|
RawStringFormats:
|
||||||
- Language: TextProto
|
- Language: TextProto
|
||||||
BasedOnStyle: google
|
BasedOnStyle: google
|
||||||
ReflowComments: true
|
ReflowComments: false
|
||||||
SortIncludes: false
|
SortIncludes: false
|
||||||
SortUsingDeclarations: true
|
SortUsingDeclarations: true
|
||||||
SpaceAfterCStyleCast: false
|
SpaceAfterCStyleCast: false
|
||||||
|
@ -3,22 +3,22 @@
|
|||||||
资源管理器。
|
资源管理器。
|
||||||
这里的资源管理器并非Windows下的文件浏览器,而是负责对各种资源,比如字体、主题、图片、界面数据、字符串和其它数据的进行集中管理的组件。引入资源管理器的目的有以下几个:
|
这里的资源管理器并非Windows下的文件浏览器,而是负责对各种资源,比如字体、主题、图片、界面数据、字符串和其它数据的进行集中管理的组件。引入资源管理器的目的有以下几个:
|
||||||
|
|
||||||
*
|
* 让上层不需要了解存储的方式。
|
||||||
让上层不需要了解存储的方式。在没有文件系统时或者内存紧缺时,把资源转成常量数组直接编译到代码中。在有文件系统而且内存充足时,资源放在文件系统中。在有网络时,资源也可以存放在服务器上(暂未实现)。资源管理器为上层提供统一的接口,让上层而不用关心底层的存储方式。
|
在没有文件系统时或者内存紧缺时,把资源转成常量数组直接编译到代码中。在有文件系统而且内存充足时,资源放在文件系统中。在有网络时,资源也可以存放在服务器上(暂未实现)。资源管理器为上层提供统一的接口,让上层而不用关心底层的存储方式。
|
||||||
|
|
||||||
*
|
* 让上层不需要了解资源的具体格式。
|
||||||
让上层不需要了解资源的具体格式。比如一个名为earth的图片,没有文件系统或内存紧缺,图片直接用位图数据格式存在ROM中,而有文件系统时,则用PNG格式存放在文件系统中。资源管理器让上层不需要关心图片的格式,访问时指定图片的名称即可(不用指定扩展名)。
|
比如一个名为earth的图片,没有文件系统或内存紧缺,图片直接用位图数据格式存在ROM中,而有文件系统时,则用PNG格式存放在文件系统中。资源管理器让上层不需要关心图片的格式,访问时指定图片的名称即可(不用指定扩展名)。
|
||||||
|
|
||||||
*
|
* 让上层不需要了解屏幕的密度。
|
||||||
让上层不需要了解屏幕的密度。不同的屏幕密度下需要加载不同的图片,比如MacPro的Retina屏就需要用双倍解析度的图片,否则就出现界面模糊。AWTK以后会支持PC软件和手机软件的开发,所以资源管理器需要为此提供支持,让上层不需关心屏幕的密度。
|
不同的屏幕密度下需要加载不同的图片,比如MacPro的Retina屏就需要用双倍解析度的图片,否则就出现界面模糊。AWTK以后会支持PC软件和手机软件的开发,所以资源管理器需要为此提供支持,让上层不需关心屏幕的密度。
|
||||||
|
|
||||||
*
|
*对资源进行内存缓存。
|
||||||
对资源进行内存缓存。不同类型的资源使用方式是不一样的,比如字体和主题加载之后会一直使用,UI文件在生成界面之后就暂时不需要了,PNG文件解码之后就只需要保留解码的位图数据即可。资源管理器配合图片管理器等其它组件实现资源的自动缓存。
|
不同类型的资源使用方式是不一样的,比如字体和主题加载之后会一直使用,UI文件在生成界面之后就暂时不需要了,PNG文件解码之后就只需要保留解码的位图数据即可。资源管理器配合图片管理器等其它组件实现资源的自动缓存。
|
||||||
|
|
||||||
当从文件系统加载资源时,目录结构要求如下:
|
当从文件系统加载资源时,目录结构要求如下:
|
||||||
|
|
||||||
```
|
```
|
||||||
assets/raw/
|
assets/{theme}/raw/
|
||||||
fonts 字体
|
fonts 字体
|
||||||
images 图片
|
images 图片
|
||||||
x1 普通密度屏幕的图片。
|
x1 普通密度屏幕的图片。
|
||||||
@ -346,8 +346,7 @@ ret_t assets_manager_set (assets_manager_t* am);
|
|||||||
|
|
||||||
> <p id="assets_manager_t_assets_manager_set_custom_build_asset_dir"> 设置一个函数,该函数用于生成资源路径。
|
> <p id="assets_manager_t_assets_manager_set_custom_build_asset_dir"> 设置一个函数,该函数用于生成资源路径。
|
||||||
|
|
||||||
>
|
> 有时我们需要优先加载用户自定义的资源,加载失败才加载系统缺省的,可用设置一个函数去实现这类功能。
|
||||||
有时我们需要优先加载用户自定义的资源,加载失败才加载系统缺省的,可用设置一个函数去实现这类功能。
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
@ -38,22 +38,22 @@ typedef ret_t (*assets_manager_build_asset_dir_t)(void* ctx, char* path, uint32_
|
|||||||
* 资源管理器。
|
* 资源管理器。
|
||||||
* 这里的资源管理器并非Windows下的文件浏览器,而是负责对各种资源,比如字体、主题、图片、界面数据、字符串和其它数据的进行集中管理的组件。引入资源管理器的目的有以下几个:
|
* 这里的资源管理器并非Windows下的文件浏览器,而是负责对各种资源,比如字体、主题、图片、界面数据、字符串和其它数据的进行集中管理的组件。引入资源管理器的目的有以下几个:
|
||||||
*
|
*
|
||||||
* *
|
* * 让上层不需要了解存储的方式。
|
||||||
*让上层不需要了解存储的方式。在没有文件系统时或者内存紧缺时,把资源转成常量数组直接编译到代码中。在有文件系统而且内存充足时,资源放在文件系统中。在有网络时,资源也可以存放在服务器上(暂未实现)。资源管理器为上层提供统一的接口,让上层而不用关心底层的存储方式。
|
* 在没有文件系统时或者内存紧缺时,把资源转成常量数组直接编译到代码中。在有文件系统而且内存充足时,资源放在文件系统中。在有网络时,资源也可以存放在服务器上(暂未实现)。资源管理器为上层提供统一的接口,让上层而不用关心底层的存储方式。
|
||||||
*
|
*
|
||||||
* *
|
* * 让上层不需要了解资源的具体格式。
|
||||||
*让上层不需要了解资源的具体格式。比如一个名为earth的图片,没有文件系统或内存紧缺,图片直接用位图数据格式存在ROM中,而有文件系统时,则用PNG格式存放在文件系统中。资源管理器让上层不需要关心图片的格式,访问时指定图片的名称即可(不用指定扩展名)。
|
* 比如一个名为earth的图片,没有文件系统或内存紧缺,图片直接用位图数据格式存在ROM中,而有文件系统时,则用PNG格式存放在文件系统中。资源管理器让上层不需要关心图片的格式,访问时指定图片的名称即可(不用指定扩展名)。
|
||||||
*
|
*
|
||||||
* *
|
* * 让上层不需要了解屏幕的密度。
|
||||||
*让上层不需要了解屏幕的密度。不同的屏幕密度下需要加载不同的图片,比如MacPro的Retina屏就需要用双倍解析度的图片,否则就出现界面模糊。AWTK以后会支持PC软件和手机软件的开发,所以资源管理器需要为此提供支持,让上层不需关心屏幕的密度。
|
* 不同的屏幕密度下需要加载不同的图片,比如MacPro的Retina屏就需要用双倍解析度的图片,否则就出现界面模糊。AWTK以后会支持PC软件和手机软件的开发,所以资源管理器需要为此提供支持,让上层不需关心屏幕的密度。
|
||||||
*
|
*
|
||||||
* *
|
* *对资源进行内存缓存。
|
||||||
*对资源进行内存缓存。不同类型的资源使用方式是不一样的,比如字体和主题加载之后会一直使用,UI文件在生成界面之后就暂时不需要了,PNG文件解码之后就只需要保留解码的位图数据即可。资源管理器配合图片管理器等其它组件实现资源的自动缓存。
|
* 不同类型的资源使用方式是不一样的,比如字体和主题加载之后会一直使用,UI文件在生成界面之后就暂时不需要了,PNG文件解码之后就只需要保留解码的位图数据即可。资源管理器配合图片管理器等其它组件实现资源的自动缓存。
|
||||||
*
|
*
|
||||||
*当从文件系统加载资源时,目录结构要求如下:
|
*当从文件系统加载资源时,目录结构要求如下:
|
||||||
*
|
*
|
||||||
* ```
|
* ```
|
||||||
* assets/raw/
|
* assets/{theme}/raw/
|
||||||
* fonts 字体
|
* fonts 字体
|
||||||
* images 图片
|
* images 图片
|
||||||
* x1 普通密度屏幕的图片。
|
* x1 普通密度屏幕的图片。
|
||||||
@ -229,8 +229,7 @@ ret_t assets_manager_preload(assets_manager_t* am, asset_type_t type, const char
|
|||||||
* @method assets_manager_set_custom_build_asset_dir
|
* @method assets_manager_set_custom_build_asset_dir
|
||||||
* 设置一个函数,该函数用于生成资源路径。
|
* 设置一个函数,该函数用于生成资源路径。
|
||||||
*
|
*
|
||||||
* >
|
* > 有时我们需要优先加载用户自定义的资源,加载失败才加载系统缺省的,可用设置一个函数去实现这类功能。
|
||||||
* 有时我们需要优先加载用户自定义的资源,加载失败才加载系统缺省的,可用设置一个函数去实现这类功能。
|
|
||||||
*
|
*
|
||||||
* @param {assets_manager_t*} am asset manager对象。
|
* @param {assets_manager_t*} am asset manager对象。
|
||||||
* @param {assets_manager_build_asset_dir_t} custom_build_asset_dir 回调函数。
|
* @param {assets_manager_build_asset_dir_t} custom_build_asset_dir 回调函数。
|
||||||
|
@ -30,7 +30,6 @@
|
|||||||
* MIME_TYPE。
|
* MIME_TYPE。
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* @const MIME_TYPE_APPLICATION_ENVOY
|
* @const MIME_TYPE_APPLICATION_ENVOY
|
||||||
* "application/envoy"。
|
* "application/envoy"。
|
||||||
|
@ -16282,7 +16282,7 @@
|
|||||||
}
|
}
|
||||||
],
|
],
|
||||||
"annotation": {},
|
"annotation": {},
|
||||||
"desc": " 设置一个函数,该函数用于生成资源路径。\r\n\r\n >\r\n 有时我们需要优先加载用户自定义的资源,加载失败才加载系统缺省的,可用设置一个函数去实现这类功能。\r\n\r\n\r\n",
|
"desc": " 设置一个函数,该函数用于生成资源路径。\r\n\r\n > 有时我们需要优先加载用户自定义的资源,加载失败才加载系统缺省的,可用设置一个函数去实现这类功能。\r\n\r\n\r\n",
|
||||||
"name": "assets_manager_set_custom_build_asset_dir",
|
"name": "assets_manager_set_custom_build_asset_dir",
|
||||||
"return": {
|
"return": {
|
||||||
"type": "ret_t",
|
"type": "ret_t",
|
||||||
@ -16362,7 +16362,7 @@
|
|||||||
"events": [],
|
"events": [],
|
||||||
"properties": [],
|
"properties": [],
|
||||||
"header": "base/assets_manager.h",
|
"header": "base/assets_manager.h",
|
||||||
"desc": " 资源管理器。\r\n 这里的资源管理器并非Windows下的文件浏览器,而是负责对各种资源,比如字体、主题、图片、界面数据、字符串和其它数据的进行集中管理的组件。引入资源管理器的目的有以下几个:\r\n\r\n *\r\n让上层不需要了解存储的方式。在没有文件系统时或者内存紧缺时,把资源转成常量数组直接编译到代码中。在有文件系统而且内存充足时,资源放在文件系统中。在有网络时,资源也可以存放在服务器上(暂未实现)。资源管理器为上层提供统一的接口,让上层而不用关心底层的存储方式。\r\n\r\n *\r\n让上层不需要了解资源的具体格式。比如一个名为earth的图片,没有文件系统或内存紧缺,图片直接用位图数据格式存在ROM中,而有文件系统时,则用PNG格式存放在文件系统中。资源管理器让上层不需要关心图片的格式,访问时指定图片的名称即可(不用指定扩展名)。\r\n\r\n *\r\n让上层不需要了解屏幕的密度。不同的屏幕密度下需要加载不同的图片,比如MacPro的Retina屏就需要用双倍解析度的图片,否则就出现界面模糊。AWTK以后会支持PC软件和手机软件的开发,所以资源管理器需要为此提供支持,让上层不需关心屏幕的密度。\r\n\r\n *\r\n对资源进行内存缓存。不同类型的资源使用方式是不一样的,比如字体和主题加载之后会一直使用,UI文件在生成界面之后就暂时不需要了,PNG文件解码之后就只需要保留解码的位图数据即可。资源管理器配合图片管理器等其它组件实现资源的自动缓存。\r\n\r\n当从文件系统加载资源时,目录结构要求如下:\r\n\r\n ```\r\n assets/raw/\r\n fonts 字体\r\n images 图片\r\n x1 普通密度屏幕的图片。\r\n x2 2倍密度屏幕的图片。\r\n x3 3倍密度屏幕的图片。\r\n xx 密度无关的图片。\r\n strings 需要翻译的字符串。\r\n styles 主题数据。\r\n ui UI描述数据。\r\n ```\r\n\r\n",
|
"desc": " 资源管理器。\r\n 这里的资源管理器并非Windows下的文件浏览器,而是负责对各种资源,比如字体、主题、图片、界面数据、字符串和其它数据的进行集中管理的组件。引入资源管理器的目的有以下几个:\r\n\r\n * 让上层不需要了解存储的方式。\r\n 在没有文件系统时或者内存紧缺时,把资源转成常量数组直接编译到代码中。在有文件系统而且内存充足时,资源放在文件系统中。在有网络时,资源也可以存放在服务器上(暂未实现)。资源管理器为上层提供统一的接口,让上层而不用关心底层的存储方式。\r\n\r\n * 让上层不需要了解资源的具体格式。\r\n 比如一个名为earth的图片,没有文件系统或内存紧缺,图片直接用位图数据格式存在ROM中,而有文件系统时,则用PNG格式存放在文件系统中。资源管理器让上层不需要关心图片的格式,访问时指定图片的名称即可(不用指定扩展名)。\r\n\r\n * 让上层不需要了解屏幕的密度。\r\n 不同的屏幕密度下需要加载不同的图片,比如MacPro的Retina屏就需要用双倍解析度的图片,否则就出现界面模糊。AWTK以后会支持PC软件和手机软件的开发,所以资源管理器需要为此提供支持,让上层不需关心屏幕的密度。\r\n\r\n *对资源进行内存缓存。\r\n 不同类型的资源使用方式是不一样的,比如字体和主题加载之后会一直使用,UI文件在生成界面之后就暂时不需要了,PNG文件解码之后就只需要保留解码的位图数据即可。资源管理器配合图片管理器等其它组件实现资源的自动缓存。\r\n\r\n当从文件系统加载资源时,目录结构要求如下:\r\n\r\n ```\r\n assets/{theme}/raw/\r\n fonts 字体\r\n images 图片\r\n x1 普通密度屏幕的图片。\r\n x2 2倍密度屏幕的图片。\r\n x3 3倍密度屏幕的图片。\r\n xx 密度无关的图片。\r\n strings 需要翻译的字符串。\r\n styles 主题数据。\r\n ui UI描述数据。\r\n ```\r\n\r\n",
|
||||||
"name": "assets_manager_t",
|
"name": "assets_manager_t",
|
||||||
"annotation": {
|
"annotation": {
|
||||||
"scriptable": true
|
"scriptable": true
|
||||||
|
Loading…
x
Reference in New Issue
Block a user