刚接手一个项目要把公司自研的Android APP接入FlexManager设备云平台。需求听起来不大——做个登录就行但真上手之后发现登录这个看似人畜无害的功能恰恰是把APP从本地工具变成云端平台最关键的一道关卡。一通折腾下来踩了不少坑也把整个接入流程梳理顺了。这篇文章就是我的完整实操记录从接口设计思路到Android端代码落地再到联调排错一次性说透。先交代下背景。FlexManager是一个面向物联网和工业设备的设备云平台核心能力是设备接入管理、远程配置、数据采集和运维告警。APP要登录它本质就是通过它暴露的API接口完成账号认证拿到合法的访问凭证之后才能合法地调用设备数据、下发指令。这篇内容适合谁看适合第一次接触设备云平台API接入的Android开发也适合那些想搞清楚登录接口到底在做什么的后端或运维同学。阅读前提你了解Android开发基本概念手上有FlexManager平台的接口文档或类似云平台的API文档知道JSON长什么样。1. 登录前先想明白这个登录接口到底在帮你做什么1.1 登录的本质不是验证账号密码而是换一张通行证很多人一提到登录接口第一反应就是把用户名密码POST给服务器服务器返回成功或失败。对单机软件来说这个理解没毛病但对于设备云平台来说登录要解决的问题远不止验证你是谁。FlexManager这类平台的特点是设备侧和APP侧同时接入云端还要做权限控制、操作审计、多租户隔离。如果APP调每个接口都把用户名密码带一遍等于把钥匙挂在门上既不安全也没法做细粒度控制。所以平台的标准做法是客户端拿账号密码去换一个临时凭证Token之后所有业务接口都用这个Token来证明身份而不是重复提交密码。我在接入时看到FlexManager的文档它的登录接口设计思路跟主流平台一致登录一次换取一个访问令牌令牌有过期时间过期后再通过刷新机制续期。理解了这个逻辑后面做Android端设计才能顺理成章。你可能会问直接照抄平台文档不就行了为什么非要理解设计思路因为不理解本质的话遇到问题只能瞎猜。比如后面我会讲到401错误为什么反复出现、为什么刚登录成功很快又失效这些都能从登录换通行证这个模型里找到答案。1.2 理清角色的边界APP、平台、设备各管什么接入FlexManager之前最值得做的一件事就是把角色边界理清楚。这个平台跟普通业务后台不一样它有三个核心角色APP端你正在开发的Android客户端面向最终用户负责登录、查看设备列表、监控实时数据、下发控制指令。FlexManager云端负责账号体系、设备状态管理、数据汇聚、权限校验和指令转发所有跨端交互都经过它。设备端被云平台纳管的硬件设备它只认云端的下发或者轮询指令不直接跟APP通信。为什么要把这个关系理清楚因为和传统APP直连设备的做法完全不同。我之前做过一个蓝牙直连设备的APP手机和设备走的是本地链路通信不受云端控制。但FlexManager是设备云设备永远在云端挂着APP要操作设备必须经过云端中转。登录接口就是进入这个中转体系的入口。理清这个边界之后你会自然理解几个设计细节APP端不应该保存设备的通信协议细节因为设备的连接状态和数据都归云端管登录返回的Token要有足够的权限范围因为它被云端用来判断这个人能不能操作这台设备APP的登录状态必须跟云端的会话状态保持一致本地说你登录了、云端说你没登录那你什么都干不了。1.3 主流设备云登录API的交互流程长什么样FlexManager的登录接口虽然不同部署版本在路径和参数名上会有差异但整体交互流程遵循行业通用范式。下面这个序列图式描述可以帮助你快速建立整体认知不是严格的UML是流程示意APP端 FlexManager云端 | | | 1. 提交账号密码设备标识 | |-------------------------| | | 2. 校验账号密码、检查设备合法性 | | | 3. 返回访问令牌刷新令牌 | |-------------------------| | | | 4. 携带访问令牌调用业务API | |-------------------------| |... ...|核心步骤只有四个提交凭证、云端校验、下发令牌、带令牌访问。但就是这个看似简单的流程里面藏着大量工程细节。比如提交凭证时要不要做密码加密传输设备标识是什么登录参数里的设备类型有什么讲究令牌过期之后是自动续期还是强制重新登录这些细节我在后面几章逐步展开。2. Android端接入前的准备工作与方案选型2.1 先别急着写代码把环境配置好接入FlexManager登录接口不是一个独立工程它通常要寄生在你已有的APP工程里。所以一开始就要把Android开发环境整理到位。首先确认Android Studio版本和Gradle配置。接入网络库和JSON解析库都需要合适的SDK版本支持。我这次用的组合是Android Studio Flamingo2022.2.1Gradle 8.0compileSdk 33minSdk 24。这个组合的好处是覆盖了绝大多数主流机型同时能用到比较新的API特性。依赖方面建议在项目级build.gradle里统一管理版本号避免出现依赖冲突。实际加的几个关键依赖是OkHttp负责底层网络通信、Retrofit做接口封装、Gson或Moshi做JSON解析。有人会问登录接口就一个有必要上Retrofit吗我的经验是一旦登录成功后面调业务接口是成体系的一堆API早晚要上Retrofit不如一开始就把架子搭好。以下是build.gradle片段注意版本号以你接的FlexManager文档要求的网络版本为准dependencies { implementation com.squareup.okhttp3:okhttp:4.11.0 implementation com.squareup.okhttp3:logging-interceptor:4.11.0 implementation com.squareup.retrofit2:retrofit:2.9.0 implementation com.squareup.retrofit2:converter-gson:2.9.0 implementation com.google.code.gson:gson:2.10.1 }2.2 网络层选型为什么我坚持用Retrofit OkHttp组合现在Android圈子里的网络库有不少选择Volley、OkHttp、Retrofit各有一批拥趸。对于FlexManager这类需要长期维护的物联网云平台接入项目我推荐Retrofit作为顶层封装、OkHttp作为底层实现理由有三个第一个理由是接口定义清晰。Retrofit用注解把API定义和调用方式绑定在一起看代码就能知道调的是哪个路径、用什么方法、传什么参数。登录、刷新令牌、获取设备列表这些接口一目了然后续维护的人不会一头雾水。第二个理由是扩展能力强。FlexManager平台后续可能会加版本号、加签名参数、加自定义Header这些改动在Retrofit的Interceptor机制里做起来很顺手。我在接入过程中就加了一个日志拦截器把每个请求和响应的完整信息打印出来联调时帮了大忙。第三个理由是社区成熟、资料多。就算你完全没接触过这套组合搜一下就能找到大把示例。选择成熟方案意味着你踩过的坑别人大概率也踩过不会卡在某个隐性坑里出不来。下面是定义FlexManager登录接口的Kotlin代码我直接按实际项目风格写interface FlexManagerApiService { POST(api/v1/auth/login) FormUrlEncoded suspend fun login( Field(username) username: String, Field(password) password: String, Field(device_id) deviceId: String, Field(device_type) deviceType: String android ): ResponseLoginResponse }这段代码看着简单但有几个细节说明一下。FormUrlEncoded表示参数以表单形式提交这与FlexManager文档中登录接口的格式约定保持一致如果你在文档里看到的是JSON请求体就要换成Body LoginRequest。suspend关键字是Kotlin协程的标准写法避免回调地狱。ResponseLoginResponse返回类型里包含了HTTP原始状态码这是排查401、500这一类问题时的关键信息不建议去掉。2.3 登录接口的参数设计每个字段都有它的用途FlexManager的登录接口要求传入的参数不是随便写几个字段就算完。我梳理一下典型的参数清单并解释每个参数的用途参数名类型必填说明usernameString是平台分配的用户账号通常由管理员在FlexManager后台创建passwordString是账号密码传输时要考虑加密详见下文device_idString是当前APP安装设备的唯一标识用于绑定设备device_typeString是标识接入端类型Android传android即可app_versionString否APP版本号云端可用于兼容性判断timestampString视平台而定请求时间戳配合签名机制防重放攻击device_id这个参数我曾经没当回事后来发现坑很大。FlexManager平台会记录每台设备的最后登录时间、IP、设备型号如果device_id为空云端可能无法正常维护会话上下文甚至直接拒绝登录。实际项目中device_id可以通过Settings.Secure.ANDROID_ID获取但要注意它在某些OEM设备上可能返回相同值更严谨的做法是结合Build.MODEL等信息生成UUID并持久化保存。password的传输加密问题也需要重视。如果你们的FlexManager服务端开启了HTTPS强烈建议网络传输本身是加密的。但很多企业内网的IoT平台还在用HTTP密码等于裸奔。我在这个项目里做了二次封装客户端对密码做MD5或SHA-256摘要之后再提交服务端做同样处理比对。要注意这只能防止明文被抓包不代表可以替代HTTPS如果有条件还是把服务器换成HTTPS更稳妥。2.4 搞清楚登录返回的数据结构再决定本地存什么登录接口的响应体结构直接决定了你本地要存哪些数据。FlexManager的登录响应我收到的格式类似这样{ code: 0, msg: 登录成功, data: { access_token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.xxx, refresh_token: def50200a9b1c9f1e4e6c5f0d7c9e6f4a60f2c2b8d9e1e2f3a4b5c6d7e8f9a0, expires_in: 7200, token_type: Bearer, user_info: { user_id: u_10086, username: engineer01, display_name: 张工, role: admin } } }用一个表格解读关键字段字段含义使用建议access_token访问令牌请求业务接口时放在Authorization头用于访问受保护资源不可明文存储refresh_token刷新令牌用于在访问令牌过期后换新需安全存储防止被盗用expires_in访问令牌有效秒数示例是7200秒用于本地判断何时刷新token_typeToken类型FlexManager用Bearer拼进请求头时用格式为Bearer access_token值user_info当前登录用户的基础信息缓存到本地供UI展示真正写入代码时我会把这些字段映射成一个LoginResponse数据类data class LoginResponse( val code: Int, val msg: String, val data: LoginData? ) data class LoginData( SerializedName(access_token) val accessToken: String, SerializedName(refresh_token) val refreshToken: String, SerializedName(expires_in) val expiresIn: Long, SerializedName(token_type) val tokenType: String, SerializedName(user_info) val userInfo: UserInfo? ) data class UserInfo( SerializedName(user_id) val userId: String, SerializedName(username) val username: String, SerializedName(display_name) val displayName: String, SerializedName(role) val role: String )Gson的SerializedName注解一定不要偷懒不写如果不写后台字段的命名风格和下划线命名法不一致时解析就会收到null。这是我实际踩过的坑当时排查了半天才发现是字段映射问题。3. 登录实操落地从网络请求到本地存储完整实现3.1 定义Retrofit服务实例记得配上拦截器定义好接口后下一步是创建Retrofit实例。这个环节非常关键因为登录请求本身也需要拦截器来辅助调试和附加公共参数。object ApiClient { private val okHttpClient: OkHttpClient by lazy { OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(15, TimeUnit.SECONDS) .writeTimeout(15, TimeUnit.SECONDS) .addInterceptor(HttpLoggingInterceptor().apply { level HttpLoggingInterceptor.Level.BODY }) .addInterceptor { chain - val requestBuilder chain.request().newBuilder() // 登录接口之外自动附加token if (!chain.request().url.encodedPath.contains(/login)) { val token SessionManager.getAccessToken() if (token.isNotBlank()) { requestBuilder.addHeader(Authorization, Bearer $token) } } requestBuilder.addHeader(Content-Type, application/x-www-form-urlencoded) requestBuilder.addHeader(Accept, application/json) chain.proceed(requestBuilder.build()) } .build() } private val retrofit: Retrofit by lazy { Retrofit.Builder() .baseUrl(BuildConfig.FLEX_MANAGER_BASE_URL) .client(okHttpClient) .addConverterFactory(GsonConverterFactory.create()) .build() } val apiService: FlexManagerApiService by lazy { retrofit.create(FlexManagerApiService::class.java) } }这里我加了三个超时参数connectTimeout设10秒读写超时设15秒。为什么不是无限等因为FlexManager部署在公网设备端的网络环境千差万别如果一直不超时用户会以为APP卡死了。15秒的读写超时是一个比较合理的折中值既要照顾弱网用户也不能把错误无限期挂在界面上。日志拦截器我只建议在debug环境开启线上环境要关掉否则等于把token明文写进日志里。接FlexManager这类工业平台时尤其要注意日志泄露有可能带来生产数据风险。3.2 登录请求的完整实现协程 状态回调写完网络层就可以实现登录功能了。我使用Kotlin协程来处理异步用一个LoginRepository来封装登录逻辑这样Activity和ViewModel都不需要直接跟网络框架打交道。class LoginRepository(private val apiService: FlexManagerApiService) { suspend fun login(username: String, password: String): ResultLoginData { return try { val deviceId DeviceIdUtils.getDeviceId() val response apiService.login( username username, password EncryptUtils.sha256(password), deviceId deviceId, deviceType android ) if (response.isSuccessful) { val body response.body() if (body ! null body.code 0 body.data ! null) { SessionManager.saveSession( accessToken body.data.accessToken, refreshToken body.data.refreshToken, expiresIn body.data.expiresIn ) Result.success(body.data) } else { Result.failure(LoginException(body?.msg ?: 登录失败)) } } else { Result.failure(LoginException(HTTP ${response.code()})) } } catch (e: Exception) { Result.failure(e) } } }这段代码有几个值得注意的工程细节。第一Result.success和Result.failure是Kotlin标准库的Result类型用它能非常方便地在UI层做状态分发。第二我把密码做了SHA-256之后再提交这是之前讲过的安全策略落到了代码里。第三登录成功后立刻调用SessionManager.saveSession保存凭证保证了后续页面拉起时能立刻读取到登录态。如果真的遇到网络异常catch会把异常包装成Failure。但要注意Kotlin Result类型不能直接用response.isSuccessful来做成功判断还要看业务码body.code是不是0很多云平台的HTTP状态码是200但业务码可能是401或500这种情况必须处理。3.3 本地Session管理Token怎么存才安全又方便登录凭证拿到之后本地存储方案非常关键。常见的做法有SharedPreferences、DataStore、文件存储、数据库。我推荐用SharedPreferences或者更现代的DataStore因为Token是简单的键值对数据没必要引入数据库。但安全上要特别注意Android的SharedPreferences默认是明文存储如果手机被root过应用私有目录里的.xml文件可能被直接读到。所以我在项目里对Token做了二次处理明文Token只在内存中存在磁盘上存的是经过加密的密文。方便可行的方案有使用Android Keystore系统生成密钥配合AES加密后存储用Jetpack Security Crypto库的EncryptedSharedPreferences它对开发者透明API形式跟SharedPreferences几乎一样。我用的是EncryptedSharedPreferences整体接入成本很低但能显著提升Token存储安全性。关键片段object SessionManager { private const val PREFS_NAME flex_session private const val KEY_ACCESS_TOKEN access_token private const val KEY_REFRESH_TOKEN refresh_token private const val KEY_EXPIRES_AT expires_at lateinit var prefs: SharedPreferences private set fun init(context: Context) { prefs EncryptedSharedPreferences.create( context, PREFS_NAME, MasterKey.Builder(context) .setKeyScheme(MasterKey.KeyScheme.AES256_GCM) .build(), PrefKeyEncryptionScheme.AES256_SIV, PrefValueEncryptionScheme.AES256_GCM ) } fun saveSession(accessToken: String, refreshToken: String, expiresIn: Long) { prefs.edit() .putString(KEY_ACCESS_TOKEN, accessToken) .putString(KEY_REFRESH_TOKEN, refreshToken) .putLong(KEY_EXPIRES_AT, System.currentTimeMillis() expiresIn * 1000) .apply() } fun getAccessToken(): String prefs.getString(KEY_ACCESS_TOKEN, ) ?: fun getRefreshToken(): String prefs.getString(KEY_REFRESH_TOKEN, ) ?: fun isLoggedIn(): Boolean { val token getAccessToken() return token.isNotBlank() System.currentTimeMillis() getExpiresAt() } fun logout() { prefs.edit().clear().apply() } }这里有一个细节值得讲保存expires_at而不是只保存expires_in。因为你拿到的是相对过期时间而客户端需要的是绝对过期时间。我见过不少项目直接存expires_in然后每次启动时从登录时算起结果没过多久就被误判为已过期用户体验很差。正确做法是登录成功时把System.currentTimeMillis() expiresIn * 1000存下来判断登录态时跟当前时间比较。3.4 登录后的自动续期Refresh Token要提前刷别等失效才动手Token会过期这是设备云平台必然的规则。FlexManager的access_token有效期一般是2小时7200秒。如果想做到用户无感续期正确做法是在有效期还剩一小段时就主动用refresh_token换新的access_token而不是等过期后请求失败再处理。我采用的策略是在调用业务接口时先判断当前Token是否即将过期预留5分钟如果快过期了就先去刷新Token再继续请求。代码片段fun shouldRefreshToken(): Boolean { val expiresAt prefs.getLong(KEY_EXPIRES_AT, 0L) return System.currentTimeMillis() (expiresAt - 5 * 60 * 1000) } suspend fun refreshAccessToken(): Boolean { val refreshToken getRefreshToken() ?: return false val response apiService.refreshToken(refreshToken) if (response.isSuccessful response.body()?.code 0) { saveSession( accessToken response.body()!!.data.accessToken, refreshToken response.body()!!.data.refreshToken, expiresIn response.body()!!.data.expiresIn ) return true } return false }这里要特别注意一点刷新失败时不要无限重试。如果refresh_token也失效了说明用户在云端的会话已经被服务端清理这时候最合理的做法是跳回登录页让用户重新输入账号密码。我定的规则是刷新失败最多重试一次再失败就强制登出。还有一点容易踩坑在并发场景下多个业务接口同时发现token过期可能会并发发起多个刷新请求。这里需要在内存里加一个同步锁保证同时只有一个刷新请求在跑其他请求等待刷新完成后复用新token。我没在代码里贴出这个细节但实际项目中做得好的团队一定会加这个锁。4. 联调与问题排查从拿到文档到跑通登录我踩过的那些坑4.1 联调前的Checklist别让低级错误浪费一下午联调登录接口看起来简单但很多团队就在这里浪费了大量时间。根据我的经验联调前先过一遍这个清单确认FlexManager平台侧已为你创建账号且账号状态是启用而非待激活确认baseUrl配置正确尤其是结尾的/Retrofit对斜杠的处理比较敏感确认后端接口文档里的路径是api/v1/auth/login还是v1/api/auth/login前缀搞错直接404确认参数名大小写和拼写完全一致username和高亮显示的user_name是两码事确认设备标识、密码加密方式等服务端要求的附加字段都已实现。这个清单看着基础但每一项我都踩过对应坑。有一次联调一直返回404排查到最后发现是baseUrl多了一个/Retrofit拼接URL时导致了路径重复。这种错误新手会犯老手也会犯所以写进文档常备无患。4.2 常见错误码与快速处理方案FlexManager的登录接口在出错时会在HTTP状态码之外返回业务错误码。实操中我遇到的错误码汇总成一个速查表错误码HTTP/业务码)含义快速处理方案401Token无效或未授权检查请求头Authorization是否带对刷新Token试试400请求参数错误检查参数格式尤其是device_id和非必填字段是否用了null403账号被禁用或无权限联系FlexManager平台管理员确认账号状态404接口路径不存在核对baseUrl和接口路径尤其是版本前缀429请求频率超限降低登录请求频率SDK层加节流500服务端内部错误抓包发完整报文给后端排查多半不是客户端问题特别说下401。开发阶段遇到401我第一反应不是看代码而是抓包看Authorization头到底拼没拼对。常见问题是Bearer和token之间的空格、token多了换行符、token被截断了。这个错误我见过太多次几乎都出在字符串拼接细节上。4.3 抓包看HTTP报文一眼定位问题所在联调阶段最有效的排查工具就是抓包。Android端抓包常见方案有两个Charles老牌经典桌面端配置好代理后手机WiFi代理指向电脑即可看到完整的HTTP请求与响应。OkHttp的LoggingInterceptor不需要额外工具直接打印到Logcat调试方便但线上要关闭。我建议两个搭配使用。LoggingInterceptor适合快速查看参数和响应体Charles适合看完整的网络链路和证书交互。接FlexManager这种平台时要特别注意Android 7.0以上系统默认不信任用户证书抓HTTPS包时需要在network_security_config.xml里临时允许用户证书联调完记得移除。我的调试习惯是在登录点击事件处加日志打印提交的URL和参数然后看Logcat的输出。如果参数里有中文特殊字符先看是不是编码问题如果响应里有code:-1这种看起来不像HTTP状态码的业务码一定要去查FlexManager的文档说明别拿通用HTTP状态码去套。4.4 设备云平台特有的问题多端登录与设备绑定策略接入FlexManager登录接口时有一个普通APP不会遇到的特殊问题多端登录和设备的绑定关系。FlexManager这类设备云平台通常会限制一个账号同时在多少台设备上登录。如果配置成单端登录新设备登录会把旧设备的会话踢下线。此时旧设备再去调用业务接口就会收到401或者专门的会话冲突错误。我接入时平台默认允许多端登录但踢下线机制存在。所以在Android端要做到两件事一是收到401时不要立即无脑重新登录先判断是不是被踢下线如果是提示用户账号在其他设备登录二是登录成功后拉取账号绑定的设备列表确认当前设备在平台侧是合法设备避免出现登录成功但看不到任何设备的尴尬。这个逻辑看着简单但需要后端配合。建议在拿到user_info后调用一次获取设备列表接口如果返回空列表大概率是权限没分配好比用户主动反馈要体感好很多。5. 登录之后的延伸设计如何让APP在FlexManager体系里走得更稳5.1 Token与权限的联动你的登录接口其实是全家桶的钥匙登录成功后拿到的Token不仅仅用于调设备列表接口FlexManager平台通常会将权限模型贯穿所有业务接口。也就是说Token的作用范围、生效时间、权限边界直接决定用户能在APP里看到多少设备、执行哪些操作。所以登录功能做完之后建议立刻在内存里把user_info中的角色信息缓存起来。FlexManager平台的常见角色有管理员admin、操作员operator、只读观察员viewer。不同角色能做的操作差异很大管理员能改设备参数、下发升级包观察员只能看数据曲线。把这些角色信息用好APP后续的UI展示和功能开关就不用一遍一遍请求服务端来判断了。我在项目里设置了一个UserRoleManager登录时写入角色UI层根据角色决定按钮的显隐。这样做减少了重复请求也提升了体验。要注意权限判断的最终依据永远在云端本地角色缓存只是交互层的优化不能作为安全边界。5.2 登录失败的用户体验设计别用服务器错误四个字糊弄人FlexManager登录失败的原因五花八门账号不存在、密码错误、账号被禁用、设备未绑定、网络超时、版本不兼容。如果APP把所有失败都显示成登录失败请重试用户就只能干瞪眼。我建议的失败提示分级策略网络异常显示网络连接失败请检查网络后重试并提供重试按钮HTTP 404/500显示服务暂时不可用请稍后再试同时内部上报日志账号密码错误精确提示账号或密码错误并且不要在日志中记录密码明文账号被禁用提示该账号已被停用请联系管理员会话被踢下线提示账号在其他设备登录。这个细节很容易被忽略但对用户留存影响很大。做设备云APP的用户往往不是普通消费者而是运维、工厂操作员他们需要的是明确的故障指引而不是冷冰冰的错误码。5.3 代码之外接口文档维护与版本兼容FlexManager平台也在迭代接口的版本号、参数名、Token过期策略都可能变化。Android端接入完成后一定要做两件事一是把接口请求和响应的示例、错误码表、特殊注意事项沉淀成自己团队的接口维护文档。后端同学可能更新了平台侧的字段但没同步通知到APP团队有了一份本地文档至少能快速对齐。二是做好版本兼容逻辑。FlexManager如果升级了接口版本老的接口通常会保留一段时间。APP端可以配置一个接口版本号常量当发现新版本接口可用时平滑切换。我自己在代码里用的方式是在BuildConfig里配置FLEX_API_VERSION上线前由工程师统一维护。6. 几个让我印象深刻的坑写成给后来人的提醒文章最后我想把接入过程中让我印象最深、最耽误时间的几个坑单独拉出来给准备做同样事的同行做个提醒。第一个坑是明文抓包造成的误判。当时我打开Charles想看看登录参数是不是传对了发现密码字段清清楚楚显示在报文里第一反应是传输加密没生效。后来查了半天发现不是加密逻辑有问题而是Charles默认开了SSL解密解密后当然看到的是明文。真正确保传输安全的是HTTPS层而不是我代码里做的那层二次摘要。所以做安全方案时先确认平台侧到底支不支持HTTPS不要自己闷头做了一层还指望它包打天下。第二个坑是同步刷新Token时的竞态。登录功能的逻辑看起来是串行的但APP里有多个业务接口同时触发时可能同时发现token快过期了同时去调刷新接口。服务端可能第一个刷新请求成功、第二个刷新请求因为refresh_token被消费而失败导致业务请求全部401。解决方法是前面提到的加同步锁项目里用Mutex保证同一时间只有一个刷新线程。第三个坑是设备标识的持久化。我第一次实现时直接用ANDROID_ID作为device_id结果发版后运维反馈一部分用户登录失败。排查下来发现部分国产ROM会针对不同应用返回不同甚至变化的ANDROID_ID。后来改成首次启动时生成UUID并保存到本地解决了这个问题。设备标识必须是安装维度恒定的这一点在设备云平台接入中格外重要。把这三个坑写出来的原因是它们都不是那种看一眼文档就能解决的错误而是藏在工程边缘的暗礁。我希望后来人万一遇到相似问题哪怕能少花半天排查时间这这篇文章就没白写。接入FlexManager登录接口本身不难难的是把流程想清楚、把边界理清楚、把异常处理干净。做完这个模块之后我对登录是入口工程这句话有了更深的体会——登录做得好不好直接决定了整个APP在用户心中的专业度。
