安卓这个词现在几乎成了智能手机的代名词，但真要坐下来聊"安卓概述、安卓架构、安卓开发入门"这三件事，很多刚入行的朋友还是一头雾水：知道它是个手机系统，知道能用 Java 或 Kotlin 写 App，可一问他系统分成几层、应用启动时到底发生了什么、minSdk和targetSdk为什么要分开设，就答不上来了。这篇东西我想从一个实际写过几年应用、也被各种崩溃和适配问题折磨过的人的角度，把安卓从"是什么"到"怎么上手"这条线完整捋一遍。不管你是完全没接触过移动端、想找个方向切入的新手，还是从后端、前端转过来、需要快速补齐安卓基础概念的老手，下面这些内容应该都能直接用上。我会把架构分层讲透，把环境搭建的每一步踩点写清楚，再把四大组件、生命周期、常见崩溃排查这些真正影响开发效率的部分拆开说，中间穿插一些只有实际动手才会知道的细节。

1. 安卓概述：先搞清楚你每天在开发什么

1.1 从一部手机开机说起，安卓系统到底由哪些东西拼成

很多人对安卓的第一印象就是"一个能装 App 的系统"，这个理解不算错，但太粗。把它拆开看，一部安卓手机开机之后，大致会经历这么几个阶段：芯片上电，引导程序把内核拉起来，内核完成硬件初始化和驱动加载，然后挂载系统分区，启动第一个用户态进程，再由它去拉起系统服务，最后才是桌面出现、应用可以被点击。

这条链路里，前面几段跟普通开发者关系不大，属于底层和厂商定制的地盘；但从"系统服务被拉起来"往后，就全是应用开发者要关心的事了。你写的每一个页面、每一次点击响应，本质上都是在跟这些常驻系统服务打交道：要显示界面，得找窗口管理服务；要读通讯录，得找内容提供者；要弹通知，得找通知服务。理解这一点非常重要，因为它解释了为什么安卓开发里到处都是"拿系统服务"的代码，也解释了为什么权限、后台限制这类东西会直接掐住应用的脖子。

再往上一层看，安卓不只是一个操作系统，它还是一整套配套的东西：一套应用框架接口、一套打包和签名规范、一套应用分发机制、一套设计规范。你在做安卓开发的时候，实际面对的从来不是单一系统，而是"系统 + 工具链 + 规范"的组合体。新手最容易犯的错，就是把注意力全放在写界面代码上，忽略了后面这几块，结果工程能跑起来，却不知道怎么打包、怎么定位线上崩溃、怎么处理不同机型差异。

我一般建议刚入门的人先建立一个整体图景，哪怕细节暂时不懂。因为安卓的知识点非常碎，没有一个骨架去挂，学起来就是散沙。而这个骨架，就是接下来要讲的四层架构。

1.2 一句话概括安卓的四层架构

安卓的官方架构描述里，从上到下分成四层：应用层、应用框架层、系统运行库与运行时、硬件抽象层与内核层。不同版本的文档在细节划分上略有出入，但主干一直是这个结构。

先用一句大白话概括：最上面是你写的 App，往下是系统提供的一堆现成服务，再往下是让代码能跑起来的运行环境和基础库，最底下是跟硬件打交道的内核。

这个结构的核心价值在于"隔离"。上层不需要知道底层怎么实现，只要按约定调用就行。比如你要在屏幕上画一个按钮，不需要关心这块屏幕是哪个厂商的、分辨率多少、驱动怎么写，只要调用框架层的接口，剩下的事情由下层处理。这种隔离带来的好处是开发效率，代价是你在遇到问题时，往往不知道问题出在哪一层，只能一层层往上排查。后面讲问题排查的时候，我会把这个思路具体化。

1.3 版本碎片化是绕不过去的现实

聊安卓概述不能不提版本问题。桌面系统大家习惯了三五年换一次大版本，安卓这边是每年一个新版本，加上厂商定制、机型保留旧系统、用户不愿升级，结果就是同一个应用要同时面对跨度好几年的系统版本。

这件事对开发者的直接影响体现在三个配置项上：minSdk、targetSdk、compileSdk。它们不是随便填的数字，每一个都对应实实在在的取舍。

我自己的习惯是：compileSdk始终跟最新稳定版对齐，targetSdk跟着应用商店的要求走，minSdk看产品面向的人群。如果是面向大众的工具类应用，minSdk定在较老版本比较稳妥；如果是企业内部应用或者设备可控，直接拉到较新版本，能省掉大量兼容代码。这个决定最好在项目启动时就定下来，中途调整会牵扯到依赖库版本、混淆规则、甚至界面适配方案，改起来很麻烦。

