Android 智能硬件 SDK技术 Wiki

机制说明：进程负责隔离与资源承载，线程负责调度执行，组件是 Android 管理应用行为的入口。普通 Service 的生命周期回调默认在主线程；Provider 的远程访问接口可能在 Binder 线程并发执行，需要同步保护。

扩展说明：Service 一定是独立进程吗？不是，默认与应用其他组件处于同一进程；只有相应进程配置等条件才会改变。做 BLE SDK 也不必为了“后台”强行新建进程。

机制说明：onCreate 做一次性页面初始化；onStart 对应可见阶段；onResume 对应前台交互阶段。生命周期回调表示状态变化，不是精确的屏幕呈现时间点。onResume 返回也不代表首帧已经显示。

扩展说明：A 打开一个不透明 B 时呢？典型顺序是 A.onPause，B.onCreate、onStart、onResume，然后 A.onStop。透明页面、多窗口等场景可能不同，不能把单一场景当成所有窗口的规则。

机制说明：系统需要根据新的尺寸、方向、语言、密度等配置重新选择资源。若正确声明并自行处理相关 configChanges，可能收到 onConfigurationChanged 而不为这些变化重建，但应用必须自己完成资源和布局适配。

扩展说明：跨屏一定重建吗？不一定，取决于配置差异、应用声明和系统策略。即使没有重建，窗口尺寸和布局约束变化也会触发重新测量与布局，所以画面仍可铺满新屏幕。

机制说明：启动模式解决的是实例和任务栈行为，实际结果还受 Intent flags、taskAffinity、启动来源等影响。FLAG_ACTIVITY_NEW_TASK 参与任务选择，不等于“开新线程”，也不保证降低启动时延。较新平台还有 singleInstancePerTask，可作为扩展了解。

扩展说明：onNewIntent 里直接读取 getIntent 可以吗？如果后续代码要从 getIntent 读取新参数，应调用 setIntent(intent) 或明确使用传入参数，避免继续拿旧 Intent。

机制说明：首次启动一般是 onCreate → onStartCommand，多次启动可多次调用 onStartCommand。首次绑定一般是 onCreate → onBind，解绑涉及 onUnbind。两种使用方式可以组合，生命周期要一起判断。bindService 不等于跨进程，跨进程时才涉及相应 IPC。

扩展说明：长时间设备连接用什么？看业务是否需要用户可感知的持续任务，再考虑符合限制的前台服务或伴生设备能力。普通 Service 不保证进程常驻；前台服务也要满足启动条件、类型和权限要求。S04

机制说明：“切到后台线程”不等于广播任务就能无限运行。可延迟、要求最终完成的任务考虑 WorkManager；实时且持续的任务根据系统后台规则选择合适机制。动态注册要与拥有者生命周期对应，跨应用广播还需考虑导出策略和权限校验。

扩展说明：为什么退出页面后还收到广播？可能注册对象的生命周期比页面长，或没有注销。先确认接收者拥有者，再检查注册与清理是否成对。

机制说明：处理顺序是查合并后的 Manifest，确认哪个 SDK 注入 Provider，用 Trace 验证开销，再查它是否支持关闭自动初始化和显式初始化。AndroidX App Startup 能管理初始化依赖，但具体初始化工作仍需控制成本。S05

扩展说明：可以删掉 Provider，再自己 new 一次吗？不能默认这么做。Provider 的系统注册、Context、权限和生命周期不是普通对象初始化；只有供应方支持的接入方式才可靠。不能臆造一个 SDK.init 方法代替它。

机制说明：不是把所有 Context 都替换成 Application 就结束了。Dialog、主题相关布局和窗口操作具有自己的要求；SDK 应区分纯业务能力和 UI 能力，避免为通信保存整个 Activity。

扩展说明：WeakReference 能彻底修复吗？不能。它不能替代取消任务、移除监听、关闭连接等资源管理；对象随时可能消失，也会让代码更复杂。

机制说明：measure 与 layout 不必永远只执行一次。复杂嵌套、权重或约束可能增加测量次数。View 在构造函数和 onCreate 中可能尚未完成布局，直接读 getWidth 往往得到 0。

扩展说明：何时获取稳定尺寸？根据用途用 onSizeChanged、布局监听等，并处理后续尺寸变化。post 常能延后执行，但不应把它当作所有场景“尺寸一定就绪”的严格保证。

机制说明：wrap_content 不等于自动知道内容宽高。自定义 View 要计算期望尺寸，加上 padding，再结合父约束调用 resolveSize 等方法。match_parent 也不能脱离父容器当前的测量条件简单理解。

扩展说明：自定义进度控件 wrap_content 占满父布局怎么办？检查是否直接使用父容器提供的最大尺寸，忽略了自己的期望尺寸；同时检查最小尺寸和 padding 的计算。

机制说明：频繁 requestLayout 会增加布局工作，但影响范围取决于具体 View 树和框架优化。大量小更新应考虑合并。setSelected、setMargins 等涉及已使用中的 UI 状态和布局变更，应在主线程完成；修改 LayoutParams 后要通过正确途径触发布局更新。

