Co_Hui的博客

是系统的“序列化仓库”（只存小东西，且必须由 Activity 亲自管理）。ViewModel是内存中的“大型数据仓库”（配置变更时不怕，但进程死亡就完蛋）。是“ViewModel 随身携带的钥匙”，让 ViewModel 可以随时把关键的小数据锁进系统的“序列化仓库”里，让 ViewModel 同时具备了抵抗进程死亡的能力，且代码高度内聚，无需界面层参与。

Intent 实现了 Parcelable，跨进程时会被序列化到 Parcel 中，因此目标进程获得的是重新构造的 Intent，而不是原对象引用。是的，因为这里涉及应用进程和 AMS 所在的 system_server 进程的 Binder IPC 通信息，所以 Intent 传递数据会受到 Binder 事务的大小限制。使用全局变量或单例模式：将数据存储在全局变量（静态变量或自定义Application中变量，主要满足生命周期与进程一样）或单例对象中，这样在不同的 Activity 之间可以直接访问。

在实际开发中，我们应默认使用单进程，只有当确实需要隔离内存或提升稳定性时才引入多 PID；而 UID 的共享则要慎用，因为涉及签名绑定，且可能破坏沙箱安全模型。面试中能理清这两个概念的区别与应用边界，就能体现出对 Android 底层安全模型和进程管理的深入理解。

MVC 架构主要分为以下几个部分：请求的流程：存在问题：MVP的构成：流程：相较于MVC：仍然存在的缺点： 模式将 改名为 ，基本上与 模式完全一致。唯一的区别是，它采用双向数据绑定（）：的变动，自动反映在 ，反之亦然同时将代码划分为三个部分：流程： 与 很相似，其借鉴了前端框架的思想，更加强调数据的单向流动和唯一数据源。![[Pasted image 20260424011110.png]]分为三个部分：MVI强调数据的单向流动，主要分为以下几步：用户操作以Intent的形式通知ModelMode

Activity、Service 等继承 ContextWrapper，可以在不修改 ContextImpl 的情况下增加主题、生命周期或组件特有的逻辑，这体现了装饰器模式中“包装原对象并扩展功能”的思想。这三个类虽然分别各种承担着不同的作用，但它们都属于Context的一种，而它们具体Context的功能则是由ContextImpl类去实现的。因为 Context 一共有 Application、Activity和Service三种类型，因此，一个应用程序中 Context 的数量为。

解释器执行每条字节码时，都需要经过取指、解码、分派和执行。取指是读取下一条字节码，分派是根据操作码跳转到对应的处理逻辑，解释执行则是由解释器完成该指令表示的操作。寄存器型字节码通常用更少的指令完成相同任务，因此可以减少解释器循环和指令分派次数，这在以解释执行为主的早期移动设备上有一定性能优势。JIT 出现之前或尚未触发时，JVM 通过解释器逐条读取和分派字节码，执行解释器内部已有的本地处理逻辑；当方法或循环成为热点后，JIT 会把整段字节码编译成本地机器码，后续直接执行机器码，不再逐条解释。

RecyclerView 的缓存机制是其高性能的核心。它通过来高效地复用，从而 减少的开销 以及 inflate 的次数，实现流畅的滑动体验。