2019 年主要都是在用 Web 前端技术来写 Hybrid 应用，所以技术上的积累大部分都是和 Hybrid 有关的。上面这张图就是今年的整体技术探索路线图。下面我就一一阐述下其中每项具体内容：
成果： https://github.com/mcuking/JSBridge
在开发 Hybrid 过程中因为有感于客户端提供给前端的接口过于难用，主要有两点：1. 安卓 和 iOS 两端接口调用方式不同； 2. H5 端无法传入回调函数来接收 Native 的方法执行结果。于是乎我准备突破一个纯前端开发的定位，开始涉足 Native， 当然主要是 Native 和 Web 融合的部分。
第一步就是开始研究 H5 和 Native 通信桥梁—JSBridge，通过在掘金上阅读了大量关于 JSBridge 底层实现原理的文章，最终自己实现了一个安卓平台的教学版 JSBridge： https://github.com/mcuking/JSBridge
不过最终在实际项目中使用的是安卓和 iOS 双平台均支持的 DSBridge: DSBridge-Android DSBridge-IOS
成果：成功融合了两个不同技术栈的 App，对 React Native 有一定实战经验
公司决定将原来基于 Vue 的纯 H5 开发的 App 和一个基于 React Native 的开源 IM 客户端 mattermost-mobile 融合成一个 App。主要通过 React Native WebView 加载了 H5 页面，并且统一了两个 App 的鉴权，定义了两者互相跳转调用的机制，另外改造了 RN 部分的交互（从安卓的 Material Design 风格改成 iOS 风格）。
成果： https://github.com/mcuking/vue2react
因为 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 的方式，以及不同人的代码风格迥异，觉得这类工具局限性较大，所有后续并没有持续开发，甚是遗憾。
成果： https://github.com/mcuking/mobile-web-best-practice
这段时间其他部门也要采用 H5 + Native 方式开发模式，因此过来咨询了一些相关问题。后来觉得为什么不把在这方面的一些积累整理成一个最佳实践模板呢？这样的话后面的人就能少踩很多坑。于是乎就创建了这个仓库：mobile-web-best-practice。其中涵盖了 web 在移动开发中的大部分方面：mobile 组件库、JSBridge、虚拟路由栈、样式适配、手势库、webpack 优化、异常监控、客户端上 H5 常见问题等等。
成果：前端分层架构实践心得
一直以来我们都是用 Vue 同时开发 Mobile 和 PC 两端，两位前端分别负责一端，很多业务逻辑都是单独在两端实现的，当产品需要修改部分业务时，时常会漏掉某一个端；另外一个问题是，项目没有按照一定思想分层，导致很多业务逻辑堆积在 View 层或者 Utils 公用方法中。
为了解决这两个问题，笔者研究了 DDD/Clean Architecture 等思想以及在前端的一些实践经验，将前端项目按照分层架构思想，分成了 Services 层（包含 Request 层、Translator 层）、Entities 层、Interactors 层、View 层，以实现关注度分离，使得业务逻辑的分布有了一定思想指导。另外将前面除了 View 层之外的 PC 和 Mobile 两端可共用的层抽离出了单独的一个 npm 包，从而实现除了视图层之外的改动，只需要一次即可（除非某个业务逻辑在不同平台有不同要求）。
从刚开始开发这个 App 的时候，H5 部分就是通过远程 Url 进行加载的，加载速度一直备受诟病。首次加载时过于依赖用户当时所处的网络环境，弱网情况下加载白屏时间可达 5 到 6 s 甚至更久。虽然第二次加载会有 Http 缓存，但是实际上这种缓存并不稳定，经常会有丢失现象。
为了保证页面加载速度是由开发者可控的，笔者开始收集很多互联网公司在这方面的解决方案，发现主流方式都是采用离线包方案，通过结合目前我司的前端部署实际情况（通过 Jenkins 打包成 Docker 镜像），最终形成了一套可行的离线包方案，迭代完成后又将所有端（前端 webpack 插件、离线包平台前后端、安卓离线包库）代码都开源在我的 GitHub 上了，希望能够帮助到其他人。下面是这个方案的技术架构图，更多细节就不在这里赘述了，感兴趣的可以查阅上面的文章。
在这个过程中，在将整个方案提到项目组里进行开发之前，需要验证方案的可行性。于是笔者购买了自己的云服务器，并部署了 Jenkins，Docker 等工具，跑通了整个离线包方案，并将这个过程记录成了一篇文章：
Github + Jenkins + Docker 实现自动化部署
2020 年技术上的规划仍旧是在跨端开发领域中继续深入下去，目前主要的规划主要有两个：
系统深入地学习 Android 和 Java
研究小程序底层实现原理，并实现一套自己的小程序，从而探索 web 技术在移动开发中的新模式
另外还有两个生活小目标：
找个志趣相投的人生伴侣
在杭州有个属于自己的小窝
写到这里我的总结和展望就写完了，最后希望大家在 2020 年都能够实现自己设立的小目标～
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.