App工程架构

App工程架构方面，原先的App开发还是单工程单构建的方式，各产品间的代码耦合严重，于是进行了App工程的解耦（图3和图4）。

图3 / 图4

解耦后各产品间代码完全独立，相互页面和功能的跳转走数据总线或者URL总线方式来实现，打包时的资源问题可以通过Run Script（iOS）和Gradle（Android）来定制化解决。

在App工程架构解耦后，紧接着是两个问题：

· 开发框架是否满足产品开发需求？

· 性能和质量是否达到用户体验要求？

为了解决第一个问题，我们梳理了现有的App功能，将通讯、定位、Hybrid框架、数据库、登录、分享、基础库等核心功能实现了SDK化，也提供给公司其他App直接使用；同时将App内部的公共业务组件例如地图、日历、城市、图片、通讯录等实现了统一。

要解决第二个问题『App性能和质量』，首先需要了解App性能的现状，即App端性能的采集。常规做法有两种：1．使用第三方性能采集SDK，例如OneAPM、听云等第三方工具；2．自建。携程为了完整掌握用户数据采用了自建的方式：App通过日志SDK采集日志，上传至日志服务端，日志消息经Kafka消息队列存入HDFS（RCFile格式）分布式文件存储系统，后期的数据查询均基于Hive系统来实现。

App端的性能数据会在多种纬度（操作系统、App版本、网络状况、位置）下采集网络（网络服务成功率、平均耗时、耗时分布等）、定位（经纬度成功率、城市定位成功率等）、启动时间、内存流量等各类指标。其中像网络服务性能是对于用户体验至关重要的端到端性能，也是优化的核心依据。

性能数据采集后需要采用简单直观的Portal进行展示，携程为无线业务开发了Web端和App端性能展示Portal，图5是网络性能的截屏，数据会每小时进行更新聚合并展示。

图5

基于完备的性能采集数据，很多App性能便可以依据数据进行迭代优化，例如App网络服务方面，携程App采用了以下多种优化手段：

· 使用TCP长连接实现网络服务，减少网络连接时间

· 根据网络状况2G/3G/4G/WIFI进行调优参数

· 根据连接/读/写不同阶段使用重试机制

· 使用IP列表避免DNS解析失败或者劫持，无需进行DNS解析

· 根据网络延迟选择服务端IP（使用Ping）

· 使用ProtocolBuffer+Gzip减少Payload

经过这些优化手段，携程App的端到端网络服务成功率从最初很差的95.32%提升至99.87%，用户体验得到明显提升。

携程App的Hybrid框架也是经过多个版本的迭代，已经支持强大的插件功能，已经做到凡是可以用Native的组件通通使用Native组件来优化Hybrid业务的体验。携程Hybrid框架在设计之初即采用了离线包功能：Hybrid业务整体打包在App中，节省了用户打开页面时的资源加载时间；同时离线包支持查分增量更新，并通过7z压缩方式进一步降低了增量更新包的大小，相对zip压缩减少30%大小。