卡顿、耗电、响应，以及内存安全与加固。

一、性能

Android性能优化 blockcanary

BlockCanary 通过监控主线程 Looper 找出卡顿。它在消息分发前后打点，超过阈值就 dump 堆栈。适合开发期抓同步 IO、过度布局和锁等待。原理和 Choreographer 掉帧监测互补：一个看消息时长，一个看 vsync。接入后要把阈值设在人能感知的范围，太低会噪声爆炸。

线上要用采样和聚合，避免每个卡顿都上传完整栈。堆栈要符号化。修复优先主线程数据库和过度 measure。和 StrictMode 一起开，能更早暴露磁盘访问。BlockCanary 是手电筒，不是性能预算本身。建立卡顿看板后，再按页面分配优化。工具只能告诉你卡在哪，改代码才是结果。

Android性能优化-耗电量优化

耗电优化要对付 Doze 和 App Standby：灭屏后系统推迟网络和 Job，长期不用的应用进待机桶。唤醒锁、定位、蓝牙扫描和前台服务是大户。策略是合并请求、用 Job/WorkManager、可见时才开高精度定位。电池历史和 Bugreport 能看出是谁在持锁。

前台服务要有真正可见的通知，否则会被系统打。推送尽量走高优先级通道的必要场景。循环唤醒检查改成系统调度。测试在真机开省电模式。耗电是产品问题，不只是技术指标：用户会卸掉“后台偷偷跑”的应用。先测量再改，不要凭感觉关功能。Doze 兼容做好，应用在锁屏后才像一个好公民。

Android 性能优化-响应优化

Android 系统每隔 16ms 会发出 VSYNC 信号重绘我们的界面(Activity)。

页面卡顿的原因：

(1)过于复杂的布局.

(2)UI 线程的复杂运算

(3)频繁的 GC,导致频繁 GC 有两个原因:1、内存抖动, 即大量的对象被创建又在短时间内马

上被释放.2、瞬间产生大量的对象会严重占用内存区域。

JVM 性能优化

JVM 性能优化覆盖分配、JIT、GC 与线程。先用 JFR/async-profiler 找热点，再决定是减对象、改数据结构，还是调编译阈值。逃逸分析与标量替换能消掉短命分配，但依赖内联，不要过早拆方法。

锁竞争看 JUC 与偏向锁历史；容器选对 HashMap 初始容量能少扩容。JNI 与反射是隐藏成本。大页、NUMA、压缩普通对象指针 (CompressedOops) 影响堆布局。

和应用层调优的边界：代码无谓分配时，调 GC 只是止痛。把基准测试用 JMH 固定下来，避免用 System.nanoTime 手写微基准被优化掉。

二、安全

Android 敏感数据在应用内存的安全性探讨

Android 应用内存里的敏感数据（口令、token、身份证号）一旦进入堆或日志，就可能被调试器、崩溃上报或系统快照带走。Java 字符串不可变且会驻留，不适合长期保存密钥；更稳妥的是用 char[] 或 native 缓冲，用完立刻清零。

实践上应：尽量缩短明文存活时间、禁止把密钥写进 SharedPreferences 明文、关闭调试日志中的 payload、崩溃上报做脱敏。硬件支持时把密钥放进 Keystore，只在 TEE 里完成签名或解密。root 或调试包上内存转储无法彻底防御，因此安全模型应假设设备不可信，靠短时效令牌与服务端校验兜底。

Xposed

Xposed 是 Android 上的一种框架层 Hook 机制，通过替换 Zygote 进程的运行时环境，让模块能在目标进程加载时拦截 Java 方法调用。它曾被广泛用于调试、界面自定义和行为观测，但也带来明显的兼容性与安全风险。

现代设备上更常见的是 LSPosed、EdXposed 等基于 Riru/Zygisk 的继承方案。从工程角度看，关键是理解方法替换发生在进程启动之后、类加载之前，因此与加壳、隔离进程、自身 ART 优化都可能冲突。若只是为了排查问题，优先考虑官方 Profiler、日志与单测；不要把框架层 Hook 当作生产依赖。

Android接口加密认证

Android 接口加密认证要解决两件事：信道保密和请求归属。TLS 是基础，证书校验必须走系统信任锚，证书锁定只能作为额外策略并要有更新通道。应用层再叠加登录态、短期 token 和请求签名，防止重放。

不要把长期密钥写进客户端代码，签名密钥一旦下发就要可轮换。时间戳和 nonce 要有服务端窗口。敏感字段最小化，日志脱敏。加固和混淆只能提高成本，不能替代服务端鉴权。调试包与发布包的网络安全配置要分开，避免生产还信任用户 CA。最终以服务端校验为准，客户端加密只是补充。