54.应用开发的有些场景中,如果希望根据条件导入模块或者按需导入模块,可以使用动态导入代替静态导入,下面导入场景中适合使用动态import的是
A.当静态导入的模块很明显的降低了代码的加载速度且被使用的可能性很低,或者并不需要马上使用它。
B.当被导入的模块说明符,需要动态构建。
C.当被导入的模块,在加载时并不存在,需要异步获取。
D.当静态导入的模块很明显的占用了大量的系统内存且被使用的可能性很低。
55.下面关于混淆规则描述正确的是
A.-enable-export-obfuscation:开启直接导入或导出的类或对象的名称和属性名混淆
B. -disable-obfuscation:关闭所有混淆
C.-enable-toplevel-obfuscation:开启属性混淆
D.-enable-property-obfuscation:开启顶层作用域名称混淆
56.ArkTS中不能使用以下哪些类型。
A.tuple type
B. any
C. unknown
D. union type
57某App有A、B、C、D四个团队分别负责ModuleA、ModuleB、ModuleC和ModuleD四个业务模块,随着业务的发展,ModuleA需要跳转到ModuleB、ModuleC的页面ModuleB需要跳转到ModuleC、ModuleD的界面,Modulec需要跳转到ModuleA的界面,ModuleD需要跳转到ModuleB和ModuleC的界面。由于复杂的依赖关系,导致一旦有变化就需要知会各个团队,所以该团队的架构师想要解耦各个业务模块,以下哪些做法是不推荐的()
A. 采用静态import方式引入对应跳转的页面,
B. 采用RouterModule作为中介者并用动态import解耦各个业务模块。
C. 在RouterModule中采用路由表方式解耦各个业务模块。
D.可以采用Navigation作为页面导航根容器,将其放在entry中,其他Module的页面作为Navigation的子页面。
58.以下代码片段哪几个class/interface违反了ArkTS语法规范
class Person {}
class Student extends Person {}
class Instructor implements Person {}
interface Shape {}
interface Circle implements Shape {)
class Square implements Shape {}
A.Circle
B.Square
C.Student
D.Instructor
59.以下关于HAP(Harmony Ability Package).说法正确的是()
- HAP是应用安装和运行的基本单位,在DevEo co Studio工程目录中,一个HAP对应一个Module。应用打包时,所有的Module都只能生成.hap文件。
- 应用工程编出的app文件中,只能包含一个hap文件。
C.应用工程如果包含多个Module,在应用市场上架时,会将多个.hap文件打包成一个.app文件。
D. DevEco Studio会在编译构建时,不需要对HAP进行一致性校验。
60.以下对系统兼容性的理解正确的是
A系统能力都会保持绝对的兼容性,不能因为任何非非兼容性的修改而导致开发者成本上升
B.已发布的系统能力有可能会发生非兼容性变更,比如新增特性或修改问题导致的行为不兼容,这种情况下应用需要关注changelog并进行适配。
C.安全法律法规等不可控因素会导致系统非兼容性变更,开发者需要积极适配
D.应用不需要关注系统的兼容性变化,那都是系统开开发人员需要关注的事情
61.从桌面冷启动如下应用代码,点击Change按钮5次,整个过程中,代码中的2条log依次出现的次数是:
class Data {
num: number
type: string
constructor(num: number,type:string)
{this.num = num;
this.type = type;}
}
@Reusable
@Component
struct Item {
@State data: Data |undefined = undefined;
aboutToAppear(): void {
console.log("Demo log1")
}
aboutToReuse(params: ESObject): void {
console.log("Demo log2");
this.data=params.data
}
build() {
Text("num="+this.data?.num+",type="+this.data?.type)
}
}
@Entry
@Component
struct Test1Page {
data1:Data=new Data(1,"type1")
data2:Data=new Data(2,"type2")
@State data:Data=this.data1
build() {
Column(){
if (this.data.type=="type1"){
Item({data:this.data}).reuseId(this.data.type)
}else {
Item({data:this.data}).reuseId(this.data.type)
}
Button('Change').onClick(()=>{
if (this.data===this.data1) {
this.data=this.data2
}else{
this.data=this.data1
}
})
}
}
}
A.2,4
B.6,0
C1,5
D1,0
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-由于未拥有该商品,发货失败时