安卓概述、架构与开发入门：从四层架构到四大组件实战

安卓这个词现在几乎成了智能手机的代名词但真要坐下来聊安卓概述、安卓架构、安卓开发入门这三件事很多刚入行的朋友还是一头雾水知道它是个手机系统知道能用 Java 或 Kotlin 写 App可一问他系统分成几层、应用启动时到底发生了什么、minSdk和targetSdk为什么要分开设就答不上来了。这篇东西我想从一个实际写过几年应用、也被各种崩溃和适配问题折磨过的人的角度把安卓从是什么到怎么上手这条线完整捋一遍。不管你是完全没接触过移动端、想找个方向切入的新手还是从后端、前端转过来、需要快速补齐安卓基础概念的老手下面这些内容应该都能直接用上。我会把架构分层讲透把环境搭建的每一步踩点写清楚再把四大组件、生命周期、常见崩溃排查这些真正影响开发效率的部分拆开说中间穿插一些只有实际动手才会知道的细节。1. 安卓概述先搞清楚你每天在开发什么1.1 从一部手机开机说起安卓系统到底由哪些东西拼成很多人对安卓的第一印象就是一个能装 App 的系统这个理解不算错但太粗。把它拆开看一部安卓手机开机之后大致会经历这么几个阶段芯片上电引导程序把内核拉起来内核完成硬件初始化和驱动加载然后挂载系统分区启动第一个用户态进程再由它去拉起系统服务最后才是桌面出现、应用可以被点击。这条链路里前面几段跟普通开发者关系不大属于底层和厂商定制的地盘但从系统服务被拉起来往后就全是应用开发者要关心的事了。你写的每一个页面、每一次点击响应本质上都是在跟这些常驻系统服务打交道要显示界面得找窗口管理服务要读通讯录得找内容提供者要弹通知得找通知服务。理解这一点非常重要因为它解释了为什么安卓开发里到处都是拿系统服务的代码也解释了为什么权限、后台限制这类东西会直接掐住应用的脖子。再往上一层看安卓不只是一个操作系统它还是一整套配套的东西一套应用框架接口、一套打包和签名规范、一套应用分发机制、一套设计规范。你在做安卓开发的时候实际面对的从来不是单一系统而是系统 工具链 规范的组合体。新手最容易犯的错就是把注意力全放在写界面代码上忽略了后面这几块结果工程能跑起来却不知道怎么打包、怎么定位线上崩溃、怎么处理不同机型差异。我一般建议刚入门的人先建立一个整体图景哪怕细节暂时不懂。因为安卓的知识点非常碎没有一个骨架去挂学起来就是散沙。而这个骨架就是接下来要讲的四层架构。1.2 一句话概括安卓的四层架构安卓的官方架构描述里从上到下分成四层应用层、应用框架层、系统运行库与运行时、硬件抽象层与内核层。不同版本的文档在细节划分上略有出入但主干一直是这个结构。先用一句大白话概括最上面是你写的 App往下是系统提供的一堆现成服务再往下是让代码能跑起来的运行环境和基础库最底下是跟硬件打交道的内核。这个结构的核心价值在于隔离。上层不需要知道底层怎么实现只要按约定调用就行。比如你要在屏幕上画一个按钮不需要关心这块屏幕是哪个厂商的、分辨率多少、驱动怎么写只要调用框架层的接口剩下的事情由下层处理。这种隔离带来的好处是开发效率代价是你在遇到问题时往往不知道问题出在哪一层只能一层层往上排查。后面讲问题排查的时候我会把这个思路具体化。1.3 版本碎片化是绕不过去的现实聊安卓概述不能不提版本问题。桌面系统大家习惯了三五年换一次大版本安卓这边是每年一个新版本加上厂商定制、机型保留旧系统、用户不愿升级结果就是同一个应用要同时面对跨度好几年的系统版本。这件事对开发者的直接影响体现在三个配置项上minSdk、targetSdk、compileSdk。它们不是随便填的数字每一个都对应实实在在的取舍。配置项含义调高之后的影响调低之后的影响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:androidhttp://schemas.android.com/apk/res/android android:layout_widthmatch_parent android:layout_heightmatch_parent android:orientationvertical android:gravitycenter TextView android:layout_widthwrap_content android:layout_heightwrap_content android:text第一个页面 / /LinearLayoutmatch_parent表示跟父容器一样大wrap_content表示刚好包住内容。这两个值几乎每个布局都会用到理解它们的含义比记住属性名重要得多。gravity控制子元素的对齐方式orientation控制排列方向这几个属性组合起来就能实现大部分基础布局。点击运行之后模拟器上出现文字第一个工程就算跑通了。这一步看起来简单但它是后面所有工作的基础。环境跑不通后面全是空谈。提示第一次运行如果卡在下载依赖或者同步构建配置很久不动先检查网络再检查仓库地址配置。绝大多数首次构建失败都是网络问题不是代码问题。4. 安卓开发核心四大组件与生命周期4.1 页面组件生命周期是全流程的基础页面组件是用户能看见的部分也是开发者打交道最多的组件。它的生命周期回调有好几个但真正需要重点理解的是下面这一组回调触发时机在这里该做什么onCreate页面第一次创建初始化界面、绑定数据、注册监听onStart页面即将可见开始轻量级的状态刷新onResume页面获得焦点可交互启动动画、恢复传感器、刷新实时数据onPause页面失去焦点但仍部分可见暂停动画、保存临时状态、释放独占资源onStop页面完全不可见停止耗时任务、注销广播、释放较重资源onDestroy页面被销毁最终清理取消所有未完成的任务这张表的关键不在于记住名字而在于理解页面不是一直活着的。用户切到别的应用、接个电话、旋转屏幕、切换深色模式页面都可能经历暂停、停止甚至销毁重建。这里有个真实案例。早期我写过一个表单页面用户在输入框里填了一半切出去查了个资料回来输入内容全没了。原因就是页面被系统回收又重建而我没有把输入状态保存下来。修复方式是在合适的回调里把数据写进状态包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 构建失败速查表构建阶段的问题占了新手提问的一大半我整理了一张速查表按出现频率排序现象大概率原因处理方向同步配置卡住或超时仓库地址不可达、网络不稳检查仓库配置换用可访问的镜像源提示找不到某个依赖仓库没配全、版本号写错核对依赖坐标确认仓库包含该组件编译报接口不存在compileSdk太低提高编译版本或降级依赖库版本提示版本不兼容构建工具与开发环境版本不匹配对齐两者版本必要时升级环境方法数超限依赖过多超出单个 dex 上限开启分包清理无用依赖签名校验失败签名配置与已安装版本冲突卸载重装或统一签名配置资源文件报错文件名含大写字母或非法字符改成小写字母加下划线这张表覆盖不了所有情况但能解决八成常见问题。排查的核心思路是先看完整报错信息的第一行和最后一行第一行通常是错误类型最后一行通常指向具体文件。中间的堆栈大多是调用链路新手容易在这里迷失。还有个小技巧构建失败的时候先执行一次清理任务再重新构建。很多莫名其妙的构建错误清掉缓存重来就好了。如果还不行检查是不是开了什么实验性配置关掉再试。5.2 运行时崩溃定位四步法崩溃比构建失败更让人头疼因为它不是每次都复现。我自己的定位流程固定为四步。第一步看崩溃日志的类型和首行。类型决定了排查方向空指针就看哪个对象没初始化类型转换异常就看强转的位置主线程耗时就看哪里做了同步网络或数据库操作资源找不到就看布局或图片名字是不是写错了。第二步看堆栈里第一个属于你自己代码的帧。系统框架的帧可以略过直接找你项目包名下的那一行。绝大多数崩溃的根因都在那一行附近。第三步复现。不能稳定复现的崩溃先想办法构造复现路径是特定机型、特定系统版本、特定操作顺序还是特定网络状态。复现路径确定了问题基本就解了一半。第四步加日志验证。在可疑位置打日志跑一遍看执行到哪一步断了。日志要带上下文信息比如当前页面名、关键变量的值、用户的操作路径。注意线上崩溃不能只靠用户描述必须接入崩溃收集机制把堆栈、设备信息、系统版本、应用版本都上报上来。没有这些信息排查就是盲猜。5.3 适配与性能问题真正耗时间的地方功能写完只是开始适配和性能才是真正吃时间的地方。这里说三个最容易出问题的方向。屏幕适配。安卓设备的屏幕尺寸和密度跨度极大从几英寸到十几英寸都有。布局里要尽量用密度无关单位和相对尺寸避免写死像素值。换算关系是这样的密度无关单位 像素值 ÷屏幕密度 ÷ 160。举个例子屏幕密度是 480那么 1 个密度无关单位等于 3 个像素。知道这个换算你就能明白为什么在高密度屏幕上写死 100 像素会显得特别小。深色模式适配。新版系统普遍支持深色模式如果应用不做适配用户在深色模式下打开就是一片刺眼的白。正确做法是把颜色定义抽到资源文件里为深色模式准备一套独立的值文件系统会自动切换。不要在代码里写死颜色值这是最常见的适配遗漏。列表性能。列表几乎是每个应用都有的组件也是最容易卡的地方。核心原则只有一条复用条目视图不要在滚动过程中创建新视图。另外条目里的图片要按需加载并缓存不要在绑定数据时同步解码大图。我见过一个列表每滑动一屏就卡一下最后发现是每次绑定都在主线程解码图片改成异步加载加缓存之后立刻顺滑。5.4 我个人踩过的坑和固化下来的习惯最后分享几个我自己踩过、后来固化成习惯的点都是文档里不太会写的。第一永远不要相信这个页面不会被销毁。只要用户能切走页面就可能被回收。所以数据要么及时持久化要么能通过状态包恢复。这个习惯建立之后偶现的数据丢失问题基本绝迹。第二主线程只做界面相关的事。任何可能超过十几毫秒的操作全部挪到工作线程。判断标准很简单涉及磁盘、网络、大量计算、跨进程调用一律异步。第三权限要按使用时机申请不要一启动就全要一遍。用户打开应用还没看到界面就被一堆权限弹窗糊脸体验极差而且拒绝率很高。正确的做法是在真正需要某个权限的功能入口处申请并解释为什么需要。第四崩溃收集和日志从第一天就要接入。不要想着等功能稳定了再加线上问题的黄金排查期就那么短没有日志什么都做不了。第五多设备验证。至少准备一台低端机、一台高端机、一台平板如果支持。很多问题只在特定设备上出现模拟器测不出来。第六依赖库要克制。每引入一个库就多一份体积、一份兼容风险、一份升级负担。引入之前先问这个功能自己写要多久如果只是一两个简单功能自己写往往比引入一个重型库更划算。安卓开发这条路入门门槛其实不高跑通第一个工程可能一个下午就够了。但从能跑到跑得稳中间隔着的是对架构分层的理解、对生命周期的敬畏、对设备差异的耐心。我自己前两年写的代码现在回头看几乎每一页都有能改的地方这不是坏事说明认知在往前走。真正让我进步最快的不是看了多少教程而是每次崩溃之后老老实实把根因挖到底然后把结论记下来。这个习惯坚持下来同样的坑基本不会踩第二次。