1. 学Android之前先把这张地图装进脑子很多人一上来就撸代码跟着教程建了个Hello World跑通了就觉得自己会Android了。结果一到面试或者真正做项目被问得一脸懵四大组件怎么通信的Binder又是什么玩意为什么权限要这样写这些问题的根源在于你对Android整个系统的架构缺一张“全图”。我当时拿着《第一行代码》啃的时候第一遍光顾着敲代码第二遍才认真把架构部分读透。读完之后再回头看Activity、Service、ContentProvider这些内容感觉像是开了天眼——原来每个组件的设计逻辑都是建立在系统架构之上“顺理成章”的产物。1.1 四层架构对新手意味着什么Android系统按官方划分是四层Linux内核层、系统运行库层、应用框架层、应用层。我当时用了一个特别土但特别贴切的比喻Linux内核是“地基和水电”系统运行库是“毛坯房里的基础设施”应用框架层是“精装修交付的标准”应用层就是“你自己往房子里添置的家具”。为什么这个东西重要因为你在日常开发中遇到的80%问题本质上都是“家具和标准接口没对齐”的问题。比如你在子线程里更新UI崩溃提示CalledFromWrongThreadException这就是因为你试图绕过应用框架层的消息机制直接去操作界面。理解了它是基于Handler这个“传送带”设计的你就不会犯这种低级错误。应用框架层尤其值得多花时间。Context、Activity、Service、BroadcastReceiver、ContentProvider这些东西全部由ActivityThread和AMSActivityManagerService、WMSWindowManagerService这些系统服务在背后调度。说白了你这边的代码只是“提交申请”真正的“审批和调度”全都发生在系统服务那边。1.2 架构思维如何贯穿四大组件有了架构思维你会自然而然地提出一系列“为什么”为什么Activity要配一个任务栈为什么Service的优先级比Activity低还得靠前台服务拉高为什么ContentProvider天生就能跨进程这些都和它们各自在架构中的定位有关。比如四大组件中Activity负责界面交互Service负责后台执行BroadcastReceiver负责全局通知ContentProvider负责数据共享。它们的共同点是都通过Intent来进Activity和Service、Receiver都是都必须在AndroidManifest里注册BroadcastReceiver可以动态注册ContentProvider不需要手动注册但需要在manifest里声明。这些“套路”背后的统一逻辑是组件由系统统一创建和管理你的代码只是回调。所以我的建议是不要急着背四大组件的生命周期表格。先花半天时间把Android的四层架构和Binder跨进程通信的用户态/内核态模型搞明白再回头看生命周期你会发现自己根本不需要死记硬背很多行为都能推导出来。2. 四大组件Android应用的四个发动机四大组件是Android应用的骨架绕不开躲不掉。我说句实在话很多人学了半年Android四大组件每个都能叫上名字但你让他说说它们之间怎么联动、各自的使用场景是什么、生命周期里哪些坑不能踩他立马卡壳。这一章我不打算照着书念而是讲些实际开发里真正用得上的理解和判断。2.1 Activity应用的“门面”也是任务栈的核心Activity可以理解成一个“带生命周期管理的界面容器”。它和前端页面的最大区别是它的生命周期不只由你自己控制系统在内存紧张、屏幕旋转、应用切后台的情况下会随时销毁或重建它。生命周期我记得最扎实的方式是把它分成三对看onCreate/onDestroy是出生与死亡onStart/onStop是可见与不可见onResume/onPause是可交互与不可交互。实际开发中最容易出问题的是onSaveInstanceState和onRestoreInstanceState这套状态保存机制。旋转屏幕的时候Activity会被销毁重建如果你在onCreate里加载了一个特别耗时的数据旋转一次就重新加载一次能卡到怀疑人生。解决方案有两个简单粗暴的是在AndroidManifest里给Activity配configChangesorientation|screenSize让旋转时不重建正路则是用ViewModel配合状态保存把数据从Activity的“一次性生命周期”里拿出来。还有启动模式也值得多说一句。standard、singleTop、singleTask、singleInstance这四种模式面试必问开发也常用。最容易被忽略的是singleTask搭配taskAffinity的使用方式很多第三方SDK的主界面就是这样处理栈问题的。你在项目里见到某个Activity在最近任务列表里单独显示为一个任务那就是taskAffinity和singleTask的功劳。2.2 Service干后台活的老黄牛Service这名字起得很有迷惑性很多人以为它就是“后台线程”实际上Service默认运行在UI线程。你要是在Service里直接做耗时操作照样ANR给你看。Service分两种启动式startService和绑定式bindService。启动式一开就自己在后台跑调用方不管它绑定式则像“接口连接”Activity和Service之间可以互相调用方法Service的生命周期还跟着绑定方走。实际项目里音乐播放这种持续后台任务用启动式而像和某个硬件设备通信这种需要交互的用绑定式更合适。还有个大坑8.0之后你不能再像以前那样随心所欲地在后台启动Service了。后台执行限制一开你在后台调用startService会直接抛IllegalStateException。解决办法是改用startForegroundService加startForeground让服务以“前台服务”的身份运行同时必须给用户一个可见的通知。到了Android 14上前台服务又细分了数据类型比如媒体播放、定位、通话等你必须在manifest里声明对应的foregroundServiceType。2.3 BroadcastReceiver系统广播的“大喇叭”BroadcastReceiver是四大组件里最“轻量”的它的生命周期极其短暂onReceive执行完就结束了所以你千万不能在onReceive里做异步操作比如开个线程去处理数据然后返回——大概率进程直接被系统杀掉。动态注册和静态注册的区别现在依然是高频考点。静态注册就是在manifest里声明App没启动也能收到广播动态注册在代码里registerReceiver必须等App运行起来才有效。8.0之后绝大多数隐式广播都不允许静态注册了官方理由是为了省电和限制后台行为。所以你看到的很多老项目里静态注册的Receiver一个个被改成动态注册或者JobScheduler。实际开发中我通常只在需要监听系统级事件时才用BroadcastReceiver比如开机启动、网络变化、屏幕解锁这些。App内部的数据通信用EventBus或者LiveData都比广播高效得多。2.4 ContentProvider跨应用数据交换的“正规军”ContentProvider是四大组件里存在感最低的但它的地位极其重要。它是Android官方钦定的跨进程数据共享方案底层基于Binder实现本身就带权限控制。联系人、短信、相册这些系统数据都是通过ContentProvider暴露给上层App的。用ContentProvider写代码其实不难继承ContentProvider实现onCreate、query、insert、update、delete、getType这几个方法然后在manifest里注册即可。难的是理解它的定位它把“数据访问”和“数据存储”彻底解耦了。外部调用方只需要知道Content URI不需要关心数据存在数据库、文件还是网络。这一点在组件化开发中特别好用。以前多模块之间共享数据动不动就写一堆单例或者静态变量越写越乱。后来我直接抽一个独立的Provider模块数据访问统一走ContentProvider接口跨进程也好、跨模块也好一个URI全搞定。我把四大组件的核心差异整理成一个表方便你查阅组件核心职责启动方式是否必须有界面典型场景Activity界面展示与交互startActivity(Intent)是登录页、详情页Service后台长时间执行startService / bindService否音乐播放、文件下载BroadcastReceiver接收广播事件sendBroadcast后系统回调否网络变化监听、开机自启ContentProvider跨进程共享数据ContentResolver访问否联系人读取、模块间数据共享3. 权限管理别让App一上来就“越界”权限这个东西新手阶段是最容易忽略的。早期Android版本确实简单在manifest里写上权限安装时一次性授权就完事了。但Android 6.0之后危险权限必须在运行时动态请求这一下子就让很多人“水土不服”。3.1 普通权限与危险权限的区别系统把权限分成了普通权限和危险权限两大类。普通权限比如INTERNET、ACCESS_NETWORK_STATE在manifest里声明后自动授予用户无感知。危险权限则涉及用户隐私比如读取联系人、获取定位、读写存储、读取通话记录这些必须在运行时弹窗询问用户。危险权限又按“权限组”来管理。这里有个非常容易踩坑的点系统在授权时是按组来的只要你同意了一个组里的任意一个权限同组的其他权限也会被一并授权。比如你申请了CAMERA用户同意后RECORD_AUDIO如果和它在同一组就会被一起授予。但国内很多ROM对权限组有魔改所以我从来不敢假设“同组权限一定已授权”每次用到前都老老实实检查一遍。3.2 运行时权限的完整处理流程一套标准的运行时权限流程是这样的我已经在项目里固化成了模板先用ContextCompat.checkSelfPermission检查是否已授权。如果没授权调用ActivityCompat.requestPermissions申请。在onRequestPermissionsResult回调里判断结果。如果用户拒绝过且调用了shouldShowRequestPermissionRationale说明用户之前点过“不再询问”这时候需要引导用户去系统设置页手动打开。代码写起来不复杂但校验时机要把握好。我见过太多人只在启动页申请一次权限结果用户从设置页关闭权限回来后App直接崩溃。正确的思路是在使用功能前实时检查权限不能靠“一次性申请终身有效”。下面是一个标准的权限申请片段可以参考一下private fun checkAndRequestPermission() { val permission android.Manifest.permission.CAMERA if (ContextCompat.checkSelfPermission(this, permission) PackageManager.PERMISSION_DENIED) { if (ActivityCompat.shouldShowRequestPermissionRationale(this, permission)) { showSettingsDialog() } else { ActivityCompat.requestPermissions(this, arrayOf(permission), REQUEST_CODE_CAMERA) } } else { openCamera() } } override fun onRequestPermissionsResult(requestCode: Int, permissions: Arrayout String, grantResults: IntArray) { super.onRequestPermissionsResult(requestCode, permissions, grantResults) if (requestCode REQUEST_CODE_CAMERA) { if (grantResults.isNotEmpty() grantResults[0] PackageManager.PERMISSION_GRANTED) { openCamera() } else { showTips(没有相机权限请到设置页手动开启) } } }3.3 权限被拒绝的兜底方案权限被拒、甚至被勾选“不再询问”之后App拿不到权限功能肯定跑不起来。这时候最稳妥的做法就是跳系统设置页让用户自己去手动开。跳转代码也简单val intent Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS) intent.data Uri.parse(package: packageName) startActivity(intent)说句心里话权限设计这部分最能体现一个开发者有没有“用户思维”。好的App在权限被拒时会清楚告诉用户“哪个功能需要什么权限、为什么需要、不开会有什么影响”而不是一句冷冰冰的“权限被拒绝”。还有Android 13之后的通知权限也要单独申请属于POST_NOTIFICATIONS运行时权限。很多人老项目的通知发不出来多半就是没适配这个后面讲通知的时候再细说。4. 数据持久化把用户的数据稳稳存住持久化是开发绕不开的需求。用户的设置项、登录状态、聊天记录、收藏列表总得有个地方存。Android提供了好几套方案很多新手容易一上来就上数据库其实很多场景用SharedPreferences就够了工具选型这件事早期想清楚能省不少事。4.1 SharedPreferences适合什么场景SharedPreferences本质就是一个XML文件以键值对形式存储底层实现是写入一个xml再读入内存。它适合存轻量级的数据比如用户的登录态、开关选项、亮度调节等。不适合存复杂结构数据或者大文本。这里要提一个老生常谈的坑不要在SharedPreferences里存大量数据。它每次提交的时候要么全量提交commit同步阻塞返回boolean要么异步提交apply异步写入无返回值但时序不能保证。我见过有人在里面存了几百KB的JSON结果每次读取都卡顿还不好排查。从Android 7.0开始系统推荐用精简版的SharedPreferences实现但底层逻辑没变。如果你在组件化项目里使用记得给每个模块分配不同的文件名避免key互相污染。我还习惯封装一个统一的Key类把所有的键集中管理不然半年后你看到各种sp_key_xxx根本不知道哪个对应哪个。4.2 SQLite和Room结构化数据的正解数据量一大、关系一复杂SharedPreferences就不行了。SQLite是Android内置的关系型数据库原生的SQLiteOpenHelper写起来很麻烦你得手动写SQL语句、维护游标、关闭连接一不小心就出内存泄漏或者SQL语法错误。所以后来我果断换成了Room。Room是官方在SQLite之上封装的ORM框架注解驱动的写法非常清爽。比如你要建一张用户表Entity(tableName user) data class User( PrimaryKey(autoGenerate true) val id: Long 0, ColumnInfo(name name) val name: String, ColumnInfo(name age) val age: Int ) Dao interface UserDao { Insert suspend fun insert(user: User) Query(SELECT * FROM user WHERE id :id) suspend fun getUserById(id: Long): User? } Database(entities [User::class], version 1) abstract class AppDatabase : RoomDatabase() { abstract fun userDao(): UserDao }Room最大的优势是在编译期就帮你校验SQL语句和实体类字段写错了直接编译报错而不是运行到一半才崩溃。再配合协程数据库操作的线程切换也省心直接在suspend函数里操作就行。说几个Room的实际技巧数据库版本升级时一定要写Migration不能图省事直接fallbackToDestructiveMigration否则用户一升级App数据全没了这种线上事故我见过不止一次。还有Room默认不让在主线程操作数据库除非你显式允许这个设计实际上是在保护你的界面流畅性。4.3 文件存储不要忽略这个最原始的手段有时候存个图片、PDF、日志直接写文件比存数据库更合适。Android的文件存储分为内部存储和外部存储。内部存储通过getFilesDir()获取每个应用一个专属目录别的App访问不了外部存储通常是公共存储区比如DCIM、Downloads需要处理存储权限和分区存储的适配问题。分区存储是Android 10开始强推的核心思想是App只能直接访问自己专属目录下的文件以及通过MediaStore访问公共媒体文件。想直接访问任意路径不行你得用SAFStorage Access Framework让用户通过系统文件选择器来授权。这一块儿的适配坑特别多。我印象最深的是有段时间很多App用以前的File路径方式访问公共存储结果在Android 10以上直接FileNotFoundException排查了半天才发现是分区存储导致的路径限制。所以新项目里我基本都是用MediaStore写入媒体文件或者用SAF获取Uri后通过ContentResolver读写。关于SharedPreferences、Room、文件存储怎么选我总结出了这么个原则轻量级配置用SharedPreferences关系型结构化数据用Room大文件、图片、日志用文件存储。想清楚这三条99%的场景都不纠结。5. 通知机制把消息送到用户眼前通知是App触达用户的一个重要方式。但从开发者角度说通知的适配简直是一个大坑连着另一个大坑。从8.0的通知渠道到13.0的运行时通知权限中间还夹杂着各种ROM对通知显示策略的魔改。5.1 NotificationChannel8.0之后必须先建渠道Android 8.0引入了通知渠道NotificationChannel强制要求所有通知必须先归属到某个渠道。这个渠道一旦创建用户就可以在系统设置里单独控制每个渠道的通知是否显示、是否响铃、是否震动。所以你在代码里发通知之前必须先创建渠道if (Build.VERSION.SDK_INT Build.VERSION_CODES.O) { val channel NotificationChannel( CHANNEL_ID, 订单消息, NotificationManager.IMPORTANCE_HIGH ) channel.description 订单状态变更提醒 notificationManager.createNotificationChannel(channel) }渠道的重要性级别直接决定通知的打扰程度IMPORTANCE_HIGH会响铃加横幅IMPORTANCE_LOW只在通知栏安静显示IMPORTANCE_NONE就直接不显示了。这里有个容易被坑的点渠道一旦创建重要性级别就不能再改用户自己可以在设置里调但你的代码改不了。所以创建渠道时要想清楚这个渠道的定位。5.2 通知的基本用法和PendingIntent的关键点发一条通知的核心步骤构建NotificationCompat.Builder设置小图标、标题、内容、优先级然后加上点击后的跳转意图。跳转就涉及PendingIntent这个东西可以理解为“包装了一份Intent但由系统代你在未来某个时刻发送”。这里有三种类型getActivity点击打开界面、getBroadcast触发广播、getService启动服务。很多人刚开始搞混记住一句话你想让用户点了通知之后干什么就选对应的那个。PendingIntent还有一个容易被忽略的flag问题。Android 12开始强制要求声明可变性也就是setFlag(FLAG_IMMUTABLE或FLAG_UPDATE_CURRENT)。FLAG_IMMUTABLE表示PendingIntent创建后不可被修改安全系数高一般通知跳转用这个就行。FLAG_UPDATE_CURRENT则允许更新当前已有的PendingIntent的附加数据。如果你遇到通知点击后拿到的extra还是旧的多半就是flag没配对。Android 13的通知权限适配也别忘。如果你的targetSdkVersion升到33以上必须在运行时申请POST_NOTIFICATIONS权限否则通知直接不显示连渠道都不会建。这条很多人踩坑以为是通知代码写错了其实只是忘了权限。6. 异步别在主线程里做“重活”Android的异步问题每个开发者都会遇到。它的本质很清晰主线程负责UI绘制和事件分发一旦阻塞超过5秒就会ANR。所以耗时操作必须挪到子线程执行完再回到主线程更新UI。6.1 为什么必须在子线程干活很多人刚学的时候不理解为什么System.out.println在主线程里没事在子线程里更新TextView就崩溃因为Android的UI框架不是线程安全的如果允许多个线程同时改UI状态会乱成一锅粥。所以官方做了一个规定只有主线程可以更新UI。这个规定本身不复杂麻烦的是“执行完回到主线程”这一步。一开始你用Handler.post(Runnable)回到主线程写多了又烦又乱后来用AsyncTask但它在API 30被正式废弃了再后来用线程池加回调代码量也不小。直到Kotlin协程普及异步代码才算有了一个优雅的解决方案。6.2 Handler消息机制的原理要理解Android异步绕不开Handler、Looper、MessageQueue这三兄弟。一个新线程默认是没有Looper的只有主线程在启动时就调用了Looper.prepare和Looper.loop所以主线程才能不断从消息队列里取出消息、分发给对应的Handler去处理。有个有意思的点是Looper.loop()是一个死循环。那为什么不会卡住主线程因为Android是事件驱动的主线程的“空闲”就是在循环里等待新消息就像外卖骑手没单时在路边等单一样效率很高谈不上卡死。而这个设计也正是子线程不能直接更新UI的原因UI操作本质上是投递一个消息到主线程的MessageQueue由主线程Looper取出来再执行。6.3 从AsyncTask到协程异步方案的演进AsyncTask被废弃是时代必然。它内部用线程池加Handler配合工作看似好用但一旦在异步任务里忘了取消Activity销毁后任务还在跑回来回调时发现组件没了直接崩溃。而且AsyncTask并不能完美处理Activity重建的场景数据还会丢。线程池相对可控一些。Executors类提供了四种常见的线程池实际项目中我推荐用ThreadPoolExecutor手动指定核心线程数、最大线程数和队列类型这样能精确控制资源占用。固定线程池适合短任务多发的场景缓存线程池适合任务不多但持续时间短的情况定时线程池适合轮询类的需求。Kotlin协程是目前最推荐的方案。它本质上还是线程池那一套但通过挂起函数把异步代码写成了顺序执行的样子viewLifecycleOwner.lifecycleScope.launch { val userData withContext(Dispatchers.IO) { repository.fetchUserData() } textView.text userData.name }这段代码不需要自己开线程、不需要回调看起来就像同步代码但它执行时自动切到IO线程执行完自动切回主线程。关键是lifecycleScope还能感知生命周期Activity销毁时自动取消协程天然杜绝了内存泄漏的老问题。给我的建议是新项目里协程是首选但协程底层原理比如Dispatchers的切换机制、结构化并发一定要理解不然遇到并发问题依然手足无措。老项目里线程池继续跑着也别急着重构先把核心链路的BUG修完再逐步迁移。7. 服务Android后台任务的“老爷爷”前面四大组件那节其实提过Service但服务这块内容是面试和开发中的重点值得单独展开。很多业务比如音乐播放、文件下载、数据同步都离不开Service。而且Service和AsyncTask、协程很容易搞混它们都能执行耗时任务但定位完全不同。7.1 启动服务与绑定服务的区别启动服务用startService服务一旦启动就独立于启动者运行即使启动它的Activity销毁了服务还在后台跑。它适合“一次性触发”的后台任务比如上传日志、同步数据。绑定服务用bindService服务和绑定方形成一种“Client-Server”关系。绑定方可以拿到Binder对象直接调用服务里的方法服务生命周期的结束也会跟着绑定方走最后一个绑定方解绑时服务自动销毁。适合音乐播放控制器、蓝牙设备通信这类需要双向交互的场景。实际项目里经常两个一起用。音乐播放器就是典型先startService让它在后台跑起来然后再bindService获取控制接口。这样即使界面关了音乐还在放打开界面时又能拿到播放控制权。7.2 后台限制8.0和12.0以后的两个大坎从Android 8.0开始系统限制后台应用启动服务后台状态下调用startService会崩。解决办法是startForegroundService并且在5秒内调用startForeground把服务提升为前台服务。前台服务必须有一个持续显示的通知用户能看清你在干什么同时这个通知不可以被手动划掉除非服务停止。到了Android 12限制更严格了。后台应用想启动前台服务也受到了限制除非这个App之前已经被用户主动引导到过前台或者满足特定豁免条件。这就意味着很多后台任务不能再用“悄悄开个前台服务”的思路来解决得转向WorkManager这类系统级调度方案。WorkManager是官方推荐的延迟性任务组件它不是一个传统意义上的服务而是基于JobScheduler等底层机制封装的任务调度器能够保证任务在合适的时间执行支持链式任务、周期任务、约束条件比如网络可用时才执行。我现在的做法是需要立即执行且用户感知的任务用前台服务不需要立即执行的任务交给WorkManager省电又省心。8. 实际开发中的高频问题与排查思路最后这块把我在学习《第一行代码》加实际开发过程中遇到的高频问题集中整理一下给你做个速查表遇到别慌按表排查基本都能解决。现象可能原因排查思路通知不显示8.0后未创建渠道13.0后未申请通知权限渠道级别为IMPORTANCE_NONE检查NotificationChannel创建代码检查通知权限是否已授予子线程更新UI崩溃CalledFromWrongThreadException用Handler.post或协程的withContext(Dispatchers.Main)切回主线程后台启动服务抛异常8.0后台执行限制导致IllegalStateException改用startForegroundService并调用startForeground提升为前台服务Activity旋转屏幕后数据丢失未保存实例状态用ViewModel或在onSaveInstanceState里保存状态SQLite操作报sqlite语法错误手写SQL出错或表结构变更换Room编译期自动校验SQLSharedPreferences读取卡顿存入的数据量过大把大JSON或大列表迁移到数据库SP只存轻量键值文件读写报FileNotFoundException分区存储限制直接用绝对路径访问公共目录改用MediaStore或SAF方式读写数据库升级后旧用户崩溃缺Migration数据结构不兼容写Migration完成表结构变更禁止直接删除重建点击通知跳转拿不到extra数据PendingIntent的flag使用不当创建Intent时setFlags(Intent.FLAG_ACTIVITY_NEW_TASK)PendingIntent用FLAG_IMMUTABLE或FLAG_UPDATE_CURRENT再补几个排查思路的细节。权限相关问题第一件事就去设置页看当前权限状态甚至用adb命令pm list permissions查系统里的权限定义能省去很多瞎猜的时间。ANR问题去/data/anr目录下抓trace文件看主线程卡在哪个方法上往往比你想的快得多。通知不显示的问题先用一个最简单的测试通知排除代码问题再逐步加约束条件定位是渠道还是权限的锅。还有个经验想多说一句Android的日志排查不要只盯着Logcat那几行。很多时候崩溃日志里真正的Root Cause在堆栈上方几行或者藏在logcat里其他进程的输出中。你养成一个习惯看到崩溃先看“Caused by”那一行一般那才是真正的根因。比如最常见的SecurityExceptionPermission Denial堆栈可能很长但Caused by后面就是具体哪个权限被拒。再比如WindowLeaked异常经常是从Activity泄漏导致的看堆栈后你会发现其实就是某个Dialog没在Activity销毁前dismiss。写在后面这套基础是Android开发的“内功”说句掏心窝子的话四大组件、权限、持久化、通知、异步、服务这些内容看着基础却是我做了几年Android开发之后觉得含金量最高的东西。项目里那些花里胡哨的新框架、新架构本质都是在这些地基上盖楼。你把这些基础吃透了读源码、上协程、玩Compose都会快很多。我个人实际复习这套知识的时候有个习惯每学完一个模块就在纸上画一张脑图把该模块的核心类、关键方法、生命周期、常见坑位全部手写一遍然后对照书里内容做减法把记忆中模糊的地方重点标注。这个过程看着原始但比翻十遍书有用得多。这套笔记就分享到这儿。如果里面有哪块你还想深挖评论区吱一声我们展开细聊。