扩展说明：子线程能否画 UI？可以后台计算数据、生成适合离屏处理的结果，但不能任意并发修改页面 View 树。postInvalidate 也只是安排重绘，不让其他 View 操作自动变安全。

机制说明：以圆形设备进度条为例：onMeasure 处理 wrap_content；onSizeChanged 计算圆心和半径；onDraw 画背景轨道与进度；setProgress 更新值后重绘。还要处理 padding、颜色状态、无障碍描述和恢复状态。

扩展说明：为什么手指操作了却没有点击语义？自己处理触摸时，确认在符合点击条件后调用 performClick，并正确处理 ACTION_CANCEL、多指切换和移动阈值。

机制说明：一次手势通常从 DOWN 开始，经多个 MOVE，到 UP 或 CANCEL 结束。子 View 在 DOWN 阶段接住事件，通常才能成为后续事件的目标。父容器中途拦截时，原目标子 View 会收到 CANCEL。

扩展说明：OnTouchListener 和 onTouchEvent 谁先？在满足启用等条件时，监听器可先处理；监听器返回 true 后通常不会再进入该 View 的 onTouchEvent。不要让监听器无条件消费所有事件，导致点击逻辑失效。

机制说明：不能只比较某一次 MOVE 的绝对值，还要考虑 touchSlop、多指、边界和 CANCEL。支持嵌套滚动的控件可通过 NestedScrolling 机制分配滚动距离及 fling，通常比强行禁止所有父层拦截更稳。

扩展说明：子控件到边缘后怎么让父容器接手？需要定义边界交接规则，并正确结束或转交当前手势，不能让两个控件同时认为自己独占同一段事件。

机制说明：RecyclerView 复用 ViewHolder 减少重复创建，但 onBindViewHolder 仍然可能很重。图片缩放和解码、列表差异计算、局部刷新、避免绑定时同步查询，都影响流畅性。DiffUtil 要正确区分“同一条数据”和“内容相同”。

扩展说明：快速滑动时图片错位为什么？异步请求返回后，ViewHolder 可能已经绑定其他条目。应取消旧请求或验证当前绑定标识，并在绑定时清理旧展示状态。

机制说明：60Hz、90Hz、120Hz 的周期约为 16.67ms、11.11ms、8.33ms，但具体帧截止时间还要结合流水线和系统调度分析。doFrame 结束不是像素已经出现在屏幕上，之后还涉及 RenderThread、GPU、合成和呈现。S07

扩展说明：主线程空闲就一定不卡吗？不一定，还可能是 RenderThread、GPU、SurfaceFlinger 或调度链路问题。定位时关联 FrameTimeline 与实际线程活动，不能只盯一个 doFrame 耗时。

机制说明：Message 是任务载体，MessageQueue 管理任务及执行时机，Looper 驱动处理，Handler 负责投递和分发。主线程的 Looper 由框架准备；普通线程需要自己的消息循环才适合绑定 Handler。

扩展说明：主线程 Handler.post 一个耗时任务是不是异步了？它只是排队后执行，仍占用主线程。postDelayed 的延时是最早可执行条件之一，不保证在指定毫秒精确开始；前面的任务可能造成延误。

机制说明：判断主线程时要区分 Running、Runnable 与等待状态。Running 表示正在使用 CPU；Runnable 表示想运行但还没得到 CPU；等待可能是消息队列正常空闲，也可能是等锁、Binder 或 I/O。它们需要不同优化手段。

扩展说明：堆栈显示 nativePollOnce 就说明问题在那里吗？不一定，采样时主线程可能已经空闲。需结合问题发生时间和完整 Trace，避免把采样位置当作根因。

机制说明：这里的“异步消息”指队列调度属性，不代表另开线程。IdleHandler 在主线程执行时仍必须很短；繁忙状态下执行时机不确定，不能放首屏强依赖，也不能把 100ms 工作搬进去就宣称消除了主线程开销。

扩展说明：IdleHandler 返回 true 和 false 呢？true 表示保留，以便后续空闲时再次回调；false 表示执行后移除。要警惕持有 Activity、长期重复任务和遗漏清理。

机制说明：ThreadPoolExecutor 典型处理顺序是先增加到核心线程数，再尝试入队；队列满后才在最大线程数范围内扩容，最终可能拒绝。无界队列可能积压内存，也会让最大线程数难以发挥预期作用。

代码练习一 有界任务池：以下是机制示例，线程数和容量必须经实际压测决定。由 SDK 实例拥有并负责关闭，不要每次请求都创建新池。

ExecutorService ioPool = new ThreadPoolExecutor(
    2, 4, 30, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(64),
    new ThreadPoolExecutor.AbortPolicy());
try {
    ioPool.execute(() -> performIo());
} catch (RejectedExecutionException e) {
    reportBusy(); // 按约定线程通知调用方
}
// 由拥有者在资源释放阶段调用 ioPool.shutdown()

