百度外卖移动组件架构与优化
百度外卖移动组件架构与优化
写在前面：
本文内容是饿了么技术沙龙20期：移动技术专场《百度外卖移动组件架构与优化》张朝@百度外卖Android高级开发工程师演讲分享，本文Github链接
分享内容
一、跨平台动态组件方案 二、外卖移动组件架构设计 三、组件业务流程生态 四、组件性能优化实践 五、未来规划
一、跨平台动态组件方案
1.1 三类动态组件方案
Native原⽣生组件：
1、性能、体验非常好 2、开发成本高 3、无法跨平台，传播性差 4、可能的审核风险
Hybrid组件：
1、完全跨平台，易于传播 2、迭代效率非常高 3、性能、体验较差 4、端能力依赖发版
JS驱动原生：
1、性能、体验非常好 2、迭代效率较高 3、学习与开发成本较高 4、稳定性较差
二、外卖移动组件架构设计
2.1 早期业务背景与架构
1、主业务与垂类业务同时快速迭代 2、缺少平台化与模块化的支撑 3、H5垂类业务井喷式发展（各类H5对端能力需求不同，发散不收敛，通信方式不统一，协议混乱） 4、模块耦合严重，新业务无法快速上线
2.2 移动组件—通信枢纽
JS -> Native
1、API层最终通过kernel发起通信 2、WMApp.kernel.invoke(action, params, callback) 3、invoke内创建iframe向Native发送消息 4、Android可采用addJSInterface，iOS原生支持，不通用
Native -> JS
1、Native执行WMAppBridge函数，listener需提前注册 2、WMAppBridge.notify(callback,data) 3、WMAppBridge.notifyListener(name, data)
2.3 传统页面加载流程
2.4 移动组件—离线化机制
1、离线包内置Config配置离线页面属性：本地文件相对路径、预加载开关等 2、基于MD5 Check的离线包更新与安装 3、invoke内创建iframe向Native发送消息 4、file://跨域问题，需Bridge提供网络请求能力 5、是否支持多版本管、是否内置默认包，由业务特征决定 6、页面启动由外卖OpenUrl支持，保证灵活性与一致性
2.5 移动组件—本地目录
三、组件业务流程生态
3.1 业务接入与迭代流程
3.2 重要平台搭建
组件发布管理平台、组件性能监控平台、组件异常监控平台
四、组件性能—网络优化
4.1 网络请求预加载
Total Time：T1 + T2 + T3 + T4，串行化
网络请求T3与WebView加载流程较独立，可通过Native前置发起实现并化
Total Time：Max ( T1 + T2, T3 ) + T4，并行化，时长缩减约300ms - 800ms
4.2 预加载配置
1、预定义的请求配置规则，对组件Config扩充request节点（网络请求基本配置：url、method、contentType、data、header等） 2、Native完成动态参数的替换，生成网络请求并发出（常用的动态参数：lat、lng、os、addressId等） 3、业务组件可动态开启/关闭预加载，灵活降级
4.3 网络连接优化
1、组件⽹网络请求由Native发起，更高效率且可掌控 2、基于OkHttp，默认具备Gzip、ConnectionPool等优势 3、基于百度DNS服务的WMHttpDNS，防劫持，更高的稳定性与性能 4、Native级别更细粒度的接口性能与异常监控（APM） 5、低成本的https/http2.0切换
五、组件性能—容器预热
5.1 组件容器预热
1、Total Time：Max ( T1 + T2, T3 ) + T4，大部分情况下，T1 + T2 > T3 2、离线化机制已经使T2尽可能降低，T1成瓶颈（Android尤为明显） 3、Android初次创建WebView，开销很大（时长高达500ms - 1000ms） 4、非初次创建，开销会降低（时长约100ms - 500ms） 5、ApplicationContext进行容器预创建，启动后context替换成Activity
不建议做WebView容器复用，需做DOM清理，避免JS Context污染
六、组件其他优化
6.1 组件I/O优化
1、频繁I/O性能开销较大，降低稳定性 2、JSBridge-Cache，降低注入开销 3、PageConfig-Map，降低I/O次数，快速定位文件位置
6.2 安全性
安全性问题，域名过滤+沙盒目录校验。控制敏感信息读取权限，避免第三方页面隐私泄露， 控制File、Content读取权限，避免File域攻击（跨域高危漏洞）
七、未来规划
7.1 离线包体积与实时性
1、采用7zip压缩技术，更高的压缩率 2、对用户流量与成本做更深评估，引入Diff增量包支持 3、在主动拉取包更新的基础上，引入Push实时推包机制
7.2 性能与安全性
1、更细粒度的页面性能监控 2、更深入的网络优化（性能与成功率） 3、更全面的安全性控制（离线包签名与认证，避免恶意篡改）
## 最后
不知不觉，自己已在前端两年摸爬滚打两年了，讲前端成长，我认为主要在两个方面，一部分是能力，一部分是知识。我个人的观点，能力占百分之八十，知识占百分之二十。联想起鲁迅先生的《朝花夕拾》，于是乎我从今年6月底开始用docsify搭建了几个文档网站在我的github里开始编写《前端笔记系列》(注：有参考[nieyafei]，我把它们分为四类：[【Html/Css/Sass/Less/浏览器/网络】]()、【JavaScript/数据结构/算法】、【Vue/React/Angular/Node】、【微信/小程序】。它们记录分享我眼中的前端相关零碎知识、原理、源码、技巧、面包、前端会议沙龙笔记...目前只编写了【Html/Css/Sass/Less/浏览器/网络】，后面的三节会陆陆续续持续更新...
本文记录在【Html/Css/Sass/Less/浏览器/网络】行业会议 里，如果有帮助到你，赏个★star。
