百度外卖移动组件架构与优化

百度外卖移动组件架构与优化

写在前面:

  本文内容是饿了么技术沙龙20期:移动技术专场《百度外卖移动组件架构与优化》张朝@百度外卖Android高级开发工程师演讲分享,本文Github连接
封面css

分享内容

1、跨平台动态组件方案
2、外卖移动组件架构设计
3、组件业务流程生态
4、组件性能优化实践
5、将来规划

1、跨平台动态组件方案

1.1 三类动态组件方案

Native原⽣生组件:html

一、性能、体验很是好
二、开发成本高
三、没法跨平台,传播性差
四、可能的审核风险

Hybrid组件:前端

一、彻底跨平台,易于传播
二、迭代效率很是高
三、性能、体验较差
四、端能力依赖发版

JS驱动原生:git

一、性能、体验很是好
二、迭代效率较高
三、学习与开发成本较高
四、稳定性较差

移动组件@百度外卖

2、外卖移动组件架构设计

2.1 早期业务背景与架构

一、主业务与垂类业务同时快速迭代  
二、缺乏平台化与模块化的支撑
三、H5垂类业务井喷式发展(各种H5对端能力需求不一样,发散不收敛,通讯方式不统一,协议混乱)
四、模块耦合严重,新业务没法快速上线

架构变迁—外卖平台化

移动组件—Hybrid框架

2.2 移动组件—通讯枢纽

JS -> Nativegithub

一、API层最终经过kernel发起通讯
二、WMApp.kernel.invoke(action, params, callback)
三、invoke内建立iframe向Native发送消息
四、Android可采用addJSInterface,iOS原生支持,不通用

Native -> JS算法

一、Native执行WMAppBridge函数,listener需提早注册
二、WMAppBridge.notify(callback,data)
三、WMAppBridge.notifyListener(name, data)

2.3 传统页面加载流程

2.4 移动组件—离线化机制

一、离线包内置Config配置离线页面属性:本地文件相对路径、预加载开关等
二、基于MD5 Check的离线包更新与安装
三、invoke内建立iframe向Native发送消息
四、file://跨域问题,需Bridge提供网络请求能力
五、是否支持多版本管、是否内置默认包,由业务特征决定
六、页面启动由外卖OpenUrl支持,保证灵活性与一致性

2.5 移动组件—本地目录

3、组件业务流程生态

3.1 业务接入与迭代流程

3.2 重要平台搭建

组件发布管理平台、组件性能监控平台、组件异常监控平台
组件发布管理平台
组件性能监控平台
组件异常监控平台小程序

4、组件性能—网络优化

4.1 网络请求预加载

请求预加载
Total Time:T1 + T2 + T3 + T4,串行化
网络请求T3与WebView加载流程较独立,可经过Native前置发起实现并化 跨域

请求预加载
Total Time:Max ( T1 + T2, T3 ) + T4,并行化,时长缩减约300ms - 800ms浏览器

4.2 预加载配置

一、预约义的请求配置规则,对组件Config扩充request节点(网络请求基本配置:url、method、contentType、data、header等)
二、Native完成动态参数的替换,生成网络请求并发出(经常使用的动态参数:lat、lng、os、addressId等)
三、业务组件可动态开启/关闭预加载,灵活降级

4.3 网络链接优化

一、组件⽹网络请求由Native发起,更高效率且可掌控
二、基于OkHttp,默认具有Gzip、ConnectionPool等优点
三、基于百度DNS服务的WMHttpDNS,防劫持,更高的稳定性与性能
四、Native级别更细粒度的接口性能与异常监控(APM)
五、低成本的https/http2.0切换

5、组件性能—容器预热

5.1 组件容器预热

组件容器预热

一、Total Time:Max ( T1 + T2, T3 ) + T4,大部分状况下,T1 + T2 > T3 
二、离线化机制已经使T2尽量下降,T1成瓶颈(Android尤其明显)
三、Android初次建立WebView,开销很大(时长高达500ms - 1000ms)
四、非初次建立,开销会下降(时长约100ms - 500ms)
五、ApplicationContext进行容器预建立,启动后context替换成Activity

组件容器预热

不建议作WebView容器复用,需作DOM清理,避免JS Context污染安全

6、组件其余优化

6.1 组件I/O优化

一、频繁I/O性能开销较大,下降稳定性
二、JSBridge-Cache,下降注入开销
三、PageConfig-Map,下降I/O次数,快速定位文件位置

6.2 安全性

安全性问题,域名过滤+沙盒目录校验。控制敏感信息读取权限,避免第三方页面隐私泄露, 控制File、Content读取权限,避免File域攻击(跨域高危漏洞)

7、将来规划

7.1 离线包体积与实时性

一、采用7zip压缩技术,更高的压缩率
二、对用户流量与成本作更深评估,引入Diff增量包支持
三、在主动拉取包更新的基础上,引入Push实时推包机制

离线包体积与实时性

7.2 性能与安全性

一、更细粒度的页面性能监控
二、更深刻的网络优化(性能与成功率)
三、更全面的安全性控制(离线包签名与认证,避免恶意篡改)

## 最后

  不知不觉,本身已在前端两年摸爬滚打两年了,讲前端成长,我认为主要在两个方面,一部分是能力,一部分是知识。我我的的观点,能力占百分之八十,知识占百分之二十。联想起鲁迅先生的《朝花夕拾》,因而乎我从今年6月底开始用docsify搭建了几个文档网站在个人github里开始编写《前端笔记系列》(注:有参考[nieyafei],我把它们分为四类:[【Html/Css/Sass/Less/浏览器/网络】]()、【JavaScript/数据结构/算法】、【Vue/React/Angular/Node】、【微信/小程序】。它们记录分享我眼中的前端相关零碎知识、原理、源码、技巧、面包、前端会议沙龙笔记...目前只编写了【Html/Css/Sass/Less/浏览器/网络】,后面的三节会陆陆续续持续更新...
  本文记录在【Html/Css/Sass/Less/浏览器/网络】行业会议 里,若是有帮助到你,赏个★star。

相关文章
相关标签/搜索