扩展说明：CallerRunsPolicy 一定好吗？不一定。如果主线程提交任务，拒绝时就可能在主线程直接执行耗时任务。SDK 应有明确的忙碌错误或背压策略，而不是悄悄改变线程语义。

机制说明：多个变量之间有约束时，分别使用 Atomic 并不自动保证组合一致。例如“连接状态为 READY 时，session 必须存在”是整体约束，可以通过锁、不可变快照或单线程状态机维护。

扩展说明：设备 SDK 更倾向哪种并发设计？优先减少共享可变状态，把连接和命令状态集中到一个串行执行器；跨线程数据用不可变对象传递，再在必要处精确同步。

机制说明：常见危险是持有锁时执行同步 Binder、网络请求或外部回调。外部代码可能回调当前 SDK 或需要同一把锁，形成重入或交叉等待。更稳妥的是锁内只修改必要状态，复制结果后在锁外通知。

扩展说明：增加 synchronized 能修复所有并发 bug 吗？不能，锁范围过大可能把竞争变成阻塞或死锁。要先说清共享状态、所有者和允许的状态迁移。

机制说明：远程同步 Binder 调用会等待服务端处理，主线程发起就可能阻塞 UI。远程服务端调用通常由 Binder 线程池处理；同进程本地接口调用可能直接在调用线程执行。AIDL 并不让线程安全问题自动消失。

扩展说明：自定义对象可以传吗？可以按接口支持的形式进行 Parcelable 等序列化设计，但不是任意 Java 对象都能原样发送。大数据不适合全部塞进事务，应考虑文件描述符、共享内存或分块协议。

机制说明：为任务明确拥有者：页面级工作随页面或 View 生命周期结束，ViewModel 工作通常随对应 ViewModel 清理，设备会话工作随会话关闭。取消要传递到真正的底层请求或阻塞 I/O，并在结果回调前检查会话或请求是否仍有效。

扩展说明：Future.cancel(true) 就一定停了吗？不一定，它通常发出中断请求，任务和底层操作需要响应中断。对 Socket 等资源，还应按其 API 设计关闭和退出路径。

扩展说明：Kotlin 能彻底消灭空指针吗？不能，!!、Java 平台类型、初始化问题等仍可能产生 NPE。它让空值约束更显式，但边界输入仍要验证。S10

机制说明：Dispatchers.Main 常用于 UI，Default 用于 CPU 计算，IO 用于适合阻塞方式执行的 I/O。withContext 可切换执行上下文；delay 挂起协程而不占着线程睡眠，Thread.sleep 会阻塞当前线程。Retrofit 的异步挂起接口与自己写的同步文件读取要区别看待。

扩展说明：两个 suspend 调用顺序写出来会并行吗？通常不会，仍是顺序执行。需要明确的并发结构，例如 coroutineScope 中启动 async，再 await；同时定义失败与取消策略。

机制说明：普通父子 Job 中，一个子任务失败可能影响同级任务；SupervisorJob 等机制改变失败传播关系，但不代表异常自动被处理。CoroutineExceptionHandler 是未处理异常的兜底机制，不是恢复当前失败协程的替代品。

扩展说明：callback API 包一层 suspend 就结束了吗？还要关联取消与底层 cancel，防止多次恢复，并处理“取消与回调同时到来”的竞争。长期事件流通常更适合 callbackFlow，并在 awaitClose 释放注册。

机制说明：想象“设备列表页面”是显示器，ViewModel 是这块页面当前的工作台：正在加载、设备列表、错误信息、选中设备都可由它管理。旋转时显示器换了一个，工作台可以继续用。普通成员变量跟旧页面一起丢失；静态变量则边界过大，难清理、难隔离。

扩展说明：为什么不把所有数据都放 ViewModel？它不是数据库，也不是任意页面共享的全局仓库，更不负责直接持有 View。长连接归属和持久化应根据业务生命周期放在 Repository、会话管理或数据层。

扩展说明：SavedStateHandle 能替代数据库吗？不能，它依赖系统保存状态机制及任务恢复条件；用户主动结束任务等情况不能当作必然恢复。不要存大图、完整海量列表或活动连接，只保存重建所需的小型参数。S14

机制说明：点击刷新时，View 调用 refresh，ViewModel 更新为 Loading，Repository 获取设备数据，ViewModel 产出 Content 或 Error，View 根据状态渲染。View 不需要知道 BLE UUID，通信层也不需要知道 TextView。

扩展说明：Model 就是一个 Java Bean 吗？不应这样理解。广义 Model 包括业务数据与数据处理能力，实体类只是其中一部分。简单页面不必为了层数强行制造无用的转发类。

机制说明：View 页面收集 Flow 时要绑定生命周期。Fragment 通常使用 viewLifecycleOwner.lifecycleScope 和 repeatOnLifecycle，避免 View 销毁后继续更新旧绑定。StateFlow 会根据相等性合并状态，不能原地修改同一个可变对象后期待每次都发射。

