面向低配手机与慢速网络的手机应用：让真实顾客也用得舒适

手机应用往往是在最新的手机和办公室的高速网络上设计与测试的。而你的顾客可能使用已有几年历史的手机，内存有限、存储空间几乎已满，信号在路上、市场里或远离基站的地区时强时弱。对开发团队来说很顺畅的体验，对真实用户来说可能令人沮丧。

在印度尼西亚这样的市场，设备的多样性和网络质量的差异非常大。打开缓慢、耗费流量或耗尽电量的应用很快就会被删除。许多用户删除应用并不是因为不需要，而是因为他们的存储空间只够放几个最有用的应用。

本文介绍如何设计和维护在普通设备与慢速网络上仍然舒适的手机应用：应用体积、启动速度、流量使用、电量、无网络工作以及如何测试。没有捏造的数字；重点是可以从一开始就应用的原则和工作习惯。

摘要

• 针对顾客中最常见的设备和网络来设计和测试，而不是最好的设备和网络
• 应用体积、启动时间和流量使用是用户体验的一部分
• 在网络缓慢或中断时，让应用仍然有用
• 通过推迟不紧急的工作来节省电量和内存
• 在真实设备上衡量性能，并在发布后持续监控

了解顾客的设备和网络

从数据而不是假设开始。查看你的应用或网站用户统计，了解最常用的品牌、操作系统版本、屏幕尺寸和网络类型。这些数据常常令人惊讶：被认为陈旧的设备，原来被大多数顾客使用。

根据这些数据设定一台参考设备：一部配置普通、代表典型用户的手机。这台设备成为基准。如果应用在参考设备上很舒适，在更好的设备上几乎肯定也舒适。反过来则不然。

也要考虑使用场景。在外勤、车辆上或信号弱的地区的用户，与在家使用固定网络的用户有不同的需求。了解你的应用实际是在何时何地被使用的。

应用体积：存储空间是稀缺资源

许多用户的存储空间几乎已满。体积大的应用更难安装，在需要空间时也更快被删除。体积还影响下载和更新的流量成本，这对一些用户来说相当明显。

可以通过几种方式减小体积：压缩并调整图片尺寸、移除未使用的资源和库、避免捆绑过多字体或素材，并使用模块化分发功能，根据设备需要提供应用的各个部分。每增加一个库，都应该质疑它的好处。

如果你的需求很简单，可以考虑轻量版本或渐进式网页应用。对于目录或下单这类功能，快速的网页体验往往更适合不愿再安装一个应用的用户。

启动速度与响应

从点击图标到用户可以操作的时间，在很大程度上决定了第一印象。在普通设备上，繁重的启动工作，例如加载大量数据、初始化许多库或显示很长的启动画面，会让人感觉慢得多。

先显示最重要的内容，推迟其余部分。在后台加载更新的同时，显示骨架屏或最后保存的数据，使用户不至于盯着空白屏幕。第一个屏幕不需要的服务，只在需要时才初始化。

也要留意对触摸的响应。卡顿的长列表、沉重的动画和不提供反馈的按钮，会让应用感觉出了故障。使用逐步加载的列表，在吃力的设备上减少动画，并提示某个操作正在处理中。

节省流量并在慢速网络上保持稳健

对许多用户来说，流量并非无限。只发送所需的数据，每页请求合理的数量，压缩响应，并缓存很少变化的数据，避免每次都重新下载。下载的图片应与设备屏幕的尺寸相匹配。

慢速且时断时续的网络要求稳健性。为请求设置合理的超时，以逐渐增大的间隔重试，不要让用户在没有任何消息的情况下干等。显示诚实的状态，例如网络较慢并提供重试，而不是无止境的转圈。

考虑用户可以开启的省流量选项：较低质量的图片、关闭自动播放，或大文件仅通过 Wi-Fi 同步。这些小选项会受到严格控制流量的用户的欣赏。

在没有网络时仍然有用

许多应用不需要在网络丢失时完全瘫痪。已经浏览过的目录、订单历史或正在填写的表单，可以继续从本地存储中获得。仍然能阅读和准备操作的用户，比迎面看到错误消息的用户要有耐心得多。

对于写入数据的操作，例如发送订单或报告，可以考虑本地队列，在网络恢复时自动发送。清楚地显示哪些已发送、哪些仍在等待，使用户不会重复操作或产生怀疑。

离线工作的概念本身会带来挑战：数据在两个地方被修改时的冲突，以及安全同步的需要。从一开始就设计规则，并选择真正受益于离线工作的功能，而不是一次全部都做。

电量与内存

快速耗尽电量的应用会被怀疑并被删除。常见原因包括持续的位置更新、过于频繁的后台工作、永不停止的动画，以及没有必要的重复网络请求。只在需要时请求位置，并且只用所需的精度。

在内存很小的设备上，系统可能随时关闭后台应用。定期保存用户的状态，使应用再次打开时回到原来的位置，而不是从头开始。释放不再可见的图片等大型资源。

如有可能，把繁重的工作，例如大规模同步或文件上传，安排在设备正在充电并连接 Wi-Fi 时进行。用户不会察觉，但他们的电量和流量得到了节省。

对普通设备友好的界面

小屏幕和低分辨率要求简单的布局。避免过于拥挤的元素、过小的文字和难以点按的触控目标。按钮和链接应大到足够拇指点击，并有适当的间距以避免误触。