2. 安卓架构逐层拆解：每一层到底在干什么

2.1 应用层：你写的代码住在最上面

应用层就是安装包里的东西，包括系统自带的桌面、设置、相机，也包括你自己开发的 App。这一层是所有开发者最熟悉的部分，但有个细节常被忽略：系统自带应用和你写的应用，在框架层面使用的是同一套接口。它们没有特殊通道（少数系统级权限除外）。这意味着你在文档里看到的接口行为，对系统应用同样适用，你遇到的那些限制，系统应用也得遵守。

应用层的组织单位是"应用"，每个应用运行在自己的沙箱里，有独立的用户 ID、独立的文件目录、独立的进程空间。应用之间默认不能直接读对方的数据，要共享数据必须通过系统提供的机制，比如内容提供者、共享文件、或者跨进程调用。这个设计是安卓安全模型的基础，也是新手最容易困惑的地方——为什么我把文件写到应用目录里，别的应用就看不见？因为沙箱就是干这个的。

打包出来的安装包本质上是个压缩包，里面有编译后的代码、资源文件、清单文件、签名信息。清单文件特别关键，它声明了应用包含哪些组件、需要哪些权限、支持哪些硬件特性。系统在安装时读的就是这个文件，很多"应用装不上""功能用不了"的问题，根子都在清单配置上。

2.2 应用框架层：系统提供的一整套"管家服务"

框架层是开发者日常调用最频繁的一层，你可以把它理解成系统给应用准备的一整套管家服务。想显示界面，有窗口和视图系统；想跳转页面，有页面管理服务；想弹通知、读传感器、定位、播放音频，都有对应的管理服务。

这一层最有代表性的几个服务，构成了安卓开发的骨架：

• 页面管理服务：负责页面栈的维护、生命周期回调的分发、页面之间的跳转与返回。你写的页面类只是被它管理的对象，什么时候创建、什么时候可见、什么时候被回收，全由它决定。
• 窗口管理服务：负责窗口的层级、尺寸、输入事件分发。界面显示异常、点击穿透、悬浮窗遮挡，通常都能在这里找到原因。
• 包管理服务：负责应用的安装、卸载、组件解析、权限授予。你在清单里写的每一个组件，最终都由它登记在案。
• 活动管理服务：负责后台任务、通知、广播等系统级事件的调度。新版系统对后台行为的限制越来越严，主要就是这一层在收紧。

框架层的一个显著特征是"回调驱动"。系统不会主动等你，它只会在特定时刻调用你注册的回调方法，你在回调里做该做的事。这套模型的好处是省电省资源，坏处是你必须非常清楚每个回调的触发时机，否则就会出现"数据还没准备好界面就刷新了""任务被杀了不知道"这类问题。后面讲生命周期的时候会详细展开。

2.3 系统运行库与运行时：代码是怎么跑起来的

再往下一层是运行库和运行时，这一层普通开发者平时看不到，但它决定了代码能不能跑、跑得快不快。

运行库这块包含几类东西：图形渲染库、多媒体编解码库、数据库引擎、字体与排版引擎、网络与加密基础库等等。这些东西的共同点是"通用且与业务无关"，系统把它们做成公共能力，应用直接调用，不用每个应用自己带一份。

运行时这块，安卓采用的是"应用进程内运行"的模式。每个应用启动时，系统会为它创建一个独立的运行时实例，负责类加载、内存分配、垃圾回收。你的代码不是直接跑在裸机上，而是跑在这个运行时里。这带来两个直接后果：一是内存管理基本自动化，你不用手动释放，但也意味着你无法精确控制回收时机；二是应用的启动速度、内存占用、卡顿表现，跟运行时的行为强相关。

这里有个常被误解的点：应用进程被杀掉，不等于应用被卸载。系统在内存紧张时会回收后台进程，下次启动重新创建就行。但这也意味着，你不能假设任何内存里的状态会一直存在。用户切出去接个电话，回来你的页面可能已经被重建了。所有需要持久化的数据，必须落到文件、数据库或者键值存储里。这个认知越早建立越好，能避免大量"偶现数据丢失"的诡异问题。

2.4 硬件抽象层与内核：离你最远也最能坑你

