破解移动系统设计面试（iOS 和 Android）

利用本指南的最新版本来完成您的下一次移动系统设计面试。

系统设计面试一直以来深受 FAANG 公司青睐，自几十年前首次推出以来，人气日益高涨。它已成为大多数后端职位面试流程的标准环节。如今，它终于来到了我们这些移动工程师的视野，我们过去更习惯于通过家庭作业来展示自己的技术设计技能和架构知识。

系统设计面试主要关注两个主题：设计和架构。作为候选人，你很可能会被要求负责移动应用程序或功能的技术设计。内容简短而模糊，例如：

设计一个照片分享应用程序（例如 Instagram）
设计一个通讯应用程序（例如 WhatsApp 或 Messenger）
设计新闻推送功能（类似 Twitter）

其目的是让你展示如何将抽象的需求转化为精准细致的解决方案。它还能让面试官通过你在此过程中做出的不同决策来了解你的知识广度。虽然它们并非完美无缺，但与带回家的挑战相比，它们有一个显著的优势：大大减少了候选人和面试官所需的时间。

在当前人才招聘竞争激烈的市场中，大型科技公司和小型初创公司都在不断探索简化招聘流程的新方法。为此，越来越多的公司开始采用这种面试方式，取代招聘 Android 和 iOS 开发者时那种带回家完成的面试挑战。事实上，我在发展上一个团队时就亲自尝试过。我们将招聘时间从平均 3 周以上缩短到了大约 1 周。这一改变对求职者和面试官都产生了显著的效果，不过这大概是另一篇文章要讲的故事了。

系统设计面试可能看起来有点吓人，尤其是当你从未做过，或者没有设计服务于数百万用户、由数十名工程师共同开发的大型应用程序的经验时。这类面试是如何为移动端设计的，也笼罩着一层神秘的氛围。如果你搜索过，你可能会发现，有很多资料、课程和优秀的书籍解释了后端系统设计面试的工作原理，并提供了准备方面的帮助，但针对移动端的却很少。我们在这方面都是新手，所以我决定分享我作为候选人和面试官应对这类面试的经验。

你很快就会发现，没有理由害怕。只要稍加指导和练习，就能轻松应对这类面试（就像你现在应对家庭作业一样）。说不定你最终会乐在其中。

面试剖析

大多数系统设计面试持续约 45 分钟（有时可能会延长至 1 小时），并且都遵循非常相似的结构：

6 - 8 分钟：面试官的介绍和简短的开场白
4 - 5 分钟：问题陈述
25 - 30 分钟：设计并讨论您的解决方案
5 分钟：向面试官提问的时间

我见过很多求职者犯的一个相当典型的错误，我自己也犯过，那就是假设你只有45分钟的时间来解决问题，因为面试就是这么长。实际上，正如你从上面的日程安排中看到的，你大约有30分钟的时间来设计你的解决方案。因此，掌握时间至关重要。你需要以最佳的方式分配这30分钟，让你尽可能多地涵盖内容。即使在这30分钟里，也难免会被打断。所以最好制定一个清晰的计划，并进行足够的练习，以确保你能够完美地解决问题。

💡提示：练习时，用计时器计时，并强迫自己在 30 分钟时停止。然后，回顾你涵盖的主题，并列出如果时间再多一点你会添加的主题。仔细检查两个列表，并问问自己：我是否涵盖了与这个问题最相关的主题？第二个列表中是否有我觉得我应该涵盖的主题？如果有，如果你再次遇到同样的问题，你会如何将它添加到你的叙述中？这样做可以帮助你形成一致的方法，并逐渐形成一种感觉，即对于每种类型的问题，哪些主题/领域更值得探索，以及在多大程度上更值得探索。

面试官的观点

在描述如何理解这些访谈之前，我们需要了解桌子另一边的人（或这些人）的观点。他们在寻找什么？

开放式问题的面试旨在考察你的知识边界。让你选择想要涵盖的主题，并考察你在构思解决方案时如何优先考虑这些主题。这种设计是为了让面试官评估以下方面：

通过提出正确的问题，将其转化为一组具体的需求，从而解决模糊问题的能力
你的思考过程：如何将一个大问题分解成几个小部分，同时保持整体的联系并满足所有要求
如何做出决策，评估不同的选择及其利弊
您的知识储备如何？您对 Android 或 iOS 开发的哪些部分比较熟悉，哪些部分不太熟悉？您能为服务器提出一个解决方案吗？
最后，同样重要的是你的沟通和协作能力。你如何整合你的解决方案并获得认可

