【HarmonyOS Next之旅】DevEco Studio使用指南(三)

【HarmonyOS Next之旅】DevEco Studio使用指南(三)

目录

1 -> 一体化工程迁移

1.1 -> 自动迁移

1.2 -> 手动迁移

1.2.1 -> API 10及以上历史工程迁移

1.2.2 -> API 9历史工程迁移


1 -> 一体化工程迁移

DevEco Studio从 NEXT Developer Beta1版本开始,提供开箱即用的开发体验,将SDK、Node.js、Hvigor、OHPM等工具链进行合一打包,简化DevEco Studio安装配置流程;并提供一体化的历史工程迁移能力,帮助开发者快速完成工程转换。

注意

为了避免数据丢失,迁移前请对工程进行备份。

一体化变更点如下:

变更点详细说明
删除compileSdkVersion字段

删除工程级build-profile.json5中的compileSdkVersion配置。

说明

  • 由于targetSdkVersion未配置时值默认与compileSdkVersion的值一致,如果之前未配置targetSdkVersion,targetSdkVersion的值将与配套的SDK版本保持一致;如果之前配置过targetSdkVersion,targetSdkVersion的值不变。
  • 若工程为Openharmony工程,则无需执行此步骤。
删除部分hvigor文件 & 删除冗余hvigor配置
  1. 删除hvigor-wrapper.json。
  2. 删除hvigorw、hvigorw.bat。
  3. 删除hvigor-config.json5中的hvigorVersion字段,并删除dependencies中@ohos/hvigor-ohos-plugin及rollup字段。
删除HarmonyOS SDK配置删除local.properties中的HarmonyOS SDK配置。若工程为Openharmony工程,则忽略此步骤。
增加开发态配置
  1. 在hvigor-config.json5中增加开发态配置版本号modelVersion。
  2. 在工程级的oh-package.json5中增加开发态配置版本号modelVersion。

1.1 -> 自动迁移

1. 打开历史工程,Notifications通知栏将出现“Sync failed.”同步失败提示,点击Migrate Assistant,进入迁移助手页面。

说明

可以通过菜单栏Tools > Migrate Assistant,进入迁移助手页面。

2. 在页面下方的Migrate Assistant页签中选择迁移到5.0.0/5.0.1/5.0.2,并点击Migrate按钮,此时将出现弹窗提示开发者进行数据备份。若确认已完成备份,请点击弹窗中Migrate,启动迁移任务。

3. 待工程重新完成同步,并无其他报错提示,即为迁移成功。

说明

若工程是NPM管理的API 8/9工程,先按照适配OHPM包管理完成升级,再通过菜单栏Tools > Migrate Assistant,进入迁移助手页面,完成一体化工程自动迁移。

1.2 -> 手动迁移

1.2.1 -> API 10及以上历史工程迁移

如自动化迁移不成功或希望进行手动迁移,迁移前同样需对工程进行备份。手动迁移流程如下:

1. 进入工程级build-profile.json5文件,删除compileSdkVersion配置。若工程为Openharmony工程,则无需删除compileSdkVersion字段。

2. 删除并修改Hvigor相关文件:

  • 在左侧工程目录中删除hvigorw、hvigorw.bat文件,并删除hvigor目录下的hvigor-wrapper.js文件。
  • 进入hvigor > hvigor-config.json5文件中,新增modelVersion字段,以API 12为例,其值为"5.0.0"。并删除hvigorVersion字段、dependencies中的@ohos/hvigor-ohos-pluginrollup字段

3. 在工程级oh-package.json5文件中同样也需新增modelVersion字段,以API 12为例,其值为"5.0.0"。

4. 在local.properties文件中,删除HarmonyOS SDK配置。若工程为Openharmony工程,则无需执行此步骤。

5. 点击编辑界面上方Sync now或进入菜单栏点击File > Sync and Refresh Project,重新进行工程同步。若无其他报错,至此历史工程手动迁移完成。

1.2.2 -> API 9历史工程迁移

1. 将工程级build-profile.json5文件中compileSdkVersion字段删除,并将compatibleSdkVersion字段从app字段下迁移到当前选中的product中。当前生效的product可以通过点击编辑区域右上方

2. 请将compatibleSdkVersiontargetSdkVersion(若已配置)从9改为4.0.0(10),并配置runtimeOS。版本号需满足M.S.F(X)规则的字符串类型,使用英文.和()。

