复杂场景下唤起App实践

最新推荐文章于 2024-03-24 22:11:05 发布

大转转FE

最新推荐文章于 2024-03-24 22:11:05 发布

阅读量306

点赞数

文章标签： python java 大数据编程语言分布式

本文链接：https://blog.csdn.net/P6P7qsW6ua47A2Sb/article/details/121846995

版权

本文详述了在唤起App过程中遇到的新问题及如何进行项目重构，包括运行环境判断策略优化、引入hooks和利用位操作进行优化。此外，还探讨了下载后还原、短信短链接唤起和唤端数据统计等更多实践，以及周边生态建设的工具平台、统跳平台和中间落地页。最后，项目已在GitHub开源。

摘要由CSDN通过智能技术生成

一前言

在上一篇文章《唤起App在转转的实践》中，我们介绍了唤端技术的实现原理和一些实践。

这里先回顾一下上一篇主要内容：

1. 什么是唤端？

一张图了解一下什么是唤端。

2. 唤端功能

唤端功能架构图如下。

功能

3. 唤端技术

唤端技术架构图如下。

二面临的新问题

虽然，当前方案已经支持了基本的唤端能力，可以说是唤端技术在转转的从 0 到 1。
然而，随着时间的迁移，支持兼容的业务逻辑越来越多，项目内部结构已混乱不堪、维护艰难，并且满足不了新的业务诉求，因此，决定对其进行一次重大重构。

经过业务反馈和调研，主要问题如下：

集团内App尚未完全覆盖，平台兼容性尚待完善。
未与行业方案对齐，满足不了业务提出的更高要求。
周边生态有待完善，业务使用体验有待提高。

对以上问题进行了梳理、评估，最终定下了本次重构目标：

整体架构升级，支持唤起多App，提升唤起兼容性。
对标业界方案，完善现有能力。
唤起App周边生态完善，提升业务体验。

三项目重构

整体架构

1. 旧的方案与架构

首先，看一下原来的目录结构(其实一个好的基础库项目只看目录结构就能大概推测出架构的轮廓)。

|-src
  |-- callers
    |-- 58App.js
    |-- browser.js
    |-- qq.js
    |-- wechat.js
    |-- zzLike.js
  |-- core
    |-- base.js
    |-- index.js
  |-- libs
    |-- config.js
    |-- platform.js
    |-- utils.js
 index.js

架构图如下：

旧架构

这种以运行时平台基础的策略模式+适配器模式的设计架构，随着业务复杂度的提高，主要存在以下弊端：

运行平台多变莫测，如果新增运行时环境则必须新增一个 caller 类支持，不符合开闭原则。
在进行业务扩展和处理交叉逻辑时，代码量会激增，严重影响基础库代码体积。
功能职责划分不清晰不明确，每一个 caller 类，都需要单独进行处理，项目整体维护成本较大并会增加心智负担。

在支持有限个运行时平台，唤起单一App时，上述架构设计完全满足需求，上述问题也不会凸显，但是随着业务复杂度和要求越来越高，缺点会越来越突出。

2. 业界方案

对社区的一些唤端方案和建设进行了一些调研并进行了对比。主要内容如下：

项目	特点	缺点	star
开源-web-launch-app^[1]	功能职责划分明确，兼容平台多	参数设计较复杂，内部封装不够简练，不支持回调	678
开源-callapp-lib^[2]	功能职责划分明确，代码组织友好，兼容平台多	只提供浏览器端唤起单一App方案	1.8K
文章-唤端背后的技术^[3]	介绍了一些前沿方案	缺少细节信息量，不开源