招才猫直聘安卓DU动态框架实现

什么是DU？DU，全称为DynamicUpdate。顾名思义，就是动态更新框架。DU的诞生，是为了解决Android平台的动态部署能力，因此我们可以通过DU解决产品同学想快速验证的部分重要需求，同时用户体验接近Native。

要实现快速迭代，就要避开APP发版环节，采用动态部署的方式，将功能动态下发到用户手机内。市场上解决此类问题的方案也多种多样，常见方案大致存在以下几种：

A、Web / Hybird 方案；

B、JS + Native 方案；

C、Android插件化方案。

三种方案各有优缺点，具体优缺点对比以及技术选型不是本文重点，这里不再展开讨论，感兴趣的同学可自行查阅相关文章。我们选取的是第二种方案：JS+Native解决方案。

JS+Native动态部署方案，其原理是：通过JS与native交互协议，用JS代码操作原生系统的UI组件，代替DOM元素来渲染。由于最终渲染是由Native完成，所以即实现了跨平台动态更新的特性，也保证了流畅的用户体验。市面上较流行的解决方案有：

React Native：是由Facebook开源的跨平台移动应用开发框架。支持用开源的JavaScript库React.js来开发iOS和Android原生App。其主张“Learn once, write everywhere”。

WEEX：WEEX是一款基于通用跨平台的 Web 开发语言和开发经验，来构建 Android、iOS 和 Web 应用的开发框架。目前 前端框架Vue 和 Rax被广泛应用于 Weex 页面开发。其宣称“Write Once, Run Everywhere”。

DU也是基于JS+Native原理。它更加轻量，是面向Android研发人员设计的一款动态开发框架。它的设计思路遵循招才猫动态部署框架整体的思路，使Android/iOS  Native开发的小伙伴上手机开发成本低，甚至可忽略。下图是用DU框架开发的页面，大家可以看出，与我们Android开发规范相似度非常高。

DU的布局文件、文案定义、颜色、尺寸定义，都与Android完全一致，都是用xml定义，就连文件命名也延续了Android的命名；

DU的图片，放到了固定的图片文件夹中，在布局文件中使用的时候，只要定义$drawable/xxx即可加载对应的图片文件；

DU框架里面封装了加载DU页面的DUActivity以及DUFragment。在启动DU页面时，将布局文件与页面进行关联。在Activity/Fragment创建的时候，会自动创建资源解析器与构建器。

资源解析器会将布局文件以及布局中用到的颜色、尺寸、图片等信息，进行解析转换，并交给Views生成器，生成一个个带有完整描述的组件，这些组件会形成ViewsTree。

转换器将生成的ViewsTree交给构建器。构建模块会根据各个控件的描述，创建对应的组件，并添加到DecorView上，并为有交互的控件添加事件监听。

至此，DU完成了页面的渲染。

JSUIComponents，是对应控件的调用封装。如封装JSButton对应的各种方法调用。

UIComponents组件，就是现有APP自己创建的控件，也可以是系统封装的控件，如Button。

Proxy，是控件代理层。代理层有两个作用：

A、封装属性代理。通过代理里面封装的Property，为不同控件设置不同的属性，并且Property是可以继承的，相应的也就是控件的属性可以继承。如DUViewGroupProxy.Property 继承自DUViewProxy.Property，所以DUViewGroup不但拥有了自己的属性，同时也拥有了DUView的属性。这样可以避免重复定义控件属性，增加属性复用性。

B、将调用与实现隔离。如Button控件，在招才猫端对应的就是招才猫封装的ZCMButton，但是对应其他APP，就会是xxxButton。有了代理层， 在集成DU框架时，可以实现控件的快速切换，而不是再封装一套。

view_config配置文件，此文件主要作用是将View与Viewproxy做映射关系。

layout.xml，为布局文件。

以上为Native端的实现。

SDK里面已经封装了交互协议以及View生成器。在SDK初始化的时候，已经根据view_config.xml的配置信息，将View与ViewProxy做了一一对应。在渲染页面时，view生成器会根据layout创建相应控件，并通过ViewProxy，调用view的setxxx方法，为view属性赋值。

与UI扩展类似:

jSExtendsible封装了扩展模块的方法调用；

NativeExtengdsible，是具体扩展功能的实际执行方；

extendsible_config.xml将jSExtendsible与NativeExtengdsible做了映射关系；

SDK内部，通过ModuleManager，将jSExtendsible调用协议解析、并交给NativeExtengdsible执行，最后将执行结果返回。

JS是弱类型语言，在DU的协议传输中，DU框架将所有数据转为字符串传输。而Android端的具体执行，其实都是根据协议，通过反射调用相应功能模块来完成的。Java是强类型语言，这就需要将协议中方法调用的参数做强类型转换。

例如：JS端调用textView.setHeight(12)设置高度，协议传输过程中，12是字符串，调用的是Android端TextView的setHeight(int pixels) 方法。这时需要将字符串”12“转换为int类型。类转换器处理的就是类似场景。

目前DU已经封装了30几种类转换器，基本可以覆盖常规开发需要。接入方也可以根据实际情况，扩展自己的类转换器。具体原理以及实现过程和UI扩展、模块扩展一致，如下图。这里不再赘述。

以上， DU动态框架核心技术点已给大家分享完毕。当然，我们在开发过程中，遇到了各种各样的问题，在这里和大家做个分享，采坑经验最宝贵：

1、JS引擎的选择

在DU行程框架诞生之前，招才猫使用了以WebView为引擎，作为协议中转核心，通过JS，创建Native页面并执行相关逻辑，实现了发布页面的动态化。

在后续优化中，在发布页面基础上，提取了通用协议，并做了更加丰富的封装，产出了第一版DU，同样，第一版DU框架的核心引擎也是WebView。WebView在这里的作用仅仅是执行JS，并负责与Native通讯。可以想见，WebView页面绘制等功能并没有使用，但是我们仍会进行初始化，造成了资源浪费。经过对比与调研，我们最终引入了V8，作为DU框架的JS解析执行以及通讯引擎，减少了DU在运行时的资源消耗。

2、复杂动画的处理

在需求开发中，必然会用到各种动画效果，DU框架已支持常用的动效实现，如Animation、Transition等，DU已做了封装，可以直接使用。但在我们使用过程中发现，简单动效还好，DU完全能够胜任。一旦在DU中实现比较复杂的动效时，页面就会出现卡顿现象。经过试验与分析，我们发现在动效执行过程中，JS与Native会进行频繁交互，在协议传输、解析过程中，由于数据传输过于频繁，造成通讯模块处理延迟，导致页面卡顿。

在解决动画问题上，我们针对动效交互的协议做了大量优化，但收益不佳。在后续优化中，我们放弃了在动效交互协议上做文章，而是考虑其他解决方案。得益于我们UI扩展能力，在开发实践中，我们将复杂动效封装成UI组件，将动效完全交由Native实现，JS端仅仅作为调用方。这样，就不存在动效执行中，协议交互频繁的问题了。此方案的坏处就是如果动效组件在之前版本中没有实现过，还是需要跟随版本上线。不过在实践中，需要特别复杂动效的情况，少之又少。DU完全能够胜任目前的需求。