DEEPROUTE LAB | One code, run in any systems

【DEEPROUTE LAB栏目介绍】元戎启行是一家国际领先的L4级自动驾驶全栈解决方案提供商，为车企、Tier1、出行公司、物流企业等提供多应用场景、定制化的自动驾驶解决方案。本栏目是我们创办的自动驾驶学术产业前沿知识共享平台。我们将会不定期分享公司内部的Paper Reading，也会在这分享我们对行业以及最新技术进展的理解，期待有越来越多的同学爱上自动驾驶，加入这个行业！

前言 Background

在客户端开发迭代越来越讲求迅速和同步的今天，我们要做一个App，正常情况需要不同的岗位人员来兼顾，同时兼容移动端或者PC端的多终端平台，各终端分开开发，开发量大，但是开发周期更新迭代还不好同步，效率偏低和用户体验不统一。

那有没有可能只写一套代码就能在所有系统平台使用？其实Web应用可以实现，你只需要安装一个浏览器，然后打开一个网页就可以了。但是Web应用天生有缺陷，对于复杂的IO操作和图形化渲染效果，由于权限、性能等问题，没法完全满足需求。

所以从几年前开始，很多国内外的公司都开始探索客户端应用的跨终端解决方案，并渐渐在全行业推广使用，支持和兼容性也越来越好，以下是本人对跨终端应用的一些简单理解总结。

目标 Objectives

首先来谈谈我们想要什么？

终极目标：One code，run in any systems

现实情况：一套代码多终端发布，听起来也许很美好，但真实做起来并不容易

次终极目标：工程师只需掌握1-N个相似的技术栈就能完成多终端应用的开发和维护

接着我们来想想为什么？

这个事情呢，就像老板给大家开员工大会一样，目标很宏大，现实很骨感，但回归问题本质，为啥跨终端开发问题总是被提出而且能让老板痛心疾首，我们可以总结成几点：

1. 提高效率减少重复劳动**！（就是程序猿想偷懒，老板想节省成本）

2. 易上手好维护！（程序猿们学习新东西太累了，老板想让员工非不可替代）

3. 保证性能体验！（有时候代码优化比框架优化更影响性能，老板要求保证高可用）

方案 Keys

目标有了，爱折腾的工程师们会怎么样做呢？

我们先聊PC端的吧。

PC端当今主流的是Windows、Linux、macOS三大平台，以往应用也都是分开开发分开编译，技术栈主要是C#、C++、Java、Python等。后来越来越多童鞋转向Web端开发，只需要安装一个浏览器输入一个网页地址就能打开Web应用，无需下载安装应用，使用起来极其方便，重点还支持热更新呢，一下风头无两。

输入一个随着nodejs和V8引擎的出现和发展，一群爱折腾的前端工程师也想掺和一下桌面应用，把自己写的网页拓展一下，用Web的技术栈来实现PC应用的开发，甚至完全兼容取代。

Electron就这样出现了，Ta是GitHub发布的跨平台桌面应用开发工具，支持使用Web技术开发桌面应用，其本身是基于C++开发的，GUI核心来自于Chromium，而JavaScript引擎使用V8。前端代码方式编写，同时打包成Windows、Linux、macOS应用，其开发的应用本质上就是一个Web应用跑在浏览器内核上，再通过Node.js(C++)来对原生API进行操作。简直就是黑科技啊！

在Electron中，分为主进程和渲染进程，前者负责调用底层API(如IO操作、内存管理等)，后者负责Web页面渲染，前者通过封装后暴露接口方式让后者调用，后者通过回调发送消息的方式与前者的监听函数进行通讯。

对于当今PC终端开发，个人偏向使用Electron或QT（QT是神一样的存在且对嵌入式支持度好），毕竟只需要不用再重新学习新技术就能让诟病的Web应用缺点得以解决，完美解决一套代码发布成Web应用和不同终端PC应用，美哉美哉！像大家常用的VS Code就是Electron开发的，然而Electron开发也有很明显的几个缺点：因为内置Node.js和Chromium内核，导致打包过大；前端开发对于底层API了解不深，很难让性能的使用充分发挥；因为浏览器渲染限制，对于高渲染要求的程序还是会出现卡顿。

