写点什么

苏宁易购 Android 架构演进史

  • 2018-04-16
  • 本文字数:3749 字

    阅读完需:约 12 分钟

摘要

一个电商类 APP,对用户而言,是琳琅满目的商品,是层出不穷的优惠,既是社交导购,更是交易售后;而对于开发者来说,用户行为的背后,或许仅仅是一次次数据的存储、处理、传输和展示。

在苏宁易购 android 客户端不断发展的过程中,也出现了许多的问题:

  • 如何高效、安全的处理数据流向的各个环节?
  • 如何规避软件升级、硬件差异、网络环境等携带的风险?
  • 如何合理的解决产品快速迭代和开发应接不暇之间的矛盾?
  • 如果最大限度的提高开发效率,降低开发、管理和运营的成本?

有问题,就有对应的技术方案,就需要合理的架构去支撑。

本文将根据移动发展各个阶段的时代特点,结合移动电商 app 业务的特质,以移动数据交互全景的视角,讲述苏宁易购 android 客户端在不同阶段出现的问题,采取的技术应对方案,以及如何衍生出最终的 android 运行架构。

移动青铜时代(2012-2014)

时代特点:

  • 移动特征,2G~3G 网络为主,数据传输效率低,电商类 APP 用户的活跃性低;
  • 发布模式,传统的软件生命周期,需求收集、评审 → 测试案例生成、评审 → 开发设计、编码、评审 → 测试 → 发布 → 运营,单团队单线发布;
  • Android 生态,Android 2.0~3.0,行业内都处于探索阶段,技术交流少,多以系统 API 为主;开发工具 Eclipse。

APP 业务特征:

  • 业务系统,以 PC 业务为主,没有针对移动业务数据的 API,需要单独研发一个数据中转系统,以保持移动业务的正常运转;
  • 产品逻辑,展示、交互简洁,业务复杂度低,以商品的搜索、展示、购买等核心流程为主;

移动应用数据交互全景:

研发过程中的问题:

由于业务逻辑简单,页面展示、交互的复杂低,通过 Android 原生的 Activity+WebView 即可以满足绝大部分的产品需求;需求、开发、测试、发布、运营都在正常的版本周期内有条不紊的进行着;在 Android 发展初期,最主要的问题就是:

如何提高开发者的编码质量。

技术应对方案:

资深人力资源对核心技术进行封装,高内聚,低耦合;以最精简的 API 对外,降低使用复杂度,让开发人员专心于业务逻辑的研发。

应用架构生成:

采用最基本的软件设计理念,即分层 + 解耦:

  • 分层,数据流转处理采用责任链模式,保证各个环节的逻辑清晰明了;
  • 解耦,各层之间添加标准的 API 代理,确保被依赖层可以正常的维护、升级。

移动白银时代(2014-2016)

时代特点:

  • 移动特征,3G~4G 网络为主,数据传输效率高,高效便捷的购物体验,让手机购物成为了主流;
  • 发布模式,单线已经无法满足各条产品线的快速迭代,敏捷开发应运而生,多团队多线发布;
  • Android 生态,Android 4.0~5.0,移动技术交流百花齐放,插件化、热修复、APK 加固等黑科技如虎添翼;开发工具 Eclipse → Android Studio。

APP 业务特征:

  • 业务系统,以移动业务为主,提供针对移动业务特征的 API,废弃原有的转接系统,一方面提高移动数据的传输、处理速度,一方面降低单一系统异常带来的移动体验风险;
  • 产品逻辑,除了核心的商品搜索、展示、交易,评价、社交、导购、物流等都开辟出单独的产品线,以满足用户使用过程的各种需求;

移动应用数据交互全景:

研发过程中的问题:

如果说一个产品从出现到成熟,一定要经过一个“战争期”的话,我想一定是这个时期了,摘要里列出的大多数问题都爆发在这个阶段,

1 软\硬件差异方面:

  • App 在 Android_x.x 上是可以运行的,在 Android_y.y 就不行
  • App 在其他手机上都可以跑,就 XXX 手机不行

2 网络环境方面:

  • App 在 WIFI 正常显示数据,切到 3G 显示异常
  • App 在运营商 1 网络下正常显示,在运营商 2 网络下一片空白
  • XX 省请求数据超时严重,其他地区正常

3 产品运营方面:

  • XX 需求一定要跟着 App 版本走么,能不能明天就上,不然活动就过期了
  • HTML5 体验太差了,能不能让开发优化下
  • 这个页面在 App 已经做好了,让开发直接用,这个不算开发时间

