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 实现自动化部署