青桔单车 chameleon 跨平台实践

前言

近些年，整个前端领域发展迅速，效率型的前端框架也层出不穷，每个团队选择的技术解决方案都不太一致，因为互联网的特性及中国自身的特色，各个产品对于多端的投放的需求是一致的。像小程序这种跨端场景和现有的开发方式也不一样，为了满足业务的需求技术人员在日常开发中会因为投放平台的不一样而进行多套代码的维护，效率较低且成本也高。跨端框架应景而生（这里就不过多介绍各个跨端的框架了）。

在我看来大前端是趋势，跨端是趋势的第一步，而对于技术人员来说在不影响功能体验的情况下能解决维护多套代码的痛点非常重要，改编一下比较流行的一句话:「lean once，write once，run anywhere」

背景

行业现状 — 百家争鸣

经过将近两年的发展，小程序已经深入用户的日常生活，小程序应用数量超过了百万量级，覆盖200多个细分的行业，日活用户达到两个亿。与此同时，像支付宝、百度、头条、手Q等等都开始了自家的小程序生态，百家争鸣应景而生。青桔单车作为便民的出行工具，对于用户使用方式上也是成本越低体验越友好，即用即走的小程序已然成为平台选择的趋势。

业务要求 —高效稳定多入口

高效、稳定、多入口就是业务现在的要求，青桔单车是日活相对较高的小程序（目前在阿拉丁小程序 TOP 榜前10），这也要求我们对小程序的性能（加载、渲染、响应的时间）、稳定及安全有较高的标准。

同时业务也需要在各个平台上获得更多的入口，这就直接导致我们在选择框架，业务开发时要求比较严谨。

框架期望

从用户角度出发，为了减少用户使用成本（下载安装或更新 APP ），我们选择了市场上比较符合单车特性的平台作为入口。那么这时候对于研发来说就会有很多问题，我们在选择框架时，会对以下点有较高的期望或要求:

1. 各端开发效果要高度一致，不能开发一次后用大量时间兼容多端
2. 针对不同的端有差异化的实现方式，能较容易去扩展，以应对产品对不同端的差异化需求
3. 工程化要好，因为前端过程式的开发比较低效，需要使用软件工程的技术和方法进行开发、管理
4. 框架设计，接入不用改动太多代码，具有较好的抽象度
5. 对性能上要求很高，包大小、加载、渲染、响应都需要严格考虑

实践

跨端技术方案设计

跨平台框架——chameleon

引用 chameleon 官网的简介：

Chameleon 不仅仅是跨端解决方案，让开发者高效、低成本开发多端原生应用。基于优秀的前端打包工具 Webpack，吸收了业内多年来积累的最有用的工程化设计，提供了前端基础开发脚手架命令工具，帮助端开发者从开发、联调、测试、上线等全流程高效的完成业务开发。

从chameleon框架的架构设计图看：

• 在各个平台下chameleon基于其本身的运行池增加一层包括路由、自定义生命周期、组件、数据事件绑定及管理、样式渲染等相对完整的 DSL；
• chameleon-tools 做编译（基于 webpack），提供语法检查、转译、依赖组装等；
• chameleon-UI、chameleon-API 做各个平台样式的不一致、API差异化的抹平；
• 提供多态协议的方式解决组件及 API的差异化；

综合来看 chameleon 的设计模式比较适合我们做跨端项目的开发，提升我们的效率，不维护多套重复的代码…

青桔单车业务技术架构

青桔单车简单的业务流程图：

青桔单车业务相对复杂，包括登录、认证、电子围栏、宣教、状态扭转等超过 30 个页面（不包括各种 H5 实现），用户主动打开/微信扫码进入小程序，完成登录后开始扫码开锁，开锁成功后 === 发单成功，用户开始骑行，骑行结束后完成支付整个流程结束（这里只提到核心流程），因为业务需要，我们需要维护微信、支付宝、高德（快应用、百度接入中）等众多小程序，对于研发来说最快的是 copy 一套代码然后针对性进行修改&