在公司项目，现在主要是我们的数据管理工具（Data Pipeline）使用的Electron来进行部分开发，这样在客户端可以跳过浏览器自身进程进行上传和下载的IO操作，可以有更高的自由度和体验感。同时我们在Electron内使用React+UI库的方式也极度提高效率。

图片说明

我们再来聊移动端。
从13-14年开始移动端大爆发，一大堆崭新的岗位也相继出现，安卓工程师、IOS工程师、H5工程师、手游工程师等等。但前期的简单粗暴发展渐渐到了现在的冷静稳定期，又一堆爱折腾的客户端开发工程师开始思考怎么在后移动开发时代发展新的开发模式。
当然，在红海期结束之后，之前的移动端快速开发抢占市场也进入到如何提高效率快速敏捷的进行迭代。效率成为了核心关键点，于是便出现各种方式的提高效率和节省成本尝试。
大概梳理了一下到现在为止的几个主流多终端开发方案模式：
图片说明

另外还有两个有趣的参与者：
1. 小程序：被创造的独立的生态系统，基于Web基础上各家小程序百花齐放，但各家封闭不通用。

解决方案：通过编译框架层解决，类如Taro、Uniapp等框架，把JSX写的模板通过静态编译的方式编译成小程序自身的模板。
问题：因为各家模板的不统一，导致代码编写的组件和API有诸多限制，渲染性能也有损耗，而后转为运行环境+静态编译优化的方式。

2. PWA：PWA（Progressive Web App）是Google提出的一种理念，使用多种技术来增强web app的功能，可以让网站的体验变得更好，能够模拟一些原生功能，比如通知推送、离线渲染等。在移动端利用标准化框架，让网页应用呈现和原生应用相似的体验。

特点：外表高仿APP的Web应用，前提是安装主流浏览器（如Chrome/Firefox），支持PC和移动端，就是通过浏览器快捷打开一个Web应用，例如：“将网页书签添加到手机屏幕”这样的功能。所以所有Https的Web应用稍微修改一下，都能改造成PWA。
缺点：只是在展现、缓存、通知、后台功能方便对Web App进行优化，更多是对之前Web标准在体验层面的升级优化，没有本质解决Web端痛点问题。

总结一下，移动端跨终端解决方案关注的两个核心问题：动态化发布和开发成本。

结果 Results

针对以上方案我们实践的选型标准有：

应用的类型、更新频率、用户人群等
自身团队的技术栈，例如我希望都是React体系下进行开发
框架的文档资料、第三方扩展和社区活跃度等
标杆团队和友商团队的选择
对UI交互和业务逻辑一致性的要求
开发效率和维护成本

但是我还想到的几个问题：

debug any system也不容易，有些方案的热更新就是个大问题
webview性能提升，是否值得一套复杂方案
跨终端方案专注于UI层的统一多于业务逻辑层代码的统一，我希望的是让React逻辑能复用
对于动态化布局和Web容器优化之间的取舍
性能提升肯定会越来越好，但框架升级的阵痛也很痛

跨终端方案并没有对用户产生比原生更好的体验，但对开发者却有极大意义，这是能打破固有平台限制的一次次反抗！
对于我们这些创业团队的开发者，有时候需要身兼多职，还要兼顾敏捷开发的要求，跨终端解决方案可以让我们用更小成本做产品验证和避免重复造轮子，让更专业的人在通用库方面做迭代，我们能更多关注满足业务逻辑的需求。

所以，我们能做的：
跨终端方案会给我们提供UI层的统一和底层原生的API，解放开发者，能更多把时间追求业务逻辑的极致，业务逻辑和前后端交互的跨端统一是我们完全可控的，业务体验高可用才是我们的重点。
跨终端也是每年都在变，也许明年旧的方案又被推倒，新的方案又上位了，所以不存在最好的方案，只存在暂时的最合适方案，根据自己项目的需要来制定合适的方案，这才是提高效率之道。