答案没有对错之分——只有不同的选择。你的面试官也深知这一点。所以，请不要专注于寻找完美的解决方案。相反，你应该像日常工作一样，专注于设计解决方案，运用你所掌握的知识来突出你的优势。有人曾经给我一个建议，而且我一直觉得很有帮助，那就是专注于你所了解的部分。如果面试官真的想帮助你成功，他们会更感兴趣的是了解你所了解的内容，而不是你不知道的内容。此外，快速提出解决方案并逐步改进通常会为你加分。在大多数情况下，最初的问题并非全部内容，你的面试官会期望你回答一些后续问题。这就是为什么采用迭代方法（从一个高级的“更简单”的解决方案开始，并随着新需求的增加而不断改进）相对有效的原因。

自由选择练习的重点领域是一把双刃剑。它让你可以自由地引导谈话，探索你更擅长的部分，但与此同时，面试官可能会认为你没有涉及的领域是因为你不了解。记住，大多数面试官（大公司尤其如此）在撰写评估时往往倾向于保守。因此，最棘手的一点是，在简要介绍与问题相关的所有主题和深入探讨与问题更相关的主题之间找到平衡。

找到这种平衡很难，主要是因为你和面试官认为相关的内容可能不一样。幸运的是，大多数面试官都会在这方面给予你帮助。他们可能会在你遗漏他们认为必要的内容时提示你，甚至会直接要求你补充他们感兴趣的特定部分。因此，你能做的最好的就是倾听面试官的意见，并利用她的提示来指导你的解决方案。如果有疑问，不要害怕问她你需要问的问题。

方法

下面我将介绍一种应对移动系统设计面试的策略。这是我多年来亲身实践并观察众多成功候选人的优秀表现后总结出来的。

💡提示：不要把这当作一个放之四海而皆准的策略。我鼓励你花时间去理解它，了解每个步骤的重要性和目标，然后将其融入到你的生活中。根据你感觉更自然的方式进行调整，最终，没有两个候选人是完全一样的，你才是最了解什么最适合你的人。你有能力，也有经验，相信自己。

它由六个简单的步骤组成：

了解问题
定义范围
确定技术要求
提出一个高层设计
深入研究一个组件
包起来

让我们更详细地介绍一下这六个步骤。

1. 理解问题

第一步应该没什么意外。在创建解决方案之前，我们需要了解问题。

这或许是最显而易见的一步，但却是大多数求职者（包括我自己）屡屡失败的一步。为什么？因为我们下结论太快。不过，我们也不必对自己太苛刻。我们这么多人落入这个陷阱是有原因的。这是一种众所周知的偏见，而面试环境（证明自己的压力）会加剧这种偏见。

“跳跃结论偏差，也称为推理-观察混淆，是一个心理学术语，指的是在没有足够信息确保自己正确的情况下做出决策。这会导致错误或草率的决策，而这些决策往往弊大于利。”
资料来源：维基百科

所以，既然你已经了解了，就不要妄下结论。放慢你开始设计解决方案的步伐，避免成为那种在还没有完全理解问题的情况下就贸然开始解决方案的候选人。相反，你应该专注于了解面试官希望你关注的内容、这类应用最相关的挑战，以及你之前解决过哪些类似的情况。

面试官给你一个模糊、开放式的问题是有原因的，而这一步正是原因所在。记住，她评估的是分析不完整问题、识别暗区以及提出正确问题的能力。

因此，在这一步，你需要提出一些澄清性的问题，以便更好地理解问题。思考一下你获得的信息，然后提出相关问题来完善思路。

根据问题的不同，我发现在此阶段提出以下几个问题很有用：

我们被要求设计什么？
用户是谁？他们将如何使用我们的系统？
初始用户数量是多少？预计增长多少？
我们是否获得了初步的设计/线框，或者我们也应该制作它们？
我们是在设计 MVP 还是最终产品？
我们是从零开始构建的，还是可以利用现有的组件？有哪些现有的模式/架构值得我们遵循？
实施和维护我们系统的团队有多大？
我们是否只需要设计移动应用程序或整个系统的其他部分（例如 API）？
是只支持 iOS 还是 Android？还是跨平台？我们应该同时支持智能手机、平板电脑还是两者？

