【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

Native 与 Weex 交互通用解决方案

  • 2020-10-26
  • 本文字数:4428 字

    阅读完需:约 15 分钟

Native 与 Weex 交互通用解决方案

背景

从 2018 年开始,有赞移动团队使用 Weex 做为移动端跨平台动态性技术解决方案。自 Weex引入之后需求推进速度得到很大提升,因此被开发同学使用到各个 App和各个模块中,在使用过程中各个 App为了 Weex调用 Native功能,都各自实现了不同功能的 WeexModule,经过 2 年多的发展,发现各个 App中有很多功能差不多的 WeexModule,例如:专用于路由跳转、配置中心、账号信息等类似功能的 WeexModule


我们期望能有一个解决 Native 与 Weex 交互的通用解决方案,简化业务方接入工作,也方便同个 Weex页面可以在不同模块或者不同 App进行正常渲染,因此 ZanWeexModuleSDK就孕育而生。下面将带大家逐步解析 ZanWeexModuleSDK设计方案。

一、现状分析

我们首先分析一个有赞通用的 NativeWeex交互流程图:



从上图我们可以看到,一个完善的基础 WeexAPP它会有有很多个 WeexModule用于 WeexNative组件进行交互,常用的就是路由、网络请求、配置中心、埋点、日志、基础 UI 调用、分享这些重要功能。并且还有很多模块如:IM业务模块、商品业务模块等也有 Weex页面。当我们再去看多个 App 或模块时,就有下图的现状。



上图是不同 App或业务模块都有各自实现的 WeexModule并相互独立,当有业务需求将一个 App或业务模块的 Weex页面迁移到另外 App 或业务模块里,在 WeexModule上的工作量就非常大,既要梳理两个 WeexModule的逻辑差异,又要重新合并逻辑。所以非常需要一套通用 WeexMoudle规则,来做到规范和统一。

二、整体设计

我们通过分析各个 App在使用不同功能的 WeexMoule场景和实现,发现有大部分的功能都是重叠的,只有少部分 App特有逻辑,因此我们进行了这样的改造:



从上图中我们可以看到,通用 WeexModule把各个业务的 WeexModule逻辑全部收拢,简单业务接入通用 WeexModule就只需要关心 Weex代码实现,不用再关心业务使用的 WeexModule实现内容。并且也能做到同个 Weex页面可以在不同模块或者不同 App进行正常渲染。

2.1 筛选通用 WeexModule

有了整体设计方案接下来我们就要分析具体怎么筛选出这些 WeexModule。想要打造一个完善的 Weex通用 MoudleSDK规范不是一口气吃成胖子,设计出来的 SDK差异越大越复杂,接入成本就会越高,推动接入就越不容易,所以需要一步一步来。第一个版本只包含最通用的模块,简化接口设计和集成方式。


所以总结出以下筛选原则:


  • WeexModule复用度高

  • WeexModule的接入、使用方便

  • 新旧接口尽量保持一致


通过以上原则,筛选出第一版的通用 module并简单介绍下:


  • 网络 Module :替换每个 Weex自己实现网络请求封装类, Weex上使用方式保不变

  • 路由 Module :简单路由已实现,独立业务提供自定义实现,接入使用方便

  • 配置 Module :获取移动端动态配置的配置数据, Weex无需重新解析,直接返回的是 Map

  • 日志 Module : Debug本地日志打印, Release日志上传服务器,使用方便

  • 通知 Module :用于跨页面通知状态变化,使用方便

  • 埋点 Module : Weex上使用方式不变,方便 ZWeexManager进行 init 时候不用在实现 IZWeexService

  • 账号 Module :常用来判断登陆状态和获取登陆信息


具体怎么筛选的,举两个选择出的例子:

路由 Module

路由module是非常通用的 WeexModule,它需要处理跳转到各个不同实现的页面,如:NativeWeexFlutterH5,所以 WeexSdk直接提供 navigator的是肯定无法满足各个 App的, 所以各个 App就有了各自不同的路由 module,为了做到后续将各个 AppWeex相关和 Native交互都统一走 ZanWeexModule,所以设计了 ZanNavigatorModule,而 ZanNavigatorModule用法上也和原先一样

网络 Module

卡门网关是有赞移动端依赖的对外网络请求网关,之前各个 AppWeex网络请求依赖的是在 WXStreamModule提供的网络请求能力,让后自己封装一个工具类,用于处理卡门网络请求。而各个 App 的 Native网络请求都已统一使用 ZanRemote二方库提供的卡门网关网络请求能力,卡门网络请求一旦有改动 ZanRemote二方库升级了,而 Weex的封装类没进行修改升级,就会导致 WeexNative不一致,产生请求问题,而这种问题也不容易排查,可能会产生故障。因此我们需要 WeexNative统一使用一套网络请求能力,所以需要提供一个 WeexModule处理网络请求,因此有了 ZanCarmenModule,在用法上还保持了以前封装类的使用方式,方便快速替换


