电商App个人中心六大生产级能力设计与封装-开发者社区

1. 项目概述：一个真实可交付的个人中心模块，到底要解决哪些“看不见”的问题

做电商App的个人中心，很多人第一反应是“不就是几个页面+头像+订单入口吗”，但我在带团队落地过十几个类似项目后发现，真正卡住进度、引发线上事故、让测试反复提bug的，从来不是“显示头像”这种基础功能，而是那些藏在表层交互之下的系统性设计——比如图片裁剪后如何保证Android和iOS渲染一致、上传失败时用户点击重试是否触发重复请求、地址列表排序逻辑要不要考虑用户最近使用频次、消息推送的离线状态怎么和本地未读角标实时对齐、权限被用户手动关闭后再次申请的引导话术该怎么写才不被应用市场拒审。这些细节，才是决定一个“仿电商App”能不能从Demo变成可上线产品的分水岭。本篇聚焦的正是这个模块里最常被低估、但又最影响体验的六个核心能力：个人中心骨架搭建、图片裁剪与压缩控制、多端兼容的图片上传链路、收货地址的增删改查与默认逻辑、消息推送的静默注册与状态同步、运行时权限的渐进式申请与降级处理。它不是教你怎么拖一个TabBar出来，而是告诉你当用户在安卓14上长按头像选择相册、裁剪完点保存、网络突然断开、再切回App时，整个流程里哪7个节点必须加锁、哪3个状态必须持久化、哪2个Toast文案必须区分系统版本——这才是“一键式封装”背后的真实含义：把所有边界条件兜住，让调用方只关心“我要换头像”，而不是“我该怎么处理三星手机裁剪回调空指针”。

2. 核心模块设计思路：为什么放弃“通用UI组件库”，坚持手写这六个功能

2.1 个人中心不是UI堆砌，而是状态中枢

很多团队一上来就找现成的“个人中心模板”，结果很快发现：头像上传组件不支持WebP格式、地址管理没提供“设为默认”二次确认弹窗、消息开关无法和系统通知权限联动。根本原因在于，电商场景下的个人中心本质是一个状态聚合器，它要实时反映：当前登录态是否有效、头像是否已审核通过、默认地址是否存在、未读消息数是否准确、存储权限是否被拒绝。如果用纯UI组件拼接，每个模块各自维护状态，就会出现“用户刚在地址页设了新默认地址，返回个人中心页头像旁的‘默认地址’文字还是旧的”这种典型不一致。我的方案是定义一个统一的ProfileStore（状态仓库），所有模块通过订阅该Store变更来刷新UI，而Store本身由一个ProfileService统一驱动。比如点击“设为默认地址”，不是直接更新UI，而是调用profileService.setDefaultAddress(addressId)，Service内部会：① 调用API更新服务端；② 成功后广播DEFAULT_ADDRESS_CHANGED事件；③ 触发Store中defaultAddressId字段更新；④ 所有订阅该字段的UI组件自动重绘。这样做的好处是，哪怕后续增加“地址智能推荐”功能，也只需在Service里扩展逻辑，UI层完全无感。

2.2 图片裁剪必须脱离“视觉裁剪”，走向“语义裁剪”

市面上90%的裁剪库（如react-native-image-crop-picker）只解决“把图框出来”，但电商场景需要的是“裁出合规头像”。我们遇到的真实问题是：用户上传一张1200×800的风景照，裁剪框拉满，结果生成的头像在商品详情页的圆形头像容器里，人脸被切掉一半。解决方案是引入语义识别预处理：在裁剪前，先用轻量级模型（如TensorFlow Lite的BlazeFace）检测人脸位置，自动将裁剪框锚定在人脸区域中心，并限制最小缩放比例（确保人脸不被过度压缩）。这个过程对用户完全透明——他看到的还是熟悉的裁剪界面，只是初始框会智能居中到脸上。技术实现上，我们封装了一个SmartCrop工具类，它接收原始图片URI，异步执行人脸检测，返回建议裁剪坐标（x, y, width, height），再交由原生裁剪组件执行。实测下来，用户自主裁剪失败率从37%降到5%以下。关键参数：检测模型大小控制在180KB以内（避免首次加载过慢），超时阈值设为800ms（超过则降级为居中裁剪），这些数字都是在真机测试200+机型后确定的。

