S2R/STR（智能座舱快速启动）

定义

STR （Suspend to Ram），顾名思义挂起（加载）到RAM。 当走STR 流程的时候会把SOC /CPU 运行的任务分步的挂载到RAM 里面（对应L 型框架，先挂起Android，然后挂起QNX）,等系统挂起成功后，仅维持RAM 的电源（其它硬件断电），以达到休眠和快速唤醒的功能；

背景&应用场景

随着汽车行业的发展（或者说卷），作为主要和用户交互的界面—-智能座舱域也急需提升用户体验，快速开机也变成一个优化体验的关键点（在STR 出现前，用户只能等android 启动后才能使用中控屏），基于这样应用场景STR 也应运而生；

智能座舱域加入STR 功能。用户用完成车（关门&锁车后），会先判断电池电量，环境温度，高低压等状态。当满足进STR 状态时（如：电池电量>13%,防止STR 状态下电池亏电）。如果不满住会走Sleep 状态（完全断电，下次启动会走冷起）。

配合的措施

STR 功能虽然可以达到快速启动的功能，基本上用户上车就看到android Function 的界面，但是也有一样点需要注意；

1. 电池耗电

Sleep 状态，SOC 侧是完全断电状态，当Sleep 状态下静态电流基本上是0.3mA左右。但是STR 过程中需要给RAM 供电，STR 的静态电流基本在10mA~15mA；长时间STR状态下（用户长时间不用车），小电瓶会有亏电风险。

基于这种场景，处理的方法是，对STR 做最大的时间限制（如：STR 最长120h）；当超过120h，用户没有用车，会自动从STR 状态进Sleep状态（比如，长时间不用车，发现再次用车时播放了开机动画）；

Ps：一把STR 状态下，再次用车。车机会直接显示full function 界面，不会播放开机动画；

2. 碎片化处理

大家潜意识中都有一个概念（者说应急处理方法），电子用品出现有卡死或者黑屏，重启一下基本上可以解决95%的问题。当系统长时间运行的时候，有些进程异常或者变成了僵尸进程，导致占用额外内存/CPU 资源。

为了避免STR 状态下长时间运行，座舱的处理方法就是定时重启（在某个特殊的时间点，唤醒车机，判断使用有用户使用，如果没有就重启一次，然后再进STR ）。

小结

整车上STR功能， 也是2021年之后慢慢出现的，随着整车厂商的重视和功能的明确，硬件厂商也做了对应的适配（如：高通车规级芯片基本上都给出了STR 的方案），STR 功能基本成熟。

但是总体上STR 功能还是比较复杂，STR 需要各个APP 适配（进STR 时需要释放对应的硬件资源），现在成功率基本可以维持在95%左右；

所以有看到STR 失败也不要慌张；