7.3 设备能力权限与新架构升级

7.3 设备能力权限与新架构升级

本节摘要：能力有闸门（权限），模块有未来（新架构升级）。本节先对照两端权限模型——iOS 的用途声明加一次性系统弹窗、Android 的清单声明加运行时授权——给出「上下文前置说明、拒绝后引导设置」的完整申请流程；再把三方接入的合规要点过一遍；最后画出存量旧式模块走向新架构的渐进路线。本节是桥接篇的收口，也是上架合规（第 8 章）的前哨。

从一次相机权限拒绝说起

反例先行：某应用的扫码功能在用户首次点击「扫码」时立刻弹出系统权限框，用户莫名其妙点了拒绝，功能从此黑屏且没有任何提示，评论区开始出现「扫码是坏的」。问题的三层病灶：弹窗无上下文（用户不知道为什么要相机）、拒绝后无降级（黑屏等于坏掉）、拒绝后无出路（不知道去设置能打开）。合规且体面的权限体验是一条完整流程，而不是一次系统调用。

图：合规的权限申请流程与两端差异

代码层面，把流程收敛成一个跨端钩子，界面层只认结果不问细节：

import React from 'react';
import { PermissionsAndroid, Platform, Linking, View, Text, Pressable } from 'react-native';

export function useCameraPermission() {
  const [granted, setGranted] = React.useState(false);

  const request = React.useCallback(async () => {
    if (Platform.OS === 'android') {
      const res = await PermissionsAndroid.request(
        PermissionsAndroid.PERMISSIONS.CAMERA,
        // 附带说明：解释为什么需要，被拒后再次请求时尤其重要
        { title: '需要相机权限', message: '用于扫描条码与拍摄照片', buttonPositive: '好的' },
      );
      setGranted(res === PermissionsAndroid.RESULTS.GRANTED);
    } else {
      // iOS 侧经统一权限库查询并申请；拒绝后引导设置
      const status = await requestIosCamera();
      setGranted(status === 'granted');
    }
  }, []);

  const openSettings = () => Linking.openSettings();
  return { granted, request, openSettings };
}

// 界面层：只认 granted，降级界面里给出去设置的出路
function ScanScreen() {
  const { granted, request, openSettings } = useCameraPermission();
  if (!granted) {
    return (
      <View style={{ padding: 20 }}>
        <Text>开启相机权限后才能扫码哦</Text>
        <Pressable onPress={request}><Text>开启相机</Text></Pressable>
        <Pressable onPress={openSettings}><Text>去设置里手动打开</Text></Pressable>
      </View>
    );
  }
  return null; // 已授权：渲染相机预览
}
​

权限漏斗：把体验做成可度量的漏斗

权限流程既然是产品流程，就该有产品流程的待遇——埋点度量。四个关键节点的转化构成权限漏斗：进入功能入口的比例、前置说明后仍愿意继续的比例、系统弹窗授权的比例、拒绝后从设置回流的比例。漏斗数据能回答「体验问题出在哪一段」：弹窗前流失大，说明前置说明没讲清价值或时机太早；弹窗本身拒绝多，检查用途文案是否含糊；设置回流少，说明降级界面的引导不够强。iOS 与 Android 的漏斗要分开看——两端弹窗形态与用户预期不同，混在一起的数据会互相污染。这一节的方法与 8.4 的监控思想同源：把「感觉体验不好」变成「哪一步流失了多少」，是体验工程的通用句式。

三方接入：自动链接时代的清单

接入三方能力（地图、支付、推送）如今大多由自动链接代劳——依赖装好即接入构建，不再手动改工程。省事不等于免责，接入清单仍有四项要人工过目：初始化时机（多数 SDK 要求启动早期初始化，但第 6 章说过启动是寸土寸金，低频 SDK 应延迟到首次使用）；双端密钥配置（同一服务两端的密钥体系分开，配置错了只在其中一端报错，排查时容易互相误导）；权限连带（SDK 常自带权限诉求，接入地图可能连带定位权限，要在隐私清单里如实申报）；版本与架构兼容（三方原生库对新架构与引擎版本的适配状态要查证，这是第 8 章构建问题的常见来源）。

新架构升级：兼容层的桥效应

存量项目的模块迁移不需要一步到位。框架提供了互操作兼容层：旧式模块不改造也能在新架构下运行，框架在幕后把旧调用模式翻译成新机制——性能打折但功能无损。据此，务实的迁移路线是「先整体开新架构吃红利，旧模块借兼容层过渡，再按热度逐个改造」：调用最频繁的模块优先改成声明式 TurboModule（7.1 的写法），长尾模块留在兼容层里慢慢搬。改造顺序上还有一条经验：先把事件通道迁移（旧的事件注册机制与新的监听机制行为差异最大），再迁方法调用。升级完成后，按 2.2 节的方法回归双端核心链路，重点盯冷启动前的外部事件与线程敏感场景。

完整案例：相机权限的全链路改造

背景：承接开头的反例，团队决定重做扫码功能的权限体验。操作：申请入口前加自有说明弹窗，讲清用途再触发系统弹窗；iOS 侧补全用途声明文案并与隐私政策对齐；Android 侧区分「可再次请求」与「永久拒绝」两种拒绝态，前者附说明再请求、后者引导设置；两种拒绝态都渲染降级界面——手动输入条码号的备用入口，保证功能不因权限而死；埋点记录各步骤转化，形成权限漏斗。结果：授权率明显提升，设置页回流的二次授权也可见，「扫码是坏的」差评消失。解读：这个案例的题眼是「权限是产品流程，不是技术开关」——四步流程里三步是产品与文案工作。变式：定位权限比相机更敏感（后台定位在两端都有专门限制），流程相同但前置说明要更充分，且要准备「仅使用期间允许」这类中间档位的适配。

本节要点回顾

• 权限四步：上下文说明、贴近使用时机的系统弹窗、降级界面、去设置的出路；
• 两端模型差异：iOS 一次拒绝去设置、Android 可附说明再请求一次，钩子内部消化；
• 用途声明即审核材料：iOS 的文案质量直接影响上架审核；
• 三方接入四清单：初始化时机、双端密钥、权限连带、架构兼容；
• 迁移走兼容层：先开新架构吃红利，高热模块优先改造，事件通道先迁。

桥接篇完结。最后一章把应用送出门：构建、测试、签名上架、热更新，以及长期的守护。