随着互联网红利的消失,整个移动市场的关注从“流量”转成了“留量”,大部分的移动产品也都告别了初期的抢占市场,进入了 A/B 实验和快速试错的阶段,迭代速度、效果验证的压力与日俱增,效率变成了移动 App 的核心竞争力。

同时随着红海期结束,现有 App 都开始对用户的时间进行激烈的争夺。普通的 App 不断的扩展领域和内容来满足长尾需求、超级 App 们也不断的提高护城河构建自有生态。所以无论是流量分发、精细化运营、还是提升时长,都需要 App 不断的增加平台化的属性,高效的响应调整和变化。

技术趋势一定是顺应行业发展的,在提升效率这样的行业背景下,App 整体的架构和技术选型,也都到了进行服务于效率的架构升级,拥抱工程化敏捷的时候了。

- 目录-


- 基于 Web 技术栈的敏捷提效-


无论激进的改革派们选择哪一种单一的技术栈进行重构、也无论动态化和跨平台技术中台团队如何分享和布道,面对存量代码和历史包袱,除去中台、组件化等常规优化,为了提升 App 整体的工程化效率,最实际和平稳的架构升级方案,就是基于 Web 和 Javascript 技术栈,选择和搭配多种框架或优化来满足业务需求,解决业务痛点。

当然基于 Web 技术栈的优化只是未来 App 架构升级的方向之一,App 面对效率的提升、平台化建设以及中台的技术趋势,也需要不断的升级和扩展其他技术栈和平台新技术来寻求突破,赋能产品。在这里我们只围绕动态化布局和框架Web 容器优化小程序和跨平台三个方面,简单介绍基于 Web 技术栈的动态化跨平台优化方案。

- 动态化布局 -


无论任何形态的 App 产品,对于客户端开发的大部分的工作都集中在了不断的 UI 样式调整、交互调整、A/B 实验等等。那么对于工程化敏捷的实现,无论是提升开发效率、减少 Leadtime 还是释放人力成本,对这部分能力的升级都是极为关键和重要的, 这就要求 App 必须要实现 动态化 UI 布局 的能力。

1. DSL + Layout 方案

回归到动态化 UI 到本质,我们希望做到 UI 布局动态化,最简单的方式就是动态下发 UI 的布局信息,Native 使用解析之后的数据对 View 进行布局。


其实以上,也就是目前流行的 DSL + Layout 动态化方案的整体实现。天猫的 Tangram、美团的 MTFlexboxPicasso 等等都是在此基础上进行的完善和封装。同时由于 Flexbox + Yoga 的出现,这种技术方案甚至已经发展到了几乎每个小团队都有一个轮子的程度。

2. JavaScript 运行时方案

通过 DSL + Layout 的方式,我们就可以实现交互较少的基础 UI 动态化布局能力。那么随着动态化 UI 的功能边界不断扩大,这种方式的局限性也渐渐的显露出来:对于自定义视图的扩展、交互能力处理的限制、复杂 UI 状态的管理复杂性等等。


当然作为一个功能完备的框架,在这类框架中我们不光要关注整体功能的模块分布,其中 Javascript、布局计算、UI 渲染等逻辑的线程管理、跨栈数据传递的优化、组件注册以及布局、更新逻辑,以及基于 JS 驱动异步布局的设计思想,都值得不断的学习和体会。

3.框架优化方向和工程实践

随着这类技术方案的普及,各大公司和团队也都有了定制化的优化方案, 比如基于 RN 腾讯的 Hippy、携程的 CRN 等等。同时相应的方案也被更上层的框架所内置,比如后文介绍的跨平台方案如 chameleon , uni-app 等也都内置了 Weex 来实现 Native App 。

整体上看,为了更好的和自身的历史逻辑和产品形态结合,不同的开发团队在保证核心链路的基础上,对整个框架方案的各个层面都进行了优化和扩展,比如从语言到渲染的完整链路:

同时与现有业务融合的工程化建设和方法论,也是近几年各大演讲分享的热门话题。从自动化构建打包集成、JS 文件的 lint 检测、版本兼容以及离线资源发布,到各种工具链和脚手架、完善的 Debug 能力和可视化的发布平台;从各项性能指标的完整监控、统计和告警,到对历史业务和逻辑的重构经验等等。

- Web 容器优化 -