扩展说明：SharedFlow 默认就能保证 Toast 事件不丢不重吗？不能。没有订阅者时的行为受 replay、缓冲等配置影响；导航、支付结果等重要结果更适合形成可确认的状态与消费协议，而不是只发一个瞬时事件。

代码练习二 状态与生命周期：这是结构示例，需要已有 AndroidX Lifecycle、协程依赖以及业务模型。Repository.loadDevices 必须具备主线程可安全调用的挂起实现，阻塞 I/O 由其内部调度。

sealed interface DeviceUiState {
    data object Loading : DeviceUiState
    data class Content(val items: List<Device>) : DeviceUiState
    data class Error(val message: String) : DeviceUiState
}
class DeviceViewModel(private val repo: DeviceRepository) : ViewModel() {
    private val _state = MutableStateFlow<DeviceUiState>(DeviceUiState.Loading)
    val state: StateFlow<DeviceUiState> = _state.asStateFlow()
    private var refreshJob: Job? = null
    init { refresh() }
    fun refresh() {
        if (refreshJob?.isActive == true) return
        refreshJob = viewModelScope.launch {
            _state.value = DeviceUiState.Loading
            try {
                _state.value = DeviceUiState.Content(repo.loadDevices())
            } catch (e: CancellationException) {
                throw e
            } catch (e: Exception) {
                _state.value = DeviceUiState.Error("加载失败 请重试")
            }
        }
    }
}
// Fragment.onViewCreated 内 viewModel 已通过合适的 Factory 获取
viewLifecycleOwner.lifecycleScope.launch {
    viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.state.collect { state -> render(state) }
    }
}

扩展说明：停止收集后后台任务一定停止吗？不一定。这里暂停的是 UI 收集，viewModelScope 中已启动的刷新有自己的生命周期；是否取消取决于业务需求。退出并清理 ViewModel 时，其作用域会被取消。S16

机制说明：Repository 决定业务从哪里取数据；Retrofit 接口表达路径、方法和参数；OkHttp 执行传输；JSON Converter 把响应映射成对象。它们是不同层次，不是三个可随意互换的名字。

扩展说明：每次请求都 new OkHttpClient 可以吗？通常应复用配置合适的客户端，共享连接池等资源。对于不同网络绑定、证书策略或独立隔离需求，再明确区分客户端实例及资源归属。

机制说明：请求可能经历缓存判断、连接选择或建立、发送、接收以及重试或重定向。不要把一条业务调用假定为只发生一次网络交换，也不要把某个版本的内部类顺序当作永久 API 契约。

扩展说明：能在拦截器里读取响应体做日志吗？响应体通常具有一次消费语义。完整读取可能消耗内容、占用大量内存，还会暴露敏感字段。使用有界、脱敏且不破坏后续消费的方案，并按 API 要求关闭资源。

机制说明：查询类操作常容易设计为可重试；支付、设备启动动作、固件升级确认等可能产生重复副作用。对这些操作应使用业务请求 ID、幂等键、设备端去重或结果查询。退避加入随机抖动，避免大量客户端同时重试。

扩展说明：PUT 一定安全、POST 一定不能重试吗？HTTP 语义中的幂等性要结合实际接口实现。POST 也可以通过幂等协议安全重试，不能只看方法名。读取超时也不意味着整次调用只允许这么长时间。

机制说明：不要让每个请求各自刷新，也不要让刷新请求再次进入同一套失效循环。刷新失败要形成明确的登录失效结果。并发控制时避免持锁做长时间网络等待，尤其不能让所有刷新任务等在已被占满的同一执行资源上。

扩展说明：记录完整请求头便于排查可以吗？Authorization、Cookie、设备凭据需要脱敏。线上排查通常记录请求 ID、阶段耗时、错误分类和必要的非敏感元数据即可。

机制说明：Kotlin 的非空声明不是对外部 JSON 的万能验证器，具体表现还取决于序列化库与配置。大 JSON 解析、复杂映射或数据库写入都可能耗时，不能因为网络使用异步接口就默认后处理对主线程安全。

扩展说明：接口加了新字段就一定不兼容吗？通常可通过忽略未知字段等策略兼容；删字段、改类型、改变业务含义更危险。还要在开启混淆的 release 包验证反射模型、泛型信息和必要保留规则。

机制说明：一次新建 HTTPS 连接可能涉及 DNS、连接建立、TLS 握手，再发送 HTTP 请求。连接复用、HTTP/2 多路复用等减少重复成本，但不能掩盖服务端慢或大响应处理慢。

扩展说明：设备自签名证书不通过，直接信任全部证书可以吗？不能作为正式方案。应按产品信任模型配置证书或可信身份验证，验证主机或设备身份；本地网络也不是天然安全边界。

机制说明：用请求 ID 串起客户端事件、服务端日志和用户场景；对比冷连接与复用连接、Wi-Fi 与蜂窝、前后台、不同设备。还要看连接池、并发限制、响应体大小和主线程是否在处理返回数据。