有了这些通用 Module就能很好的支持业务方在实际开发中使用。通用 Module选出来了,那接下来我们就可以对各个 WeexModule去设计了。

3.2 WeexModule设计思路

针对那些可能存在自定义逻辑的 WeexModule,所以在设计的时候需要实现公共部分,并且提供接口给到使用方设置自己的逻辑,例如:路由Module,业务方会存在一些跳转到自己指定的页面场景


/** * 自定义处理Navigator */public interface WXMNavigatorService extends WXMBaseService {    /**     *      * @param context 上下文     * @param uri weex模块标示     * @param url 路径     * @param params 可选参数     * @return     */    boolean navigator(Context context, String uri, String url, JSONObject params);
}
复制代码


  • 怎么使用这 WXMNavigatorService个接口,让相应的 WeexModule找到对应的 WXMNavigatorService接口?为此我们在 WeexModuleManager管理类里提供里一个 serviceMap保存 WXMBaseService实例,让后给到用于查询使用


public class WeexModuleManager {  /**     * 根据默认uri区分weex模块,或者使用自定义字符串     */    private final HashMap<String,HashMap<Class,WXMBaseService>> serviceMap = new HashMap<>(); /**     * 获取sevice     * @param uri 唯一标示     * @param clazz service类型     * @return      */    public WXMBaseService getService(String uri,Class clazz){        ...    }    /**     * 根据uri区分weex模块     * @param uri  唯一标示     * @param clazz service类型     * @param service service实现类     */    public void setService(String uri,Class clazz,WXMBaseService service){     ...    }}
复制代码


通过 WeexModuleManager 提供的 getService 方法我们可以在 WeexMoudle 里找到业务方法实现 WXMBaseService 调用对应的方法,传递参数给到业务方。

3.3 针对 weex回调参数设计规则

各个 module处理完之后,抛给 Weex页面的回调必须要有统一的规则,不然在接入的难度上会有所提高,为了统一规范和降低接入成本,所以我们需要一个通用的回调规范:


 /**     * 带回调的跳转     * @param url  格式 app_name://pageName 和 https://     * @param params  跳转到相应页面需要的数据,相应页面不需要数据可不传 {"key1":"value"}     * @param jsCallback   触发后回调 返回值格式:{"code":200,"data":{},"message":"","success":true}     */    @JSMethod    public void open(String url, JSONObject params, JSCallback jsCallback) {       ...    }
复制代码


其中入参格式的定义,url 是按照已有的标准用于区分 Native跳转、 H5Weex跳转,params 方便使用方不用再做解析操作以及和 iOS 统一返回定义成 JSONObject,其中 jsCallback内部返回值是重点设计,为了保障各个 WeexModule以及以后的 WeexModule统一规范返回格式,模仿采用了后端返回值格式,让 Weex将其当作类似网络异步请求,在使用的时候就可以统一使用回调返回方法处理。


我们通过以上步骤分析把 ZanWeexModuleSdk 设计出来了,接下来我们下在 Weex中具体怎么使用。

三、实践

3.1 业务方接入

Native中初始化

在 native 中需要初始化 WeexModuleManager并且把自定义实现类注册到 WeexModuleManager中。


 //application中初始化   public void initWeex() {       WeexModuleManager.init(app());       //自定义路由跳转       WeexModuleManager.get().setService(AppConfig.WEEX_URI,ZanWXMNavigatorService.class,new ZanWXMNavigatorService());   }
复制代码

Weex中如何使用

我们看下新的 ZanCarmenModule具体使用并且对比下老的方式请求网络, ZanCarmenModuleWeex中对应的唯一标示 zwm-carmen,调用 ZanRemote二方库提供的卡门网络请求能力,方便进行卡门请求。


const carmen = weex.requireModule('zwm-carmen')// post方法carmen.post({    url:"wsc.appconfigs/1.0.2/get",    params:{"key":"value"}}, response =>{    if(response.success) {        let data = response.data    }else {    }})

//对比以前通过工具类请求网络import Network from '@common/tool/Network' //封装方法 request(name,page,success,mError) { this.network.request('XXXX/1.0.0/list','POST',{body:{page:page,size:20}},success,mError) } //具体请求 this.request(page, response => { let data = response.data }, error => { } );
复制代码


可以看到新的 ZanCarmenModule相对老的方式写法上更简单,而且调用返回处理也是保持一样。

3.2 问题反馈

随着 ZanWeexModuleSDK完成,陆续在有赞各个 App 进行的 Weex项目中接入使用,如:微商城、零售、美业、精选、有赞客等 App 中,也有如:IM 模块、商品模块、营销模块等模块中,在实际开发使用中小伙伴也给到我们很多意见和吐槽。


  • 小 A:"网络 Module 很方便的,在新的业务模块中网络的直接用就可以了”

  • 小 B:"路由 Module 那个可以再扩展下,现在业务方需要手动处理 NativeWeexH5的路由,可以增加多一点通用实现”

  • 小 C:“日志 Module 要是提供一些高级点的特性就好了,比如识别出对象,就用 json 字符串打印”


