前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Facebook:如何让应用适合所有系统、带宽以及屏幕

Facebook:如何让应用适合所有系统、带宽以及屏幕

作者头像
CSDN技术头条
发布2018-02-08 16:23:57
1K0
发布2018-02-08 16:23:57
举报
文章被收录于专栏:CSDN技术头条

如果你的移动应用程序只能在某个地区(比如US)运行良好,那么该如何改善?在@scale conference上,Facebook多次谈及了这个问题。那么如何才能设计出一个更适合用户需求的应用,这里我们看向Facebook项目经理Chris Marra的Developing Android Apps for Emerging Market(视频链接,YouTube需访问外国网站)演讲视频综述。

视频请点击上方视频链接

在移动网络上,Chris表示,因为地区差异,用户在网络连通性上存在着巨大的差异。USA的3G覆盖率是70%,平均延时为280毫秒。而在印度,3G覆盖率是6.9%,延时达500毫秒。在巴西,3G覆盖率是38.6%,延时则超过850毫秒。

同时,Facebook还在用户使用的设备上做过综合调研:不是所有用户的设备都很快,不是所有设备的屏幕都很大,同样不是所有人都在一个很快的网络下。结果显示,大部分用户使用的设备都是2011年左右生产,双核心及拥有1GB以上的内存。开始时,Facebook应用只针对高端用户设计,因此那些低端设备拥有者的使用体验非常差。

为了满足这些用户的体验需求,Facebook专门建立了独立的应用——使用针对低端设备的轻量级动画等策略。而针对那些小屏幕手机的拥有者,Facebook更设计了匹配不同屏幕大小的应用程序。

当下,Facebook已经衍变为以产品为中心的架构:垂直团队负责对应的产品,而不是统一而论,比如,一个Android团队负责所有Andriod产品。当然,同样存在一个垂直团队,他们致力提升整个Android平台上的产品体验,深入研究这个平台的技术细节。

每个团队都负责终端到终端的性能,及所负责产品的可靠性。这里同样存在一个核心团队,负责关注、分析和帮助解决性能问题。

不管是核心团队还是产品团队都是必不可少的。核心团队善于检测和识别问题,并与产品团队一切合作来解决这些问题。对于移动开发来说,端到端的控制整个产品至关重要,包括核心参与指标(core engagement metrics)、核心可靠性(core reliability)及核心性能指标(core performance metrics),而核心性能指标又包括日常使用情况、冷启动时间及可靠性。

在如何解决网络性能瓶颈上,Facebook Engineering Manager发表了题为Tuning Facebook for Constrained Networks(视频链接,YouTube需访问外国网站)的讲话。Andrew表示,解决这个问题主要从以下3个方面着手:Image Download Sizes,Network Quality Detection,Prefetching Content。

视频请点击上方视频链接

总体来说,在Facebook规模,面面俱到并不是一件容易的事情。用户设备不只是覆盖Andriod和iOS两个领域,工程师必须针对各种手机进行对应的设计。

减少图片大小——JPEG降低30%,PNG降低80%

大部分从Facebook应用程序下载的数据都是图像:占Android设备下载总数据的85%,占Facebook Messenger下载总数据的65%。因此,缩减图像的体积可以减少客户端的下载量,从而减少下载时间,特别有益于高延时网络。

为显示层返回一个适当大小的图片

  1. 在服务器上压缩大小。杜绝给客户端发送大的图片,然后让客户端去压缩。这将浪费大量的带宽,并且占用更多时间。

2. 发送一个缩略图(用于描述图片)以及一个预览图片(比如newsfeed),在用户要求访问后再发送完全体积的图片。同时在大部分情况下,用户的需求也只是一个缩略图或者一个小图片。

3. 随着屏幕的变大,图片缩放并不如以往那么效率,但是仍然可为,区别只是回报不同而已。

改变图片的格式

  • 90%发送到安卓的Facebook和Messenger图片都会被转换成WebP格式。
  • WebP格式2010年由谷歌发布。
  • 同等质量下WebP节省JPEG格式7%的下载体积。
  • 质量和参数调优后,在无明显差异下节省JPEG格式30%的下载体积。
  • WebP同样支持透明度和动画,这个特性被用于Stickers产品。
  • 在相对旧的安卓设备上,图片会通过WebP传输,而在客户端上会被转码成JPEG用于渲染。

网络质量检测——特定网络相对的调整

1.同等网络制式下(2G、3G、LTE、WiFi等),US的网络速度会是印度和巴西的两到三倍。

2. LTE通常情况下会快于WIFI,因此你不能只基于传输技术的速度做调整。

3. 为客户端添加以下功能

测量所有大型传输的吞吐量

Facebook服务器在每个响应的HTTP header中提供了一个Round Trip Time(RTT)估算。

客户端会测量传输的平均吞吐量和RTT时间,从而确定对应网络的质量。

4. 连接质量被分为以下几组:150kbps以下的“Poor”、150-600kbps的“Moderate”、600-2000kbps的“Good”以及大于2000kbps的“Excellent”。

5. 功能开发人员可以根据网络的质量来调整行为。

6. 基于质量问题存在的一些调整:

  • 增加/减少压缩。
  • 调整并行网络请求数量,不会占用全部带宽。
  • 禁用/允许自动播放视频,不要在慢的网络下造成更多的数据传输。
  • 预取更多的内容。

7. Facebook开发了Air Traffic Control工具以支持不同流量的配置文件模拟,每个配置文件可设置的参数包括bandwidth、packet loss、packet loss-correlation、delay、delay correlation、delay jitter。

预取内容

  • 在内容被真正需要之前建立请求并传输。
  • 在高延时下,预取内容非常重要,因为用户在漫长的等待中能得到的只是一个空白屏幕。
  • 在应用程序启动的过程中为feeds建立请求,因此在feed展示时所有数据都会就绪,数据下载的过程可以与其他初始化任务并行发生。
  • 为网路请求保存一个优先级队列,不要因为后台网络请求阻塞前台的网络请求,或者因为用户看不到的数据而影响用户当前感兴趣的数据。
  • 监视过度获取以及设备资源的过度消耗。过度获取可能耗尽磁盘空间,或者耗费大量的用户流量。

前台参数

  • 客户端上传到服务器。这里的思想是尽量上传更少的数据到服务器,这就意味着在发送到服务器之前调整图片的大小。如果上传重试失败的很快,通常是因为网络问题。
  • Facebook App大概有20个不同的APK(Andriod应用程序包),主要基于API等级、屏幕大小和处理器架构。

原文链接:How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks (编译/仲浩 审校/魏伟)

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2014-09-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 CSDN技术头条 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档