扩展说明：服务器说 50ms 返回，用户却等了 2 秒怎么解释？2 秒可能包含连接建立、排队、传输、重试、解析和 UI 阻塞。需要统一时钟或关联标识，并先统一双方测量起止点。

机制说明：可以把设备看作功能目录：某个 Service 是“设备控制”，某个 Characteristic 是“命令输入”，另一个是“状态上报”。GATT Client 与 Server 是数据访问角色，不能与 Central 与 Peripheral 在概念上完全画等号。

扩展说明：BLE 连接一定要先配对吗？不一定，是否需要配对、绑定和链路加密取决于特征权限与产品安全协议。扫描到设备、完成连接、完成身份认证也不是同一个阶段。

机制说明：常见通知订阅既需要本地 setCharacteristicNotification，也需要向对应 CCCD 描述符写入启用 Notification 或 Indication 的值，并等待写入结果。仅建立连接或仅调用本地启用接口，都不保证会收到设备上报。

扩展说明：Notification 与 Indication 有什么不同？Indication 在 ATT 层有确认机制，Notification 没有这种逐条 ATT 确认；但无论哪种，都不能把传输层成功当作“设备业务已经执行完成”。关键操作需要业务响应。

机制说明：常见状态有 Idle、Scanning、Connecting、Discovering、Subscribing、Authenticating、Ready、Disconnecting。一次 API 返回“已受理”不等于完成；对需要串行的 GATT 操作，应等对应回调或明确失败后再推进。每一阶段都要有超时、取消和清理入口。

代码练习三 连接与命令状态设计：下面是设计规则，不是可直接调用的 Android API。实现时把状态修改集中到一个串行执行器。

connect
  创建新的 sessionId 并进入 Connecting
onConnected
  校验当前 GATT 实例与会话 然后进入 Discovering
onServicesReady
  排队订阅与握手 全部完成后进入 Ready
sendCommand
  仅 Ready 接收 建立 requestId 超时与业务确认条件
onDisconnectOrClose
  结束会话 失败回调未完成请求 释放 GATT 与监听

扩展说明：某次写超时后直接发下一条可以吗？要谨慎。系统回调不一定带应用自定义请求 ID，迟到回调可能被误认成下一条的结果。无法可靠区分时，应结束或重建会话；业务回包则通过协议序号匹配，不能只在本地发明一个 ID 就假定设备会返回它。

机制说明：以实际协商结果和协议上限决定分包大小，不要根据 requestMtu 的入参直接假定成功。Android 14 起首次 GATT 客户端请求 MTU 时有请求 517 及后续请求处理的行为变化，但不表示所有设备都实际协商到 517，也不表示任意 514 字节业务包都能发送。S21

扩展说明：应用层如何分包？可定义消息序号、分片编号、总长度与校验信息，接收端有界缓存并设组包超时。丢包、重传和去重要按可靠性需求实现；CRC 主要检测错误，不提供身份认证。

扩展说明：SDK 可以自己弹权限框吗？纯通信 SDK 更适合报告缺少的能力并提供接入说明，由宿主在合适交互时机申请。若 SDK 提供 UI 封装，也要明确 Activity 生命周期和重复请求处理。

机制说明：状态 133 一类错误不能直接归为唯一原因。保留机型、系统、固件、阶段、GATT 状态、耗时和连接代次，进行受控重试并对比设备端日志。避免循环频繁扫描和重连，也不要依赖隐藏 refresh API 作为通用解法。

扩展说明：设备已经发通知，应用没收到怎么办？核对发给哪个连接、CCCD 是否成功、目标 UUID、加密状态，以及回调是否到达但被线程阻塞或会话校验丢弃。优先用时间线把问题缩到一层。

机制说明：下发成功不代表配网成功，还要分别确认凭据接收、接入路由器、获取地址，以及业务要求的云端注册或本地可达。Wi-Fi Direct 是点对点连接能力，不能直接等同于让设备接入家庭路由器。

扩展说明：配网失败如何提示？按阶段给出权限拒绝、找不到设备、认证失败、网络不支持、设备离线等可行动结果，避免所有情况只显示“请重试”。

机制说明：Android 10 起的 WifiNetworkSpecifier 常用于应用发起的本地设备连接，涉及系统确认；WifiNetworkSuggestion 则向系统提供网络建议，不能当作强制立即切网的命令。进程整体 bindProcessToNetwork 会影响其他请求，应慎用并正确恢复。

权限补充：Android 13 起相关 Wi-Fi 管理 API 使用 NEARBY_WIFI_DEVICES，但 startScan、getScanResults 等仍可能要求定位授权。Android 17 上面向 API 37 及以上的应用还需要按局域网保护规则处理 ACCESS_LOCAL_NETWORK 或适用的系统中介选择流程，不能只记 INTERNET 一个权限。S23S24

扩展说明：onAvailable 就能告诉用户配网成功吗？不能，它说明相应网络可用，还要验证设备服务可达以及设备最终的入网结果；结束时移除 NetworkCallback 并释放会话。