最底下两层是硬件抽象层和内核。硬件抽象层的作用是把不同厂商的硬件差异包装成统一接口，让上层不用为每个芯片写一套代码；内核负责进程调度、内存管理、驱动加载、电源管理、安全隔离这些最底层的事。

对应用开发者来说，这两层平时是透明的，但一旦出问题，往往就是最棘手的那种。举几个典型场景：

第一，功耗与后台限制。内核层面的电源管理策略决定了应用在后台能活多久、能不能定时唤醒。新版系统在这块越来越激进，很多以前能用的后台保活手段现在都失效了，正确做法是改用系统推荐的后台任务调度机制。

第二，内存与进程优先级。内核根据进程的优先级决定谁先被杀。前台页面所在的进程优先级最高，后台服务次之，空进程最先被回收。理解这一点，就能明白为什么"把逻辑放在后台服务里"这种做法在某些场景下并不可靠。

第三，机型差异。不同厂商在硬件抽象层和内核上做了大量定制，导致同样的接口在不同设备上表现不一致。通知样式、后台策略、权限弹窗、字体渲染，这些地方都可能出现差异。做适配的时候，不能只在一台设备上验证。

2.5 分层架构给开发者带来的三条实际约束

把架构拆完，落到实际开发上，我总结了三条反复被验证的约束，新手记住这三条能少走很多弯路。

第一条：跨层调用必须走框架接口。你不能绕过框架层直接操作底层硬件，这不仅做不到，而且是安全模型明确禁止的。所有能力都必须通过系统提供的接口申请，这就解释了为什么权限、清单声明这些东西如此重要。

第二条：任何跨进程交互都有成本。应用和系统服务之间、应用和应用之间，很多调用是跨进程的。跨进程调用涉及数据序列化和进程切换，比进程内调用慢一个数量级。所以高频操作绝对不能在主线程里做跨进程调用，界面卡顿很多时候就是这么来的。

第三条：状态不可信任。因为进程随时可能被回收、页面随时可能被重建、配置随时可能变化（比如旋转屏幕、切换语言、切换深色模式），所以任何界面状态都必须能从持久化数据中恢复。这条是安卓开发跟很多其他平台最大的思维差异，也是新手最容易忽略的地方。

3. 安卓开发入门：从零把环境跑通

3.1 工具链选型：为什么几乎没有第二种选择

安卓开发的工具链相对集中，官方提供的集成开发环境基本是事实标准。这件事对新手其实是好事——不用纠结选哪个，直接上就行。但在动手之前，有几件事得先想明白，因为它们会直接影响后面几个月的体验。

开发语言的选择。现在的主流是两种：一种是比较新的、语法更简洁的语言，另一种是历史更久的经典语言。新项目我强烈建议用新语言，语法糖多、空指针检查更严格、协程写异步很舒服。老项目维护的话，只能跟着项目走，但即便用经典语言，也可以逐步引入新语言的写法。

构建工具的选择。官方的构建系统是必须用的，没有替代方案。它的配置文件是整个工程的骨架，依赖管理、签名配置、打包变体、混淆规则全在这里。新手常见的错误是把配置文件当黑盒，出错了就到处搜答案复制粘贴，结果越改越乱。我的建议是花半天时间把配置文件的结构看懂，后面能省下几十个小时。

模拟器与真机的取舍。模拟器适合快速验证界面和逻辑，启动快、截图方便、能模拟各种屏幕尺寸。但模拟器有几个坑：性能表现和真机差别大、部分硬件相关功能（相机、传感器、定位）模拟不完整、某些系统行为不一致。我的做法是日常开发用模拟器，功能自测和性能验证必须上真机，至少要覆盖一台低端机和一台高端机。

这里有个经验：不要一开始就装一堆插件和辅助工具。官方环境装好、能跑通一个空工程，就已经够用了。工具越多，环境冲突的概率越高，新手很难分辨是代码问题还是环境问题。

3.2 环境搭建的完整步骤与版本对齐

下面这套流程是我自己反复装过多次、也帮别人排查过多次之后总结出来的顺序，照着走基本不会卡住。

第一步，装运行时环境。构建系统需要一个运行环境，版本不能太老。装完之后在终端里验证版本号，能打印出来说明装好了。这一步经常出问题的地方是环境变量没配或者配错，导致终端里找不到命令。

第二步，装开发环境本体。装的时候会引导你下载一套开发工具包，包括编译工具、平台接口、模拟器镜像。这一步网络不太稳定的话会很慢，耐心等，不要中途强退。