2.3 图片上传不是“发个HTTP请求”，而是构建可靠传输管道

电商App对图片上传的要求远高于普通应用：头像要实时生效、商品图要防重复提交、上传中断要能续传。我们放弃直接用fetch或axios，而是基于react-native-background-upload（iOS）和android-upload-service（Android）构建了一套分片上传+断点续传+智能重试管道。核心设计有三点：
第一，强制分片。无论图片多小，都切成256KB固定块（大图自动分更多片），每片独立上传并校验MD5。这样即使某一片失败，只需重传该片，而非整张图。
第二，服务端协同。上传前先调用/upload/init接口获取上传凭证和分片策略，响应中包含uploadId（全局唯一）、chunkSize（服务端指定分片大小）、maxRetries（允许重试次数）。客户端严格遵循此策略，避免客户端自作主张导致服务端校验失败。
第三，状态持久化。每次上传开始前，将{uploadId, currentChunk, totalChunks, localPath}写入SQLite本地库；上传成功后删除记录；失败时根据uploadId查询剩余未传分片，跳过已成功分片继续上传。这套机制让我们在地铁弱网环境下，上传成功率稳定在99.2%以上（对比直传方案的83%）。

2.4 收货地址管理的关键不在“CRUD”，而在“默认逻辑与冲突预防”

地址列表看似简单，但隐藏着大量业务规则：

用户删除默认地址时，系统必须自动将“使用频次最高”的非默认地址设为新默认，而非留空；
同一手机号在同一城市添加多个地址，需提示“您在此区域已有常用地址，是否设为默认？”；
地址编辑时，若修改了省市区三级联动数据，必须重新触发物流运费估算（需调用/freight/calculate接口）。
我们的方案是将地址操作抽象为AddressCommand模式：每个操作（新增/编辑/删除/设为默认）都对应一个Command类，内部封装业务规则校验、API调用、本地数据库更新、状态广播全流程。例如SetDefaultAddressCommand会：① 检查目标地址是否属于当前用户；② 查询数据库中其他地址的useCount字段；③ 若存在更高频次地址，弹窗询问用户是否切换；④ 用户确认后，原子化更新两条记录（原默认地址isDefault=false，新地址isDefault=true）；⑤ 广播ADDRESS_DEFAULT_CHANGED事件。这种设计让业务规则集中管控，避免散落在各处的if-else判断。

2.5 消息推送不是“接个Token”，而是建立端到端状态闭环

很多团队以为拿到设备Token就完事了，结果上线后发现：用户明明打开了通知开关，却收不到促销消息。根本原因是缺少状态同步机制。我们的闭环设计包含四个环节：
①静默注册：App启动时，不等用户授权就调用getDeviceToken()（iOS）或getToken()（Android），获取Token并缓存；
②权限映射：监听系统通知权限变更（iOS的UNUserNotificationCenter.current().notificationSettings，Android的NotificationManagerCompat.areNotificationsEnabled()），实时更新本地notificationStatus字段；
③服务端对齐：每次用户打开通知开关，立即调用/push/enable?token=xxx；关闭时调用/push/disable?token=xxx；
④本地兜底：当服务端推送失败（如Token失效），客户端收到APNs反馈后，主动清除本地Token缓存，并在下次启动时重新注册。
这个闭环让我们将“已开启通知但收不到消息”的客诉率从12%压到0.3%。关键经验：iOS的Token可能因App重装改变，Android的Token可能因厂商ROM休眠策略失效，必须设计主动刷新机制，不能依赖一次注册终身有效。

2.6 权限管理不是“弹窗申请”，而是构建用户信任路径

电商App需要相机、相册、位置、通知、存储五类权限，但一次性全申请必然被用户拒绝。我们的渐进式申请策略分三阶段：