4 开发测试方面:

  • 这个控件能不能抽出来公用,每次都是各自复制代码
  • 页面跳转都是写死的,抽离代码,都是报错,改动太多
  • 会员数据、手机软硬件数据能不能提供 API,现在都是另起炉灶,代码冗余太多
  • 跑一次工程太慢了,65535 是什么情况
  • 为啥商品页面的改动,还需要把会员相关的场景都测试一遍
  • 线上不能直接修改已发布 APP 的 bug,每次有问题都要重新发布,严重浪费资源

5 APP 性能方面:

  • 有用户反馈,点击 XX 页面就闪退
  • 用户又反馈,首页展示的非常慢
  • 还有用户反馈,浏览了几页就提示 APP 未响应

技术应对方案:

虽然出现了很多问题,但是这个阶段出现的技术方案,针对性并不强,都是根据生产版本出现的问题,施加的通用手段,具体如下:

  1. 完善 App 的监控机制,对 App 的奔溃、HTTP、内存、CPU 等指标数据,进行全面采集分析,确保问题的快速响应、定位、解决;
  2. 完善的用户反馈机制,让用户可以便捷的反馈,让开发者可以第一时间收到反馈并解决问题;
  3. HTTP 加速(MAA),优化请求链路,确保各项业务数据的快速响应;
  4. HTTPDNS,降低 DNS 劫持的风险;
  5. Chromium 引擎,使用 Chromium 引擎的 WebView 替代原生的 Webview,保证 HTML5 的快速渲染,提升用户的购物体验;
  6. 热修复,对已发布 APP 的问题,进行在线修复,最大程度的减少问题影响;
  7. VR/AR,增加现实、虚拟现实技术的运用,用“神奇”进一步提升促销推广的影响力。
  8. Android Studio,伴随着 Android Studio 的出现,一方面通过 gradle 提升编译速度,另一方面配合 MultiDex 同步解决 Dex 容量的问题;

而相比 app 的性能问题,产品缺陷、开发缺陷以及体验问题,才是这个阶段最主要的问题,所以在这个阶段,项目里面的所有人,每天都在看监控、看用户反馈,发现问题解决问题。

应用架构生成:

而对于客户端,也在想法设法的在架构上提高开发质量,主要手段如下:

  1. 路由、消息机制,用户模块间跳转,去除不同业务模块之间的耦合,同时也是为了业务的模块化、插件化做准备;
  2. 模块化、插件化,物理隔离不同性质的业务代码,一方面满足产品快速迭代的需求,另一方面减少蝴蝶效应,同时责任明确,促进高效开发;
  3. 服务化,通用 UI,抽离成高独立的控件,形成 UI 服务;对于通用的数据获取、处理、存储,按性质抽离成可拓展的数据处理机制,形成数据服务;

移动黄金时代(2016 至今)

时代特点:

  • 移动特征,4G 网络为主,数据传输速度 + 流量已经不在是移动 APP 的瓶颈,移动设备的物理性能大幅度提高;
  • 发布模式,敏捷开发模式运用成熟,多产品线灵活发布,可集成发布、也可独立发布;
  • Android 生态,Android 6.0~7.0,插件手段运用成熟,前端页面渲染更加高效,Weex/ReactNative、微信小程序等成为新趋势;开发工具 Android Studio。

APP 业务特征:

  • 业务系统,在传统的业务系统上,系统更加安全、高效、多样、智能,接入、升级更加灵活;
  • 产品逻辑,视频直播、虚拟现实、人工智能成为主流元素,商品销售定位更加精细。

移动应用数据交互全景:

研发过程中的问题:

不同于前面的发展阶段,这个阶段出现问题(或者说是技术需求)针对性都非常强,主要如下:

  1. 数据安全方面,APP 界面出现广告;用户信息被抓包获取;
  2. HTTP 速度方面,有些偏远地区,移动请求速度长达 3~5s,如何解决;
  3. 消息推送方面,客服的消息、活动的信息、物流的状态如何在第一时间告诉用户;
  4. 前端体验方面,前端页面滑动卡段、加载慢、交互延迟,如何优化。
  5. 产品独立方面,有些产品功能做大做强,如何快速形成独立 APP。

技术应对方案:

  1. 全站 HTTPS,加强数据安全,减少内容劫持,保障用户隐私,促进购物体验;
  2. HTTP2.0,在统一接入层(域名收敛)的基础上支持 HTTP2.0,减少 DNS 解析、请求链路复用,进一步加快移动 APP 的数据交互;
  3. 云信系统,一方面满足客服消息、活动信息、物流状态的推送,另一方面结合大数据、人工智能,实现真正的精准营销;
  4. Weex + 静态资源缓存,引入 Weex 技术,配合 Webview 的静态资源缓存技术,让前端页面体验更加原生化。