第三步，验证开发工具包。打开终端，运行版本检查命令，看看列出来的平台版本和构建工具版本是否齐全。如果缺，可以在开发环境内置的管理器里单独勾选安装。

第四步，创建一个空工程。选择"空页面"模板就行，语言选你打算用的那一种，最低支持版本先按默认来。第一次创建会触发依赖下载，时间比较长，属于正常现象。

第五步，跑起来。先启动模拟器，然后点运行按钮。第一次编译比较慢，等构建完成，模拟器上出现画面就说明环境通了。

第六步，版本对齐检查。这一步很多人跳过，但它决定了后面会不会莫名其妙报错。打开工程的构建配置，确认三件事：

android { compileSdk = 34 // 编译用接口版本，跟最新稳定版对齐 defaultConfig { minSdk = 24 // 最低支持版本，看目标用户设备分布 targetSdk = 34 // 目标适配版本，跟应用商店要求走 } }

三个版本的关系可以这么理解：compileSdk是"你写代码时能看到多少接口"，minSdk是"你的应用能装到多老的系统上"，targetSdk是"系统用哪套规则来对待你的应用"。三者不要求一致，但有个约束：compileSdk不能小于targetSdk，否则编译会报错。

还有一个容易忽略的点：构建工具版本和开发环境版本是绑定的。装了新版本的开发环境，工程里的构建工具版本如果太老，可能会提示不兼容。反过来，构建工具版本太高，老版本开发环境也打不开。团队协作的时候，这两个版本最好写进文档，避免每个人环境不一样导致构建结果不一致。

3.3 新建工程的目录结构逐个说明

工程建好之后，目录一堆，新手容易懵。我按重要程度挨个说。

app/ 应用模块，你的代码基本都在这 src/main/ java/ 或 kotlin/ 源代码目录，按包名组织 res/ 资源目录，分类存放 layout/ 界面布局文件 drawable/ 图片与图形资源 values/ 字符串、颜色、尺寸、样式 mipmap/ 应用图标 AndroidManifest.xml 清单文件，组件与权限声明 build.gradle 模块级构建配置 build.gradle 工程级构建配置 settings.gradle 模块与仓库声明 gradle.properties 全局属性配置

几个要点展开说。

清单文件是整个应用的入口说明书。系统读它才知道你的应用有几个页面、哪个是启动页、需要什么权限、支持什么屏幕。所有组件必须在这里注册，没注册的组件调不起来。这是新手最常见的错误之一：写了个页面，忘了在清单里声明，一运行就崩溃。

资源目录按类型分，不按页面分。布局放布局目录，字符串放值目录，图片放图形目录。这样做的原因是系统需要按类型做适配——比如不同语言用不同字符串文件，不同屏幕密度用不同图片。资源文件的名字只能用下划线和字母数字，不能有大写字母，这个限制经常让人抓狂。

构建配置分两级。工程级管全局，比如仓库地址、插件版本；模块级管具体应用，比如版本号、依赖库、签名。多模块工程里，每个模块都有自己的构建配置。

代码目录按包名组织。包名是应用的唯一标识，也是代码的命名空间。包名一旦确定、应用上架之后就改不了了，所以新建工程时要认真填。我见过不少人用默认的示例包名上线，后来想改发现改不了，非常被动。

3.4 第一个页面：代码与运行验证

空工程默认带一个页面，代码大致长这样：

class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) } }

三行核心代码，每行都有讲究。

继承的基类决定了这个页面具备哪些能力，官方推荐用兼容版本，能在老系统上表现得跟新系统一致。onCreate是页面创建时被调用的第一个回调，重写它的时候必须先调用父类实现，否则会直接崩溃——这是硬性要求，不是建议。setContentView把布局文件绑定到页面上，之后页面显示的内容就由那个布局决定。

布局文件本身是描述性的：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical" android:gravity="center"> <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="第一个页面" /> </LinearLayout>

match_parent表示跟父容器一样大，wrap_content表示刚好包住内容。这两个值几乎每个布局都会用到，理解它们的含义比记住属性名重要得多。gravity控制子元素的对齐方式，orientation控制排列方向，这几个属性组合起来就能实现大部分基础布局。

点击运行之后，模拟器上出现文字，第一个工程就算跑通了。这一步看起来简单，但它是后面所有工作的基础。环境跑不通，后面全是空谈。

提示：第一次运行如果卡在"下载依赖"或者"同步构建配置"很久不动，先检查网络，再检查仓库地址配置。绝大多数首次构建失败都是网络问题，不是代码问题。

