62.根据上面代码,以下解释正确的是
@State title: string ="";
@State mode: Mode = Mode.fullScreen;
isShownTitle(): boolean {
if (this.mode == Mode.fullScreen) {
this.title = "Title";
return true;
} else {
this.title = "section";
return false;
}
}
build(){
Column(){
if (this.isShownTitle()){
Text(`${this.title}`)
}
}
}
}
struct changeMode {
@Prop mode: Mode;
build(){
Row({space: 20}) {
Button('full screen').onClick(() => {
this.mode = Mode.fullScreen;
})
Button('half screen').onClick(() => {
this.mode = Mode.halfScreen;
})
}
}
A.为了避免@Prop的拷贝,可以优化使用@Link,在该例子中行为和@Prop一样。
B.在自定义组件Page的build方法里改变状态变量是非法操作,可能导致未定义的异常UI行为。
C.本例子可以运行起来,所以代码没有问题。
)D.在ChangeMode里改变mode的值,会触发其父组件Page的Title内容的切换
63.以下关于ArkUI NavDestination组件的生命周期执行顺序中正确的是
A.onWilappear->onWillShow->onShow->onAppear->onWillHide->onHidden->onWillDisappear->onDisappear
B.onWillappear->onAppear->onWillShow->onShow->onWillHide->onHidden->onWillDisappear->onDisappear
C.onWillappear->onAppear->onWillShow->onShow->onWillDisappear->onWillHide->onHidden->onDisappear
O D.
onWillappear->onAppear->onWillShow->onShow->onWillHide->onWillDisappear->onHidden->onDisappear
64.用户购买商品后,你需要及时发放相关权益。但实际应用场景中,若出现异常将导致应用无法知道用户实际是否支付成功,从而无法及时发放权益,即出现掉单情况。为了确保权益发放,你需要在以下哪些场景检查用户是否存在已购未发货的商品:
A. 应用启动时
B.createPurchase请求返回1001860051-由于已经拥有该商品,购买失败时
C.createPurchase请求返回1001860001-内部错误时
D.finishPurchase请求返回1001860052-由于未拥有该商品,发货失败时
65.在ArkTS中,以下代码片段正确的是
A.
function fn(x: string | number): void {
console.log('value: ' + x);
}
type funcType = (ns: string | number) => string;
let func: funcType = fn;
B.
function fn(x: string): string {
return x;
}
type funcType = (ns: string | number) => string;
let func: funcType = fn;
C.
function fn(x: string | number): string {
return 'value: ' + x;
}
type funcType = (ns: string) => string;
let func: funcType = fn;
D.
function fn(x: string | number): string {
return 'value: ' + x;
}
type funcType = (ns: string | number) => string;
let func: funcType = fn;
66.为了加快构建速度,提高开发效率,可以如何调整hvigor配置,从而优化构建速度
A.启用hvigor的incremental,在增量场景下检查任务是否可以跳过
B.启动hvigor的daemon模式,在增量场景下复用缓存
C.启用hvigor的parallel,在增量场景下进行并行编译处理
D.启用hvigor的typeCheck,在增量场景下进行对hvigorfile.ts进行类型检查
使用如下的代码去启动一个ability时,哪种skills定义的组件能够被匹配到:
let want = {
"uri" : "https://www.test.com:8080/query/books",
"type" : "text/plain"
}
context.startAbility(want).then((data))=> {
console.log(TAG + "startAbility success");
}).catch((err))=> {
console.log(TAG + "startAbility failed.");
}
A.
"skills": [
{
"uris":[
{
"scheme": "https",
"type" : "text/*"
}
]
}
]
B.
"skills": [
{
"uris":[
{
"scheme": "https",
"host": "www.test.com",
"type" : "text/plain"
}
]
}
]
C.
"skills": [
{
"uris":[
{
"scheme": "https",
"host": "www.test.com",
"pathStartWith" : "query/books",
"type" : "text/*"
}
]
}
]
D.
"skills": [
{
"uris":[
{
"scheme": "https",
"host": "www.test.com",
"pathStartWith" : "query/books",
"type" : "text/plain"
}
]
}
]
一个应用通常会包含多种功能,将不同的功能特性按模块来划分和管理是一种良好的设计方式。在开发过程中,我们可以将每个功能模块作为一个独立的Module进行开发,下面关于Module的说法正确的是
A.Ability类型的Module,用于实现应用的功能和特性,有两种类型,分别为entry和feature。
B.entry类型的Module,是应用的主模块,一个应用只能包含唯一一个entry类型的HAP。
C.feature类型的Module,应用的动态特性模块,一个应用中可以包含一个或多个feature类型的模块,也可以不包
D.Library类型的Module,用于实现代码和资源的共享,有两种类型,分别为Static Library和Shared Library两种类型。
当使用状态变量进行ArkUI组件间数据通信的时候,如果两个组件间没有直接的套关系(非父子和祖孙关系组件),但是他们又属于同一页面,最佳的装饰器应该选用哪个?
A. LocalStorage
B. AppStorage
C.@State+@Link
D.@Provide+@Consume