前端跨端跨栈

如何在 toB 业务中使用 RN 开发 APP

现状：研发资源有限（15人）、场景复杂，需求多变，技术栈混乱（React、Node、Java、Vue…）
切入点：技术栈统一 RN、制定协同规范

React Native 技术架构：JS => JS Bridge => Native（JS Bridge 封装 Native api，供 JS 调用）
RN App 主要模块：基础依赖包、脚本工具、组件库、页面模板、状态管理、埋点报表等
监控平台：埋点监控、错误捕获及上报、定责告警
APP 建设思路：基础/业务组件、基础通用框架、持续集成、多端融合

如何在滴滴快速落地 Chameleon（卡梅隆）

多态协议：接口、组件、样式、模板，都可以根据渠道实现自定义扩展；通过多态协议调用对应端底层能力**

如何使用 Electron 构建跨平台应用（桌面应用）

端的延展：浏览器、服务端 Node、移动端、IOT、桌面端
改变项目创建方式：CLI => GUI

• 将命令行可视化
• GUI 优势：简化操作链路、能力串联化、抹平差异、降低研发复杂度

Electron 进程通信思路

1. 主进程监听事件并定义响应回调，调用底层原生能力
2. 渲染进程触发事件并定义接收触发函数

工程化实践

由点到线：单点命令 => 任务流

具体实现方式：将命令行调用改造为函数式调用，需要通过 Promise 来实现
终端模拟：反馈任务进度？？？

更新流程：renderer process 通过定时任务检测版本请求 => 触发主进程中的版本更新模块 => 下载资源 => 反馈进度

如何使用 Rax 构建 Flutter 应用

构建跨端应用的可行性：底层模块趋于一致，这为构建跨端应用提供了可能，但仍需做一些差异处理

前端眼里的 Flutter

• 使用 Dart 进行开发，前端开发有门槛
• 脱离前端生态，不支持 Flex Layout，脱离前端生态

使用 Flutter 的刚性需求：具有动态性支持 Hot Reload；可连接前端生态

Kraken原理

Kraken JavaScript Runtime：统一底层api，Timer、Interval 等

Kraken 能否⽐ WebView 更好？

快速下拉页面会发生什么？

• WebView 异步光栅化：CPU 持续疯狂绘制，GPU 迟迟不过来获取，造成内存占用急剧升高
• Kraken 同步光栅化：CPU 绘制同时持续通知 GPU 输出，不会累积

1. 云端一体化是渲染技术新趋势
2. Kraken 赋予了前端⼯程师不再受制于浏览器⼚商，具备重新定义浏览器的能⼒

Kraken 不是容器，不同于 Webview，他是对 Flutter 的改造

如何打磨 uni-app 跨端框架的高性能

uni-app 简介：继承自 Vue；多端发布（App、H5、小程序）

跨端：条件编译

小程序

• 视图层和逻辑层是分离的
• 跨端实现：编译器 + 运行时配合
• 运行时：小程序和 Vue 里面，如何分工？
  • Vue 负责数据管理，小程序负责视图展现，uni-app runtime 作为中间桥梁进行桥接
  • 跨端实现：框架、组件、API，从这三个方面入手做转换进行差异抹平

H5：主要解决与小程序渲染引擎差异导致的系列问题

性能优化

小程序通信：视图层 => Native => 逻辑层 => Native => 视图层（4 次交互，消耗资源）

通讯阻塞是业界普遍存在的一个问题
⼀句话总结：UI 交互逻辑在视图层执⾏，避免和逻辑层频繁通讯

渲染性能

• 减少调⽤ setData 数据量，避免重复赋值
  • 改写 Vue 的 patch 实现，删掉 vnode，仅 Diff Data 数据
  • 借鉴 westore JSON Diff 库，实现⾼效、精确的差量数据
• ⾃定义组件实现局部数据刷新

主流小程序使用 Web 渲染，其实还可以使用 Native weex 渲染方式

如何借助 Taro Next 横穿跨端业务线

新特性

• 更强大：不限制语言和语法；跨框架组件
• 更迅速：剥除 AST 操作构建更快；提升初始化和更新操作的性能
• 更灵活：插件化系统；依赖瘦身、暴露配置

入口组件 app.js：引入框架（React、Vue）、全局样式、生命周期、渲染函数；与框架使用一样
API：小程序端 api Promise 化；H5 端 Mock
样式工具：CSS modules、linaria

性能优化

• Taro =setData=> View：最⼩颗粒度的 setData；按路径更新
• 预渲染
• 长列表优化：超出可视区的列表项使用展位元素取代
• 体积优化：webpack-bundle-analyzer；分包

如何在物联⽹多设备屏中实践跨端开发

跨端场景

• 端：手机、电视、手表、音响
• 系统：iOS、Android、Linux、RTOS
• 技术栈：React Native、H5、⼩程序、cube⼩程序

提效降本：跨端开发⽅案 + 可视化搭建
跨端实现方式：代码编译；跨平台解析器；云端渲染用户端展示

跨端关键技术点

跨度基础组件：差异抹平（布局组件 View、text；功能组件 Image、Video 等）

跨端模板

• 指令模板：有限的逻辑能⼒，Vue、⼩程序等都属于此类模板
• JS 语言混合模板：混⼊JS语⾔，使模板具有JS语⾔⼏乎完整的表达能⼒，JSX属于此类模板
• 对比
  • 单从模板层面讲，JS 语言混合模板的表达能力要远大于指令模板，但从与数据结合渲染出结果的能力上讲，两者是对等的
  • 以AST树冒泡的⽅式将语⾔混合模板分离为指令模板和数据预处理函数

跨端样式：能力对齐、能力补齐、样式继承等
跨端组件模型：生命周期、数据到视图的渲染方式、视图事件的监听方式
跨端应用模型：生命周期、路由、启动方式

Think

• 为什么要搞跨端跨栈，有什么好处？
  • 提效降本，这是包括跨端跨栈等工程化体系致力于解决的问题；多端适配、一套代码多处运行从而避免各端都需单独开发而造成资源浪费；而跨栈统一技术方案则能使开发具备普适性，降低开发人员学习成本及后期维护成本
• 要实现跨端跨栈应该怎么去做？
  • 各位大佬从不同角度对跨端跨栈做了分析解读，或是统一技术方案选型、或者自研跨平台解决方案、或是基于已有解决方案进行二次开发，殊路同归，都是跨端跨栈的具体体现，而具体使用哪种方案，还要根据实际情况并结合业务需求遴选，合适的才是最好的
• 跨端跨栈会遭遇什么问题，有哪些疑难点？
  • 最大问题还是适配多端，需要针对各平台差异进行抹平，同时在各端保持相对一致

书单 《牛虻》 《少有人走的路》 《摆脱疲惫感》 《闪电式扩张》 《黑客与画家》

Weex、IOT、Kraken、Rax、DSL