你不需要问所有问题。根据问题的具体情况以及你提供的信息，有些问题可能是多余的。只需优先考虑与任务最相关的问题即可。

2. 定义范围

第二步是确定并同意您将要设计的应用程序或功能的功能需求。

想想你以前用过的类似知名应用或系统，以及它们是如何解决类似问题的。它们提供哪些功能，以及它们的主要功能是什么。你可以提出许多你能想到的潜在功能，并与面试官商定在本次设计环节中你将重点关注哪些功能。这应该是面试中一个非常具有协作性的部分。

一旦范围明确并且与面试官达成一致，您就可以进入下一步并慢慢展开您的解决方案。

3. 确定技术要求

这才是真正好玩的地方！一旦明确了功能需求，你就应该转换思路，开始思考构建解决方案所需的技术考虑，以便提供你和面试官刚刚达成一致的用户体验。

让我们直接讨论设计移动应用程序时通常需要考虑的最常见方面：

联网

如今，大多数应用都会从后端共享或检索其状态。花点时间思考一下这个后端应该是什么样子。大多数情况下，REST API 就可以了。这个 API 是否提供？如果提供，它是什么样子的？

是否有任何功能需要低延迟来模拟实时更新？如果是，您将如何将这些信息推送到客户端？您可能需要使用比普通 HTTP 请求更复杂的方法。您可以使用推送通知、WebSocket、轮询等。每个选项都有利弊需要考虑。

安全

如果上面我们说大多数应用需要与其他系统通信，那么显然我们需要确保这些通信的安全。请思考以下主题：

身份验证：您的解决方案如何验证谁是您应用程序的用户（身份验证）以及如何保证提供正确的访问级别（授权）
存储敏感数据：您需要保存用户的凭证吗？是的！除非您想提供糟糕的用户体验，让用户每次登录都得重新登录。哪些凭证（例如访问令牌、刷新令牌）？我们需要处理个人身份信息 (PII) 吗？您将如何安全地存储它们？（例如钥匙串、智能锁）
安全通信：如何确保与后端的通信安全？例如，所有请求都遵循 HTTPS 协议，并使用 TLS、证书锁定等加密。

可用性

应用是否必须支持离线模式？很有可能，因为你不想每次用户打开应用时都从空状态启动。你可以使用本地存储来缓存数据（例如 Core Data、Realm、SQLite、共享偏好设置等），考虑一下选择哪种方式以及原因。

那么图片（或其他媒体）怎么办呢？如果需要，您可以在从网络检索后将其缓存在本地。这是一个不错的选择，但它也带来了一些挑战：同时处理多个请求、取消过期的请求、清理策略（例如 LRU）、限制并发请求等等。

可扩展性

在移动领域，可扩展性挑战通常与其他系统略有不同。在后端面试中，你必须设计系统以支持数百万的每秒查询量 (QPS)，并将 TB 级数据划分到多个分片中。在移动应用中，可扩展性通常与代码库的扩展和应用开发团队的规模相关。因此，请思考如何准备你的设计以支持由多个团队（数十名开发人员共同开发同一应用）共同拥有的新功能。

您可以：

将 UI拆分成更小的独立组件。每个组件都有各自的堆栈，以便不同的人可以高效地处理它们。
通过构建可重复使用的 UI 组件库来标准化您的 UI 。它可以减少代码并确保整个应用程序的用户体验一致。
模块化应用程序：将功能分成单独的模块（每个团队可以拥有），并将可重复使用的组件提取到共享和核心模块中。

表现

在如今的移动生态系统中，越来越多的应用通过提供流畅的用户体验来脱颖而出。为了实现这一点，你必须面对一个挑战：隐藏从网络获取数据的需求。

您可能想要探索的一些与性能相关的主题包括：

是否存在一些 UI 密集型操作（例如无限列表滚动、繁重的动画或复杂的过渡）？您将如何支持这些操作？例如，您可以预取数据并创建缓冲区。
应用是否需要加载图片、视频、音频等数据量较大的应用？如果是，我们应该考虑如何异步加载，这样才能保持界面流畅，同时提供最佳的用户体验。例如，可以设置一个单独的服务来异步处理媒体数据的检索，并在准备就绪时通知界面。你的方法可能存在哪些瓶颈和挑战？