机制说明：长度字段方案可以在消息头写入 payload 长度，先读足头部，校验长度，再读足正文。必须限制最大长度，并处理 EOF、超时和非法格式，避免根据不可信长度无限申请内存。

代码练习四 读取长度前缀消息：示例约定 4 字节大端有符号长度，正文上限 1MiB；在后台 I/O 执行。真实协议还需要业务类型、版本、序号与必要的完整性验证。

static byte[] readFrame(DataInputStream in) throws IOException {
    int length = in.readInt();
    if (length < 0 || length > 1024 * 1024) {
        throw new IOException("Invalid frame length");
    }
    byte[] body = new byte[length];
    in.readFully(body);
    return body;
}

扩展说明：读取中间超时后继续调 readFrame 吗？这个简化实现不能安全地从头恢复。若已读了一部分，必须保留解析状态继续，或关闭连接重新建立边界。还要设整帧总期限，避免对端每次少发几个字节却永不完成。

机制说明：心跳周期需要平衡故障发现速度与功耗，不能所有场景每秒发一次。TCP 的可靠传输不代表“设备命令只执行一次”；连接断开时，有些命令可能已经执行，只是响应没回到手机。

扩展说明：ACK 与业务结果有什么区别？ACK 可能仅表示收到、校验通过或进入队列，业务结果才表明执行成功。协议需要定义每种确认的语义，客户端分别管理发送超时、确认超时与业务完成超时。

机制说明：例如 DeviceClient 暴露 connect、observeState、execute 和 close；SessionManager 维护连接代次；CommandDispatcher 关联请求与结果；Codec 校验并编解码；Transport 负责收发和连接事件。各层依赖接口，测试时可以替换成模拟传输。

扩展说明：为什么不只做一个 BluetoothUtil？简单工具类只能降低调用成本，不能自然管理复杂会话、取消、重试和状态一致性。设备一多、协议一升级，隐含全局状态会成为主要维护风险。

机制说明：如果允许用户注入 Executor，说明回调在该执行器上的顺序保障和拒绝策略；如果固定主线程回调，说明重型数据处理应在哪里完成。终态回调通常应保证至多一次，取消和结果竞争时也要遵守同一规则。

扩展说明：SDK 可以回调前自己吞掉所有异常吗？内部要避免异常破坏状态，但不能把真实失败都伪装为成功。对调用方回调抛异常的处理也要明确，避免一条错误回调破坏整个队列。

机制说明：幂等是重复调用不会产生额外的错误副作用，不代表可以忽略配置冲突。若第二次 init 的参数与第一次不一致，应明确拒绝或按受支持方式重配。共享线程池与宿主传入资源不能被 SDK 随意关闭。

扩展说明：多进程应用中单例还只有一份吗？通常每个进程各有一份。要确认哪些进程需要初始化，必要时把服务边界设计清楚。用户切换、账号切换与设备切换也要隔离相应会话状态。

机制说明：可将工程拆为 sdk-api、sdk-core、transport-ble、transport-socket 和 sample-app。api 不暴露内部实现类；core 依赖接口；Android 平台能力隔离在适合的模块。模块数量应由边界决定，不能只为“架构好看”拆空壳。

扩展说明：接口 继承 多态为什么让替换更容易？接口规定能力，具体类提供实现，多态让调用点通过同一契约使用不同实现。真正可替换还要求行为契约一致，例如同样的取消和错误语义。

机制说明：删除方法、改签名、暴露第三方内部类型、修改资源名都可能影响宿主。consumer ProGuard 规则只保留必要入口与反射内容，不应把整个包全部 keep。含 .so 时还需检查 ABI、原生符号和目标平台兼容要求。

扩展说明：编译成功就代表 SDK 升级成功吗？不代表。还应验证实际 release 包、混淆、资源合并、运行期 API 可用性和关键设备协议兼容，覆盖旧宿主与新 SDK 的组合。

机制说明：重点场景包括首次授权、拒绝后重试、权限撤销、蓝牙中途关闭、连接时切后台、旋转重建、手机网络切换、设备重启、升级后协议变化、多次 connect 与 close。协议层还要注入半包、重复包、超时、乱序业务响应和非法长度。

扩展说明：模拟器能验证全部蓝牙问题吗？不能，真实射频环境、蓝牙栈、硬件和固件差异必须实机验证。单元测试适合验证状态机与解析器，实机联调用于验证平台和设备交互。

机制说明：连接成功率必须定义分母与排除规则，例如用户主动取消不应混入协议失败而不说明。用 sessionId 和 requestId 串联阶段，日志保留错误码、耗时、重试次数及必要上下文，避免记录 Wi-Fi 密码、token 或完整敏感 payload。

交付补充：CI 至少覆盖关键协议与状态机测试、静态检查和样例应用的 release 构建。新增问题门禁可结合代码变更与规则范围控制，避免历史存量问题淹没当前变更；但差异报告不能替代完整的集成与兼容性回归。

