苏宁易购Android架构演进史

摘要

\\

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

\\

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

\\

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

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

\\

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

\\

移动青铜时代（2012-2014）

\\

时代特点：

\\

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

APP业务特征：

\\

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

移动应用数据交互全景：

\\

\\

研发过程中的问题：

\\

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

\\

\

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

\

\\

技术应对方案：

\\

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

\\

应用架构生成：

\\

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

\\

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

\\

移动白银时代（2014-2016）

\\

时代特点：

\\

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

APP业务特征：

\\

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

移动应用数据交互全景：

\\

\\

研发过程中的问题：

\\

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

\\

1 软\\硬件差异方面：

\\

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

2 网络环境方面：

\\

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

3 产品运营方面：

\\

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

4 开发测试方面：

\\

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

5 APP性能方面：

\\

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

技术应对方案：

\\

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

\\

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

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

\\

应用架构生成：

\\

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

\\

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

\\

移动黄金时代（2016至今）

\\

时代特点：

\\

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

APP业务特征：

\\

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

移动应用数据交互全景：

\\

\\

研发过程中的问题：

\\

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

\\

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

技术应对方案：

\\

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

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

\\

应用架构生成：

\\

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

\\

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

\\

后记

\\

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

\\

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

\\

作者介绍

\\

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

\\

感谢徐川对本文的审校。