测试

您可以简要介绍一下您计划如何确保应用的质量。如今，创建一套可靠的测试套件是默认做法，但具体如何实施则取决于具体需求（例如，您是否正在构建 MVP？）。您可能需要思考并描述您的测试策略。

您可能想简要讨论以下内容：

解释您的测试策略：您将如何应用不同类型的测试（单元测试、集成测试和 UI/功能测试以覆盖端到端的主要应用程序流程）
突出你的架构的优势，解释测试每个特定组件是多么容易
使用依赖注入使编写测试更容易

监控

除非面试官要求，否则你通常不会在这一点上花太多时间。重要的是要考虑如何确保系统的正确性，并在出现问题时能够快速响应。最重要的两个支柱通常是：

崩溃报告和日志
分析

部署

您如何预见您的系统将投入生产？这可能取决于面试官的要求。最常见的话题是：

具有自动发布的 CI/CD 管道（例如使用 Fastlane 将构建版本发送到生产、QA 和 Beta 版本）
利用远程功能标志可以逐步推出更改，并将发布与审核过程分离（例如，确保新功能已准备好用于营销活动）。

这就是这一步的全部内容！

呼呼……要讲的内容太多了，时间也紧！不过别担心，目标是在大多数问题中（一两句话）提到足够多的内容，这样面试官就知道你已经考虑过了。除非问题关键，或者面试官要求，否则不要讲得太详细（记住，听从面试官的提示，循序渐进）。

4. 提出高层设计

绘制主要流程的线框（如果未提供）

如果您还没有拿到线框图，那么在深入开发解决方案之前，第一步就是先画出来。这一步至关重要。它能让您和面试官就主屏幕、UI 组件、用户交互和导航流程达成一致，这些将为您的后续技术决策提供参考。您需要确保面试官认可您认为该应用如何满足所有既定要求。

如果您只遵循三个简单的步骤，它应该非常简单：

将主屏幕绘制为框，描述主要内容
仔细查看流程，添加箭头来表示用户旅程
添加更多细节来讨论每个屏幕的组成：识别主要的 UI 元素，拆分 UI 组件（例如 CollectionView / TableView 中的卡片/单元格）。考虑可能的可重用元素

💡提示：不要花太多时间绘制高保真线框图。思考最重要的事情：描述用户体验，重点关注不同的视图及其主要组件，以及用户流程应该是什么样子。

绘制主要系统（如果需要）

此时，你应该问问面试官，她希望你涵盖端到端设计，还是只关注客户端。大多数移动系统设计面试只关注应用程序，但根据职位级别、他们寻找的工程师类型以及团队规模，他们可能希望你至少展现出对应用程序之外的基本了解。

假设面试官要求你探索端到端设计。你的设计很可能需要依赖以下几个常见元素：

移动客户端
API 服务（客户端将与之通信的层）
后端应用程序（负责后端大部分繁重工作的应用程序）
数据存储（将信息存储在云中）
通知服务（如果需要通知）

定义基本数据实体

此时，你应该对正在设计的流程以及应用将支持的功能有了很好的了解。描述与你的问题相关的最重要的数据实体应该相当容易。

💡提示：一开始不要讲得太详细。你不是在设计数据库模式。你只需要列出实体（例如用户、帖子、评论），并提及它们最相关的属性和关系。如果面试官要求更多细节，你可以更深入地讲解。

描述主要终点（如果需要）

根据你之前询问面试官时她是否告诉你提供了 API，你可能需要设计端点。

💡提示：请遵循迭代方法，无需为每个端点生成完整的规范。列出端点及其 HTTP 方法（GET、POST、PUT、DELETE）和路径（例如GET /post/:id/comments）、端点所需的输入参数以及您期望的输出。对于输出，注明主要实体通常就足够了（无需编写完整的 JSON 负载）。与往常一样，请与面试官确认这一点。

提出客户端架构

回到应用程序，现在是时候讨论并决定您的设计将遵循哪种架构和常见的软件模式。

回顾一下你熟悉的标准架构（例如 MVC、MVP、MVVM+C、VIPER、RIB 等），以及在系统不同层级（例如存储库、用例、服务等）抽象和封装逻辑的最典型模式。思考它们在应用于当前问题时的优缺点。哪些模式更符合你的需求？为什么？

