应用框架：应用间跳转实践

• 应用间跳转概念与场景
• 典型场景实现：社交分享
• 典型场景实现：广告跳转
• 典型场景实现：特殊文本识别
• 常见问题
• 总结

---

应用间跳转概念与场景

应用间跳转概念

应用间跳转是从当前正在使用的应用(调用方)跳转到需要接着操作的应用内(目标方)，进行后续的业务操作。

• 调用方与目标方:在应用拉起跳转过程中，A应用拉起B应用，那么A应用就是调用方，B应用就是目标方。

import { common } from '@kit.AbilityKit';

const link = 'https://appgallery.huawei.com/app/detail?id=com.huawei.hmsapp.books'

@Entry
@Component
struct Index {

  build() {
    Column() {
      Text('调用方')
      Button('跳转到应用市场').onClick(()=> {
        let context = getContext(this) as common.UIAbilityContext
        context.openLink(link)
      })
    }
    .height('100%')
    .width('100%')
  }
}

日常生活中的应用间跳转

1. 社交媒体中分享的内容链接，一键跳转至原应用的具体内容页面
2. 视频应用的开屏广告中，点击链接一键跳转到对应的商品详情页面
3. 日程邀请链接，一键添加日程至系统日历

典型场景一： 社交分享跳转

通过系统分享面板，将包含App Linking的链接分享给好友，实现一键直达原内容。

典型场景二：广告跳转

通过App Linking实现从广告链接到应用特定页面的精准跳转，提高营销转换率。

典型场景三：特殊文本识别跳转

通过系统的文本识别能力，识别其中的特殊文本，从而实现从文本到功能的直接跳转。

应用间跳转实现方案

根据目标应用的确定性，应用间跳转可分为两大类:

1. 拉起指定应用:直接跳转到指定应用及其具体页面。例如，A应用跳转到B应用的商品详情页。
2. 拉起指定类型应用:按功能意图让系统推荐可承接任务的应用，用户自主选择。例如，导航时由用户挑选任一地图应用。

拉起指定应用

拉起指定应用是指明确指定目标应用进行跳转的场景。系统提供两种主要实现方式:

1.应用链接(App Linking和Deep Linking)

• App Linking:通过域名校验和HTTPS协议，实现更安全可靠的跳转。当目标方未安装时，可以打开web网页内容，为用户提供更好的体验
• Deep Linking:实现相对简单，但存在被恶意仿冒的风险。

相较于Deep Linking，App Linking有如下优势:

• 安全性:通过端云安全鉴权和域名校验，确保只有合法应用被拉起。
• 直达体验:无需二次确认，直接跳转到应用内指定页面，
• 直达应用市场:未安装应用时可跳转至应用市场应用详情页，
• 延迟链接:支持应用安装后恢复之前的跳转意图。
  

•   更推荐App Linking
  

2.系统应用跳转

系统提供了一些能力和接口，在确保访问安全的前提下，可以让开发者快捷地实现系统应用跳转，例如跳转设置、应用市场、钱包、电话、日历、联系人等系统应用。详细请参见拉起系统应用。

拉起指定类型应用

在某些场景下，开发者希望基于用户意图而非特定应用实现功能，例如使用任意一款支持的地图应用导航。

在该场景下开发者并不指定某个具体应用，而是以用户意图的角度，由系统查询出当前设备内符合条件的所有应用，由用户自行选择在哪个应用中执行后续逻辑。

---

典型场景实现：社交分享

场景介绍

场景一:目标应用已安装

用户点击分享链接后，系统直接拉起目标应用并定位到内容详情页，无需经过浏览器中转，实现一键直达，极大提高便捷度和转化率。

场景二:目标应用未安装，已配置直达应用市场

当用户未安装目标应用且开发者配置了直达应用市场功能时，点击链接将直接跳转到应用市场的应用详情页。安装完成后，首次打开应用将通过延迟链接功能自动导航至原始分享内容，无需用户重新搜索或操作。

场景三:目标应用未安装，未配置直达应用市场(有web页面)

用户点击链接后，系统通过浏览器打开web页面，用户可直接查看内容。在web页面可提供“下载”按钮，引导用户安装应用获取更佳体验，安装后仍可通过延迟链接直达原内容。

整体流程

