2019 与我的技术之路

文章首发于我的博客 https://github.com/mcuking/bl...

回首 2019

2019 年主要都是在用 Web 前端技术来写 Hybrid 应用，所以技术上的积累大部分都是和 Hybrid 有关的。上面这张图就是今年的整体技术探索路线图。下面我就一一阐述下其中每项具体内容：

3 月 JSBridge

成果：https://github.com/mcuking/JS...

在开发 Hybrid 过程中因为有感于客户端提供给前端的接口过于难用，主要有两点：1. 安卓 和 iOS 两端接口调用方式不同；2. H5 端无法传入回调函数来接收 Native 的方法执行结果。于是乎我准备突破一个纯前端开发的定位，开始涉足 Native， 当然主要是 Native 和 Web 融合的部分。

第一步就是开始研究 H5 和 Native 通信桥梁—JSBridge，通过在掘金上阅读了大量关于 JSBridge 底层实现原理的文章，最终自己实现了一个安卓平台的教学版 JSBridge：https://github.com/mcuking/JS...

不过最终在实际项目中使用的是安卓和 iOS 双平台均支持的 DSBridge:
DSBridge-Android
DSBridge-IOS

6 月 React Native 和 H5 融合

成果：成功融合了两个不同技术栈的 App，对 React Native 有一定实战经验

公司决定将原来基于 Vue 的纯 H5 开发的 App 和一个基于 React Native 的开源 IM 客户端 mattermost-mobile 融合成一个 App。主要通过 React Native WebView 加载了 H5 页面，并且统一了两个 App 的鉴权，定义了两者互相跳转调用的机制，另外改造了 RN 部分的交互（从安卓的 Material Design 风格改成 iOS 风格）。

7 月 Vue to React

成果：https://github.com/mcuking/vu...

因为 6 月的融合过程中需要将一些原来写好的 Vue 组件，用 React Native 再来实现一遍，再加上当时也正在了解 taro、chameleon 这种 写一套代码运行多端的框架，于是觉得不如也写一个 Vue 组件代码转 React 组件代码的工具。

接着就开始收集了各种类似的工具，研究其中具体的实现方式，最终确定了实现的思路：先通过 vue-template-compiler 工具的 parseComponent 方法将 Vue 单文件组件分解成 template、script、style 三部分，针对 template 再使用 vue-template-compiler 工具的 compile 方法转化成 AST，script 部分则使用 @babel/parser 工具转化成 AST，然后提取 data、 props、 computed、 methods 等参数，根据 vue 和 react 属性和方法的映射关系，调整 AST 树，最终再通过工具生成 react 组件代码。

后面将其封装成 npm 包，可以通过 cli 方式或者可视化页面工具方式来使用。不过因为因 Vue 和 React 这种库的 API 更新比较频繁，React 主流写法又转向了 hooks 的方式，以及不同人的代码风格迥异，觉得这类工具局限性较大，所有后续并没有持续开发，甚是遗憾。

8 月 移动 web 最佳实践

成果：https://github.com/mcuking/mo...

这段时间其他部门也要采用 H5 + Native 方式开发模式，因此过来咨询了一些相关问题。后来觉得为什么不把在这方面的一些积累整理成一个最佳实践模板呢？这样的话后面的人就能少踩很多坑。于是乎就创建了这个仓库：mobile-web-best-practice。其中涵盖了 web 在移动开发中的大部分方面：mobile 组件库、JSBridge、虚拟路由栈、样式适配、手势库、webpack 优化、异常监控、客户端上 H5 常见问题等等。

10 月 前端分层架构

成果：前端分层架构实践心得

一直以来我们都是用 Vue 同时开发 Mobile 和 PC 两端，两位前端分别负责一端，很多业务逻辑都是单独在两端实现的，当产品需要修改部分业务时，时常会漏掉某一个端；另外一个问题是，项目没有按照一定思想分层，导致很多业务逻辑堆积在 View 层或者 Utils 公用方法中。

为了解决这两个问题，笔者研究了 DDD/Clean Architecture 等思想以及在前端的一些实践经验，将前端项目按照分层架构思想，分成了 Services 层（包含 Request 层、Translator 层）、Entities 层、Interactors 层、View 层，以实现关注度分离，使得业务逻辑的分布有了一定思想指导。另外将前面除了 View 层之外的 PC 和 Mobile 两端可共用的层抽离出了单独的一个 npm 包，从而实现除了视图层之外的改动，只需要一次即可（除非某个业务逻辑在不同平台有不同要求）。

11 月 离线包

成果：Hybrid App 离线包方案实践

从刚开始开发这个 App 的时候，H5 部分就是通过远程 Url 进行加载的，加载速度一直备受诟病。首次加载时过于依赖用户当时所处的网络环境，弱网情况下加载白屏时间可达 5 到 6 s 甚至更久。虽然第二次加载会有 Http 缓存，但是实际上这种缓存并不稳定，经常会有丢失现象。

为了保证页面加载速度是由开发者可控的，笔者开始收集很多互联网公司在这方面的解决方案，发现主流方式都是采用离线包方案，通过结合目前我司的前端部署实际情况（通过 Jenkins 打包成 Docker 镜像），最终形成了一套可行的离线包方案，迭代完成后又将所有端（前端 webpack 插件、离线包平台前后端、安卓离线包库）代码都开源在我的 GitHub 上了，希望能够帮助到其他人。下面是这个方案的技术架构图，更多细节就不在这里赘述了，感兴趣的可以查阅上面的文章。

在这个过程中，在将整个方案提到项目组里进行开发之前，需要验证方案的可行性。于是笔者购买了自己的云服务器，并部署了 Jenkins，Docker 等工具，跑通了整个离线包方案，并将这个过程记录成了一篇文章：

Github + Jenkins + Docker 实现自动化部署