『鸿蒙开发笔记』高负载服务流转的解决方案 原创 精华

大家好，我们是HarmonyOS开发者创新大赛的参赛作品《主题协作器》。这一期内容，主要带大家了解一下，服务流转需要携带较多数据量时的解决方案。

标准的HarmonyOS应用流转主要有两种形式，一种是使用IAbilityContinuation中的onSaveData与onRestoreData方法，另一种则是在使用startAbility前，为intent意图附上被流转设备的DeviceId。

在某些特定的场景下，我们的APP可能需要传递较大的数据量，如果直接采用标准的两种流转方式，很容易造成线程拥堵，以及较长的空白页等待。为此，我们采用了多线程与过渡页的形式，打造了一套独特的解决方案：
1、用户发起流转指令后，设备甲中的AbilitySlice会使用startAbility的方式，唤起设备乙上的配套Ability，但本次唤起不会传递任何大型文件数据。同时，设备乙上的配套Ability会优先使用StackLayout中的上级遮盖图层，即流转过渡页图层，以营造转场过渡效果。

2、设备甲在收到流转指令时，会事先配上一份回调函数，待设备乙上的过渡页渲染完毕，设备甲会向设备乙发起二次唤起。我们的Ability采用的是singleton单实例模式，进行二次回调唤起时，设备乙一定是在onNewIntent中发生的。二次唤起时，由于设备乙已渲染过相关转场图层，这时我们只需要再创建一个多线程计划，然后在新的线程里完成大型的文件传输，并在传输完成后通知主线程对上方过渡图层作Hide处理，即可顺利营造流转过渡效果，用户感知起来也更自然、更美观！

3、由于我们没有采用AbilityContinuation中的onSaveData与onRestoreData方法，因此我们在完成上述文件传输时，需要运用到分布式文件服务，即getDistributedDir接口。当用户发起流转指令，设备甲会将需要流转的视频、图片等较大文件，先复制到本端的分布式目录。考虑到设备甲通常是在AbilitySlice中发起流转的，而被流转的设备乙，仅可通过配套的Ability承接，这样各端在使用getDistributedDir接口时，就会出现获取的分布式目录不一致，从而找不到需要跨端传递的文件。因此，设备甲会在二次回掉唤起设备乙中的Ability时，在Intent内一并附上设备甲的分布式目录名与其它文本参数，以供设备乙承接。

4、当用户在被流转的设备乙上，对部分参数或文件进行修改，也可以再次点击设备乙中的流转按钮发起回迁。回迁流程与上述流程几乎一致，唯一的区别是：设备乙作为流转发起端时，通常是在Ability中进行的，而设备甲通常在AbilitySlice中进行。除非，用户在设备乙回迁至设备甲的相关Ability中，再次发起了流转。

5、如果用户将设备甲上的内容流转至设备乙，然后修改了设备甲上的部分参数或文件，再次从设备甲向设备乙发起流转，设备甲会重复上述1至3的动作。这不是设备甲首次将数据迁移至设备乙，设备乙上的配套Ability在这一轮的动作1里，默认状况并不是StackLayout中的过渡图层覆盖至最顶层，并且这里的动作1也是触发的onNewIntent而非onStart，设备乙会在这一次动作1里手动将过渡图层设置为Visible，然后再执行动作2。
<br>
这样，我们的HarmonyOS应用，在携带较大数据量进行流转时，用户也会感知的更自然，大家都学会了吗？我们下一期再见啦~