4. 安卓开发核心：四大组件与生命周期

4.1 页面组件：生命周期是全流程的基础

页面组件是用户能看见的部分，也是开发者打交道最多的组件。它的生命周期回调有好几个，但真正需要重点理解的是下面这一组：

这张表的关键不在于记住名字，而在于理解"页面不是一直活着的"。用户切到别的应用、接个电话、旋转屏幕、切换深色模式，页面都可能经历暂停、停止甚至销毁重建。

这里有个真实案例。早期我写过一个表单页面，用户在输入框里填了一半，切出去查了个资料回来，输入内容全没了。原因就是页面被系统回收又重建，而我没有把输入状态保存下来。修复方式是在合适的回调里把数据写进状态包：

override fun onSaveInstanceState(outState: Bundle) { super.onSaveInstanceState(outState) outState.putString("draft", inputField.text.toString()) } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) val draft = savedInstanceState?.getString("draft") inputField.setText(draft) }

状态包不是万能的，它只适合存轻量数据，比如输入框内容、滚动位置、选中的标签。大数据该落数据库还是落数据库，别塞进状态包，会触发序列化性能问题甚至崩溃。

4.2 后台服务组件：边界在哪，什么时候该用

服务组件是用来执行不依赖界面的任务的。新手经常把它理解成"后台线程"，这是个根深蒂固的误解。服务运行在主线程里，你在服务里直接做耗时操作，一样会卡界面。这个误解导致的卡顿问题，我见过太多次。

服务的正确用法，是把它当成"告诉系统我在做一件事，请别随便杀我"的声明。真正的耗时逻辑要放在工作线程、线程池或者异步任务框架里。

另外一个重要变化是后台限制越来越严。以前的常驻后台做法在新版系统上基本走不通了，正确姿势是改用系统推荐的后台任务调度机制：需要延迟执行用任务调度器，需要立即执行用前台服务并显示常驻通知，需要跟界面绑定用绑定服务。选错了机制，功能在部分机型上就会莫名失效。

我的经验是：能用页面内的异步任务解决的，绝不上服务；能用系统调度器解决的，绝不上常驻后台。每一层机制都有它的适用场景和代价，用重了会被系统限制，用轻了会丢任务。

4.3 广播接收器与内容提供者：各自守着一块地盘

广播接收器负责接收系统或应用发出的事件通知，比如网络变化、电量变化、开机完成、应用安装卸载。它的特点是"来得快去得快"，系统调用它之后，执行时间有严格限制，超时会被判定为无响应。

用广播接收器要记住两件事。第一，注册方式分动态和静态：动态注册跟着组件生命周期走，组件销毁要记得注销，否则会内存泄漏；静态注册写在清单里，应用没启动也能收到，但新版系统对静态注册的限制很多，大部分系统广播已经不允许静态注册了。第二，耗时逻辑绝对不能放在接收器里，只能做轻量处理，重活要么转给调度器，要么起前台服务。

内容提供者负责应用间的数据共享。它的价值在于统一了数据访问方式：不管底层是数据库、文件还是内存，对外都提供同一套增删改查接口。系统里的通讯录、媒体库、日历都是通过它暴露数据的，第三方应用申请权限之后就能读写。

内容提供者还有个高级用法是在应用内部做数据封装，配合观察者机制实现数据变更通知。不过对于中小型应用，直接操作本地数据库更简单直接，没必要为了架构好看硬上内容提供者。

4.4 组件间通信的三种方式对比

组件之间要传数据，常见的有三种方式，各有适用场景：

新手阶段基本只用第一种，跳转页面的时候带上参数就行。随着应用变复杂，第二种会成为主流，这时候就需要引入统一的数据层，避免每个页面各自维护一份状态导致数据不一致。第三种一般在中大型项目或者对接独立模块时才会用到，入门阶段了解概念即可。

5. 常见问题与排查技巧实录

5.1 构建失败速查表

构建阶段的问题占了新手提问的一大半，我整理了一张速查表，按出现频率排序：

这张表覆盖不了所有情况，但能解决八成常见问题。排查的核心思路是：先看完整报错信息的第一行和最后一行，第一行通常是错误类型，最后一行通常指向具体文件。中间的堆栈大多是调用链路，新手容易在这里迷失。

还有个小技巧：构建失败的时候，先执行一次清理任务再重新构建。很多莫名其妙的构建错误，清掉缓存重来就好了。如果还不行，检查是不是开了什么实验性配置，关掉再试。

