我们的2016重写了优步打车软件结果带来了功能丰富和精简的体验，支持优步的一系列产品，从uberPOOL到uberXL，并可扩展到未来的体验，如跳车．优步打车应用在全球各个市场都可以使用，显示50种语言和30种支付方式，而且还在不断增加。

尽管我们把这款应用设计得尽可能高效，但它的功能让它的大小超过了60mb，使用了更高的网络带宽，并要求乘客的手机具备特定的硬件性能。

虽然我们的新应用在全球范围内的使用率有所上升，但我们的数据显示，拉丁美洲、印度和中东等地区的骑手设备和网络连接往往不能满足这些要求。例如，56%的全球优步乘客使用Android手机2015级或更早。在这种硬件上，我们的新骑手应用程序可能不能提供最好的体验。我们希望为尽可能多的乘客提供服务，给他们尽可能无缝的交通体验。

为了应对这一挑战，我们开发了Uber Lite，这是一款专为老式安卓设备和网络基础设施可能无法可靠提供LTE数据连接的地区设计的骑手应用。

Uber Lite背后的动机

2017年，优步成立了一个由优步研究、设计、产品和工程团队成员组成的工作组，以更好地理解和解决在低连接地区雷竞技是骗人的使用旧安卓设备的乘客的痛点。当研究人员和雷竞技是骗人的设计师着手了解骑手的行为并设计出一个简化的UI时，工程师们评估了我们现有的骑手应用程序，看是否可以对其进行重组和精简，使其更轻便。

深入的工程分析显示，简单地精简应用程序是不够的。相反，我们提出了一个新的架构，将Android客户端通信职责委派给一个精心安排的、轻量级的后端层，专门为我们的基础设施提供网络调用服务。这种新的移动后端通信模型和信息架构还可以减少带宽使用，而不会使Android应用程序体积膨胀。

我们的工作导致了在2018年推出优步Lite还包括研究世界各地乘客的需求雷竞技是骗人的，考虑到他们可用的手机和无线网络。根据一组严格的要求，我们的工程团队做出了设计决策，最小化了应用程序所需的手机和网络资源。优步Lite应用程序反映了我们对交通需求超越地区和经济的认识。

产品设计注意事项

我们的骑手应用程序的最新版本跟上了那些使用最新手机硬件、能够访问快速数据网络或享受廉价数据套餐的骑手的需求。然而，现实世界是多样化的——数据显示，仅在印度，就有4600万优步乘客使用安卓手机，其技术相当于2013年的一款设备类2013手机)或更老。在全球范围内，40%的优步打车是通过2014年或更早的安卓手机预订的，33%是通过次3g数据网络预订的。

为了针对这些情况设计高性能应用程序，我们坚持了三个指导原则:光，即时,简单的．

光

基于我们的研究，我们决定新雷竞技是骗人的应用应该呈现出一个轻量级的外观，感觉和操作，下载和安装使用尽可能少的带宽和内存。

• 5兆以下:将骑手应用的下载大小控制在5兆(相当于不到三张自拍的内存大小)以下，设备上的大小控制在25兆以下，即使在网络状况恶化的情况下，或者在安装了2015年或更早硬件的安卓手机上，应用安装和下载速度也会非常快。
• 地图随时可用:Uber Lite只显示地图，如果需要的话，它会占用大量带宽。如果需要，乘客可以选择看到一个基本的实时地图。这款应用的体验是建立在减少地图使用量的基础上的，这使得该应用在数据网络使用上非常节约。
• 服务器驱动的客户端: Uber Lite利用服务和后端组件的薄编排层来计算、计算和呈现那些需要从Uber平台上繁重的提升和编排数据的作业。这种工程策略有助于将网络有效负载降低到小于1最大传输单元(MTU)。

即时

即使在3g以下的无线网络上，这款新应用的响应速度也应该非常快。

• 急切地请求:这款新应用程序在通过核心流时，在一个屏幕和下一个屏幕之间提供不到300毫秒的响应时间。
• 保留一个Dalvik可执行文件(DEX):Android应用程序变得多种多样敏捷的方法总数Android应用程序包(APK)超过65,536。使用智能编译技术结合高效的库和依赖设计确保了Uber Lite应用程序的单一DEX，即使拥有所有的骑手应用程序的核心功能。
• 实时通知:Uber Lite支持实时通知，向乘客发送重要提醒。

简单的

使用一个易于理解的五步流程来叫车，可以帮助乘客感觉自己在控制自己的体验，并使完成的次数比在应用程序上接收的次数比例更高，而使用一个更健壮的应用程序可能在较老的硬件或较慢的网络上表现不佳。

• 引导皮卡:Uber Lite通过使用兴趣点(POIs)来代替取货地点的地址，简化了目的地入口。在新兴地区，poi离实际地点的距离往往很短，司机很容易识别，这使它们成为取货的有用地标。
• Tappable目的地:优步Lite根据乘客的乘坐历史和频率增加了目的地列表，通过缓存这些目的地，以便在恶劣的网络条件下离线访问和快速选择。这款新应用的UI还允许用户点击建议的目的地，而不是输入目的地。
• 安全:乘客可以轻松地与家人和朋友分享他们的旅行，让Uber Lite把安全放在了中心位置。该特性类似于共享行程状态功能在完整的骑手应用中。
• 语言选择:本地化是Uber Lite设计的核心。许多语言，例如葡萄牙语、西班牙语和印地语，都可以立即为用户提供。

探索精益库

库在任何应用的数据大小中都占很大一部分，所以当我们开发Uber Lite时，我们希望非常明确我们将包含哪些库。我们仔细评估了一些uber开发的和第三方库的大小、内存和网络使用情况。由于我们独特的用例以及围绕大小和方法数量的积极目标，我们与不同的内部库所有者合作，将它们分成更小的模块，只使用我们真正需要的功能。对于已经模块化的库，我们小心地只挑选最基本的。