💡提示：选择一个简洁的架构，可以让剩下的练习更容易完成。这些架构可以让你更容易地将设计分解成更小、更独立的组件，从而提高解决方案的可扩展性、灵活性和可测试性。记住，面试官可能会先从一个相对简单的问题开始，然后要求你改进它以处理更复杂的场景。你的架构越能灵活地应对新挑战，你的系统在面对新挑战时就越容易调整。

很遗憾，我无法告诉你最佳架构选择。这不仅取决于问题本身，还取决于你的经验。如果你对某个新潮架构不够了解，选择它可能是错误的。相反，我建议你选择你更熟悉的架构。你必须充分理解该架构及其每个组件，因为你可能需要在面试中详细描述它。

就我而言，我倾向于默认使用由以下部分组成的相对简单且与趋势无关的清洁架构：

表示层（UI）：MVVM + 协调器，用于处理视图和控制器或活动和片段以及导航逻辑。
领域层（业务逻辑）：用例，结合来自用户和存储库的数据。
数据层：
- 存储库，用于从网络或本地存储检索数据
- 网络数据：典型 API 客户端之上的单个端点
- 持久数据：本地存储（如果缓存）
辅助服务：提取不同功能可能共享的功能，例如：
- 网络服务
- 会话服务（保存用户会话的信息）
- 凭证存储（处理用户凭证的读写）

在使用标准组件时，我发现保持架构趋势不可预测会很有帮助。我更喜欢务实一点，添加解决问题所需的组件，而不是选择更主观的选择（例如 VIPER）。这显然是一个个人偏好问题，你和面试官的意见可能会有所不同。因此，我的建议是在面试过程中与她协商，解释你的决策权衡利弊。

5. 深入研究一个组件

现在是时候更详细地检查你的某个组件了。虽然能够从高层次解决问题很重要，但面试官很可能希望你也能描述一个或多个设计组件的细节。

在这里我分享我遵循的方法：

选择最有趣的屏幕并绘制其 架构：涵盖不同 UI 组件、VM、Repos、端点/套接字、网络层、本地存储等的所有层。
跟踪依赖关系（从调用者处画箭头）
从用户的角度来回顾整个流程：用户体验如何？用户在每一步都看到什么？描述可能的视图状态：加载中、错误、无数据、有数据。
解释数据流：数据在网络模型 → 业务模型 → 视图状态模型过程中的转换。绘制箭头来表示数据流（不同于依赖关系箭头，例如使用虚线箭头，其他颜色）。
了解完以上所有内容后，深入研究某个组件。思考一下哪些部分可能是最具挑战性的，设计中是否存在瓶颈等等。例如：
- “实时”更新
- 图像缓存（挑战，NSOperation 队列）
- 重复使用单元（准备虚拟机）
- 缓冲数据请求以改善用户体验

💡提示：再次强调，一定要听取面试官的意见。大多数面试官会让你自己选择，但有些面试官可能会引导你更详细地了解她希望你涵盖的内容。如果你忘记了什么，也可能会这样做。

6.总结

快速回顾你的设计

审查初始范围和功能要求以及您的设计如何满足所有要求。

后续问题/延伸目标

此时，你的面试官可能已经开始问一些后续问题了。请认真倾听他们的回答，并解释你的设计可以如何调整以支持他们。否则，问问她是否还有其他需要你进一步阐述的地方。

进一步改进和考虑

简要介绍一下如果有更多时间你会做的一些改进：回顾一下上面提到的设计和技术考量，并思考是否可以更详细地阐述其中任何一个方面。想想你之前可能忽略的技术考量。现在或许是简要提及它们的好时机。一些你可以涵盖的主题：你的测试策略是什么样的？你将如何利用系统的正确性进行崩溃报告和分析？你将如何通过无障碍功能提升应用的包容性？

最后的想法

一般建议

在描述我们方法的各个步骤时，我们已经涵盖了很多内容（我希望现在它也已经成为了您的方法）。在所有这些步骤中，您可能已经注意到了一组共同的模式。让我们快速回顾一下：

