MCube动态化与原生工程结合最佳实践

  • MCube动态化与原生工程结合最佳实践已关闭评论
  • 46 次浏览
  • A+
所属分类:Web前端
摘要

跨端动态化开发方案重要性日益凸显,本文对我们团队MCube动态化实践做了总结,为大家提供经验和借鉴。

跨端动态化开发方案重要性日益凸显,本文对我们团队MCube动态化实践做了总结,为大家提供经验和借鉴。

接入背景

随着我们工程的需求迭代,暴露出了业务需求量大,分端开发和发版更新成本高等痛点,使用H5页面来代替,在用户体验和性能相较原生有差异,所以我们团队开始了对动态化改造的研究。

在做过一些列动态化开发的尝试,并对多种方案进行调研后,我们选择了MCube的动态化方案。之所以选用MCube,是因为它有以下的优点:

1.方案成熟,对同为京东体系下的APP来说接入成本非常低,对照文档文档,整个接入的过程并不复杂。2.MCube有丰富原子组件,组件的灵活性非常高。

3.完善的组件市场可以很好的满足我们的需求。

4.一套XML模板适用多个平台,并且可以复用。

我们在接入的过程当中遇到兼容性问题,在沟通过程中,MCube的负责同学和开发人员积极性非常高,定制化开发的效率也很高,认真负责,有问必答,整个沟通过程非常愉快。

我们团队目前已经完成了从初步尝试,到一整个业务页面动态化改造的完整历程。期间遇到了许多问题,总结出了最佳化实践的经验,本篇文章做出总结,为其他已经接入和准备接入的同学提供经验。

单楼层动态化改造

虽然MCube的SDK提供了丰富的接口方法,但是为了方便使用和后续的全页面级别动态化控制,我们还是做了大量的封装和本地化开发。

首先,在数据层面:

MCube动态化与原生工程结合最佳实践

根据MCube SDK的必传参数要求,我们封装了必要的module(页面名)和templateID(模版ID);在数据部分,模型封装了用于模版的数据源data,这样就可以让动态化视图(DYNContainerView)从数据源取数据进行展示,同时也方便外部下发;同时我们有大量原生楼层做动态化改造的场景,需要保留原数据进行交互和降级,所以模型预留了原生楼层使用的nativeData,方便在有以上需求的时候取用;最后,考虑到页面有将某些楼层按照section成组进行展示的场景,模型设计了用于组划分的groupID,相同groupID为一个section,按照页面具体的业务需求决定组的展示形式(卡片或者分割)。

在视图层面,以封装好的DynamicViewModel为基础,将动态化视图加载等操作进行了封装,形成了通用楼层CommonTableViewCell:

MCube动态化与原生工程结合最佳实践

通用楼层的能力包括:

1.解析module和templateID

2.调用MCube SDK下载对应动态化模版,并在结束时给出回调

3.展示动态化视图DynView,使用数据进行刷新

4.支持设置降级视图,失败时进行降级

5.对于元素是原生视图的,通用楼层会用过layoutId将其找到,并通过Block回调出来,方便进行后续的操作,包括宽高调整,代理设置等等

