初夏之际，OpenAtom OpenHarmony(简称“OpenHarmony”) 4.0 Beta1版本如期而至。4.0 Beta1版本在3.2 Release版本根底上，持续晋升规范零碎的ArkUI、利用框架、图形媒体等子系统能力，并提供首批API Level 10接口。

作为OpenHarmony 4.0的首个Beta版本，推出了系列新个性。期待社区开发者踊跃体验新个性，奉献智慧与力量，独特促成将来 4.0 Release版本的成熟，亲自参加并见证OpenHarmony 4.0版本的倒退历程。

下文介绍下OpenHarmony 4.0 Beta1版本局部新个性。想理解该版本的残缺个性信息，请您返回OpenHarmony 4.0 Beta1 Release Notes理解。生态搭档商用设施或软件发行版通过兼容性测评请应用OpenHarmony 3.2 Release版本。

OpenHarmony 4.0 Beta1 Release Notes
https://gitee.com/openharmony/docs/blob/master/zh-cn/release-...

利用框架

1. Extension能力最小化治理，反对各类Extension依据业务场景凋谢API，避免敏感API的调用。
2. 反对数据或文件的URI长期受权，利用能够把本人文件的读写权限受权给其余利用。
3. 反对了UIExtension机制，用于实现有界面的Extension，UIExtension的界面能够嵌入到调用方利用的窗口上显示。目前已构建UIExtension根底能力：
● 反对对立的UIExtension模板，接口含意清晰，服务开发标准化。
● 反对原生默认的Extension界面展现，不便开发者疾速实现Extension性能，同时也提供界面定制能力。
4. 反对原子化服务的分享，利用开发者能够应用UIAbility组件提供的办法，设置要分享的数据。用户能够通过分享框把原子化服务和卡片分享到另外一台终端设备。

ArkUI

1. 组件属性变动反对过渡动效，如Divider组件配置宰割条色彩和色彩属性时应用过渡动效，晋升组件属性变动时的用户体验。
2. Text/Image/Video/ListItem/GridItem组件反对用户长按组件默认进入拖拽行为，反对开发者敞开默认拖拽，晋升开发者开发效率。
3. 自定义弹框反对蒙层色彩、弹出动画自定义（如容许开发者设置弹出动画成果的相干参数），加强弹框的开发者自定义能力。
4. 反对文本组件中返回输出字符串宽高的能力，用于字符串折叠显示时，鼠标悬浮可弹出字符串残缺提示框。

利用包治理

1. 反对利用包不解压装置的个性，优化了系统启动性能和利用装置性能。
2. 反对三方生态利用应用零碎利用提供的共享包能力，三方利用不须要在本身的安装包里集成相干内容（包含代码、资源以及.so文件等），从而达到缩小生态利用的集成老本以及更新老本的目标。

分布式数据管理

1. 支持系统利用通过数据管理服务代理静默拜访其余零碎利用的DataShareExtension数据，反对通过数据管理服务代理拜访Single模式利用DataShareExtension的数据。
2. DataShare客户端提供按URI前缀订阅DataShareExtension数据变动的能力，被订阅的URI前缀下任何DataShareExtension数据发生变化都会告诉DataShare客户端。
3. 新增对立数据管理框架（Unified Data Management Framework, UDMF），反对数据标准化模型、设施内数据拖拽、UDMF数据存储适配、权限治理、生命周期治理。

文件治理

1. 反对文件分类视图治理能力，图库等利用以相册形式治理媒体文件（图片、视频无需关注具体存储地位），提供相册内增加、移除文件等性能不波及具体的FileIO行为。API接口待后续版本凋谢。
2. 提供加强的FileIO拜访能力，反对randomAccessFile、moveDir、copyDir、watcher能力。
3. 提供基于URI的文件长期受权拜访及勾销受权能力，反对文件的跨利用本地受权或跨设施受权。

图形显示

1. 反对组件自绘制内容的属性动画，反对组件呈现隐没转场动画。
2. 对对立渲染模式进行了性能优化，蕴含IPC性能优化（如通过共享内存形式传递渲染资源升高IPC通信量）、反对控件级别遮挡剔除仅需渲染下层控件升高GPU渲染工作量，使能硬件合成器进步合成能效等。
3. 图片编解码反对SVG解码，GIF格局欠缺参数解析，如总帧数、工夫距离等。

窗口

1. 反对监听窗口的获焦状态：之前版本利用开发者仅能够监听WindowStage的获焦状态，但针对零碎窗口和利用子窗口的获焦事件无奈监听。当初，利用开发者能够通过在window上注册windowEvent的形式，监听单个窗口的获焦、失焦和显示暗藏状态。
2. 反对将子窗口z轴程序调整到顶层：之前版本对于利用中创立的多个子窗口，零碎总是将最初显示窗口显示在所有子窗口的最顶层。同时，以后零碎中默认会将用户触摸或者鼠标点击的窗口晋升至所有子窗口的最顶层。当初，通过window对象的raiseToAppTop办法，利用开发者能够自行将某个子窗口调整至WindowStage多个子窗中的最顶层。
3. 重构沉迷式实现形式，优化利用关上、退出、跳转下的动画成果：之前版本，利用关上时全屏利用窗口大小默认不蕴含状态栏和导航栏的区域，除非利用调用沉迷式接口（通过setWindowLayoutFullScreen或者setSystemBarEnable）。沉迷式利用在关上的过程中调用上述接口，会导致关上动画呈现跳变，影响利用关上和利用间跳转动画的体验。新版本上，无论是否设置沉迷式显示，全屏显示的利用窗口大小都蕴含状态栏和导航栏的区域，而非沉迷式利用的状态栏、导航栏避让会通过ArkUI限度利用显示区域实现。

媒体

音频能力
1. 反对通过native接口进行音频播放和录制。
2. 反对查问或监听以后优先级最高的播放设施。
3. 反对音频焦点，利用播放音频时无需手动申请焦点，零碎会在后盾主动申请焦点，并主动执行焦点策略（如暂停、淡出、淡出复原等）；利用仅须要注册焦点事件监听函数，以接管焦点事件并更新状态，如暂停时进行进度条。

播控框架
1. 反对媒体提供方和管制方之间传递自定义媒体信息，利用可扩大媒体内容展现形式，如媒体管制方可要求媒体提供方按非凡模式显示歌曲歌词。
2. 反对媒体播放列表的框架能力，媒体提供方提供播放列表内容，媒体管制方获取播放列表内容并能够抉择任一媒体内容进行播放。
3. 反对播放历史记录的框架能力，媒体会话框架提供查问历史播放利用的列表，列表项按播放先后顺序排序（蕴含以后播放的和已退出的利用）。

媒体播放
1. 反对HLS直播以及基于datasource的流式播放能力、反对H.265视频硬解播放能力。
2. 反对播放音效、音频属性设置，反对带旋转角度视频的主动旋转播放。
3. 反对多音轨获取与切换、反对外挂字幕设置与切换。

相机

1. 欠缺ArkTS API的错误码和异样解决机制，使开发者能够通过查问错误码定位错误信息。
2. 反对前置预览镜像能力，默认状况下，前置预览画面呈镜像状态。
3. 不同相机利用应用同一个摄像头场景下，相机框架具备优先级管控和互斥策略。