mirror of
https://github.com/zlgopen/awtk.git
synced 2025-05-08 19:44:45 +08:00
update docs
This commit is contained in:
parent
f2f48473c4
commit
d836643daa
@ -94,7 +94,7 @@ PointerAlignment: Left
|
||||
RawStringFormats:
|
||||
- Language: TextProto
|
||||
BasedOnStyle: google
|
||||
ReflowComments: true
|
||||
ReflowComments: false
|
||||
SortIncludes: false
|
||||
SortUsingDeclarations: true
|
||||
SpaceAfterCStyleCast: false
|
||||
|
@ -3,22 +3,22 @@
|
||||
资源管理器。
|
||||
这里的资源管理器并非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 字体
|
||||
images 图片
|
||||
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"> 设置一个函数,该函数用于生成资源路径。
|
||||
|
||||
>
|
||||
有时我们需要优先加载用户自定义的资源,加载失败才加载系统缺省的,可用设置一个函数去实现这类功能。
|
||||
> 有时我们需要优先加载用户自定义的资源,加载失败才加载系统缺省的,可用设置一个函数去实现这类功能。
|
||||
|
||||
|
||||
|
||||
|
@ -38,22 +38,22 @@ typedef ret_t (*assets_manager_build_asset_dir_t)(void* ctx, char* path, uint32_
|
||||
* 资源管理器。
|
||||
* 这里的资源管理器并非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 字体
|
||||
* images 图片
|
||||
* 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
|
||||
* 设置一个函数,该函数用于生成资源路径。
|
||||
*
|
||||
* >
|
||||
* 有时我们需要优先加载用户自定义的资源,加载失败才加载系统缺省的,可用设置一个函数去实现这类功能。
|
||||
* > 有时我们需要优先加载用户自定义的资源,加载失败才加载系统缺省的,可用设置一个函数去实现这类功能。
|
||||
*
|
||||
* @param {assets_manager_t*} am asset manager对象。
|
||||
* @param {assets_manager_build_asset_dir_t} custom_build_asset_dir 回调函数。
|
||||
|
@ -30,7 +30,6 @@
|
||||
* MIME_TYPE。
|
||||
*/
|
||||
|
||||
|
||||
/**
|
||||
* @const MIME_TYPE_APPLICATION_ENVOY
|
||||
* "application/envoy"。
|
||||
|
@ -16282,7 +16282,7 @@
|
||||
}
|
||||
],
|
||||
"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",
|
||||
"return": {
|
||||
"type": "ret_t",
|
||||
@ -16362,7 +16362,7 @@
|
||||
"events": [],
|
||||
"properties": [],
|
||||
"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",
|
||||
"annotation": {
|
||||
"scriptable": true
|
||||
|
Loading…
x
Reference in New Issue
Block a user