不要害怕提问。问题很可能比较模糊，你需要收集必要的信息，确保你正在解决面试官希望你解决的问题。只有一个方法：问问你的面试官。
验证你的假设。向面试官核实你所做的任何假设，以确保你的方向正确。
了解并运用你的工具。真正精通绘制图表并整合你的解决方案。时间宝贵，这将提高你阐述解决方案的速度。无论是在白板上还是使用在线工具，都要练习以清晰易懂的方式组织你的思路。学习如何让你的图表易于修改和扩展。
分享你的想法。为了确保面试有效，与面试官持续沟通至关重要。记住，她想了解你的想法。
获得他人对你选择的认可。对于你做出的每一个决定，都要提及你考虑过的不同方案，它们的优缺点，以及你选择某个方案的原因和利弊。

练习，练习，练习

我之前提到过，练习这类面试对提高成功率非常重要。现在，你可能想知道最好的方法是什么。以下是一些对我而言非常有效的建议：

熟悉不同的标准架构：MVC、MVVM、MVP、Redux、VIPER等。
设计常用应用：拿起你的手机，想想你最常用的应用以及它们最知名/最具挑战性的功能（例如邮件客户端、Instagram、Spotify、Twitter、Facebook、WhatsApp、Etsy），然后思考你会如何设计它们。拿出一张纸，开始想象你会如何实现这些应用。这个简单的练习对我和我认识的大多数人来说都是最有效的。相信我，它真的有效！
阅读现有的解决方案：查看大公司工程师的技术博客文章、录音讲座等，并比较他们如何解决挑战。
回顾几个著名的开源项目。
请朋友和同事审查您的设计，获取反馈。
与同事或其他同样的候选人进行模拟面试练习。

放松身心，享受旅程

系统设计面试可能很难，甚至让人有点不知所措，但它也是一个可以发挥创造力，通过想象你从未参与过的系统来学习的地方。准备任何面试都会让人感到压力，但如果你学会享受准备过程本身，并将其视为拓展知识的机会，它就会成为一次非常激动人心的经历。

那么，关于即将到来的采访

如果您正在阅读这篇文章，很可能您正在准备面试。

移动系统设计面试就像拼图游戏。你从未拼过，但你得用各种零件来解开它。所以，一定要在你的工具箱里准备各种各样的零件，以便能够轻松地仔细检查它们，并从中挑选出最适合你的。

在本文中，我尝试分享一种应对这些面试的方法。但这仅仅是我的方法，是我自己进行过数十次面试，面试过数百名候选人后总结出来的。在描述它时，我特意涵盖了尽可能多的主题，以便你能够根据这些主题调整，形成自己的策略。不要只照搬我的方法，要把它变成你自己的！

面试前练习，精通面试技巧，但不要死记硬背。系统设计面试的难度各不相同，因为候选人和面试官的水平也各不相同。记住，面试官的职责是指导你，帮助你取得成功。请留意面试官给你的提示和建议，并将这些小细节融入到你的解决方案中。

感谢您阅读这么长的文章。希望您能更好地理解移动系统设计面试的意义：面试内容、面试官会评估哪些方面，以及如何成功应对这些面试的可靠方法。

我很乐意学习你的经验。如果你还有其他建议或策略，请在评论区分享。

祝面试顺利！

资源

这里有一份建议材料列表（帖子、WWDC 视频、课程等），以便您深入了解并扩展本文涉及的不同主题的知识。

App Architecture - Chris Eidhof、Matt Gallagher 和 Florian Kugler 合著的《iOS 应用程序设计模式》（Swift 版）。[图书]
大规模构建移动应用的 33 个工程挑战，作者：Gergely Orosz [文章|书籍]
系统设计面试：内幕指南作者：Alex Xu [书籍|课程]
推送技术。维基百科 [文章]
网络技术的进步（第一部分）。WWDC 2019 [视频]

我是谁？

我是一名拥有 15 年经验的软件工程师。大约十年前，我从为嵌入式系统编写 ANSI C 代码转向移动开发。没错！那真是美好的时光，iOS 3、Interface Builder、Eclipse、iPhone 3GS、Java 和 Objective-C 应运而生。我参与过小型项目，当时只有我一个人负责，也参与过由多个团队和 50 多名开发人员组成的大型应用程序，为全球数百万用户提供支持。这段时间，我面试过数百名候选人，也亲自以候选人的身份参加了数十次面试，从小型初创公司到大型科技公司。

文章来源：https://dev.to/ecaselles/cracking-the-mobile-system-design-interview-ios-android-4kfi