本机 Android 开发：启动应用程序的快速指南

任何已经了解什么是原生开发的人都不需要更多的理论。您需要一个路线图：从哪里开始、按什么顺序以及导致项目延迟和超出预算的障碍在哪里。

对于那些将要亲自动手或密切领导那些将要动手的人来说，这是一个快速指南。无需拐弯抹角。我会直接讨论每个阶段的步骤、决策以及对进度影响最大的错误。

前提很简单：原生 Android 应用并不难开始，难的是顺利完成。健康的项目和混乱的项目之间的区别在于最初几周做出的决定。

Android 项目的各个阶段（按顺序）

在编写任何代码之前，需要做出三个选择，如果错误的话将会困扰您：语言（现在是 Kotlin，不讨论新项目）、架构（带有 Jetpack 组件的 MVVM 是标准且有详细记录的路径）以及要支持的最低 Android 版本。

后者在巴西具有战略意义。支持非常旧的版本可以扩展您的覆盖范围，但会增加测试成本并限制资源。仅支持新版本简化了开发，但排除了部分公众。根据谁使用您的应用程序而不是谁使用您的应用程序来做出决定。

在 Android Studio 中配置项目，定义文件夹组织和版本控制。这里还建立了团队将遵循的代码标准。这听起来像是官僚作风，但正是它阻止了六个月内没有人理解所写内容。

借助 Jetpack Compose，界面构建比旧的 XML 布局系统变得更加现代和高效。屏幕、导航和业务逻辑都是在这里开发的。秘诀在于分离得好：屏幕不应该知道数据来自哪里，逻辑也不应该知道屏幕是如何绘制的。

几乎每个应用程序都与服务器通信。它定义了应用程序如何使用 API（Retrofit 是标准）、如何在本地存储数据（Room for local Bank）以及如何处理缺乏连接的情况，这在网络波动很大的巴西至关重要。

一款仅适用于完美互联网的应用程序在真正的巴西是行不通的。处理离线模式不是额外的；是一个要求。

在多台设备上进行测试，而不仅仅是一台设备。为 Google Play 准备应用程序，配置数字签名，编写所需的隐私政策并发布。第一次提交的时间总是比你想象的要长。

这个堆栈很成熟，文档齐全，并且拥有庞大的社区。如果没有充分的理由就逃避它，就会给自己制造困难。

有一系列选择在开始时看起来是次要的，但后来决定了项目的健康状况。值得尽早治疗，而不是在问题已经爆发时才治疗。

首先是状态管理。随着应用程序的增长，控制每个屏幕显示的内容以及何时更新成为代码中最复杂的部分。尽早使用 Jetpack 组件定义清晰的方法，可以避免显示过时数据或行为不可预测的屏幕混乱。

第二个是错误处理和异常状态。真实的应用程序会处理请求过程中互联网掉线、服务器宕机、意外响应等问题。从一开始就设计这些状态，加载屏幕，有用的错误消息，重试的选项，是一个健壮的应用程序与在第一次逆境中崩溃的应用程序的区别。在连接不稳定的巴西，这也不例外：这是常见的情况。

第三是测试策略。您无法在数十台设备上手动测试每次更改的所有内容。尽早投资于关键部分、业务逻辑、支付流程、计算的[自动化测试0]，可以大大减少寻找回来的错误所浪费的时间。自动化测试的设置速度很慢，但回报却很快。

第四是使用分析。对应用程序进行检测以了解人们自发布以来如何实际使用它，使您可以根据数据而不是猜测来做出决定。如果没有它，您将在黑暗中启动，并发现没有人使用您花了一半时间的功能。

第一个是忽略碎片直到最后。该团队在高端设备上进行开发，并在发布前夕发现该应用程序在大多数人使用的流行手机上崩溃。尽早在适度的硬件上进行测试。

二是松散架构。在屏幕内混合业务逻辑一开始似乎更快，但后来就变成了难以维护的泥沼。一开始的匆忙对未来产生了很高的兴趣。

三是把绩效当成细节。未优化的图像、主线程上的繁重处理、糟糕的请求，所有这些都使应用程序看起来很慢。缓慢的应用程序是指已卸载的应用程序。

第四个，也许是最被低估的，是没有计划维护。 Android 的每个新版本都可能会破坏一些东西。每条新的 Play 商店规则都需要进行调整。那些交付和放弃的人会看到应用程序腐烂。

人们有一种错觉，认为走得快就意味着跳过步骤。在Android开发中，情况恰恰相反。最快的项目是最有纪律的：从一开始就清晰的架构、持续的测试以及对巴西设备实际情况的关注。

忽视基础的捷径不是速度，而是伪装成生产力的技术债务。它看起来像是预先的延迟，而修复它的成本却要高出十倍。

快速指南不会取代经验，而是提供方向。遵循顺序，尊重基本原理，并在现实世界中而不是在实验室中进行测试。这是实现真正有效的应用程序的最短路径。

如果您现在正在设置 Android 项目或评估供应商提案，则值得使用此脚本作为健全性检查表。这里有更多关于架构和移动策略的内容，并且欢迎讨论您的项目。