面对用户关注和时间的激烈争夺,大部分 App 中都增加了大量的运营需求,比如红包礼包、福利任务、用户等级等来增加留存和提高用户时长,同时对热点事件、爆款的运营和玩法也变得越来越灵活和复杂。针对这种突发、多变、甚至政策风险的场景,产品需求对 App 提供的 Web 容器也提出了更高的要求。

1. WebView 容器优化

App 作为 WebView 容器和 Native 能力提供方,就需要对第三方提供高性能和高质量的 Webview、灵活的展示场景、以及安全和全面的 Native 能力和数据。与之对应的在 App 中的技术落地,除了前端角度的 Web 优化,主要有以下几个方面:

总的来说,客户端中的 Web 容器优化,就是围绕着 WebView,从自身加载性能、Native 能力和数据支持、对外接口安全扩展、离线包和丰富的 Native 展示场景等角度提供完整的优化方案。这其中并没有完整的通用框架支持,需要开发者结合业务逻辑整合多个优化点,制定符合业务场景的优化策略。

2. 面向前端的 Web App

以上都是从 App 开发者的视角进行的容器优化,而从前端的角度,如何将 Web 内容迁移到移动设备上形成独立 App 才是对于他们的最优方案。所以无论是 cordovaPhoneGapcapacitor,还是国内的 KerkeeappcanWeX5 等等都是这一类的解决方案和开源框架。这些框架主要实现了 Native App 的基本框架、加载展示 Web 容器、最重要的就是封装Native 能力,支持 JS 使用 Native 的能力和数据。

与上文提到的动态化布局和框架不同, WebView 容器的优化以及 Web App 框架的这类方案,虽然都是基于 Javascript ,使用 Javascript 引擎运行逻辑,但是他们使用 WebView 作为渲染展示而非映射成独立的 Naitve View。而对于这类方案更加深入的优化,就不得不对提到小程序了。Web 开发者通过 Web App 框架在操作系统上构建完整的 App,而通过小程序框架,在各自的平台里就构建出了小程序这样的功能形态。

整体上,从前端的角度来看动态化跨平台的实现方案,可以简单的分为是否使用 WebView 作为渲染介质。使用 WebView 作为渲染的跨平台动态化方案,主要各类 Web App 框架与小程序等等,而不使用 WebView 作为渲染,但是利用 Javascript Engine 的动态化跨平台方案则是 react-native / Weex 等。

- 小程序和跨平台 -


构建 App 敏捷型架构的目的,除了快速满足用户需求、提升用户体验之外,还有的就是对开发效率的提升和人员成本的优化。那么相应的对于客户端的 Web 技术栈,跨平台技术的应用正是解决的这个问题。

1. 小程序的挑战与机遇

从技术实现上说,小程序就是 JS-Api 的升级优化版,核心解决的问题也是 Web 侧对 Native / 宿主 App 能力的调用、和 Native / 宿主 App UI 组件的深度结合等。当然以微信小程序举例,小程序在以 WebView 为渲染核心的基础上有很多优化,比如为了提升渲染性能和安全管控采用的双线程模型以及背后的优化、解决 Native 组件在 WebView 中的展示层级使用了同层渲染技术的优化、以及渲染层面采用 Skia 的尝试等等。


2. 跨平台框架的演进

无论是最初的 Web,还是使用 DSL 实现统一 UI 的方案,到后来的 react-native / Weex 方案,其实都是有跨平台的“Write once, run anywhere”思想。但是从他们的实现上我们可以发现,这些技术方案并没有真正抹平平台的差异,只是对于开发者使用统一的语言来实现而已。

- 结语 -


从 Hybrid App 到 小程序,从 React Native / Weex 到 Flutter,近几年动态化和跨平台技术层出不穷,各个公司和团队也都积极的投身到其中。但是,目前动态化和跨平台的领域还没有最终的解决方案,各个框架面向的开发者、解决的问题、自身缺陷和瓶颈都很明显,比如 Web 的交互体验和稳定性、基于 DSL 方案的灵活性和扩展性、基于 JS 方案的性能和维护成本、Flutter 对混合工程的支持等等。

但是移动产品行业的发展、产品形态的转变却不会放慢脚步。越早的投入到服务于效率的架构升级、越早的拥抱中台和动态化的提效,才能在未来更好的支撑和赋能业务,发挥技术真正的价值。