self.successBlock = ^(DYNContainerView * _Nonnull dynamicView) {     UIView *nativeView = [dynamicView getRrenderViewWithLayoutId:@"100"];     if ([nativeView isKindOfClass:[原生视图类名 class]]) {        //原生事件处理        } };   

全页面动态化改造

有了通用楼层,我们就开始了下一步的改造,最终的目的是实现全页面动态化下发,这也是我们团队对于动态化改造的新理解:全页面的所有楼层均支持动态化下发,原生楼层与动态化楼层共存,由数据来驱动,灵活控制楼层的展示形式,另外还可以由配置平台设置开关,控制动态化楼层的降级。

理想情况下,业务页面的顺序和楼层数据都可以由后端下发的数据源来决定。但实际进行改造的时候,我们时常会面对的情况是:后端下发的result里混杂着所有楼层的数据字段,每个楼层在加载数据model的时候要到result里单独找到自己要用的字段进行解析,这样就存在着两个弊端:

1.楼层顺序无法由下发控制

2.无法做到分楼层动态化控制

所以我们改造的第一步是对下发的数据结构进行重新定义。

"result":{     "dynamicFloors":         [             {                 "type":"楼层类型",                 "module":"页面名",                 "templateID":"模版ID",                 "groupID":"part1"                 "data":{                 }             }         ] }   

我们设定了一个动态化楼层数组dynamicFloors,里面的每个元素代表了某一楼层的数据。type用于确定楼层类型,对于动态化楼层,会额外下发module和templateID,以此来区分动态化和原生楼层。如果发现下发了module和templateID,那么自动用DynamicViewModel来解析,将data设置进数据源,然后用CommonTableViewCell来加载和展示楼层。流程图如下:

MCube动态化与原生工程结合最佳实践

后续可以推动服务端按照这个结构进行下发,当然,在推动其他团队同学改在之前,前端也可以先行对下发的result进行改造,但千万要保证数据安全并做好容错处理和降级开关。

改造成果:

MCube动态化与原生工程结合最佳实践

踩坑Q&A

接入JDBDynamicModule后安装/编译报错

我们在接入的过程当中遇到了诸如类名和方法名冲突的问题,需要与MCube的相关负责人沟通,单独为工程进行SDK的定制化开发,解除依赖。

哪些楼层适合做成动态化楼层

就我们的经验来讲,适合做成动态化楼层需要满足以下一个或多个条件:

1.楼层的展示样式存在灵活变化的需求。

2.楼层的交互形式简单且单一。动态化着重于UI展示,相对来说模版交互事件开发较为繁琐。

3.安卓与iOS差异不大。这里的差异主要说的是模开发的差异,由于MCube本身的机制,在进行模版开发时经常会有安卓和iOS模版字段不通用的情况,具体见下面“安卓与iOS模版开发时的差异”部分。差异小可以保证安卓和iOS能采用同一套模版,减少开发工作量。

通过loadWithCallback加载模版失败

首先检查DYNContainerConfig对象的module和templateID是否设置正确。

其次检查是否实现了网络加载桥接类以及协议。MCube的所有网络请求都要经过桥接类来进行处理,走我们本地的网络请求并把结果返回给MCube。首先根据自己的命名需要创建一个类,并实现协议,在+load里对创建的类进行注册,主要是告诉MCube你的网络请求后续都由我这个类来处理

+ (void)load {    [DYNMapperManager registeProtocolName:DYNProtocolConfig.networkProtocolName handlerClassName:NSStringFromClass(self)]; }   

桥文件里的主要工作是实现协议里定义的相关方法,网络请求的DYNNetworkProtocol中主要需要实现的有:

getServerURL

根据自己的网络环境配置,返回MCube接口请求的URL头部,有两套:

1.正式环境:api.m.jd.com/XXX?functionId=

2.测试环境:beta-api.m.jd.com/XXX?functionId=

requestWithSetupModel: finish: cancel:

在这个方法里,需要创建API请求,将setupModel里的functionId和params,以及appType放进入参,发起请求,并把请求结果通过finish/cancel的Block回调返回给MCube进行处理。我们也可以在这里断点或者进行自己的处理,最主要的接口是获取模版列表,可以查看下发的模版列表文件是否正常。

getNetworkType

根据当前的网络环境返回网络类型,比如Wi-Fi,5G和4G等等。

模版中的ImageView图片无法加载

图片加载相关的请求也需要创建对应的桥接类,实现协议的相关方法。同时还需要给UIImageView创建一个category分类UIImageView+DYNBImageViewHandler,在分类里覆写dyn_setImageWithURL: placeholderImage:和dyn_setImageWithURL: placeholderImage: completed:方法,在它们里面利用sdWebImage等其他工具进行图片下载。

如何在模版中使用原生视图组件

MCube中可以将原生视图组件做为元素写到模版里,有以下步骤

1.原生视图组件实现协议里的两个方法:

#pragma mark - DYNCustomViewProtocol - (id)getCustomView {     return self; }  - (void)setDataWithValue:(id)value object:(id)object sender:(DYNViewLayout *)sender {     if ([value isKindOfClass:[原生模型 class]]) {         //使用模型刷新原生视图组件     } }   

2.在+load里声明模版元素与原生视图类的对应关系:

+ (void)load {     [DYNMapperManager registeProtocolName:@"模版元素名" module:@"模块名" handlerClassName:@"原生视图组件类名"]; }    

3.模版中用对应的元素名进行编写

<FlexboxLayout layoutId="999" width="match_parent" height="wrap_content" flexDirection="column" justifyContent="flex_start" bgColor="#FFFFFF">     <模版元素名 layoutId="100" width="100%" height="100%" data="${原生模型对应key}" bgColor="#FFFFFF">     </模版元素名> </FlexboxLayout>  

安卓与iOS模版开发时的差异

上文提到:由于MCube本身的机制,在进行模版开发时经常会有安卓和iOS模版字段不通用的情况,例如:

MCube动态化与原生工程结合最佳实践

MCube动态化与原生工程结合最佳实践

在我们的开发过程中,遇到的安卓和iOS不兼容的问题有:

1.安卓的嵌套滑动组件接入工程后,会报与本地的库有冲突。

2.FlexboxLayout 设置100%安卓可以滑动,ios滑动不了。

3.ImageView scaleType="stretch" 安卓会展示比例有问题,需要加useAspectRatio,ios没问题。

MCube动态化与原生工程结合最佳实践

4.安卓在设置渐变色的时候语法不生效:

MCube动态化与原生工程结合最佳实践

模版中如何做复杂的逻辑

1.数值结算

<ImageView height="$calc(44*SCREEN_WIDTH/375)" width="$calc(SCREEN_WIDTH)" />   

2.条件判断

<ImageView src="@{${data.img1}?${data.img1}:${data.img2}}"/> <View visibility="@{@{${data.show}!=null}?1:2}"/>   

3.渐变色(拼接语法)

<FlexboxLayout bgColorList="$joint(${startColored},$unescape(comma),${endColored})"> <TextView text="$joint((${data.text1}  ${data.text2}))"/>  

上传和发布模版

模版要上传到配置平台(具体网址请咨询相关负责人,并开通权限),在配置平台创建APP,模块(页面)和具体楼层,楼层可以发布不同版本,上传缩略图和模版文件,最后还可以选择白名单发布或者灰度发布。

MCube动态化与原生工程结合最佳实践

如何做降级方案?

降级的形式我们在不同维度设立了三套方案:

视图层面

如果MCube的SDK加载动态化视图失败,会给我们一个失败回调Block,那么我们的处理是可以利用存在DynamicViewModel里的nativeData去加载原生楼层作为降级。

下发数据层面

可以通过控制是否下发module和templateID,来控制该楼层走原生展示还是动态化展示。

业务楼层层面

我们在配置平台设置了白名单(dynamicWhiteList)进行控制:按模块名(module)-模版名(templateID)来定位具体楼层,配置true(降级)/false(动态化)决定是否降级。

数据格式:

"dynamicWhiteList":{     "页面名module":{         "模版templateID 1":true,//降级         "模版templateID 2":false//动态化     } }   

作者:京东零售 姜海

来源:京东云开发者社区 转载请注明来源