斗破第6境：Android进阶实战中的Session与内存优化

1. 第6境的“化翼藏忆”到底是什么1.1 一套开发者的另类修炼地图这个系列已经写到第6境了。当初把这套Java与Android进阶内容冠上“斗破”系的名字我自己也没想到能坚持写这么久。前5境分别拆解了基础框架、异步与并发、网络与数据解析、UI渲染与事件分发、组件化与模块解耦每一境都有一个听起来玄乎、实际却很接地气的编码主题。到了这一境标题是“化翼藏忆”拆开看就是两个词化翼对应Session藏忆对应Memory。说白了这一境要修炼的是两个常常被当成“常识”却又很容易翻车的能力会话状态管理以及内存使用意识。为什么把Session和Memory放在同一个境界因为它们本质上是一体两面。Session管的是App与服务器之间的“记忆身份”Memory管的是App运行时的“记忆容量”。一个是逻辑上的记忆一个是物理上的记忆。两者都不可见出了问题却都是“灵异事件”级别用户明明登录着突然被踢下线页面一切正常滑动几下就卡死闪退。这类问题往往不是某个功能写得不对而是状态管理混乱、内存被无意识地挥霍掉。这一境的受众我默认是已经能独立完成中小型App开发、想往中高级方向走的开发者。如果你刚接触Java与Android同样可以看但建议先把Handler、四大组件、RecyclerView这些基础打牢再回头读。文中的代码示例都是围绕一个模拟项目X来写的也就是某跨平台系统的阅读类客户端Session和内存的常见坑在这个项目里基本都踩过一遍。1.2 标题里的隐喻与技术映射我第一眼看到“化翼藏忆”这四个字脑子里冒出来的就是一句话会话如翼可飞不可落内存如忆可藏不可贪。听起来很玄其实翻译成工程语言就是两句话——登录态必须能跨界面、跨进程、甚至跨冷启动地“飞”但又不能变成一堆没人清理的过期数据堆积在后端与本地内存必须能缓存复用但又不能无限加载、无限持有、无限分配否则再大的堆也顶不住。Session的“化翼”体现在三个层次跨页面的状态传递、跨进程的状态同步、跨时间的状态续期。很多项目只做了第一层用全局变量或者单例把Token一存就完事结果进程被系统回收后再打开App就要重新登录或者服务端扩容后发现会话漂移用户在A节点登录、请求却被负载均衡转发到了B节点直接变成匿名用户。Memory的“藏忆”也分三层对象存活的合理周期、缓存淘汰的策略、以及不可见对象能否被及时回收。很多人对内存的理解停留在“少new对象”这个层面实际上现代Android开发里真正压垮内存的是Bitmap、消息队列积压、隐式持有Activity的静态引用还有底层图片解码时Native层那块不可见的开销。这几块内容都会在本境后面逐一拆开讲。2. Session实战把“登录态”当成一道可控的契约来设计2.1 先搞清楚场景移动端的Session与传统服务端Session差在哪传统Java Web开发里Session指的是服务端保存的会话数据配上Cookie ID用来识别同一用户。这个模型在浏览器里跑得很好因为浏览器会自动管理Cookie请求会自动携带服务端按Session ID一查就知道是谁。但移动端的Session不是这么玩的。在Android客户端我们说的Session更多时候指的是“登录凭证的本地管理方案”。服务端给你返回一个Token你把它存在本地每次请求时放进请求头。这个Token的生命周期、存储位置、刷新策略、多端互斥逻辑完全由客户端和服务端约定来设计。也就是说Android开发者不能只是“拿来就用”而是要亲手设计一套会话管理机制。我见过不少项目在Session上的演进路径最初都差不多一个静态变量存Token加一个SP存用户ID登录成功后写入退出时清空。这种方案在小规模内测时一点问题没有一旦用户量上来、功能变复杂问题会成串出现。比如服务端要求AccessToken每两小时过期一次同时提供一个RefreshToken用来续期。这时候如果客户端没有统一处理续期逻辑就会出现凌晨用户打开App所有接口全部401用户只能被强行踢回登录页。2.2 会话本地持久化SharedPreferences、DataStore与MMKV怎么选先提一个基本共识Token必须持久化。也就是说进程死亡、手机重启之后本地还能读出一条完整的会话记录。在Android生态里最常用的本地KV存储有三条路SharedPreferences、Jetpack DataStore、腾讯的MMKV还有一条更“重”的路就是把会话塞进SQLite或者Room通常只有需要查询历史会话列表的时候才值得。三条路的取舍我直接按项目阶段给结论。如果你在写一个1.0版本、追求最小实现SharedPreferences足够因为它的API极简、不需要引入第三方依赖。但要注意两点apply是异步落盘commit是同步落盘如果紧接着要保证写入完成并读取commit反而更稳妥读写SP实际上会先全量加载整个XML文件到内存所以不要把大对象塞进去会话记录这种小结构没问题。DataStore是官方推荐方向基于Flow做异步读写天然避免在主线程做IO。它最大的好处是协程友好符合新项目技术栈的审美但引入DataStore通常意味着整个项目已经切到协程体系如果是老项目迁移成本不小。MMKV则是基于mmap的存储方案写入速度快、支持多进程读写、也不需要额外初始化到协程环境。它尤其适合微信这类“不能卡主线程”的场景但想用的话需要评估团队是否愿意引入这个依赖。我不建议根据“哪个新就选哪个”来拍板。给模拟项目X选型时最后用了MMKV原因是项目里有一个IPC场景需要多进程会话同步SP在多进程下会有缓存不一致的坑DataStore默认也不支持多进程只有MMKV天生就考虑了这个问题。这里多一句嘴如果项目没有多进程需求真正稳妥的首选还是DataStore理由只有一个——官方维护、生命周期清晰、未来不会突然断更。2.3 会话模型设计别把Token当成一个字符串大多数项目里Token确实就是一个字符串但在工程层面正确的做法是把整条会话记录建模成一个不可变数据对象统一收口在一处管理。可以把Model抽象成下面这个样式public class SessionRecord { public final String userId; public final String accessToken; public final String refreshToken; public final long issuedAt; public final long expiresIn; public final long lastAccessAt; public SessionRecord(String userId, String accessToken, String refreshToken, long issuedAt, long expiresIn, long lastAccessAt) { this.userId userId; this.accessToken accessToken; this.refreshToken refreshToken; this.issuedAt issuedAt; this.expiresIn expiresIn; this.lastAccessAt lastAccessAt; } }为什么字段要这么齐全因为如果只存一个Token服务端无法告知客户端“这个Token还有多久失效”客户端就只能在每次请求失败后猜测原因这在跨时区、弱网络环境下非常痛苦。issuedAt加expiresIn可以计算出绝对过期时间lastAccessAt用来实现“滑动过期”策略。简单说就是用户只要在持续使用会话就自动延长如果超过N天完全没打开App会话强制作废。这种设计对安全性和体验的平衡最友好。围绕SessionRecord要提供一个统一的管理器内部保证读写原子性。最简化版本可以长这样public class SessionManager { private volatile SessionRecord current; private final Storage storage; public SessionManager(Storage storage) { this.storage storage; this.current storage.read(); } public synchronized void update(SessionRecord record) { this.current record; storage.write(record); } public synchronized void clear() { this.current null; storage.clear(); } }有同学可能问用volatile加synchronized会不会太重实际不会会话操作的频次很低登录、刷新、退出一天到头也调不了几次。关键点反而是“所有读写都走这个管理器”项目里最容易出问题的场景是有些人直接从SP读有些人从内存读两条路径各存一份数据改一处漏一处。2.4 Session过期、续期与多端互踢的落地细节会话生命周期里最容易翻车的是三个点过期判定、续期触发时机、多端互斥。过期判定不要在每次请求成功之后才判断而是要在发起请求之前判断一次。比如封装网络层时在统一拦截器里先检查本地SessionRecord是否已过期。如果距离issuedAt加expiresIn还有一段时间正常放行如果已过期但refreshToken还有效自动去请求新的Token拿到后更新本地会话再重放原请求如果refreshToken也无了才走重新登录流程。这套逻辑在OkHttp的Interceptor里很好写核心代码量不大但能避免所有业务层到处写401判断。续期触发时机有一个容易被忽略的点不要只在收到401时才去刷新。因为有些服务端对Token过期是“静默处理”的比如你拿着过期Token请求它返回的数据还是200只是结果可能是空列表或者一个被截断的内容。等发现问题时用户已经在看残缺数据了。所以可以在启动时做一次“预刷新”也就是如果会话距离过期时间只剩10%的窗口期就先主动续期把远端过期时间延长。听起来多发了几个请求实际上换来的是接口数据的稳定性和用户无感知的登录态连续性。多端互斥则是另一个大坑一般有两种实现思路。一种是服务端在每个Token上绑定deviceId客户端登录时上报设备信息新设备登录后把旧设备的refreshToken立刻作废。另一种是客户端支持会话列表用户可以在某端主动“踢掉”另一端。两者都需要服务端配合客户端能做的就是把会话记录拆成“当前设备”和“其他设备”并在被踢时清理本地记录、回到登录页。模拟项目X最初只支持单端后来上线了“最近登录设备管理”本地会话表顺理成章从KV迁移到了Room。3. Memory实战内存不是玄学是算得清的账3.1 先看账单Java堆与Native堆的边界Android运行时的内存分为Java堆和Native堆。Java堆上分配的是我们new出来的对象GC负责回收Native堆上分配的是C/C层的数据比如Bitmap的像素数据在Android 8.0之后就从Java堆挪到了Native堆还有一些图片库的缓存、音视频解码buffer等。这里有一个很常见的误区。很多人以为只要不new大数组、不new大BitmapJava堆就不会爆。实际上大Bitmap的像素数据存在Native堆Java堆只保存一个轻量的句柄对象所以你会看到内存分析器里Java堆占用并不多App却依然因为底层内存申请失败而崩溃。这类OOM往往被归类为“匿名共享内存不足”排查时第一反应应该看Bitmap和图片解码链路。另一个Native堆大户是系统图形缓冲。每一次窗口渲染、每一帧Surface都会在GPU和CPU之间搬数据这些buffer通常是共享内存映射出来的不直接计入Java堆。所以出现“设备内存还有几百兆App却崩了”的情况多半是Native/图形缓冲逼近了系统单进程的rss上限。理解这点对开发者的实际意义在于不能只看Android Profiler的Java Heap曲线还要同时看Memory Profiler里的Native内存曲线以及用adb shell dumpsys meminfo查看进程详细构成。排查内存问题时把三者叠在一起对照才能定位真正的大头。3.2 Bitmap内存绕不开的重灾区Bitmap是移动端内存问题第一大来源。一张1920x1080的图片解码成ARGB_8888格式每个像素占4字节算下来就是192010804大约7.9MB。如果这个图片是全屏显示还没离谱到哪去但如果是评论列表里一个头像原图也是2000x2000那纯粹是灾难。计算方式本身不复杂工具也都能算真正缺的往往是对“加载即全尺寸解码”这件事的警惕心。处理Bitmap最核心的手段就两个压缩和解码尺寸控制。压缩指的是质量压缩主要用于上传场景或者缩略图导出多指JPEG的quality参数从100降到80之类。解码尺寸控制则用于展示场景核心思路是让解码出来的位图尽量接近实际显示尺寸而不是源文件尺寸。Android提供了inSampleSize采样因子设为2代表宽高各缩为原来的1/2内存直接降到四分之一。一段标准的“先测尺寸再解码”代码如下public static Bitmap decodeSampledBitmap(byte[] data, int reqWidth, int reqHeight) { BitmapFactory.Options opts new BitmapFactory.Options(); opts.inJustDecodeBounds true; BitmapFactory.decodeByteArray(data, 0, data.length, opts); int sampleSize calculateInSampleSize(opts, reqWidth, reqHeight); opts.inJustDecodeBounds false; opts.inSampleSize sampleSize; return BitmapFactory.decodeByteArray(data, 0, data.length, opts); } private static int calculateInSampleSize(BitmapFactory.Options opts, int reqWidth, int reqHeight) { int halfWidth opts.outWidth / 2; int halfHeight opts.outHeight / 2; int sampleSize 1; while (halfWidth / sampleSize reqWidth halfHeight / sampleSize reqHeight) { sampleSize * 2; } return sampleSize; }第一次decode只读取宽高信息不真正分配像素内存开销极小。第二次decode才按目标尺寸解码。如果对图像质量要求不高还可以把inPreferredConfig从ARGB_8888降为RGB_565每个像素降到2字节内存再减半。但要注意RGB_565不支持透明度带圆角或透明阴影的图不能直接用。3.3 LRU缓存与图片压缩的实践经验图片缓存不能用“存了就完事”的思路必须设计淘汰策略。最常见的是LRU也就是最近最少使用淘汰。Android里可以直接用android.util.LruCache它是线程安全的内部通过LinkedHashMap维护访问顺序。关键点是“计算缓存容量”需要用运行时的可用内存来估算而不是拍脑袋写死一个数字。模拟项目X的做法是拿App最大堆内存的四分之一作为图片内存缓存上限同时按“进程可用内存动态调整”。需要注意的是最大堆内存不等于所有App都一样大不同设备差异可能很大老旧设备最大堆可能只有128MB旗舰机可能512MB以上。用ActivityManager的getMemoryClass()拿到的值才贴近真实设备。缓存容量 min(maxHeap / 4, 64MB)这个公式的取舍逻辑是缓存太小会导致列表滑动时频繁重复解码CPU狂飙且电池发烫缓存太大又容易在系统内存紧张时被判定为高内存App而优先回收。四分之一的经验值在多数场景里都比较稳。另外Service里对图片进行异步解码时要注意线程压力。如果每次滑动都开一个线程去解码大图线程数量会失控。为模拟项目X写的图片加载模块里我自己实现了一个简单的生产者消费者队列核心是限制并发解码线程数为CPU核数减一并用一个“正在加载的URL集合”挡住重复请求。虽然是重复造轮子但那段代码让我后来看Glide源码时豁然开朗——所有图片框架的底层思路都差不多只是把细节做到了极致。3.4 内存抖动、泄漏排查与MAT内存抖动是另一个容易让App卡成PPT的问题。典型场景是循环里不断创建临时对象比如在onDraw里new Paint、在列表滚动时的bindView里频繁拼接字符串。每次分配都触发GCGC又跑在主线程的合适时机里结果就是渲染一帧、GC一波帧时间直接飙升到几百毫秒。排查抖动有一个很直观的手段打开Android Studio自带的Memory Profiler观察内存分配曲线是不是呈“锯齿状”锯齿越密集说明分配越频繁。但锯齿只能说明“分配多”要定位具体位置需要点击“Record allocations”录一段操作回放然后查看分配数量和占用空间的Top类。常见的泄漏场景集中在几类静态集合持有Activity、Handler消息未清除、内部类隐式持有外部类实例、第三方SDK单例里缓存了回调。排查时最趁手的工具是LeakCanary它会在检测到泄漏时自动dump堆并给出引用链。但LeakCanary只能告诉你“泄漏了”不能替你分析泄漏原因所以拿到引用链之后还是要自己顺着路径看哪里该置空而未置空。更深层的堆分析要交给MAT或者Memory Analyzer。读MAT报告时我建议先看“Dominator Tree”这个树结构能直接告诉你哪些对象“hold住”了大部分内存。有一次模拟项目X上线后用户反馈首页越来越卡LeakCanary提示一个CachedThreadPool被静态引用里面堆积了几十个带timeout的Task线程全在等IO。用MAT一查Dominator Tree一个Executors实例占住了20多MB的对象图问题一目了然。4. 掉坑记录Session与内存的真实战场4.1 常见问题速查表这一节我把模拟项目X从开发到上线遇到过的Session和内存问题整理成了一张速查表每个坑都附了现象和定位方向。这张表不是为了让你背答案而是遇到类似现象时能快速缩小范围少走弯路。现象可能原因定位方向登录后偶发请求401重登后恢复RefreshToken并发刷新竞争检查多个请求是否同时触发refresh加锁去重切后台一段时间后Token失效滑动过期策略没覆盖后台时长检查lastAccessAt是否在onResume时更新多进程读SharedPreferences串数据SP多进程缓存不一致统一切换到MMKV或改造为跨进程方案列表快速滑动时卡顿图片解码占用大量CPU/IO检查是否每次都全尺寸解码建议采样内存曲线锯齿密集临时对象频繁分配用Profiler Record allocations抓分配点压后台后进程被杀回来白屏缓存页被回收但恢复逻辑缺失保存页面状态到SavedInstanceState或本地恢复退出登录后内存没降下来静态引用或单例缓存未清理检查全局图片缓存、推送回调、网络队列多设备登录后被互踢服务端会话绑定设备ID生效客户端检查被踢回调后是否及时清Session其中RefreshToken并发刷新是Session方向最容易忽视的坑。假设有5个请求同时因为Token过期而失败拦截器里如果没有加锁每个请求都会尝试刷新Token服务端可能会把前面的refreshToken作废后面几个刷新请求全部拿到无效Token最终连锁触发重新登录。解决方案其实简单用一个AtomicBoolean标记“正在刷新中”第一个请求负责刷新其他请求进入wait刷新完成后再让所有等待的请求拿新Token重放。关键是这个等待不能无限期要加一个超时时间兜底比如5秒内没完成就返回失败走重新登录逻辑。4.2 一次实战排查内存缓慢上涨是怎么定位的最后分享一次完整的排查过程那是模拟项目X做“会话页图片预加载”时遇到的问题。用户在会话列表页停留10分钟后内存从120MB缓慢涨到280MB再过一会儿就OOM了。刚开始我以为是小图加载太多导致的但换成只加载10条消息后内存还是涨。于是用Android Profiler录了一段操作发现Java Heap里多出了一个名叫MessagePool的集合里面持有了大量Handler消息对象。这些消息来自一个全局的CountDownTimer我在退出会话页时忘记取消Timer而Timer内部通过Handler不断向主线程postDelayed每个延时任务都持有Message引用导致整个页面对象链无法回收。修复就三行代码onDestroy时取消定时器清理静态缓存中的页面回调节点然后用LeakCanary复测确认引用链断开。回头看这类问题的根因不是“内存不够”而是“生命周期没对齐”。Session管理讲究生命周期对齐内存管理同样是生命周期对齐只不过一个是登录态的生命周期一个是页面与组件实例的生命周期。这个系列写到这里我对“化翼藏忆”的理解已经不再是一个中二的章节名。化翼是让会话状态在客户端、服务端、多设备之间轻巧流转的一套设计藏忆是让每一块内存都有明确的归属、清晰的生命周期和可控的释放时机。两件事都做好了App的“体感”会非常稳用户不会感知到它的存在但一旦做砸了它就是体验崩塌的元凶。按我个人的经验光是第五境的并发知识是不够的Session和Memory才是真正把架构落地成产品体验的那最后几块砖。如果你正在做自己的项目建议不要光看这一篇文章就上手改先给你的App画一张“会话生命周期图”和“关键页面内存分配图”哪里画不清楚哪里就是下一步要补的课。最后再分享一个实用小技巧把SessionRecord和内存统计日志都打印到本地文件发布版本里留一个隐藏开关用户反馈问题后能一键抓取“会话快照内存快照”。这个习惯帮我解决过至少三次线上的“灵异问题”准确率比让用户反复复现高出十倍。