"app": { "signingConfigs": [], "products": [ { "name": "default", "signingConfig": "default", "compatibleSdkVersion": "4.0.0(10)", //指定HarmonyOS应用/元服务兼容的最低版本。 "targetSdkVersion": "4.0.0(10)", //指定HarmonyOS应用/元服务目标版本。若没有设置,默认为compatibleSdkVersion "runtimeOS": "HarmonyOS", //指定为HarmonyOS } ], ... }

3. 将其他各模块级别的build-profile.json5文件中target字段下配置的runtimeOS删除。

4. 剩下的步骤与API 10及以上的步骤相同,参考1.2.1的步骤二完成余下手动迁移步骤。

说明

  • 一键升级只针对当前选择的product生效。
  • 如有多个product,需要分别切换不同product后,按照手动升级的方式对工程进行升级。每一个product下都需要配置相应的compatibleSdkVersion和runtimeOS。
  • 针对API 8/9 NPM工程,请先按照适配OHPM包管理完成升级,再按照API 9历史工程迁移完成手动迁移配置。
  • 从DevEco Studio 4.0 Release版本开始,代码编辑器及编译构建过程增强了对ArkTS语法规范的检查,如果历史工程中存在不符合ArkTS语法规范的代码,在迁移完成后可能会报错,需根据具体报错信息修正不符合ArkTS语法规范的代码。
  • 如果历史工程包含低代码方式开发的界面,在迁移完成后,需要将这部分低代码开发的界面转换为ArkTS代码,并修正相关报错后才可以正常编译。代码转换操作会删除visual文件及其父目录,且为不可逆过程,代码转换后不能通过ets文件反向生成visual文件。

感谢各位大佬支持!!!

互三啦!!!

Read more

C++之基于正倒排索引的Boost搜索引擎项目searcher部分代码及详解

C++之基于正倒排索引的Boost搜索引擎项目searcher部分代码及详解

这个searcher.hpp的本质是一种使用其他文件,然后实现自己功能的一种更上层的封装。 它主要实现的是就是他用户的搜索词进行处理,接着根据这个处理结果来返回网页给用户。 1. 单例模式 这边的话我们使用的是单例模式来进行实例化。同时我们建立正倒排索引。 private: ns_index::Index* index; public: Searcher(){}; ~Searcher(){}; public: void InitSearcher(const std::string& input) { //1 创建(获取)一个index对象 //在这里我们用的是单例模式 index=ns_index::Index::Getinstance(); //2根据对象建立索引 index->BuildIndex(input); //std::cout<<"建立索引成功"<<std:

By Ne0inhk
【C++】优先队列(Priority Queue)全知道

【C++】优先队列(Priority Queue)全知道

亲爱的读者朋友们😃,此文开启知识盛宴与思想碰撞🎉。 快来参与讨论💬,点赞👍、收藏⭐、分享📤,共创活力社区。   目录 一、前言 二、优先队列(Priority Queue):排队也有 “特权”? (一)优先队列是啥? (二)C++ 里怎么用优先队列? (三)优先队列内部到底咋回事? 1. 秘密武器:二叉堆(Binary Heap) 2. 元素进出的 “魔法” 插入(push)元素 删除(pop)元素 (四)优先队列都在哪里大显身手? 1. 任务调度:谁先谁后安排好 2. 图算法中的 “指路明灯” 3. 数据压缩:让数据 “瘦身” 有妙招

By Ne0inhk

C++26并发编程新特性(任务队列容量优化全攻略)

第一章:C++26任务队列容量机制概述 C++26 标准在并发编程领域引入了对任务队列容量控制的正式支持,旨在提升异步任务调度的可预测性和资源管理能力。该机制允许开发者在创建任务队列时指定最大容量,从而避免无限排队导致的内存溢出或系统响应延迟。 设计目标 * 防止任务积压引发的资源耗尽 * 提供统一的接口以支持有界与无界队列切换 * 增强 std::executor 与 std::task_block 的协同行为 核心接口变更 在 C++26 中,标准库扩展了 std::execution::queue_properties 结构体,新增 capacity 成员用于定义队列上限。当提交任务超出容量时,将抛出 std::queue_overload_error 异常或触发用户定义的拒绝策略。 // 定义一个最多容纳100个任务的执行队列 std::execution::queue_config config; config.capacity = 100;

By Ne0inhk