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

接入背景

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

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

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

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

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

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

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

单楼层动态化改造

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

首先，在数据层面：

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

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

通用楼层的能力包括：

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 来加载和展示楼层。流程图如下：

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

改造成果：

踩坑 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 模版字段不通用的情况，例如：

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

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

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

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

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

模版中如何做复杂的逻辑

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 的 SDK 加载动态化视图失败，会给我们一个失败回调 Block，那么我们的处理是可以利用存在 DynamicViewModel 里的 nativeData 去加载原生楼层作为降级。

下发数据层面

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

业务楼层层面

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

数据格式：

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

作者：京东零售姜海

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

↙↙↙阅读原文可查看相关链接，并与作者交流