大家遇到最多的问题是:虽然提供了 ZanNavigatorModule,但并没有实现很多通用的路由跳转,还是要重新实现 WXMNavigatorService,将原有的逻辑复制到 navigator()方法中。

3.3 后续规划

上述这些问题也有后续的规划:


  • 针对类似路由 Module 这种各个端差异大且常用的 WeexModule,是不可能做到一步完成所有替换,因为这种替换会伴随着风险、时间不够、考虑不全等问题。我们先逐步将公共功能剔除出来,放在 ZanWeexModuleSDK中实现,例如:跳转 Weex页面、跳转 H5页面。最后只留下各个 App的差异部分。

  • 针对类似日志 Moudle 这种 Module 会逐步完善使用体验,提供更多更好用的方法。


最后将其做成一个 WeexNative交互的通用解决方案,简化业务方接入工作,只需要关心业务代码。

四、总结

本文主要介绍了 ZanWeexModuleSDK的设计方案。ZanWeexModuleSDK的实现是结合有赞移动团队使用 Weex过程中,各个 AppWeex交互功能重复和代码冗余中产生的,读者在规划使用 Weex开发时就可以考虑这些问题,当然这也不仅仅可以应用在 WeexNative交互,也可以应用在 FlutterNative交互以及 JSNative交互方案上。希望 ZanWeexModuleSDK的设计方案能对你有所帮助。


如果你有比较好的建议,可以评论回复,如有任何问题,欢迎指正。


本文转载自公众号有赞 coder(ID:youzan_coder)。


原文链接


Native 与 Weex 交互通用解决方案


2020-10-26 14:073275

评论

发布
暂无评论
发现更多内容

web前端培训学习能找到工作吗

小谷哥

一文读懂云渲染“串流”全链路时延及优化策略

阿里云视频云

阿里云 云渲染 云游戏 串流

华为云对象存储OBS,助力企业高效解决存储问题

路过的憨憨

华为

【文本检测与识别白皮书】第三章 - 第三节:算法模型 2

合合技术团队

人工智能 深度学习 大数据 文字识别

华为云对象存储服务OBS教你一招轻松解决存储难题

路过的憨憨

华为

4000字深度总结!Pipeline五大性能实践,招招制敌

极狐GitLab

DevOps CI/CD 持续交付 pipeline 极狐GitLab

新手剪辑师秒变大神 高级感视频剪辑的几种常用技巧

懒得勤快

rdd pair reduce

小东

生产数据实时分析,产品质量高效管控|打造面向工业4.0的智能工厂02

EMQ映云科技

云原生 物联网 IoT 边云协同 10月月更

Wallys /IPQ4019 IPQ4029 ,HTTPS / all the modules of Quectel/Indoor Aluminium alloy material

wallys-wifi6

IPQ4019 ipq4029

英特尔“四维发力”系统级代工:晶圆制造、封装、芯粒、软件

科技之家

CSS学习笔记1

虾仁疙瘩汤

CSS html 10月月更

华为云数据灾备方案,撑起一把企业的保护伞

路过的憨憨

华为

开发者原来都是健身猛男?

InfoQ写作社区官方

热门活动

华为云灾备,保护企业信息数据势在必行!

路过的憨憨

华为

1024程序员节 | 畅聊名“猿”之路,重磅视频预告

小谷哥

LeaRun低代码开发平台 助推物联网应用快速落地

力软低代码开发平台

HTML学习笔记

虾仁疙瘩汤

html 前端 10月月更

华为云数据灾备方案助力企业安全,守住企业底线

路过的憨憨

华为

低代码平台 - 危险的赌注

世开 Coding

软件开发 低代码 开发框架

持续引领产业发展,华为云桌面连续6年位居国内市占率第一

路过的憨憨

华为

华为云大数据BI解决方案,如何帮助企业精准营销

路过的憨憨

华为

分布式事务-事务补偿(TCC)

zarmnosaj

10月月更

SAP | 聊一聊必不可少的Debug

暮春零贰

debug SAP 10月月更

软件测试面试真题 | 显式等待与隐式等待的区别?与强制等待的方式分别是什么,有什么区别?

测试人

软件测试 面试题 测试开发 测试工程师

华为云CDN联手OBS桶,帮助企业更好降本增效!

路过的憨憨

华为

大数据开发培训学习方法

小谷哥

你好

小东

第一次

HTML基本知识学习笔记

虾仁疙瘩汤

html 前端 10月月更

华为云数据灾备,如何让企业数据无忧

路过的憨憨

华为

华为云数据灾备方案如何成为企业的坚实后盾

路过的憨憨

华为

Native 与 Weex 交互通用解决方案_移动_黑羽_InfoQ精选文章