同程APP混合开发实践

牛提罚

主要内容

hybrid技术实践 N站合一

Hybrid的方向

我们需要

Native的用户交互体验 Web的开发效率、发布能力

Phongap



AppCan WeX5……

优点

•快速发布 •跨平台 •可调用native原生方法 •加载更快速，更加安全 •开发成本、难度比native 小



Hybrid



缺点



•性能不如native高 •富交互体验不如native •兼容性测试不太方便，特别是android



满足我们的需求

与传统web的异同



web



浏览器、客户端



基于web 站点服务器



文件放在远程服务器端



前端+.net开发



性能较差，受网络影响大不稳定



hybrid



只能在客户端内打开和使用



基于客户端+更新包后台



文件放客户端底层



前端+中间层接口+客户端公共控件



性能好、减少用户流量

hybrid架构



Hybrid



Android



iOS



BridgeJS



Native



H5\CSS3\JS



Gulp（构建打包）



Hybrid包



更新发布系统

Hybrid架构特点



BridgeJS



• iOS、Android统一使用



Ajax请求与客户端保持一致 • 直接使用中间层数据接口



公共资源统一管理



• 统一管理公共资源，减少包大小



一键构建打包



• html\css\js，压缩合并，gulp构建，打包成zip



增量升级



• 更新包增量升级，预加载机制，轻快省的原则



版本分支控制



• 针对客户端不同版本进行升级，bug修复

Hybrid架构-bridge

Hybrid架构-bridge

Hybrid架构-增量



css

5.css



js

2.js new.js



html



change.xml



4.html

hybrid架构-项目加载流程



打开项目



包校验



下载 解压



进入项目



• 本地包校验 • 5分钟时间校验 • 接口校验（是否有更新）



• 包校验 • 解压

Hybrid架构-预加载机制

• 检测（非2G） • 下载（WiFi）



• 队列检测下载



包信息检测



网络判断



项目筛选



检测下载



• 首页触发 • 5分钟时间校验



• 项目流量 • 项目比重

前端技能

前端两种架构方案

前端架构方案一 -优缺点

易上手、开发难度低

不足：框架提供的功能支持比较少；代码编写比较随意，不利于维护和扩展 （特别是项目比较大时）

单页面开发效果不好，只能在同一个页面内包含所有页面的结构，页面数据太 多时渲染速度慢

适用于：项目前端开发人员能力中下偏多的团队，对这些框架比较熟悉的团队

前端架构方案二

前端架构方案二 -优缺点

单页面开发、MVVM、数据绑定方便快捷、代码组强清晰，方便维护 和扩展 不足：学习难度稍大、不易掌握 适用于：项目前端开发人员水平中上偏多，对NG框架比较熟悉的团队

应用场景



新项目



打样



SBU



SSBU



版本迭代快 产品

一套代码应用于多个移动平台？ hybrid、touch、微信、手Q 。。。。。。

N站合一 -理念

• 一套代码 • N个平台应用 • UED规范统一、减少开发、维护成本，提高用户体验

N站合1-服务端技术实现方案

N站合一-前端架构

N站合一 -前端框架



artTempl ate

router

seajs



BridgeJS Monitor Tracklog

Zepto …



reactjs

N站合一 -特点

•UED统一

hybrid 与 H5站点 BridgeJS通用 H5站点在app运行，可 使用app公共资源

多平台灵活部署



轻量、通用性、扩展性、 易维护

公共模块统一部署

一键Debug 与 Release

后端接口统一，中间层 统一部署，工具平台支 撑

N站合一 -项目开发流程

注意事项-性能

注意事项-增量



增量越大 下载耗时越长



l更新频率



增量大小



产品需求 修改范围



前端代码质量

Hybrid的方向 快速变现的能力 + Native的用户体验

React-Native、Weex