在受限的设备上减少昂贵的视觉效果，例如多层阴影、叠加的透明度和沉重的动画。对比清晰的简洁界面不仅更轻，在阳光下以及对视力不同的用户来说也更容易阅读。

也要考虑用户的语言和数字素养。使用简单的词语、简短的流程和清晰的指引。对最缺乏经验的用户来说很容易的应用，几乎总是对每个人都容易。

在真实条件下测试

在开发者电脑上的模拟器上测试是不够的。准备几台能代表顾客的真实设备，从普通到中档，并在这些设备上测试重要的流程：打开应用、搜索、下单和付款。

模拟糟糕的网络。许多开发工具可以限制速度并增加延迟或丢包。也试试真正微弱的信号、进出隧道或电梯，以及在流程中途开启飞行模式。最大的意外往往出现在看似微不足道的情况下。

发布之后，监控来自真实设备的性能数据：启动时间、故障和突然关闭，按设备类型和版本细分。这些数据揭示在你的测试设备上从未出现过的问题，并成为确定修复优先级的依据。

不给用户添负担的更新

频繁且体积大的更新会消耗流量，使用户推迟更新。以合理的大小发布变更，并在可用时使用只下载变更部分的更新机制。在发布说明中用用户能理解的语言解释变化了什么。

只要仍有许多顾客在使用，就支持几个较旧的操作系统版本，并在终止支持之前提前很久通知。突然停止支持意味着失去无法或不愿更换手机的顾客。

准备处理仍在流通的旧版本的机制，例如不强制、除非有安全原因的更新提示。服务器应在合理的过渡期内继续为旧版本提供服务。

性能预算：让应用长期保持轻量

应用很少是因为某个重大决定而变慢；它是一点一点地变慢，每当有一个看似无害的新功能、库或图片加入时。为了对抗这一点，设定性能预算：对应用体积、参考设备上的启动时间以及主流程的流量使用商定限值。

每次发布都检查预算。如果某项变更超出限值，团队必须决定：优化它、替换其他东西，或在有明确理由的情况下有意识地提高限值。这个习惯让性能从偶尔修复的事情变成持续守护的事情。

让整个团队参与，而不只是开发人员。选择动画的设计师、要求加入追踪库的营销人员以及增加功能的产品经理，都会影响应用的分量。共同理解的预算让取舍得以公开讨论。

多样的用户与共用设备

在许多家庭和小企业里，一部手机由几个人轮流使用，或者用户相当频繁地更换号码和设备。设计不依赖于单一设备或单一号码的登录和账户恢复，并提供安全退出的方式。

也要关注无障碍需求：可放大的文字尺寸、足够的颜色对比度，以及屏幕阅读器可读取的标签。这些做法帮助视力受限的用户，也帮助在阳光下或屏幕碎裂时使用手机的每个人。

考虑在可能丢失或被借用的设备上的安全。避免在设备上公开存储敏感数据，并为付款等高价值操作提供锁定或额外验证。

诚实地权衡取舍

为普通设备设计，有时意味着不使用有吸引力的效果或功能。这不是倒退，而是经过深思熟虑的选择。对每个功能都要问：有多少顾客受益，又有多少顾客因额外的分量而受损？

往往有折中的办法：更丰富的功能只在有能力的设备上开启，而普通设备得到功能核心相同的较轻版本。这种分层方式让所有顾客都得到服务，而不牺牲设备更好的用户的体验。

直接倾听用户的声音

技术数据告诉你发生了什么，但不一定告诉你为什么。提供一个方便的途径，让用户在应用内报告问题，并在其同意下自动附带设备和版本信息。带有上下文的报告要容易解决得多。

认真阅读应用商店的评价。诸如卡顿、耗流量或发烫这样的抱怨，往往是关于真实设备上体验最诚实的线索。礼貌地回应，并在他们报告的问题被修复时告知用户。

轻量应用对业务的影响

轻量的应用不只是技术上的自豪；它直接影响业务结果。打开快、不耗流量的应用被使用得更频繁、被删除得更少，也更容易被推荐。保留你的应用的顾客，就是仍然可以通过通知、优惠和服务触达的顾客。

反过来，缓慢的体验往往不会出现在报告中。因信号弱而在支付中途放弃的用户不会发来投诉；他们只是消失了。因此，性能应被视为产品计划和业务目标的一部分，而不只是有空时处理的技术事务。

应避免的常见错误

• 只在最新的手机和办公室高速网络上测试
• 为小功能添加大型库，使应用体积膨胀
• 在应用打开时一次性加载全部数据
• 无限显示转圈而没有诚实的提示
• 持续请求位置并持续运行后台工作
• 在没有通知和过渡期的情况下终止对旧版本的支持

本周就能开始的第一步

1. 01查看用户数据，了解最常见的设备和操作系统版本
2. 02挑选一两部普通手机作为测试的参考设备
3. 03在主流程上衡量应用体积、启动时间和流量使用
4. 04在限速或断网的条件下测试重要流程
5. 05列出影响最大的三项改进，并加入开发计划

结语

好的应用不是功能最多或最华丽的，而是顾客在日常条件下能舒适使用的应用。普通的手机和慢速的网络并不是可以忽略的例外；对许多顾客来说，这就是现实。

通过了解顾客的设备、保持应用轻量、对糟糕网络保持稳健，并在真实条件下测试，你可以触达更多人，减少他们离开你应用的理由。