扩展说明：抓不到线上复现时怎么办？先补足最小诊断信息并比较异常分群，再用相同系统、机型、固件与网络条件复现。没有证据时先提出可验证假设，不把“系统 bug”当结论。

机制说明：冷启动涉及进程与应用初始化；温启动和热启动复用的资源不同。onCreate、onResume、doFrame 结束都不是天然的实际呈现终点。以手指按下作为起点的端到端指标还包含输入链路，需与系统启动指标区分。

扩展说明：如何验证首帧？关联正确窗口的帧事件、FrameTimeline 与呈现信息，并结合录屏或高速相机验证用户可见效果。240fps 相机每帧约 4.17ms，测量结果有帧粒度和动作判定误差。

机制说明：主线程长时间 Running 可能是计算或布局；Runnable 很久可能是 CPU 竞争；同步 Binder 等待需要继续看远端；磁盘或锁等待需要找资源拥有者。为关键初始化和业务阶段添加 Trace 标记，有助于对齐自己的代码与系统事件。

扩展说明：Actual Timeline 很长就等于主线程一直执行吗？不是，它表达帧相关时间线，不能当作 CPU 执行时长。必须关联对应应用帧、显示帧与线程调度信息，判断错过的是哪个阶段。

机制说明：常用方式包括精简 Provider 与 Application 初始化、延迟初始化、按需加载 ViewStub、控制布局复杂度和图片解码、正确使用异步 Inflate。后台化要同步检查线程竞争、首次使用等待和错误处理，防止把卡顿从启动搬到下一次点击。

扩展说明：开十个线程能不能更快？不一定，任务可能存在依赖，设备 CPU 与 I/O 资源也有限。并发过高会增加调度、GC、内存与锁竞争，最终让首屏更慢。

机制说明：不是所有 View 都能后台创建。构造中依赖线程 Looper、创建 Handler 或非线程安全行为，都可能使异步创建不适用并回退主线程。回调默认路径与显式 callback Executor 的行为也需按所用版本区分；真正操作页面和挂载 View 必须回到主线程。

扩展说明：布局为什么一块块出现？可能分批 inflate 和挂载、数据分批绑定，或占位内容先显示。可先准备整体结构，再一次挂载，或定义明确的骨架屏策略；并在回调时检查页面是否已销毁、当前请求是否已过期。

机制说明：线程泄漏会占用栈、调度和其他资源，也可能通过 Runnable 留住 Activity，进而形成内存泄漏，但两者不是同一概念。排查时复现进入退出循环，观察对象数量与内存曲线，用 heap dump 找到从根到泄漏对象的引用链。

扩展说明：缓存也属于泄漏吗？有边界、有淘汰策略的缓存是主动保留；长期无界增长或错误保留页面会变成问题。Bitmap 要按显示尺寸采样与合理缓存，不要寄希望于频繁调用 System.gc 来解决设计问题。

机制说明：输入分发超时常见默认阈值约 5 秒，但广播、服务等有各自条件和时限，且受版本和场景影响。主线程可能不是在忙算，而是在等锁、远端 Binder，或者没有合适的可接收输入窗口。抓取主线程栈后还要追等待链。

扩展说明：崩溃先看什么？完整异常类型、cause 链和相关业务栈，结合版本、机型与用户步骤；原生崩溃需要保留对应符号。不要只截最上面一行，也不要给所有异常套 try-catch 后当作已修复。

机制说明：设备 SDK 常见问题是持续高频 BLE 扫描、过密心跳、失败后无休止重连、频繁日志和轮询。可以限制扫描窗口、使用退避、合并状态更新、停止无人使用的任务，并确保 WakeLock 成对释放且有超时。

扩展说明：线程都休眠为什么仍可能耗电？频繁唤醒可能让 CPU 或无线模块难以进入低功耗状态。用系统电量统计、Perfetto 和适用设备上的功耗数据，结合时长、温度与网络环境做对照。

机制说明：控制构建类型、机型、系统、温度、后台负载、网络、缓存与编译状态，区分冷温热启动。可以用 Macrobenchmark 等进行回归；Baseline Profile 可改善部分代码的执行准备，但不能消除网络、错误依赖或主线程 I/O。S30

扩展说明：异步化后首帧快了 100ms 就能上线吗？还要确认内容是否可用、点击是否阻塞、是否发生数据竞争和页面销毁后回调。指标提升与正确性都满足后，再结合灰度数据判断。

实践说明：座舱多屏互动模块的冷启动优化，先用 Perfetto 把启动链路拆成初始化、布局创建、数据准备和首帧相关阶段，重点排查主线程阻塞和不必要的前置依赖。随后结合异步 Inflate、重任务后台化、ViewStub 按需加载和 IdleHandler 调整初始化时序。经过多轮实车复测与 Trace 复采，响应时延由 380ms 降到 240ms，降低约 37%；启动完成时延由 1200ms 降到 700ms，降低约 42%。