分成了两种内容，一种是社交应用要做的事情，还有一种是中间层的应用或者是系统的行为，我举个例子，比方说用户A在社交账号上分享了一个文章链接，一般都是app的链接，首先会接入到分享面板，然后分享面板会分享到一个畅联，通过畅联应用去进行分享。
那，在我们用户B的过程中呢，在用户B的畅联应用里面，能够看得到图片，因为本质上是一个链接。用户B在点击的过程中，会根据社交应用有没有安装。
比方说，我们安装了应用，就会直接跳转到文章详情页里面去。如果没有安装的话，我们要去看一下有没有用到API15之后的提供的一个直达应用市场的能力。如果说我们配置了这个能力，对吧。那么我们点击链接的过程中，也就是检测应用有没有安装，这个时候它就会直接拉起应用市场详情页，然后下载后，我们打开这个应用，因为配置了延迟链接，首次安装打开，同样我们也可以跳转到文章详情页。
如果不是API15，这个时候，就会通过浏览器打开，可以在web页面做一些业务逻辑的变化，同时，也可以引导用户去下载应用。同样，这种方式也可以做到首次打开就可以跳转到目标页面。一键直达。

社交分享跳转实现-总览

配置AppLinking服务–准备

前提条件：

1. 一台服务器
2. 域名（建议做备案）
3. SSL证书，目前AppLinking链接只支持http地址
4. 华为账号
   

配置AppLinking服务–服务器配置

1. 在网址下创建出.well-known文件夹
2. 在创建出的目录下创建applinking.json文件，填入以下内容，其中appIdentifier填入应用的APPID

{
	"applinking": {
		"apps": [
			{
				"appIdentifier": "appId"//在创建应用时生成的Id
			}
		]
	}
}

Linking服务–创建应用链接

在我们云端的事情就已经做完了。

配置AppLinking服务–创建应用

配置AppLinking服务–配置module.json5

如果说我们是一个单HAP，那就需要在entry的module.json5的abilities下

"skills": [
  {
    "entities": [
      "entity.system.home" //需要配置
    ],
    "actions": [
      "action.system.home"//需要配置
    ],
    "uris": [
      {
        "scheme": "https",
        "host": "",
        "path":"path1"
      }
    ],
    "domainVerify": true
  }
]

配置完之后，大家有时候会发现，拉不起来，其实本质上就是url没有匹配上，所以这里面也会有一个匹配规则。尤其是这个path这个功能，有全词匹配，全略匹配，正则匹配。

配置AppLinking服务–生成手动签名相关文件

配置AppLinking服务–验证

• 直接把AppLinking地址写到备忘录里，然后点击看是否可以拉起。这样不用写代码比较方便。
• 还有两种方式，通过代码或者命令后实现，我觉得不用记了，有想了解的自行百度。

接入分享面板

通过集成**Share Kit（分享服务）**拉起分享面板，用于分享文章详情的AppLinking链接。

目标方配置流程-接入分享面板

import { common } from '@kit.AbilityKit'
import { systemShare } from '@kit.ShareKit'
import { uniformTypeDescriptor } from '@kit.ArkData'

@Component
struct Detail {
  private async share() {
    let context = this.getUIContext().getHostContext() as common.UIAbilityContext
    //...
    let shareData: systemShare.SharedData = new systemShare.SharedData({
      utd: uniformTypeDescriptor.UniformDataType.HYPERLINK, //设置分享的数据类型为超链接
      content: `https//xxxxxxx?aid=aid`, //分享的AppLinking链接
      //...
    })
    let controller: systemShare.ShareController = new systemShare.ShareController(shareData)
    controller.show(context, {    //显示分享面板
      previewMode: systemShare.SharePreviewMode.DEFAULT,
      selectionMode: systemShare.SelectionMode.SINGLE
    })
    //...
  }

  build() {

  }
}

应用内跳转处理（重点）

export default class Go1Ability extends UIAbility {
  private uiContext: UIContext | undefined = undefined
  private mAid: string = ''

  /**
   * 解析链接中的参数
   * @param want
   * @returns
   */
  getAid(want: Want): string {
    let uri = want?.uri
    let aid: string = ''
    if (uri) {
      let urlObject = url.URL.parseURL(want?.uri)
      aid = urlObject.params.get('aid') as string
    }
    return aid
  }

  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    this.mAid = this.getAid(want)
  }

  onNewWant(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    let aid: string = this.getAid(want)
    if (aid && aid !== '') {
      //跳转到指定页面
    }
  }

  onWindowStageCreate(windowStage: window.WindowStage): void {
    let pageUrl: string = 'pages/Index'
    if (this.mAid && this.mAid !== '') {
      pageUrl = 'pages/Detail'
      AppStorage.setOrCreate('aid', this.mAid)
    }
    windowStage.loadContent(pageUrl) //跳转到目标页

  }
}

