【HarmonyOS开发】记录一次SDK的适配流程

大前端腾宇

共 2832字,需浏览 6分钟

 · 2024-04-10

2f862b268d4f8081fcb3c8c5d9d65517.webp

学习最好的方式就是使用项目来学习,最近在开发一个移动白板,参考官方的Demo,但是发现无法运行,最终发现SDK不匹配导致,记录一下处理过程。

效果展示

1、升级适配前;

f0131a4437fda5cbae15a5a4cc212447.webp

发现一堆的报错,看着着实有点头大1d1e41adbda7e8c4457545390737b87f.webp1d1e41adbda7e8c4457545390737b87f.webp1d1e41adbda7e8c4457545390737b87f.webp

2、升级适配后;

4019dc6f317c76c389a9d54832fbfb1d.webp

找寻问题

1、安装依赖;

2、在预览器中查看,编译;

3、分析问题可能性

  • 是否SDK导致API不匹配,升级 / 降级是否可以解决;

  • 分析错误原因;

解决方式

1、升级/降级是否可以解决

0d920ba538b3730de6afff43bca561f0.webp

1.1 发现该项目使用的是API10进行编译的,先将其 为API9试试;

b0ba34d7309e4e6487ae4bf12e4ba3bb.webp

1.2 查看是否切换成功;

7796d9d03c87c968fe7b253897817a51.webp

1.3 重新编译是否可行,可以最好,不行的话只能从代码层次去进行适配

0cec28d24ada4057a3a0bb4d82adcd71.webp

还是老样子,不行af2802615cd48f975734c7ed2326fb38.webpaf2802615cd48f975734c7ed2326fb38.webpaf2802615cd48f975734c7ed2326fb38.webp

2、分析代码错误原因

2.1 从整体上看,是由于设备管理这个库报的错

4e33aa38fd613e242713c0ff65d2a1a7.webp

进入接口文件,发现里面并没有什么内容,从API7开始支持,因此可以判定,这个库(@ohos.distributedHardware.deviceManager)不能使用喽!47f20c9b07318f1fe7b48184723ebdb7.webp47f20c9b07318f1fe7b48184723ebdb7.webp47f20c9b07318f1fe7b48184723ebdb7.webp

2.2 查询是否存在可替代的库

9036e57b4655db18bf3bfd6d29ae22b7.webp

还真有,这一点OpenHarmony做的有点不地道,API10中还保留有原有的API,但是里面的属性方法没了~~~

2.3 代码层次适配

点击预览器日志,进入每个错误里面,进行代码层次的适配,有一点需要注意,新的API中可能不包含旧的方法,需要查找替代的方法。

d700dc96b7b6d35520572d0e724aa9e9.webp

如何查找替代方法

29add0ca32b2676d2d960cdb8896df90.webp

1、在API文档中找到报错版本中的方法;

267af3d372260778ed4e26be45860dd2.webp

2、使用关键字在新API文档中查询替代方法;

63128b1588ffdcfcd77bf76b5be43a77.webp

如果有,直接替换即可

      
        
          // 修改前
        
      
      
        import deviceManager from '@ohos.distributedHardware.deviceManager';
      
      
        @StorageLink('deviceList') deviceList: deviceManager.DeviceInfo[] = [];
      
      
        
          
// 修改后 import deviceManager from '@ohos.distributedDeviceManager'; @StorageLink('deviceList') deviceList: deviceManager.DeviceBasicInfo[] = [];

但是,有点悲催,并没有找到很方便的替代方法,但是我们找到了可以组合起来使用的方法,最终修改为

      
        
          // 修改前
        
      
      
        import deviceManager from '@ohos.distributedHardware.deviceManager';
      
      
        try {
      
      
          this.localDevice = this.myDeviceManager.getLocalDeviceInfoSync();
      
      
          this.localDevice.deviceName = CommonConstants.LOCALHOST_NAME;
      
      
        } catch (error) {
      
      
          Logger.error('RemoteDeviceModel',
      
      
            `getLocalDeviceInfo failed, error=${JSON.stringify(error)}`);
      
      
        }
      
      
        
          
// 修改后 import deviceManager from '@ohos.distributedDeviceManager'; try { this.localDevice.deviceId = this.myDeviceManager.getLocalDeviceId(); this.localDevice.deviceName = CommonConstants.LOCALHOST_NAME; this.localDevice.deviceType = this.myDeviceManager.getDeviceType(this.localDevice.deviceId); } catch (error) { Logger.error('RemoteDeviceModel', `getLocalDeviceInfo failed, error=${JSON.stringify(error)}`); }[];

个人观点

OpenHarmony的代码审核是很繁琐,流程很麻烦的,而且审核人员很多都是HW的开发者,上到仓库的代码,至少应该保证可用,还有基于不同SDK版本开发的,最好能够使用分支进行记录,方便大家查看,最新的SDK,在很多实际项目中,都还未使用,我们肯定是基于最稳定的版本进行开发。希望官方后面可以优化一下,也望2024OpenHarmony更上一层楼。@OpenHarmony

c049a269bd2819c92ba1f52ac3844bf5.webp

浏览 3
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

举报