分析方法：针对一个真实瓶颈，依次分析“原本谁在等待谁”“Trace 上有什么证据”“为什么这个任务可以延后或并行”“怎样保证依赖与生命周期正确”“复测是否出现副作用”。

验证记录：380ms 的起点和终点是什么？冷启动怎么保证？哪个优化收益最大？测试多少轮、什么设备、看什么统计量？各模块的改动范围是什么？这些结论应以实际记录为依据；如果当时没有拆分单项收益，就说明结果来自组合优化，不编造每个措施节省的毫秒数。

实践说明：“我会先确认 Inflate 是否确实在关键路径且占比较高。精简 XML 可以减少创建和布局成本；异步 Inflate 可以在满足线程安全约束时，把部分创建工作从主线程移开。两者可以结合，但异步化会带来内容晚到、页面销毁后回调和状态协调问题，所以需要验证适用控件、数据依赖以及最终挂载时机。”

边界情况：如果布局不能异步创建怎么办？先定位不支持的 View 或工厂，考虑调整范围、同步创建最小首屏骨架、按需加载后续内容；不要为了维持“异步方案”破坏控件线程约束。回退到主线程的实际情况也要通过 Trace 确认。

验证标准：能说明收益来自缩短主线程关键路径，并说清总工作量可能没有下降，就比只说“后台更快”完整。还要承认首次内容就绪可能延后，需要用用户体验指标验证。

实践说明：“两类工作都涉及异步状态变化、系统接口、资源生命周期和环境差异。跨屏时要处理窗口和配置变化、输入坐标或焦点、页面重建与状态恢复；设备 SDK 要处理连接变化、权限、协议状态和断连恢复。共通方法是拆解调用链路、用证据定位边界问题，并把异常恢复设计成明确流程。”

知识补充：虚拟显示在 Android 中是具有显示标识和配置的逻辑显示输出，其内容可以送到指定 Surface；它不必等同于录屏，也不必自动拥有 Launcher。Activity 流转到另一个 Display 后是否重建，需要看配置与系统策略；返回键交给哪个窗口，则还涉及焦点和输入路由。

扩展说明：应用调用接口、系统联调、系统问题定位和 Framework 或驱动修改具有不同的实现边界。工程记录应区分这些层次，标明实际改动范围以及对应的验证证据。

参考方案：对“设置温度为 24 度”这样的目标状态操作，可按协议定义幂等；对“执行一次开锁”或“增加一次计数”这类动作，不能盲目重试。连接异常后先确认设备状态或查询请求结果；若协议无法保证，就对外暴露“结果未知”，而不是擅自报失败后重做。

扩展说明：如何实现业务恰好一次？通常需要客户端与服务端或设备共同的持久化、去重和确认协议。单靠 TCP、一个本地 boolean 或 UI 禁用按钮，不能普遍保证跨崩溃与断线的恰好一次执行。

机制说明：温度读数、进度等状态通常可以覆盖旧展示值，但命令结果、告警和需要完整记录的采样数据不能随意丢弃。SDK 应对不同数据类别规定背压策略，分别观察接收、解析、存储、分发和渲染的耗时及积压量。

扩展说明：直接把所有回调丢进线程池就行吗？不行，可能改成后台无界积压、乱序和内存增长。正确方案要控制生产和消费速率，明确顺序和丢弃策略。

机制说明：设计 NotInitialized、Initializing、Ready、Failed 等状态，合并重复初始化。页面观察状态后展示加载、可用或失败，避免轮询和忙等。依赖图中 A 等 B、B 又等 A 会形成死锁或无限等待，不能只凭“都放后台”解决。

扩展说明：准备失败时界面怎么办？依据功能必要性选择重试、限制部分功能或降级展示，同时保留错误原因与诊断信息。必须有失败路径，不能让加载指示无限转。

实践说明：对于以 Java 为主的 Android 开发，可优先学习 Kotlin 的空安全、协程、Flow 和 ViewModel，它们直接影响状态与并发设计。BLE 按扫描、连接、服务发现、订阅、握手和业务响应的顺序逐步验证。对于新的设备协议，先结合协议文档和最小验证程序建立可观测链路；文档学习、实验验证和量产应用应分别记录。

实践步骤：实际运行一个设备列表页面和一个协议解析练习。若有设备，再验证扫描、权限拒绝、订阅、断连和清理。没有真实 BLE 设备时，也能验证状态机和虚拟传输，但应明确实机能力尚未验证。

实践边界：区分已理解的机制、已完成的实现和待验证的未知点。准确记录实现语言、运行环境和验证范围，避免把实验能力当成已验证的生产能力。

协作记录：针对真实案例，依次记录背景、争议点、判断依据、与相关方确认的方案、结果和后续防复发措施。若与算法团队协作，补充输入输出格式、计算时延预算、线程模型、设备资源限制和异常数据处理。

扩展说明：线上事故第一步是复盘吗？通常先控制影响、保留证据并恢复服务，再定位与复盘。复盘应形成可执行改进，例如增加阶段错误码、补充回归场景或修复依赖设计，而不是只归责某个人。