《分鏡頭App》的創作靈感來源于殷冬的日常觀察，他發現平常人們在自拍時，往往會用前置攝像頭，由于像素、取景景別等因素的限制，前攝拍出來的效果往往不是很理想；此外，當我們幫別人拍照時，對方也無法實時看到照片的取景角度和構圖，拍出來的照片也很難讓對方滿意；對于照片的分享和美化，更是眾口難調。為了解決這些痛點，提升用戶的拍照體驗，經過不斷摸索，殷冬發現HarmonyOS的分布式技術有著很大的應用潛力。于是他基于HarmonyOS從0到1完成了《分鏡頭App》的開發。

以下將為大家分享該款應用的開發者殷冬的開發心得。

一，HarmonyOS技術使用

《分鏡頭App》主要用到了分布式文件服務、分布式硬件虛擬化、以及分布式數據服務。

分布式文件服務

利用分布式文件服務，可以自動同步其他設備拍攝的照片和視頻，實現分布式相冊功能。

起初殷冬以為分布式文件服務使用起來會很復雜，例如是否需要自己控制同步、初始化功能等等。而真正接觸后他發現，在底層上，分布式文件服務已經將復雜的工作都處理好了，只需用一行代碼，就可以使用分布式文件服務，就相當于調用本地文件系統一樣，只不過再繼續向下，底層會幫助開發者處理很多業務。

分布式硬件虛擬化

分布式硬件虛擬化的特性，可以調用其他設備的硬件，實現相關的功能。在《分鏡頭App》中，調用其他設備的相機畫面，就用到了分布式硬件虛擬化。并且可以控制拍攝畫面的比例，實現不一樣的拍攝效果。

殷冬最初接觸硬件虛擬化這個概念的時候，只是知道是基于分布式軟總線實現的虛擬化，至于怎么使用，并不是很清楚，后來通過深入的學習發現，主動調用其他設備的接口，可以使用分布式任務調度或者IDL接口兩種方法實現。而分布式任務調度和IDL接口，都可以傳遞實現Sequenceable接口的實現類對象。

而硬件功能關鍵類都實現了Sequenceable接口，比如：相機預覽畫面的關鍵類Surface，就實現了Sequenceable接口。因此可以通過IDL將設備A的Surface對象，以參數的形式，傳遞到設備B。設備B的Service Ability執行相機初始化操作，就可以拿到設備B相機的拍攝畫面。

由此，就在代碼編輯層面實現了硬件虛擬化。

分布式數據服務

在《分鏡頭App》中，有很多的協同操作。協同操作的核心邏輯，利用了分布式數據服務的數據變更通知功能。當一個設備觸發協同操作時，通過變更通知，從設備觸發UI和效果的變化，實現分布式協同功能。

分布式數據服務有兩個功能，可以為開發者帶來很大的便捷。第一個是多端數據同步功能，當通過一個設備修改了數據庫中的數據，其他設備也會做同步。第二個是在添加、修改、刪除數據庫數據時，其他設備如果創建了數據庫的鏈接，并綁定了數據變更監聽時，就會觸發該監聽。開發者可以利用這兩個功能特性，做多端的協同功能。

數據庫初始化：

數據庫變更監聽：

分布式相冊實現

相冊主要存儲圖片、視頻文件，可以使用分布式文件服務進行存儲。此項功能殷冬還需要實現動態添加的效果，即：其他設備拍攝時，本機的相冊列表動態顯示剛剛拍攝的照片縮略圖。這種效果可以在確定使用分布式文件服務存儲照片和視頻后，使用HarmonyOS的公共事件與通知功能，從而實現動態加載的效果。

在拍攝完成時，通過公共事件功能發送一條廣播。

同時，在相冊模塊，注冊公共事件，用于處理接收到通知后的動態添加縮略圖邏輯。

分布式文件服務負責同步拍攝的照片、視頻等信息，公共事件通知則主動進行頁面的刷新，二者合用，實現動態添加的效果。

二、多設備協同實現

目標設備未打開協同頁面問題處理

多設備協同實際上有個隱藏的前提，那就是所有設備都處于同一個協同頁面中。這需要處理目標設備不在協同頁面的問題。

此時可以創建一個單版本分布式數據庫，key值為設備id，value值為協同頁面是否啟動true/false。當進入到協同頁面時，在onStart方法中設置值為true。當退出頁面時，在onInactive方法中設置值為false。

在發起協同前，可以通過單版本分布式數據庫，獲取到目標設備是否啟動了協同頁面。

如果沒有啟動，可以先通過abilitySlice.startAbility（）將目標設備拉起，進入到協同頁面，然后再進入協同狀態。

如果目標設備已經處于協同頁面，就可以直接進入到協同狀態。

統一管理分布式操作

由于分布式數據服務每個應用最多同時打開16個KvStore，所以不能每一個協同操作都使用一個數據庫。這里可以在value值上做文章，以實現通過一個分布式數據庫，就可以實現一個頁面中的多個操作的協同。

首先，可以使用一個常量作為分布式協同數據庫的key。每次put時，都使用這個常量作為key，以替換之前的數據。

其次，需要創建一個實體類。成員變量中，需要有兩個基礎變量：

operationType：int型，當前協同操作的類型；

targetDeviceId：List《String》，需要協同的設備id數組；

operationType字段主要是用來區分當前的操作類型，這樣方便調用相同的功能進行協同操作。targetDeviceId主要是存儲向哪些設備發起協同操作，可以通過判斷本設備id是否在數組當中，如果不存在，就不做任何操作。

此時需要將實體類轉換成字符串，再存儲到分布式協同數據庫中。因此，可以通過JSONObject.toJSONString（），將實體類轉換成字符串并進行存儲。

被調用方需要為分布式數據庫，綁定數據變更監聽。這樣，其他設備添加或修改數據的時候，就會觸發監聽。監聽類型要設備其他設備觸發的變化，這樣可以避免本地修改也會觸發本地的監聽的問題。

在監聽中就可以處理協同的功能。首先要判斷變更的數據是否為空，避免后續出錯。然后可以將key的json值取出，并做非空判斷。

接下來需要將json字符串轉換成實體類，便于后續操作。這里可以使用JSONArray.parseObject（json， class）進行轉換。

然后進行判斷，是否需要本設備進行協同。

當本設備需要協同時，可以通過switch根據操作類型，調用不同的方法進行協同即可。

總結

殷冬通過官方文檔、論壇、HarmonyOS技術社區等途徑，系統的學習和了解HarmonyOS的特性，最終開發了本次大賽的《分鏡頭App》作品。未來，他還將持續深入了解HarmonyOS，嘗試開發更為有趣的HarmonyOS分布式應用，也期待更多開發者加入到HarmonyOS生態，一起創造無限可能！

責任編輯：haq