写点什么

苏宁易购 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:282889

评论

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

企业怎么制作帮助文档

小炮

企业 帮助文档

优酷播放黑科技 | 自由视角技术的全链路策略与落地实践

阿里巴巴终端技术

客户端 音视频技术 视频技术

一张图看懂全球最新DDoS攻击趋势

科技热闻

一文简述:云端架构的演变过程

穿过生命散发芬芳

3月月更

AI工具-标注工具labelme

AIWeker

人工智能 标注工具

国产化浪潮下TiDB解决的痛点问题

TiDB 社区干货传送门

从2018到2022: 一个大数据工程师眼中的TiDB

TiDB 社区干货传送门

AI观点说-关于深度学习的一点思考

AIWeker

人工智能 深度学习

从一起Linux云主机无法远程ssh登录故障说起

天翼云开发者社区

5 款阿里常用代码检测工具,免费用!

阿里云云效

云计算 阿里云 代码审查 研发 代码检测

私有化部署是什么意思?企业私有化部署的几种类型和利弊分析

BeeWorks

将 AWS S3 数据迁移至 TiDB Cloud 集群

TiDB 社区干货传送门

AI目标检测概要

AIWeker

人工智能 目标检测

天翼云云主机上搭建FTP服务最佳实践

天翼云开发者社区

浅谈外挂常识和如何防御

行者AI

低代码实现探索(三十九)组件库的开发

零道云-混合式低代码平台

windowsXP用户无法远程桌面连接天翼云2008云主机

天翼云开发者社区

什么是需求管理,产品如何进行需求管理

阿里云云效

云计算 阿里云 需求管理 持续交付 产品研发

模块1 作业

KennyQ

数字化转型-基本认知

Geek_XOXO

数字化转型

Q1过去了,Gartner战略技术趋势在不动产领域落了几项?

大数据 技术 低代码 AIOT 分布式,

如何实现Spring Gateway 路由的动态加载和刷新?

领创集团Advance Intelligence Group

微服务 Spring Cloud API api 网关

Nebula Graph 在众安金融的图实践

NebulaGraph

图数据库 知识图谱 保险业

Flutter 路由参数处理

岛上码农

flutter ios开发 Android开发 移动端开发 3月月更

玩转天翼云安全组

天翼云开发者社区

《中国金融科技与数字普惠金融发展报告(2022)》发布 十大趋势研判未来行业发展

BeeWorks

【征文大赛】TiDB 社区专栏第一届征文大赛,快来一次性集齐所有周边吧!

TiDB 社区干货传送门

HAVE FUN|Layotto 源码解析

SOFAStack

GitHub 开发者 活动 源码解析 源码剖析

深度确定性策略梯度(DDPG)

行者AI

【技术干货分享】一文了解Nginx反向代理与conf原理

Linux服务器开发

nginx 负载均衡 反向代理 后端开发 Linux服务器开发

轻轻松松实现本地和云主机之间的文件上传下载

天翼云开发者社区

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