概述

鴻蒙中有兩種共享包，HAR（Harmony Archive）靜態共享包和HSP（Harmony Shared Package）動態共享包。

HAR與HSP都是為了實現代碼和資源的共享，都可以包含代碼、C++庫、資源和配置文件，最大的不同之處在于：HAR中的代碼和資源跟隨使用方編譯，如果有多個使用方，它們的編譯產物中會存在多份相同拷貝；而HSP中的代碼和資源可以獨立編譯，運行時在一個進程中代碼也只會存在一份。

HAR和HSP在APP包中的形態示意圖

HSP

使用IDE的SharedLibrary模板創建后，結構如下：

HSP目錄結構

在其中的oh-package.json5中：

{
  "license": "Apache-2.0",
  "devDependencies": {},
  "author": "",
  "name": "my_shared_library",
  "description": "Please describe the basic information.",
  "main": "Index.ets",
  "version": "1.0.0",
  "dependencies": {}
}

有一個main屬性，在這個屬性指定的文件中export需要的組件和類（包括native類），這個文件名字隨便起，但是文件一定要放在該HSP的根目錄下（基于DevEco Studio4.0.3.700）。

在main指定的Index.ets中：

export { MyHsp } from './src/main/ets/pages/Index'

這里export了一個組件，其中MyHsp是組件名。這樣一來，使用方就可以import它來使用了。

它的module.json5中：

{
  "module": {
    "name": "my_shared_library",
    "type": "shared",
    "description": "$string:shared_desc",
    "deviceTypes": [
      "phone",
      "tablet",
      "2in1"
    ],
    //標識當前Module是否在用戶主動安裝的時候安裝，表示該Module對應的HAP是否跟隨應用一起安裝。- true：主動安裝時安裝。- false：主動安裝時不安裝。
    "deliveryWithInstall": true,
    "pages": "$profile:main_pages"
  }
}

注意這里的type是shared。

HAR

使用IDE的StaticLibrary模板創建后，結構如下：

截屏2023-12-28 16.50.17.png

和HSP一樣，它的oh-package.json5中的main屬性指定export文件，在其中配置需要export的組件和類。

它的module.json5中：

{
  "module": {
    "name": "har2",
    "type": "har",
    "deviceTypes": [
      "default",
      "tablet",
      "2in1"
    ]
  }
}

type是har。

依賴和導入

使用HSP和HAR也很簡單，在使用方module下（一般是entry）的oh-package.json5中：

{
  "license": "",
  //這個是用于開發過程中使用的依賴工具，不會打包到HAP中
  "devDependencies": {},
  "author": "",
  "name": "entry",
  "description": "Please describe the basic information.",
  "main": "",
  "version": "1.0.0",
  "dependencies": {
    //本地依賴的key可以是自定義，最終會在oh_modules下生成
    "my-shared-library": "file:../my_shared_library",
    "har1": "file:../har1",
    "har2": "file:../har2"
  }
}

在dependencies屬性下添加依賴項，前面的key可以自定義，value指定對應共享包module的相對路徑，然后根據IDE的提示進行ohpm的安裝，比如上面的依賴項定義好，build后會在使用方module下的oh_modules目錄下生成對應的依賴目錄：

截屏2023-12-28 15.09.41.png

注意，key會作為依賴項的最終導入名，下面我們來看導入。

import {MyHsp} from 'my-shared-library'
//如果都導入的話
import('my-shared-library')

//導入har
import {Har1Page} from 'har1'

可以看到，這里可以導入部分，也可以導入所有export的組件和類。注意看from后面的信息，這個就是前面dependencies中指定的key值，他們是一一對應的。（測試的時候需要用真機或者模擬器，previewer暫不支持共享包調用效果）

命名路由

對應module內的路由導航，我們通常使用profile指定的路由表進行，但是在module之間的路由導航時通常使用命名路由來完成。

router.pushNamedRoute({ name: 'MyHSP' }, (err) => {
  if (err) {
    console.error(`pushNamedRoute failed, code is ${err.code}, message is ${err.message}`);
    return;
  }
  console.info('pushNamedRoute success');
})

比如在一個HSP中的Entry組件的@Entry屬性上定義一個路由名字：

@Entry({ routeName: 'MyHSP' })
@Component
export struct MyHsp {
  ...
}

然后在跳轉處導入：

import('my-shared-library')

還有一種方式，即如果使用如下的導入方式的話：

import {MyHsp} from 'my-shared-library'

則MyHsp組件必須保證在組件樹中使用了，如果沒使用的話進行路由跳轉則會失敗。當然上面的導航需要依賴好共享包之后才能跳轉，在IDE的測試時需要在該處配置好依賴module，否則會報錯：

截屏2023-12-28 15.23.38.png

截屏2023-12-28 15.24.53.png

其實，命名路由還可以進行同一module內的路由跳轉：

import('./Demo1')

比如這里的Demo1文件存在于調用方同一目錄下時的引入方式。但是對于同一module內的導航來說，這種方式有些畫蛇添足，因為它需要多一步手動導入的過程，不如直接使用路由表跳轉來的簡單、整潔。