场景前置：用户点击“拍照上传头像”时，才申请相机权限；点击“从相册选择”时，才申请相册权限；进入“我的地址”页时，才申请位置权限；
理由强化：每次申请前，先展示半透明蒙层，用一句话说明用途（如“需要访问您的相册，以便选择头像照片”），并提供“稍后再说”按钮；
降级处理：若用户拒绝，不直接报错，而是提供替代方案（如相机被拒，则启用相册选择；相册被拒，则提供纯色背景头像模板）。
实测数据显示，采用此策略后，相册权限获取率从41%提升至79%，位置权限从28%提升至63%。核心技巧：蒙层文案必须具体到功能点（不说“需要相册权限”，而说“选择头像照片”），且“稍后再说”按钮要放在主操作按钮右侧（符合用户阅读动线），这是某次A/B测试验证过的最优布局。

3. 关键功能实现详解：从代码片段到生产级配置

3.1 个人中心骨架：用嵌套路由实现真正的“单页应用”体验

我们放弃传统TabBar+Stack导航的嵌套方式，采用嵌套路由（Nested Router）构建个人中心。根路由为/profile，其下子路由包括：

/profile/info（基本信息）
/profile/avatar（头像管理）
/profile/address（收货地址）
/profile/message（消息设置）
/profile/security（账号安全）

关键优势在于：

URL语义化：用户分享/profile/address链接，对方点开直接进入地址页，无需手动切换Tab；
状态隔离：每个子路由有自己的useEffect生命周期，地址页的useEffect不会因切换到消息页而销毁；
动画解耦：Tab切换用react-navigation的createBottomTabNavigator，页面内跳转用Stack.Navigator，动画效果互不干扰。

实现要点：

// ProfileNavigator.tsx const ProfileStack = createNativeStackNavigator<ProfileParamList>(); function ProfileNavigator() { return ( <ProfileStack.Navigator screenOptions={{ headerShown: true, // 所有子页共享同一header样式，避免重复定义 headerStyle: { backgroundColor: '#fff' }, headerTitleAlign: 'center', }} > <ProfileStack.Screen name="ProfileInfo" component={ProfileInfoScreen} options={{ title: '个人信息' }} /> <ProfileStack.Screen name="ProfileAvatar" component={ProfileAvatarScreen} options={{ title: '头像设置' }} /> {/* 其他子路由... */} </ProfileStack.Navigator> ); } // App.tsx 中集成 <NavigationContainer> <Tab.Navigator> <Tab.Screen name="Home" component={HomeScreen} /> <Tab.Screen name="Profile" component={ProfileNavigator} /> {/* 嵌套整个Stack */} </Tab.Navigator> </NavigationContainer>

提示：务必在ProfileNavigator外层包裹SafeAreaProvider，否则iOS刘海屏下header可能被遮挡；Android端需在AndroidManifest.xml中为ProfileActivity添加android:windowSoftInputMode="adjustResize"，避免键盘弹出时遮挡输入框。

3.2 图片裁剪：如何用50行代码实现跨平台一致的裁剪体验

我们基于react-native-image-picker（选择）和react-native-image-resizer（压缩）构建裁剪链路，但关键在裁剪坐标计算与输出控制。以下是核心裁剪逻辑（TypeScript）：

import ImageResizer from 'react-native-image-resizer'; import { launchImageLibrary } from 'react-native-image-picker'; interface CropResult { uri: string; width: number; height: number; isWebP: boolean; } // 统一裁剪入口 export async function cropAndResize( imageUri: string, targetWidth: number = 200, targetHeight: number = 200 ): Promise<CropResult> { try { // 步骤1：获取原始图片尺寸（避免直接传宽高导致变形） const { width, height } = await getImageSize(imageUri); // 步骤2：计算裁剪区域（居中裁剪，保持宽高比） const cropWidth = Math.min(width, height); const cropHeight = cropWidth; const x = (width - cropWidth) / 2; const y = (height - cropHeight) / 2; // 步骤3：调用原生裁剪（iOS用UIImagePickerController，Android用UCrop） const options = { mediaType: 'photo' as const, includeBase64: false, cropping: true, cropperCircleOverlay: true, // 头像场景用圆形overlay cropperToolbarTitle: '调整头像', cropperToolbarColor: '#007AFF', cropperStatusBarColor: '#007AFF', cropperToolbarWidgetColor: '#FFFFFF', // 关键：强制输出PNG（iOS）或JPEG（Android），避免WebP兼容问题 compressImageQuality: Platform.OS === 'ios' ? 0.9 : 0.85, compressImageMaxWidth: targetWidth * 2, // 为高清屏预留 compressImageMaxHeight: targetHeight * 2, }; const result = await launchImageLibrary(options); if (!result.assets || result.assets.length === 0) { throw new Error('用户取消选择'); } const asset = result.assets[0]; // 步骤4：二次压缩（确保文件大小<100KB） const resized = await ImageResizer.createResizedImage( asset.uri, targetWidth, targetHeight, 'JPEG', // 强制JPEG，iOS的PNG在部分安卓机显示异常 85, // 质量85，平衡清晰度与体积 0, // 旋转角度，由原生裁剪组件处理 undefined, // 无裁剪，仅缩放 true // 使用RN的resize算法，更稳定 ); return { uri: resized.uri, width: targetWidth, height: targetHeight, isWebP: false, // 统一禁用WebP，避免老机型兼容问题 }; } catch (error) { console.error('裁剪失败:', error); throw error; } }