我们的AppLinking分享给到用户B，在我们用户B里面，怎么样才能让用户B，app默认情况下可能是拉起首页，怎么样去解析这个链接，解析链接后怎么样让拉起所对应的详情页？
方案：
我们先去解析AppLinking的链接，和一些特殊的标识 >>> getAid()
有了标识之后呢，我们在onCreate或者onNewWant这两个回调中，以及在我们的onWindowStageCreate中做相应的逻辑判断。
比如说，我们没有打开这个app，我们就在冷启动过程中，没有打开的情况下，会进入onCreate和onWindowStageCreate这两个回调下，然后我们在这里去解析，在loadContent方法下去加载这个页面。app已经打开过了，则去onNewWant回调中解析然后跳转到目标页面。

页面内解析

@Component
struct Detail {
  @StorageProp('aid') aid: string = ''
  private article: Article | undefined //在页面中获取文章唯一识别标识aid

  aboutToAppear(): void {
    if (this.aid && this.aid !== '') {
      this.article = getArticlebyId(this.aid)
    } else {
    }
  }

  build() {

  }
}

配置直达应用市场

api15以上可以配置直达应用市场这个能力

使用延迟链接

通过deferredLink.popDeferredLink()接口获取原始App Linking链接，并根据解析该链接直接跳转到对应的内容详情页。

aboutToAppear(): void {
    //获取延迟参数并跳转到对应页面
    deferredLink.popDeferredLink().then((link: string)=> {
      if (link) {
        //获取链接参数
        let urlObject = url.URL.parseURL(link)
        let aid = urlObject.params.get('aid') as string
        //跳转到详情页
        this.getUIContext().getRouter().pushUrl({
          url: 'pages/Detail',
          params: {
            aid: aid
          }
        })
      }
    })
  }

Web页面开发与部署

保持多端的一致性

---

广告跳转

开屏广告=》拉起详情页
跟分享流程差不多

跳转流程

特殊文本识别跳转

在Text组件上启动enableDataDetector属性，即可实现对一段文字中的链接，日期，电话号码，地址，邮箱等特殊文本进行自动识别并标识。

Text('电话19988888888')
        .enableDataDetector(true)

分别传入包含HTTP/HTTPS链接，AppLinking链接，日期，电话号码，地址，邮箱等，文字内容到TextLink组件，均以可交互形式显示。

---

常见问题

如何查看AppLinking是否在AGC上配置成功

配置失败如何解决？

• 首先，显示 App Linking 状态失败并不不一定意味着配置错误。也有可能是配置正确，但 AppGalleryConnect(AGC) 未及时更新。若不确定是否是此问题，可以采取删除链接后重新添加的方式。如果问题依旧存在，那么大概是服务器配置问题。
  applinking.json配置文件配置错误，请参考在开发者网站上关联应用进行配置。
• App Linking地址仅支持https链接、若为http链接，请自行申请SSL证书。
• 检查配置文件所处的文件目录与文件权限确保外部可以访问。
• 若上述检查无误，建议求助网站运维侧人员，共同排查解决。

AGC上显示链接地址配置成功，但是配置到目标方后，尝试使用openLink()或其他拉起方式，应用并未成功拉起。

1. AGC配置App Linking链接时以"/“结尾。检查AGC上配置AppLinking链接地址，检查是否AGC配置的链接地址末尾是否多了”/"。
2. 检查module.json5中配置的链接地址与AGC中配置的链接地址是否一致，例如AGC中配置了“https://www.huawei.com”而在代码中使用了“https://developer.huawei.com”
3. 应用未手动从AGC上申请证书签名进行应用签名。开发者请参考验证应用被拉起效果在AGC上手动申请证书与Profile进行手动签名。
4. 开发者所处的网络有访问限制。重新更换其他网络。
5. module.json5配置文件配置错误。

---

总结

• 应用间跳转场景
• 应用间跳转的实现方案
• App Linking的配置
• 调用方如何向目标方传递参数，目标方如何进行参数的接收，如何向调用方返回执行结果
• 使用App Linking时应用未安装场景下需要对链接地址对应的前段内容进行适配
• 常见问题

---

我是gelivation，一名知识的搬运工。

直播回放：应用跳转技术与最佳实践-赵一纯