# (下篇)中高级前端大厂面试秘籍，寒冬中为您保驾护航，直通大厂 ## 引言 本篇文章会继续沿着前面两篇的脚步，继续梳理前端领域一些比较主流的进阶知识点，力求能让大家在横向层面有个全面的概念。能在面试时有限的时间里，能够快速抓住重点与面试官交流。这些知识点属于加分项，如果能在面试时从容侃侃而谈，想必面试官会记忆深刻，为你折服的~🤤 另外有许多童鞋提到: 面试造火箭，实践全不会，对这种应试策略表达一些担忧。其实我是觉得面试或者这些知识点，也仅仅是个初级的 **开始**。能帮助在初期的快速成长，但这种策略并没办法让你达到更高的水平，只有后续不断地真正实践和深入研究，才能突破自己的瓶颈，继续成长。面试，不也只是一个开始而已嘛。~😋 建议各位小伙从基础入手，先看 - [(上篇)中高级前端大厂面试秘籍，寒冬中为您保驾护航，直通大厂](https://github.com/xd-tayde/blog/blob/master/interview-1.md) - [(中篇)中高级前端大厂面试秘籍，寒冬中为您保驾护航，直通大厂](https://github.com/xd-tayde/blog/blob/master/interview-2.md) ## 进阶知识 ## Hybrid 随着 Web技术 和 移动设备 的快速发展，在各家大厂中，Hybrid 技术已经成为一种最主流最不可取代的架构方案之一。一套好的 Hybrid 架构方案能让 App 既能拥有 **极致的体验和性能**，同时也能拥有 Web技术 **灵活的开发模式、跨平台能力以及热更新机制**。因此，相关的 Hybrid 领域人才也是十分的吃香，精通Hybrid 技术和相关的实战经验，也是面试中一项大大的加分项。 ### 1. 混合方案简析 Hybrid App，俗称 **混合应用**，即混合了 Native技术 与 Web技术 进行开发的移动应用。现在比较流行的混合方案主要有三种，主要是在UI渲染机制上的不同: - **Webview UI**: - 通过 JSBridge 完成 H5 与 Native 的双向通讯，并 **基于 Webview** 进行页面的渲染； - **优势**: 简单易用，架构门槛/成本较低，适用性与灵活性极强； - **劣势**: Webview 性能局限，在复杂页面中，表现远不如原生页面； - **Native UI**: - 通过 JSBridge 赋予 H5 原生能力，并进一步将 JS 生成的虚拟节点树(Virtual DOM)传递至 Native 层，并使用 **原生系统渲染**。 - **优势**: 用户体验基本接近原生，且能发挥 Web技术 开发灵活与易更新的特性； - **劣势**: 上手/改造门槛较高，最好需要掌握一定程度的客户端技术。相比于常规 Web开发，需要更高的开发调试、问题排查成本； - **小程序** - 通过更加定制化的 JSBridge，赋予了 Web 更大的权限，并使用双 WebView 双线程的模式隔离了 JS逻辑 与 UI渲染，形成了特殊的开发模式，加强了 H5 与 Native 混合程度，属于第一种方案的优化版本； - **优势**: 用户体验好于常规 Webview 方案，且通常依托的平台也能提供更为友好的开发调试体验以及功能； - **劣势**: 需要依托于特定的平台的规范限定 ### 2. Webviev Webview 是 Native App 中内置的一款基于 Webkit内核 的浏览器，主要由两部分组成: - **WebCore 排版引擎**； - **JSCore 解析引擎**； 在原生开发 SDK 中 Webview 被封装成了一个组件，用于作为 Web页面 的容器。因此，作为宿主的客户端中拥有更高的权限，可以对 Webview 中的 Web页面 进行配置和开发。 Hybrid技术中双端的交互原理，便是基于 Webview 的一些 API 和特性。 ### 3. 交互原理 Hybrid技术 中最核心的点就是 Native端 与 H5端 之间的 **双向通讯层**，其实这里也可以理解为我们需要一套 **跨语言通讯方案**，便是我们常听到的 JSBridge。 - JavaScript 通知 Native - **API注入**，Native 直接在 JS 上下文中挂载数据或者方法 - 延迟较低，在安卓4.1以下具有安全性问题，风险较高 - WebView **URL Scheme** 跳转拦截 - 兼容性好，但延迟较高，且有长度限制 - WebView 中的 **prompt/console/alert拦截**(通常使用 prompt) - **Native 通知 Javascript**: - **IOS**: `stringByEvaluatingJavaScriptFromString` ```js // Swift webview.stringByEvaluatingJavaScriptFromString("alert('NativeCall')") ``` - **Android**: `loadUrl` (4.4-) ```js // 调用js中的JSBridge.trigger方法 // 该方法的弊端是无法获取函数返回值； webView.loadUrl("javascript:JSBridge.trigger('NativeCall')") ``` - **Android**: `evaluateJavascript` (4.4+) ```js // 4.4+后使用该方法便可调用并获取函数返回值； mWebView.evaluateJavascript（"javascript:JSBridge.trigger('NativeCall')", new ValueCallback() { @Override public void onReceiveValue(String value) { //此处为 js 返回的结果 } }); ``` ### 4. 接入方案 整套方案需要 Web 与 Native 两部分共同来完成: - **Native**: 负责实现URL拦截与解析、环境信息的注入、拓展功能的映射、版本更新等功能； - **JavaScirpt**: 负责实现功能协议的拼装、协议的发送、参数的传递、回调等一系列基础功能。 **接入方式**: - **在线H5**: 直接将项目部署于线上服务器，并由客户端在 HTML 头部注入对应的 Bridge。 - **优势**: 接入/开发成本低，对 App 的侵入小； - **劣势**: 重度依赖网络，无法离线使用，首屏加载慢； - **内置离线包**: 将代码直接内置于 App 中，即本地存储中，可由 H5 或者 客户端引用 Bridge。 - **优势**: 首屏加载快，可离线化使用； - **劣势**: 开发、调试成本变高，需要多端合作，且会增加 App 包体积 ### 5. 优化方案简述 - **Webview 预加载**: Webview 的初始化其实挺耗时的。我们测试过，大概在100~200ms之间，因此如果能前置做好初始化于内存中，会大大加快渲染速度。 - **更新机制**: 使用离线包的时候，便会涉及到本地离线代码的更新问题，因此需要建立一套云端下发包的机制，由客户端下载云端最新代码包 (zip包)，并解压替换本地代码。 - **增量更新**: 由于下发包是一个下载的过程，因此包的体积越小，下载速度越快，流量损耗越低。只打包改变的文件，客户端下载后覆盖式替换，能大大减小每次更新包的体积。 - **条件分发**: 云平台下发更新包时，可以配合客户端设置一系列的条件与规则，从而实现代码的条件更新: - 单 **地区** 更新: 例如一个只有中国地区才能更新的版本； - 按 **语言** 更新: 例如只有中文版本会更新； - 按 App **版本** 更新: 例如只有最新版本的 App 才会更新； - **灰度** 更新: 只有小比例用户会更新； - **AB测试**: 只有命中的用户会更新； - **降级机制**: 当用户下载或解压代码包失败时，需要有套降级方案，通常有两种做法: - **本地内置**: 随着 App 打包时内置一份线上最新完整代码包，保证本地代码文件的存在，资源加载均使用本地化路径； - **域名拦截**: 资源加载使用线上域名，通过拦截域名映射到本地路径。当本地不存在时，则请求线上文件，当存在时，直接加载； - **跨平台部署**: Bridge层 可以做一套浏览器适配，在一些无法适配的功能，做好降级处理，从而保证代码在任何环境的可用性，一套代码可同时运行于 App内 与 普通浏览器； - **环境系统**: 与客户端进行统一配合，搭建出 **正式 / 预上线 / 测试 / 开发**环境，能大大提高项目稳定性与问题排查； - **开发模式**: - 能连接PC Chrome/safari 进行代码调试； - 具有开发调试入口，可以使用同样的 Webview 加载开发时的本地代码； - 具备日志系统，可以查看 Log 信息； 详细内容由兴趣的童鞋可以看文章: - [Hybrid App技术解析 -- 原理篇](https://github.com/xd-tayde/blog/blob/master/hybrid-1.md) - [Hybrid App技术解析 -- 实战篇](https://github.com/xd-tayde/blog/blob/master/hybrid-2.md) ## Webpack ### 1. 原理简述 Webpack 已经成为了现在前端工程化中最重要的一环，通过`Webpack`与`Node`的配合，前端领域完成了不可思议的进步。通过预编译，将软件编程中先进的思想和理念能够真正运用于生产，让前端开发领域告别原始的蛮荒阶段。深入理解`Webpack`，可以让你在编程思维及技术领域上产生质的成长，极大拓展技术边界。这也是在面试中必不可少的一个内容。 - **核心概念** - JavaScript 的 **模块打包工具** (module bundler)。通过分析模块之间的依赖，最终将所有模块打包成一份或者多份代码包 (bundler)，供 HTML 直接引用。实质上，Webpack 仅仅提供了 **打包功能** 和一套 **文件处理机制**，然后通过生态中的各种 Loader 和 Plugin 对代码进行预编译和打包。因此 Webpack 具有高度的可拓展性，能更好的发挥社区生态的力量。 - **Entry**: 入口文件，Webpack 会从该文件开始进行分析与编译； - **Output**: 出口路径，打包后创建 bundler 的文件路径以及文件名； - **Module**: 模块，在 Webpack 中任何文件都可以作为一个模块，会根据配置的不同的 Loader 进行加载和打包； - **Chunk**: 代码块，可以根据配置，将所有模块代码合并成一个或多个代码块，以便按需加载，提高性能； - **Loader**: 模块加载器，进行各种文件类型的加载与转换； - **Plugin**: 拓展插件，可以通过 Webpack 相应的事件钩子，介入到打包过程中的任意环节，从而对代码按需修改； - **工作流程** (加载 - 编译 - 输出) - 1、读取配置文件，按命令 **初始化** 配置参数，创建 Compiler 对象； - 2、调用插件的 apply 方法 **挂载插件** 监听，然后从入口文件开始执行编译； - 3、按文件类型，调用相应的 Loader 对模块进行 **编译**，并在合适的时机点触发对应的事件，调用 Plugin 执行，最后再根据模块 **依赖查找** 到所依赖的模块，递归执行第三步； - 4、将编译后的所有代码包装成一个个代码块 (Chuck)， 并按依赖和配置确定 **输出内容**。这个步骤，仍然可以通过 Plugin 进行文件的修改; - 5、最后，根据 Output 把文件内容一一写入到指定的文件夹中，完成整个过程； - **模块包装**: ```js (function(modules) { // 模拟 require 函数，从内存中加载模块； function __webpack_require__(moduleId) { // 缓存模块 if (installedModules[moduleId]) { return installedModules[moduleId].exports; } var module = installedModules[moduleId] = { i: moduleId, l: false, exports: {} }; // 执行代码； modules[moduleId].call(module.exports, module, module.exports, __webpack_require__); // Flag: 标记是否加载完成； module.l = true; return module.exports; } // ... // 开始执行加载入口文件； return __webpack_require__(__webpack_require__.s = "./src/index.js"); })({ "./src/index.js": function (module, __webpack_exports__, __webpack_require__) { // 使用 eval 执行编译后的代码； // 继续递归引用模块内部依赖； // 实际情况并不是使用模板字符串，这里是为了代码的可读性； eval(` __webpack_require__.r(__webpack_exports__); // var _test__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__("test", ./src/test.js"); `); }, "./src/test.js": function (module, __webpack_exports__, __webpack_require__) { // ... }, }) ``` - **总结**: - **模块机制**: webpack 自己实现了一套模拟模块的机制，将其包裹于业务代码的外部，从而提供了一套模块机制； - **文件编译**: webpack 规定了一套编译规则，通过 Loader 和 Plugin，以管道的形式对文件字符串进行处理； ### 2. Loader 由于 Webpack 是基于 Node，因此 Webpack 其实是只能识别 js 模块，比如 css / html / 图片等类型的文件并无法加载，因此就需要一个对 **不同格式文件转换器**。其实 Loader 做的事，也并不难理解: **对 Webpack 传入的字符串进行按需修改**。例如一个最简单的 Loader: ```js // html-loader/index.js module.exports = function(htmlSource) { // 返回处理后的代码字符串 // 删除 html 文件中的所有注释 return htmlSource.replace(//g, '') } ``` 当然，实际的 Loader 不会这么简单，通常是需要将代码进行分析，构建 **AST (抽象语法树)**， 遍历进行定向的修改后，再重新生成新的代码字符串。如我们常用的 Babel-loader 会执行以下步骤: - babylon 将 ES6/ES7 代码解析成 AST - babel-traverse 对 AST 进行遍历转译，得到新的 AST - 新 AST 通过 babel-generator 转换成 ES5 **Loader 特性**: - **链式传递**，按照配置时相反的顺序链式执行； - 基于 Node 环境，拥有 **较高权限**，比如文件的增删查改； - 可同步也可异步； **常用 Loader**: - file-loader: 加载文件资源，如 字体 / 图片 等，具有移动/复制/命名等功能； - url-loader: 通常用于加载图片，可以将小图片直接转换为 Date Url，减少请求； - babel-loader: 加载 js / jsx 文件， 将 ES6 / ES7 代码转换成 ES5，抹平兼容性问题； - ts-loader: 加载 ts / tsx 文件，编译 TypeScript； - style-loader: 将 css 代码以`