首页
学习
活动
专区
工具
TVP
发布

换个角度提升APP性能和质量

内容来源:2017年5月26日,饿了么移动技术部iOS工程师高亮亮在“极光开发者沙龙JIGUANG MEETU—移动应用性能优化实践”进行《新瓶旧酒——换个角度提升APP性能和质量的实践之路》演讲分享。IT 大咖说作为独家视频合作方,经主办方和讲者审阅授权发布。

阅读字数:2350 | 6分钟阅读

摘要

结合当下火热的移动性能话题和 APM 系统,围绕移动应用性能质量,谈谈如何避开传统解决方案,将其他技术领域的概念如回流重绘,节流防抖、优雅降级以及渐进增强等,通过类比借鉴,作为一个新的角度来思考质量提升问题,并灵活的运用到移动端,从而提升应用的性能,稳定性和可用性。

嘉宾演讲视频回顾及PPT链接:http://suo.im/1BzjC7

刚加入饿了么的时候做了一年左右的业务线,主要是商务平台。在更早之前做过web开发。最近刚好在开发web相关的项目,觉得很多东西各个端是共通的,APP端也能借鉴一些东西,把之前的老经验带到移动端上,来做有意思的事情。

分享大纲

第一,移动性能与质量的概述

第二,所谓的“新”技术概念的介绍

第三,几点有意思的事和一些困难

移动性能与质量的概述

饿了么的用户端不会出现高峰期的现象,订餐时间都选在中午之前的一到两个小时,量级非常大。我们内部有其他很多业务线,针对与配送人员和商户的客户端,还有供应链,以及内部的沟通工具。我们内部会简单地做分析优良中差评做分级。

最早是以崩溃来算,但后来崩溃在后期并不是特别看重。崩溃率高包括ANR多这一类肯定是差,只能轮为可用的阶段。而好用的阶段除了UPM做指导性的工作,还要做非常深化的业务,我们一个框架部对外一直在输出各种SDK,供内部使用。

根据设备类型,除了在跑移动端,还有PC以及外围。PC基本上没有跑流量、耗电量的问题。结合主要的业务场景,我们面临的问题是用户端停留在用户手上的时间很短暂,而商户端和配送端一直开着APP。对配送人员来讲优先考虑的是耗电问题,耗电问题在移动端的体现有两点,网络和定位。GPS定位非常耗电,不停定位还要提升精度,是对物流端APP最大的挑战。其次对商户端考虑的是网络的优化和性能,本身网络环境是相对比较好的,我们主要提升它的APP到达和业务方面。

所谓的“新”技术概念介绍

我们经常遇到的回流和重绘问题。这个问题很经典,从最初的页面加载到最后绘制在屏幕上。

回流是在流失布局下,参照元素的布局坐标一旦发生了改变,那所有依赖它的元素都要重排,重新计算布局位置的过程,尤其消耗UPC。

重绘是不发生重排的情况下重新布局,现在的GPU都那么强大,性能并不是瓶颈。

下面是我们处理商品订单的问题,订单当时是检测到有很多用户的投诉,订单改版之后性能特别差。性能主要是卡在CPU上,CPU在计算的时候是非常慢的。

最终我们优化的结果非常好。虽然它也要做布局计算,但在快速滚动的时候帧率是达到非常满意的情况,基本上接近于60帧。

前端在滚动页面的时候需要做一些效果,在滚动时监听。在很高的频率下不停地设计元素的位置,会导致滚动时的卡顿问题。而前端用的解决方法就是节流。

我们的做法还应用于正在开发的APM台。我们有一个数据收集的问题,数据收集的数额大,频次也快,用户的轨迹分析的数据很多。我们在服务器传送数据的时候如果失败的话,基本上为了保证数据传输过去,对于非实质性数据一定要把它传过去,就存在了自动重试的问题。我把它定位为“黄金”重试节流策略。

接下来渐进增强和优雅降级。Graceful Degradation是对于出现某种情况不停地做减法。对于外围来讲,浏览器的碎片化特别重复,安卓端也有这种问题。如果它的功能不可用,就把这个功能减掉。还有渐进式增强,依赖浏览器IE6,设计一套基本的功能能在上面用,不停地做架构,直到它表现的非常好。利用更优组件,三方作为备选。操作效率会出现问题,操作效率和速度是随着失效部件的增加逐渐下降的。我的设计就是这样的框架,很简单的,先建长连,可控可靠,存在异常就降级。

最后讲法则。零崩溃零错误等于好用;启动时间Main后比Main前重要;二进制大于资源,耗件优化,硬件大于软件。

有意思的事和一些困难

关于耗电问题。手机设备在通讯的时候处于休眠期,当你有需求的时候会自动开启活跃期,活跃期和停歇期切换频繁的话,电量就掉的非常快。我们的弱网判断是针对与它的响应时间,我们自己做的网络框架可以知道所有的DSR包括数据时间。

我们拿来之后发现超时间,网络响应时间太长。这种情况下会做节流层,要么不传数据,要么降低发送频率。合理的缓存和批量的传输。大家有时候也会要求实质性非常高的数据往后端发,用户点击一搜就把数据转换成事件,可这样的情况下瞬间发送服务器还是会崩溃。我们做一个简单的调整,就是做忍受值。我们认为数据从生成劳动发送到传输,传输的时候查过最慢的DNS解析是80秒,是非常非常差的网络插件。我们认为有忍受值,目前设定的单位是60秒钟,60秒钟的数据都认为它是有实时属性、架构的才往后端传。一旦出超过60秒,就从传输队列去掉。对我们传输的间隔也会调整,除了一系列网络的节流优化,加上这套实施策略,极大地提升了网络的效率和节点问题。

最终我们还会发现通过APM平台会发现主机解析率特别高的,能达到86%。存在这样的失败率的网络软件,而且还是每台不停地发,能看到它发送的频率。我们是天网系统,是会开源的,服务器端的代码也会开源的,只是服务不会去做。

今天基本上就讲这么多,谢谢大家!

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180315A1MF1900?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券