5.2 运行时崩溃定位四步法

崩溃比构建失败更让人头疼，因为它不是每次都复现。我自己的定位流程固定为四步。

第一步，看崩溃日志的类型和首行。类型决定了排查方向：空指针就看哪个对象没初始化，类型转换异常就看强转的位置，主线程耗时就看哪里做了同步网络或数据库操作，资源找不到就看布局或图片名字是不是写错了。

第二步，看堆栈里第一个属于你自己代码的帧。系统框架的帧可以略过，直接找你项目包名下的那一行。绝大多数崩溃的根因都在那一行附近。

第三步，复现。不能稳定复现的崩溃，先想办法构造复现路径：是特定机型、特定系统版本、特定操作顺序，还是特定网络状态。复现路径确定了，问题基本就解了一半。

第四步，加日志验证。在可疑位置打日志，跑一遍，看执行到哪一步断了。日志要带上下文信息，比如当前页面名、关键变量的值、用户的操作路径。

注意：线上崩溃不能只靠用户描述，必须接入崩溃收集机制，把堆栈、设备信息、系统版本、应用版本都上报上来。没有这些信息，排查就是盲猜。

5.3 适配与性能问题：真正耗时间的地方

功能写完只是开始，适配和性能才是真正吃时间的地方。这里说三个最容易出问题的方向。

屏幕适配。安卓设备的屏幕尺寸和密度跨度极大，从几英寸到十几英寸都有。布局里要尽量用密度无关单位和相对尺寸，避免写死像素值。换算关系是这样的：密度无关单位 = 像素值 ÷（屏幕密度 ÷ 160）。举个例子，屏幕密度是 480，那么 1 个密度无关单位等于 3 个像素。知道这个换算，你就能明白为什么在高密度屏幕上写死 100 像素会显得特别小。

深色模式适配。新版系统普遍支持深色模式，如果应用不做适配，用户在深色模式下打开就是一片刺眼的白。正确做法是把颜色定义抽到资源文件里，为深色模式准备一套独立的值文件，系统会自动切换。不要在代码里写死颜色值，这是最常见的适配遗漏。

列表性能。列表几乎是每个应用都有的组件，也是最容易卡的地方。核心原则只有一条：复用条目视图，不要在滚动过程中创建新视图。另外，条目里的图片要按需加载并缓存，不要在绑定数据时同步解码大图。我见过一个列表，每滑动一屏就卡一下，最后发现是每次绑定都在主线程解码图片，改成异步加载加缓存之后立刻顺滑。

5.4 我个人踩过的坑和固化下来的习惯

最后分享几个我自己踩过、后来固化成习惯的点，都是文档里不太会写的。

第一，永远不要相信"这个页面不会被销毁"。只要用户能切走，页面就可能被回收。所以数据要么及时持久化，要么能通过状态包恢复。这个习惯建立之后，偶现的数据丢失问题基本绝迹。

第二，主线程只做界面相关的事。任何可能超过十几毫秒的操作，全部挪到工作线程。判断标准很简单：涉及磁盘、网络、大量计算、跨进程调用，一律异步。

第三，权限要按使用时机申请，不要一启动就全要一遍。用户打开应用还没看到界面就被一堆权限弹窗糊脸，体验极差，而且拒绝率很高。正确的做法是在真正需要某个权限的功能入口处申请，并解释为什么需要。

第四，崩溃收集和日志从第一天就要接入。不要想着"等功能稳定了再加"，线上问题的黄金排查期就那么短，没有日志什么都做不了。

第五，多设备验证。至少准备一台低端机、一台高端机、一台平板（如果支持）。很多问题只在特定设备上出现，模拟器测不出来。

第六，依赖库要克制。每引入一个库，就多一份体积、一份兼容风险、一份升级负担。引入之前先问：这个功能自己写要多久？如果只是一两个简单功能，自己写往往比引入一个重型库更划算。

安卓开发这条路，入门门槛其实不高，跑通第一个工程可能一个下午就够了。但从"能跑"到"跑得稳"，中间隔着的是对架构分层的理解、对生命周期的敬畏、对设备差异的耐心。我自己前两年写的代码，现在回头看几乎每一页都有能改的地方，这不是坏事，说明认知在往前走。真正让我进步最快的，不是看了多少教程，而是每次崩溃之后老老实实把根因挖到底，然后把结论记下来。这个习惯坚持下来，同样的坑基本不会踩第二次。