一、为啥不用FA
其实目前鸿蒙原生应用开发方式就两种,一种是Stage一种是FA。而开发底层设备需要用C++配合framework开发。像是串口啥的。
但是也注意,C++开发用的不是glibc,而是和安卓,alpine这种系统的精简版libc。大部分情况下影响不大,唯一注意的是代码不通用。
FA开发虽然叫做快速开发,但是其实在本质上它本身的学习成本也不低,再加上灵活度不如Stage,目前还是推荐stage,当然,你要是大量开发轻应用,还是fa吧。
二、基本功能风格和功耗测试
这里功耗测试是基于一个小的鸿蒙应用及多媒体使用。
预览器可以很好地查看应用。但是不幸的是不包含多媒体应用。
鸿蒙的初始常见格局标签是Column和row。这里两个组件有split版本。这俩版本虽然有组件分割线,也能手动拖动大小,但是缺少了大量基本的架构控制属性。也就是这两种东西的使用方法是不一样的。
就如上面的,被分割的两个大小固定平分的组件,就是用row实现的。
这里也引出了另一个问题,那就是arkts的容器组件不是包被组件,而是控制声明。
按照bootstrap的写法,每个被row组件包裹的容器占用row组件的空间,使用row本身的size组件,也就是N/12去控制里面组件的实际大小。
但是如果到了arkts你会发现row并不受控,而是它的下属组件会乖乖按照row原本的规则排列。
也就是说row下属的组件会按照row的规则排列,而不是row本身当做容器包被组件控制尺寸。
Row() {
Text(this.message)
.fontSize(50)
.fontWeight(FontWeight.Bold)
}
.backgroundColor(0x000000)
.width('50%')
.height('100%')
.alignItems(VerticalAlign.Center)
.justifyContent(FlexAlign.Center)
但是,如果让row包裹row可以控制一群组件的大小尺寸
Video({ src: this.videoSrc,
previewUri: this.previewUri,
currentProgressRate: this.curRate,
controller: this.controller})
像是鸿蒙这种组件式开发,开发个带控制的video还是简简单单
【不能上传段视频】
从视频可以看出,在安装应用的时候会有个快速的2-3瓦的功耗跳变。
而播放视频则是有个稳定3瓦的提升。
从播放视频时的状态来看,电源直接飙升了3度。当然,对于电源来说这点稳定提升不算什么。而且温度提升并不是线性提升,而是随着温度升高,自然散热率会不断飙升。
|