作为一个例子，我们使用肋骨优步的开源跨平台移动架构框架，用于我们的应用程序架构。主骑手应用程序通过rib将核心代码从非核心代码中分离出来插件框架，从而使系统的核心流(其基本功能)可以与非核心代码完全隔离。然而，这个框架增加了我们网络调用的有效负载大小。为了防止这种情况在Uber Lite中发生，我们决定不使用rib的插件框架。

此外，因为我们在Uber Lite中需要更少的屏幕转换，我们在肋骨筛垛只用本机转换。因此，我们能够删除大约200千字节的额外依赖项。

除了限制我们的库的大小，我们还减少了Uber Lite的应用大小:

• 只发送特定于应用程序位置的资源，如字符串，以防止应用程序变得太大。
• 通过Uber现有的linting结构使用矢量图像格式，以避免需要PNG资源签入。
• 从合成访问器和协变覆盖等操作生成的Uber Lite字节码中删除过多的方法。

选择架构设计

雷竞技是骗人的在研究其他公司现有的轻量级应用时，我们发现了三种设计范式:WebView，一个带有服务器渲染UI的本地应用程序架构，以及一个标准的本地应用程序架构。在探索了这些不同的选择后，我们决定采用原生应用设计。

使用本机shell虚拟机，内容和UI都是从服务器推送的，这意味着应用程序的二进制文件中没有产品代码。这种方法的优点是应用下载和磁盘大小都很小，而且可以在不增加本地代码的情况下添加功能。然而，不断向乘客的手机推送UI组件会让有效载荷变得太大，所以我们探索了以下替代方案:

• 反应本地/颤振:虽然灵活，但库的大小(6到8兆)使这种方法行不通。
• WebVew已交付优步手机网站在我们自制的、基于web的界面上使用WebView层最初似乎是一个有吸引力的选择，但当我们进行试验时，我们发现了多个问题，如不同Android版本之间的碎片化、无法集成关键功能、性能不佳以及难以使用现有的移动基础设施。

虽然我们决定使用原生应用程序的方法，但我们对非关键流程使用了基于ui的动态框架，这些流程是核心拼车体验的辅助，如支付、帮助和支持。

Uber Lite信息流

应用程序最慢的动作通常是从网络获取数据。发展中市场的低互联互通加剧了这一问题。在构建Uber Lite的信息流以适应2G连接时，我们做出了8个关键的设计决策:

• 使用服务器端事件进行后台更新。背景更新对于保持数据的新鲜度而不影响骑手的体验至关重要。通过从服务器推送后台更新，我们可以控制更新的时间和频率。
• 提前推送信息。在刚上线时就推送信息，如骑行类型和支付选项，减少了网络呼叫超时的开销，并通过使产品信息即使在离线时也可以在应用程序UI中显示，改善了骑行者的体验。
• 推送有关更改的信息。我们将有关状态变化的数据实时推送到应用程序中，这样乘客就可以随时了解司机的动作，比如司机接受了他们的行程。
• 每个屏幕只允许一个网络请求。联合网络请求可以提高网络性能，增强骑手的体验。
• 使用单个TCP连接。在2G网络中，上传速度远远低于下载速度，仅仅建立连接就会比传输数据花费更多的时间。保持数据请求和响应大小小于1MTU确保只需要建立一个TCP连接。
• 避免冗余沟通。通过网络避免重复和不必要的信息会降低网络利用率。例如，与其定期轮询信息，不如只在状态发生变化时发送信息，这有助于应用程序避免冗余通信。
• 决定后端操作。让后端决定它需要向应用发送什么，而不是要求在应用中进行不必要的计算。
• 在客户端缓存数据。Uber Lite缓存静态数据，以避免网络调用，如特定用户的产品和支付配置文件。与此同时，我们也在离线搜索方面做了努力，当用户使用wifi并充满电时，我们会智能缓存位置。

下一个步骤

优步Lite的旅程才刚刚开始，它的未来看起来充满希望。随着时间的推移，我们将继续创建新的功能，同时也会寻找方法来控制应用程序的足迹，并忠实于我们的设计原则，即轻、即时和简单。下面，我们将讨论几个我们打算在未来加入的Uber Lite，以遵守这些准则:

非频繁流的WebViews/动态UI

我们已经开始探索使用WebView或动态UI框架来处理应用中某些非频繁流的策略。我们想在WebView中尝试不同的缓存策略，以使它们在较慢的网络中更快。优化缓存应该有助于在不影响应用大小的情况下长期扩展应用。选择原生体验与优化应用程序大小之间的取舍是一种有意识的权衡，我们希望保留对原生用户最重要的流程，并提供更流畅的体验。

ProGuard, ReDex和应用程序包

我们也在探索使第三方库更精简的策略。虽然清理Uber自己的内部库很容易，但像ReactiveX和Dagger这样的开源库占了Uber Lite的很大一部分。而我们已经在使用混淆器为了优化APK，我们正在积极寻求进一步优化ProGuard和ReDex．与此同时，我们也在探索新的解决方案，如应用捆绑包，以快速发布新功能。

工具

保持应用程序的小是很困难的，一个大的提交可以摆脱我们的大小限制。为了维护我们的设计原则，我们正在积极地开发工具，以防止多索引、生成应用程序大小指标、删除未使用的依赖项，以及白名单包，以防止通过传递依赖项需要新库。我们还增强了CI管道来抛出这些错误，以便开发人员可以从每个拉请求中获得实时反馈。

对开发每天被数百万人使用的移动应用程序感兴趣吗?考虑加入我们的团队安卓或iOS开发人员!