摘要

移动青铜时代（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时代即将到来，有人说那是人工智能的时代，有人说那是物联网的时代，也有人说那是虚拟现实的时代，技术改变人们生活习惯的同时，也给开发者带来的各色各样的问题，时代在变，技术方案在变，支撑技术的架构也在变。