与此同时,Google 在 Android Studio 上推出 Instant Run 用来加速 gradle 的编译速度,进一步提升开发效率。

应用架构生成:

这个阶段的架构调整,针对上述问题 5 做了很多精细的工作,一方面要颗粒化业务层、服务层、ADK 层,另一方面还要调整原有的单向依赖关系,让应用工程本身容器化,满足产品线的快速集成、快速独立,实现 APP 研发的 DIY,主要调整如下:

  1. 彻底落实模块化、插件化,所有产品线开辟独立工程,业务代码完全物理隔离,以 Android Library(aar) + Plugin(apk)的方式对外提供;
  2. UI 控件、数据服务精细化,即保证所有 UI 控件、数据服务的高度独立,让使用方(业务层)自由取舍;
  3. 基础 ADK 标准化,收集集团所有 APP 的技术需求,集中优秀人力资源打造超高性能 ADK,生成开发文档并推广,促进各产业 APP 高效研发。

后记

5G 时代即将到来,有人说那是人工智能的时代,有人说那是物联网的时代,也有人说那是虚拟现实的时代,技术改变人们生活习惯的同时,也给开发者带来的各色各样的问题,时代在变,技术方案在变,支撑技术的架构也在变。

千变万化的背后,唯一不变的、也是我们锲而不舍追求的,就是:“在掌握时代特点、业务特征、软硬件限制的前提下,合理利用各种资源,设计出最高效的开发方案。”

作者介绍

李呈武,苏宁易购前端技术专家,资深 Android 开发者,深度掌握 Android 虚拟机、插件化、Weex 等技术,熟悉移动网络的特质,对移动端的架构设计有独特的见解,一直致力于通过优秀的架构设计,减少开发成本,提升开发质量。

感谢徐川对本文的审校。

2018-04-16 18:283107

评论

发布
暂无评论
发现更多内容

(mode4)千万级学生管理系统考试试卷存储方案

消失的子弹

架构 云原生

安全逆向分析实战

网络安全学海

Linux 网络安全 信息安全 WEB安全 漏洞分析

手把手带你做好项目管理|引航计划|管理

石云升

项目管理 管理 引航计划 技术专题合集

为什么赛博朋克里总少不了日本元素?

脑极体

自我提升:高效能人士的7个习惯学习笔记

程序员架构进阶

自我管理 自我提升 10月月更

设计电商秒杀系统

gawaine

架构训练营

推荐2个网站,牛x就完事了!

Jackpop

如虎添翼!6款备受欢迎的Edge浏览器插件

Jackpop

如何评估一个软件的项目费用?

石云升

项目管理 管理 引航计划 内容合集 10月月更

后端的另一种打开方式-路由还能这么玩~

Bob

微服务 后端 网络 服务 引航计划

手把手带你做好团队管理|引航计划|管理

石云升

团队管理 管理 引航计划 技术专题合集

中国法定数字货币(DCEP)全面启航!全国普及势在必行

CECBC

924清退在即,你的币转入数字货币钱包了吗?

CECBC

引航计划|AI|优质合集手把手带你玩转AI

Nydia

AI 引航计划

uni-app 在mac电脑连接安卓手机进行真机调试

达摩

uni-app app调试

架构实战营 模块九 作业

脉醉

架构实战营

原创万字总结人工智能技术栈与学习路线 下集 进阶篇

cv君

AI 引航计划

7. 简单生成器函数,Pool 实现多进程程序,异常管理,浏览器版本帮助手册

梦想橡皮擦

10月月更

JavaScript 脚本优化的 10 个技巧

devpoint

JavaScript 性能优化 10月月更

原创万字总结人工智能技术栈与学习路线 上集 基础篇

cv君

AI 引航计划

从头开始(概率)学HMM:精讲第二课-学习问题(BW算法)

herosunly

AI 引航计划 内容合集

linux之history使用技巧

入门小站

Linux

在线HTTP请求/响应头转JSON工具

入门小站

工具

浅谈人工智能的历史

Nydia

AI驱动!7款开发者必备生产力工具

Jackpop

决策树——从原理走向实战

cv君

AI 引航计划

电商秒杀系统

feitian

Vue3 + TypeScript 开发实践总结

程序员海军

大前端 Vue3 引航计划

从头开始(概率)学HMM:精讲第一课-隐马尔可夫模型定义

herosunly

AI 引航计划 内容合集

模块九作业

VE

架构实战营

数据库:B/B+树

正向成长

B+树 B树

苏宁易购Android架构演进史_Android/iOS_李呈武_InfoQ精选文章