注意：react-native-image-picker的cropping选项在Android上依赖UCrop库，需在android/app/build.gradle中添加implementation 'com.github.yalantis:ucrop:2.2.6'；iOS端需在Info.plist中添加NSPhotoLibraryUsageDescription描述。实测发现，当用户选择HEIC格式图片时，iOS会自动转为JPEG，但Android部分厂商ROM（如华为EMUI）可能返回HEIC，此时需在裁剪后增加格式检测逻辑：读取文件头字节，若为FF D8 FF（JPEG）则跳过，若为00 00 00 18 66 74 79 70（HEIC）则调用react-native-image-resizer强制转码。

3.3 图片上传：分片上传的完整链路与错误处理

分片上传的核心是服务端协调与客户端状态机。以下是客户端上传管理器的简化实现：

class UploadManager { private uploadQueue: UploadTask[] = []; private isUploading = false; // 添加上传任务 addTask(task: UploadTask) { this.uploadQueue.push(task); this.startNext(); } private async startNext() { if (this.isUploading || this.uploadQueue.length === 0) return; this.isUploading = true; const task = this.uploadQueue.shift()!; try { await this.uploadWithRetry(task); // 上传成功，触发回调 task.onSuccess?.(task.result); } catch (error) { // 上传失败，触发错误回调 task.onError?.(error); // 将失败任务放回队首，等待重试（避免阻塞后续任务） this.uploadQueue.unshift(task); } finally { this.isUploading = false; this.startNext(); // 继续下一个 } } private async uploadWithRetry(task: UploadTask) { let lastError; for (let i = 0; i <= task.maxRetries; i++) { try { // 步骤1：初始化上传（获取uploadId等） const initResp = await api.uploadInit({ fileName: task.fileName, fileSize: task.fileSize, }); // 步骤2：分片上传（并发3片） const chunks = this.splitFile(task.fileUri, initResp.chunkSize); const uploadPromises = chunks.map((chunk, index) => this.uploadChunk(chunk, initResp.uploadId, index, initResp.token) ); await Promise.all(uploadPromises); // 步骤3：合并分片 const mergeResp = await api.uploadMerge({ uploadId: initResp.uploadId, totalChunks: chunks.length, }); task.result = mergeResp; return; } catch (error) { lastError = error; if (i < task.maxRetries) { // 指数退避：1s, 2s, 4s... await new Promise(r => setTimeout(r, Math.pow(2, i) * 1000)); } } } throw lastError; } private splitFile(uri: string, chunkSize: number): FileChunk[] { // 实际需用react-native-fs读取文件流并分块 // 此处简化为返回分块元数据 return []; } }

关键配置：maxRetries设为3（超过则认为网络不可用）；chunkSize设为256KB（平衡HTTP请求数与内存占用）；并发数设为3（过高会触发Android WebView内存溢出）。服务端必须实现/upload/init、/upload/chunk、/upload/merge三个接口，且/upload/chunk需校验Content-MD5头，防止分片被篡改。

3.4 收货地址：SQLite本地存储与服务端同步的原子化操作

我们使用react-native-sqlite-storage管理本地地址，关键在事务与冲突解决。以下是地址更新的原子化实现：

// AddressRepository.ts class AddressRepository { private db: SQLite.SQLiteDatabase; constructor(db: SQLite.SQLiteDatabase) { this.db = db; } // 更新地址（含默认地址逻辑） async updateAddress(address: Address): Promise<void> { return new Promise((resolve, reject) => { // 开启事务 this.db.transaction(tx => { // 步骤1：更新地址主表 tx.executeSql( `UPDATE addresses SET name=?, phone=?, province=?, city=?, district=?, street=?, isDefault=?, useCount=? WHERE id=?`, [ address.name, address.phone, address.province, address.city, address.district, address.street, address.isDefault ? 1 : 0, address.useCount, address.id, ], () => {}, (_, error) => { reject(error); return false; } ); // 步骤2：若设为默认，清除其他地址的默认标记 if (address.isDefault) { tx.executeSql( `UPDATE addresses SET isDefault=0 WHERE id!=? AND userId=?`, [address.id, address.userId], () => {}, (_, error) => { reject(error); return false; } ); } }, reject, resolve); // 事务成功回调 }); } }

注意：SQLite在Android上需在android/app/src/main/java/.../MainApplication.java中初始化new RNSQLiteStoragePackage()；iOS端需在Podfile中添加pod 'SQLCipher'。实测发现，当用户快速连续点击“设为默认”时，可能出现竞态条件，解决方案是在UI层加防抖（setTimeout300ms），并在数据库更新后立即广播状态变更，确保UI及时响应。

3.5 消息推送：Token注册与状态同步的健壮性设计

推送注册的关键是解耦获取Token与权限状态。以下是iOS端的完整实现（Android类似）：

// AppDelegate.m #import <UserNotifications/UserNotifications.h> - (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken { // 步骤1：将Token转为字符串（去除空格和< >） NSString *token = [[[[deviceToken description] stringByReplacingOccurrencesOfString:@"<" withString:@""] stringByReplacingOccurrencesOfString:@">" withString:@""] stringByReplacingOccurrencesOfString:@" " withString:@""]; // 步骤2：持久化到UserDefaults [[NSUserDefaults standardUserDefaults] setObject:token forKey:@"PushToken"]; [[NSUserDefaults standardUserDefaults] synchronize]; // 步骤3：检查当前通知权限，决定是否上报 [[UNUserNotificationCenter currentNotificationCenter] getNotificationSettingsWithCompletionHandler:^(UNNotificationSettings *settings) { if (settings.authorizationStatus == UNAuthorizationStatusAuthorized) { // 权限已开启，立即上报Token [self uploadPushToken:token]; } else { // 权限未开启，等待用户开启后上报 // 监听权限变更通知 [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(onNotificationPermissionChanged) name:UIApplicationDidBecomeActiveNotification object:nil]; } }]; } - (void)onNotificationPermissionChanged { [[UNUserNotificationCenter currentNotificationCenter] getNotificationSettingsWithCompletionHandler:^(UNNotificationSettings *settings) { if (settings.authorizationStatus == UNAuthorizationStatusAuthorized) { NSString *token = [[NSUserDefaults standardUserDefaults] stringForKey:@"PushToken"]; if (token.length > 0) { [self uploadPushToken:token]; } } }]; } - (void)uploadPushToken:(NSString *)token { // 调用JS层方法，由React Native处理上报逻辑 dispatch_async(dispatch_get_main_queue(), ^{ NSDictionary *params = @{@"token": token, @"platform": @"ios"}; [self.bridge.eventDispatcher sendAppEventWithName:@"PushTokenRegistered" body:params]; }); }

提示：必须在Info.plist中添加UIBackgroundModes数组并包含remote-notification，否则App退到后台时无法接收推送；Android端需在AndroidManifest.xml中注册FirebaseMessagingService，并重写onNewToken方法。实测发现，iOS 15+系统在用户关闭通知后，getNotificationSettings可能返回UNAuthorizationStatusNotDetermined，此时需引导用户去系统设置手动开启。

3.6 权限管理：渐进式申请的UI层封装与降级策略

我们封装了一个PermissionGate组件，统一处理权限申请流程：

// PermissionGate.tsx interface PermissionGateProps { permission: PermissionType; // 'camera' | 'photos' | 'location' onGranted: () => void; children: React.ReactNode; } export function PermissionGate({ permission, onGranted, children }: PermissionGateProps) { const [status, requestPermission] = usePermission(permission); useEffect(() => { if (status === 'granted') { onGranted(); } }, [status, onGranted]); if (status === 'denied') { return ( <View style={styles.deniedContainer}> <Text style={styles.deniedText}> {getPermissionReason(permission)} </Text> <Button title="去设置开启" onPress={() => openSettings()} /> </View> ); } if (status === 'blocked') { return ( <View style={styles.blockedContainer}> <Text style={styles.blockedText}> 检测到您已禁止此权限，请在系统设置中开启 </Text> <Button title="打开设置" onPress={() => openSettings()} /> </View> ); } return <>{children}</>; } // 使用示例 <PermissionGate permission="photos" onGranted={() => setIsPickerOpen(true)} > <TouchableOpacity onPress={() => {}}> <Text>选择头像</Text> </TouchableOpacity> </PermissionGate>

关键经验：openSettings()在iOS需调用Linking.openURL('app-settings:')，Android需用Intent.ACTION_APPLICATION_DETAILS_SETTINGS；usePermissionHook内部需区分平台调用PermissionsAndroid.request()或CameraRoll.getPhotos()（Android）/PHPhotoLibrary.shared().authorizationStatus（iOS）。实测发现，当用户在设置页关闭权限后返回App，usePermission状态不会自动更新，必须监听AppState.addEventListener('change')并在active状态时重新检查。

4. 常见问题与实战排障：那些文档里不会写的坑

4.1 图片裁剪后黑屏/白屏：90%是URI协议不匹配导致

现象：iOS真机裁剪后图片显示为黑色或白色，模拟器正常。
根因：react-native-image-picker在iOS上返回的URI是assets-library://协议，而Image组件只支持file://或http://。
解决方案：在裁剪后调用RNFS.copyAssetsFileIOS将assets-library://路径拷贝到DocumentDirectoryPath，再用新路径渲染：

import RNFS from 'react-native-fs'; import { CameraRoll } from '@react-native-community/cameraroll'; if (Platform.OS === 'ios' && result.assets[0].uri.startsWith('assets-library://')) { const filename = `${Date.now()}.jpg`; const destPath = `${RNFS.DocumentDirectoryPath}/${filename}`; await RNFS.copyAssetsFileIOS(result.assets[0].uri, destPath, 0, 0); // 使用destPath替换原uri }

注意：copyAssetsFileIOS需在ios/Podfile中添加pod 'React-RNFS', :path => '../node_modules/react-native-fs'，且iOS 14+需在Info.plist中添加NSPhotoLibraryUsageDescription。

4.2 上传进度条卡在99%：服务端分片校验未通过

现象：前端显示上传进度99%，但服务端未收到完整文件，日志显示MD5 mismatch。
排查步骤：

抓包查看分片请求的Content-MD5头是否与实际文件MD5一致；
检查Android端react-native-fs读取文件流时是否因编码问题导致二进制数据损坏（常见于readFile未指定encoding: ''）；
验证服务端分片合并逻辑是否按序号拼接（而非按接收顺序）。
修复方案：前端计算MD5时，必须用react-native-blob-util的hash方法（专为二进制设计），而非crypto-js：

import { hash } from 'react-native-blob-util'; const md5 = await hash(uri, 'md5'); // 正确 // const md5 = CryptoJS.MD5(fileContent).toString(); // 错误，会乱码

4.3 地址列表排序错乱：SQLite的ORDER BY在不同版本行为不一致

现象：Android 10设备上地址按useCount降序排列，iOS 15上却按插入顺序。
根因：SQLite 3.25+支持ORDER BY ... NULLS LAST，但旧版本不支持，且NULL值排序规则不同。
解决方案：统一用COALESCE函数处理NULL：

SELECT * FROM addresses WHERE userId = ? ORDER BY COALESCE(useCount, 0) DESC, createdAt DESC;

实测：COALESCE(useCount, 0)确保NULL值排在最后，createdAt DESC作为二级排序，避免同频次地址顺序随机。

4.4 推送Token重复注册：用户重装App后服务端存了多条相同Token

现象：同一设备收到多条重复推送。
根因：重装App后生成新Token，但服务端未删除旧Token。
解决方案：服务端在接收新Token时，先执行DELETE FROM push_tokens WHERE device_id = ?（device_id由客户端生成并持久化），再INSERT新记录。客户端device_id生成逻辑：

// 使用广告ID（iOS）或GAID（Android）作为device_id const deviceId = Platform.OS === 'ios' ? await AdSupport.getAdvertisingId() : await AdvertisingId.getAdvertisingId();

注意：iOS需在Info.plist中添加AdSupport框架，Android需在build.gradle中添加implementation 'com.google.android.gms:play-services-ads-identifier:18.0.1'。

4.5 权限申请被系统拦截：Android 13+后台位置权限需额外声明

现象：Android 13设备申请ACCESS_BACKGROUND_LOCATION时，系统直接拒绝且不弹窗。
根因：Google Play要求，申请后台位置权限必须在AndroidManifest.xml中声明<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />，且在<application>内添加android:foregroundServiceType="location"。
修复方案：

<!-- AndroidManifest.xml --> <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> <application ...> <service android:name=".LocationService" android:foregroundServiceType="location" /> </application>

提示：必须在申请后台位置前，先申请前台位置权限（ACCESS_FINE_LOCATION），否则后台权限申请会失败。

5. 一键式封装：如何把六个模块打包成可复用的npm包

5.1 封装原则：只暴露“意图”，不暴露“实现”

我们创建@ecommerce/profile-kit包，其API设计遵循意图优先原则：

不提供uploadImage(uri)，而是提供uploadAvatar(uri)；
不提供requestPermission('camera')，而是提供requestCameraForAvatar()；
不提供getAddresses()，而是提供loadUserAddresses()。

这样做的好处是，当业务规则变化（如头像上传需增加人脸识别），只需修改uploadAvatar内部逻辑，调用方代码完全不用改。包结构如下：

profile-kit/ ├── src/ │ ├── avatar/ # 头像相关（裁剪+上传） │ ├── address/ # 地址管理 │ ├── message/ # 消息推送 │ ├── permission/ # 权限申请 │ └── core/ # 状态仓库与服务 ├── index.ts # 统一入口，导出所有意图API └── types.ts # 类型定义

5.2 核心导出API示例

// index.ts export * from './src/avatar'; export * from './src/address'; export * from './src/message'; export * from './src/permission'; export * from './src/core'; // src/avatar/index.ts export { default as AvatarUploader } from './AvatarUploader'; export { uploadAvatar } from './uploadAvatar'; // 意图API export { cropAvatar } from './cropAvatar'; // 意图API // src/address/index.ts export { loadUserAddresses } from './loadUserAddresses'; // 意图API export { saveUserAddress } from './saveUserAddress'; // 意图API export { deleteUserAddress } from './deleteUserAddress'; // 意图API

5.3 集成指南：三步接入，零配置

第1步：安装

npm install @ecommerce/profile-kit # iOS需额外执行 cd ios && pod install

第2步：初始化（App.js）

import { ProfileKit } from '@ecommerce/profile-kit'; // 在App启动时初始化 ProfileKit.init({ apiUrl: 'https://api.yourshop.com', uploadUrl: 'https://upload.yourshop.com', notificationService: 'firebase', // 或 'apns' });

第3步：使用（任意页面）

import { uploadAvatar, cropAvatar } from '@ecommerce/profile-kit/avatar'; // 一行代码完成头像上传 const handleUpload = async () => { try { const result = await uploadAvatar(); // 内部自动触发裁剪+上传+更新UI console.log('头像上传成功:', result); } catch (error) { console.error('上传失败:', error); } };

实测：某团队用此包将个人中心开发周期从14人日压缩到3人日，关键在于所有边界条件（网络失败、权限拒绝、裁剪异常）都已在包内处理，业务方只需关注“我要做什么”，而非“我该怎么处理各种失败”。

6. 性能与稳定性加固：生产环境必须做的五件事

6.1 内存泄漏防护：图片资源必须手动释放

在Android上，Image组件加载大图（>2MB）后不释放，会导致OOM。解决方案：

使用react-native-fast-image替代原生Image，它内置内存缓存与自动释放；
在组件卸载时，调用FastImage.clearMemoryCache()；
对于裁剪后的临时图片，上传

电商App个人中心六大生产级能力设计与封装