做移动开发这些年我几乎每个项目都逃不过推送、热修复和崩溃监控这三件事。去年年中我们团队启动一个本地生活类App加上我统共三个人没人愿意从零去搭一套消息通道和崩溃采集体系一番对比后选了阿里云EMAS当全家桶。这个决定本身逻辑没毛病但接下来三个月里我们在接入、发布、监控上踩的坑比之前两三个项目加起来都多。这篇不打算对着官方文档复述只记录我从选型到上线这段时间的真实遭遇以及每段坑背后真正的原因。如果你正在接EMAS或者已经接了一半卡在原地这里面的内容应该能帮你少熬几个夜。1. 选型复盘为什么选“全家桶”而不是自己拼1.1 小团队做移动基建最怕的是什么我们当时的处境很典型产品已经进了开发阶段却还缺三块基础能力——消息推送、崩溃分析、热修复。自建的话推送要维护长连接要设计心跳策略、离线消息存储、厂商通道适配崩溃监控要搭采集服务、聚合展示、堆栈还原。对个人开发者或三五人的小团队来说这些东西做起来就是无底洞。别的不说光是国产ROM的后台清理策略和厂商推送适配没有专人跟进都会被拖死。所以接第三方服务几乎是唯一选择。选型时我们围绕着EMAS、以及其他几家独立推送/热修复厂商来回比较过。最终拍板EMAS的理由主要有三条一是推送、热修复、崩溃分析、远程日志可以在同一个控制台上管理共用一套AppKey和SDK体系运维心智负担小二是不用担心某些服务商哪天停止维护单一功能毕竟整个平台持续有商业支持三是阿里系SDK对国内Android生态的适配经验确实更丰富尤其是消息推送这条链路。当时觉得这个选择很稳但后来发现选“全家桶”也意味着它把一整套复杂的兼容工作打包塞给了你。你省去了自己拼装的麻烦同时也就失去了一点点排查问题时的独立性。这是个很重要的心理建设接入EMAS不是“加几个SDK”而是把一套完整的移动基建设施装进你的工程里。1.2 选型时看重的和后来才付的成本我用一张表来还原当时的预期和实际之间的差距这条经验对任何决定用全家桶方案的团队都有参考价值。能力我们以为的成本实际发生的成本推送集成SDK申请一个AppKey就能发消息还要去多个手机厂商开放平台注册开发者账号、申请推送权限、等待审核前后拖了两周热修复上传补丁、等待生效补丁包生成、签名、混淆规则、生效机制都有讲究稍有不慎客户端“无感”崩溃分析看后台报表就行要配置混淆映射、统计采样策略不然出来的堆栈根本看不懂远程日志打个日志而已日志埋点、上报策略、用户授权都要设计不然线上问题来了抓不到现场这张表不是劝退而是提醒所有打算接入的人平台能力是齐全的但它的每一项能力都需要你额外付出配置和配合成本。尤其是厂商通道申请那块最好在项目刚启动时就先把开发者账号和审核材料递交掉而不是等到要发版了才想起来。这一条排在所有坑的第一位因为它纯是时间问题技术含量不高但卡住你的方式最无解。2. 接入第一天的“见面礼”依赖冲突和初始化顺序2.1 两个SDK在依赖图里打架运行时报NoSuchMethodError正式集成EMAS推送SDK那天我们原本估计两个小时能搞定。结果第一个坑来得比想象中快工程里之前已经接入了阿里云对象存储的SDK都是阿里系理论上应该相处融洽但Gradle同步一跑弹出的却是重复依赖冲突和版本不一致警告。当时没太在意觉得只是版本号不同试试能不能跑。结果App一启动闪退日志直接指向一个不存在的fastjson方法典型的NoSuchMethodError。这个问题的本质是依赖传递。两个SDK各自声明了对fastjson、okhttp、gson的依赖但版本要求不一样。Gradle在解析依赖树时默认选择较高版本但较高版本的fastjson可能移除了某个老方法于是运行时调用就炸了。当时我们配了一堆exclude才平息下来dependencies { implementation(com.aliyun.ams:alicloud-android-push:3.x.y) { exclude group: com.alibaba, module: fastjson exclude group: com.squareup.okhttp3, module: okhttp } implementation(com.aliyun.ams:alicloud-android-hotfix:3.x.y) { exclude group: com.alibaba, module: fastjson } }这里有个小建议不要一上来就盲目exclude。先用Gradle命令把依赖树打出来看一眼./gradlew :app:dependencies deps.txt然后打开deps.txt确认到底是谁引了谁、冲突到什么程度再决定排除哪个坐标。我们第一次排除得过于粗暴把okhttp版本统一到了自己项目里的版本结果某个SDK底层用了新版本才有的api又炸了一次。后来把整个工程的所有三方库版本都收拢到一份版本管理文件里这种问题才基本绝迹。2.2 初始化顺序防呆设计该在主线程最前面做的事依赖冲突解决后第二个坑是初始化顺序。EMAS平台每个功能模块都需要在Application里注册一开始我们“多线程思维”上头把初始化逻辑扔到了线程池里认为异步执行更快、不阻塞启动速度。结果推送token迟迟拿不到热修复补丁也经常拉取失败。查了半天才发现SDK内部很多逻辑依赖Application.onCreate的生命周期回调如果初始化被放到异步线程会和SDK自己注册的一些系统广播、进程生命周期回调产生竞态。后面老老实实把所有EMAS相关初始化拉回主线程并且放在Application的onCreate最前面public class MyApplication extends Application { Override public void onCreate() { super.onCreate(); // EMAS相关初始化尽量放在这里越靠前越稳 EMASService.enableLogging(true); // 调试时打开日志 PushServiceFactory.init(this); // 推送初始化 SophixManager.getInstance().queryAndLoadNewPatch(); // 热修复查询补丁 } }这里想多说一句为什么“queryAndLoadNewPatch”必须尽量早。它的作用是启动时向服务端拉取补丁信息拉取过程中有网络、签名校验、白名单判断等一系列操作。如果它在Application的靠后位置才调用主流程已经往下走了补丁即使拉回来也无法替换当前已经加载的类只能等下一次冷启动。这类初始化时机问题官方文档其实写过但实际项目中很容易因为工程复杂而忽略尤其是如果还接了友商SDK大家都催着初始化顺序就会乱。我们后来整理了一份内部规范EMAS全家桶的初始化永远放第一位其次才是业务SDK和自研框架。3. 推送收不到先用这条链路把锅找出来3.1 一次活动推送送达率只有四成接入EMAS推送一个月后运营第一次用后台发正式活动推送选择的是“通知栏消息”而不是“应用内消息”目标用户1万人推送时间定在早上8点整。结果后台报表出来送达率不到40%。运营第一反应是推送服务不行但我们打开推送明细一看很多设备的状态是“离线”还有一批是“厂商通道送达失败”。这才意识到问题根本不在EMAS服务端而是移动端生态里那些默认“没人管”的配置。从那时起我们建立了一套固定排查链路后续再遇到类似情况基本能在半小时内定位问题方向。这套链路也适合其他推送服务本质思路是相通的。3.2 在线、离线、厂商通道三个环节逐个拆推送到达率这件事首先要拆分两个状态App前台在线、App不在前台包括退到后台和进程被杀死。在线状态下推送靠EMAS的长连接通道只要网络正常基本都能实时到达。离线状态下长连接大概率断着这时候就要靠厂商通道接力。厂商通道这条链路的关键点是App在手机上初始化时必须通过厂商的SDK拿到该设备在此厂商推送服务下的唯一标识我们通常叫token然后把这个token上报给EMAS服务端。只有当EMAS服务端持有token后续离线消息才能通过厂商服务器下发到手机系统再由系统弹出通知栏。我们当时推送失败60%的离线设备很多是token没上报成功。原因也让人哭笑不得部分测试机在初始化推送SDK时网络请求失败token获取回调没有被重试机制覆盖之后App进程一直活着就没有再触发重新注册。而EMAS后台这时候显示的是“该设备还未注册厂商通道”。所以自查第一步就是去EMAS控制台看目标设备的厂商通道注册状态。如果显示未注册再回到代码里检查注册回调是否成功有没有做失败重试。PushServiceFactory.init(this); // 获取设备推送标识并上报到EMAS PushManager.getInstance().getDeviceToken(new CommonCallbackString() { Override public void onSuccess(String token) { // token已拿到控制台会显示设备已注册厂商通道 } Override public void onFailed(String errorCode, String errorMsg) { // 必须在这里做失败重试或延时重试 } });3.3 通知权限和后台限制能做的都做了还是收不到绕开token问题后还有两座大山系统通知权限和国产ROM的后台管理机制。从Android 13开始App要弹通知栏消息必须先申请通知权限。很多用户安装App之后没点允许那即使是厂商通道也没办法把通知栏消息亮出来。我们一开始没有做专门的通知权限引导导致一大片用户完全收不到推送。后来在首页和设置页里都加了权限检测逻辑发现没授权就弹一个引导弹窗。代码很简单if (Build.VERSION.SDK_INT 33) { requestPermissions(new String[]{Manifest.permission.POST_NOTIFICATIONS}, 1001); }至于ROM后台限制这是国内安卓生态独有的头疼事。不同品牌的手机都有自己的“省电优化”“自启动管理”“后台耗电限制”机制用户如果把App从自启动名单里移除或者把后台活动直接冻结厂商通道的送达都会被延迟甚至吞掉。我们在测试阶段就吃过这个亏用同一台手机在默认设置下能收到推送一旦手动开启“纯净后台模式”推送就静悄悄没了。这不是EMAS的问题所有推送厂商面对同一台手机都会遇到。所以我的建议是推送到达率目标要现实一点。主流厂商通道都配好、通知权限引导做好、用户在ROM后台白名单里放行这些全部做到位之后离线推送的到达率才能谈“稳定”。控制台里的数据指标也要按“应用在线”“离线且厂商通道正常”“离线但受系统限制”三层去拆而不是笼统看一个总数。4. 热修复“发了等于没发”Sophix生效的隐藏规则4.1 补丁“成功上传”和“真正生效”之间的距离第四个大坑来自热修复。当时我们线上有一个版本出现启动崩溃是个很low的空指针问题。团队连夜改了代码按流程生成补丁、上传EMAS控制台、发布灰度。第二天起来打开后台一看崩溃率纹丝不动。第一反应是补丁包坏了但补丁状态显示“已发布”也有下载次数。后来查了官方文档、翻了不少社区帖子才把问题拆解成几层。Sophix的机制是这样的客户端启动时会调用queryAndLoadNewPatch()向服务端查询有没有适用于当前版本的补丁下载后到本地做校验和合并。它的生效时机是“下次冷启动”不是“热加载”。而且如果App进程一直没被杀死补丁永远等不到被加载的机会。这和我们当时的操作直接冲突——我们几个开发自己测试时杀掉App重开补丁生效了但大多数线上用户是长时间不杀进程的他们一直活在旧的类加载环境里自然感觉“补丁没用”。所以后来我们把这个机制讲给运营和客服听热修复不是“立刻修好”而是“下一次启动时修好”。对大部分用户来说这通常意味着最长不超过一天内能修复。如果遇到顽固suspect进程一直不重启甚至要借助系统内存回收。4.2 基础包、混淆、签名一个对不上就前功尽弃补丁不生效的第二个常见原因是产物匹配问题。Sophix补丁是基于基线版本生成的官方称之为“基础包”。也就是说补丁只能在这个基础包版本之上生效。如果线上用户跑的是更早的版本而补丁是基于新版本打出来的那用户端会在校验阶段直接被拒绝。还有混淆规则。补丁生成时的混淆映射必须和线上基础包一致。我们踩过一次坑修改完代码后用了新的R8规则文件导致补丁里的类名映射全部对不上加载后直接失败。这个问题的隐蔽性在于它不报“补丁包损坏”之类的明显错误只在日志里留下一个校验失败告警不细看根本发现不了。签名同理。生成补丁时使用的签名要和线上发布包一致。我们当时为了效率在一台开发机上用debug签名的包生成了补丁发布到生产环境后自然是全军覆没。现在我们的流程里强制加了一条补丁构建必须走独立的签名配置不允许复用开发调试签名。4.3 灰度验证的正确姿势热修复的灰度发布也是一门学问。我们第一次发布补丁时设了灰度比例1%想着先放一小部分用户试试。测试同学用自己手机怎么都测不出来后来发现是因为测试App账号没被加入灰度白名单默认走了“不生效”的逻辑。正式的灰度验证操作应该是这样先在控制台创建白名单分组把内部测试机的设备标识加进去然后发布策略选择“白名单优先”确认这一批设备都能稳定修复后再逐步放量到5%、10%、50%直到全量。这个过程听起来繁琐但能避免“修复了一个崩溃又引入一个崩溃”的恶性事故。移动端线上事故修复本来就争分夺秒但越急越要按流程走。还有一个细节不要拿root过的设备做热修复验证。Sophix在root设备上的加载逻辑很不同很容易误判“补丁可以用”。我们后来专门准备了一台没有root的备用机来验证补丁准确率提升非常明显。5. 混淆规则和R8压缩崩溃堆栈里的“翻译难题”5.1 崩溃堆栈全是“乱码”先别慌第一次上线后崩溃分析后台开始涌入一堆堆栈但全是a.a.b、b.c.a这种符号完全看不出是哪一行代码。这其实是所有接崩溃监控的App都会遇到的问题代码在打包时被ProGuard或R8混淆了类名和方法名都被替换成了短符号堆栈还原需要映射文件mapping.txt。EMAS控制台提供了混淆映射上传入口操作很简单把构建产物里的mapping.txt传上去再做一次堆栈还原就能看到真实的类和方法。麻烦的是处理时机不一样效果完全不一样。有人等到出了事故才开始找映射文件而构建机器一清理上次的mapping就没了。所以我们的版本工程里把mapping.txt直接作为构建产物归档进OSS和APK一一对应版本号命名一致随时能取出来。映射文件上传之后崩溃堆栈从“乱码”变成了“带包名的乱码”。为什么还带包名因为有一些混淆规则不够完善只混淆了方法名类名还看得到也有些是SDK自己的代码没被混淆但内部逻辑还是晦涩。这个过程没有捷径就是对照自己工程里的keep规则一条一条过。5.2 R8把动态注册的类“剪掉”了混淆的另一个衍生坑来自R8的裁剪优化。之前我们在某个业务模块里用反射动态注册了一个广播接收器这个类在代码里没有被直接引用。发布新版本后这个模块的功能在部分机型上失效崩溃日志指向ClassNotFoundException。原因是R8在压缩阶段认为这个类没有静态引用属于“不可达代码”直接把它裁剪掉了。而它实际上需要在运行时通过字符串类名去反射创建。这种问题最难受的地方在于本地debug包通常没开R8所以完全复现不了只有打了release包才会暴露出来。解决办法是给反射类写keep规则-keep class com.xx.project.receiver.DynamicReceiver { *; } # EMAS相关SDK建议也保留避免底层动态注册逻辑被破坏 -keep class com.aliyun.ams.** { *; } -keep class com.alibaba.sdk.android.** { *; } -keep class com.taobao.** { *; }这里额外提一句很多SDK的接入文档里都会提供自己的keep规则建议原封不动粘到proguard-rules.pro里不要自作聪明精简。我们踩过“觉得没问题删了几行keep”的坑上线后第三方SDK在某些机型上直接初始化失败排查了一整天才发现是把keep规则删多了。6. 崩溃率降了不代表体验好了线上观测的真实差距6.1 数据平台显示崩溃率很低用户侧却一直在骂项目运行两个多月后我们看EMAS后台的崩溃率数据已经降到0.5%以内按行业标准来说算健康。但应用商店评论里还是持续有用户说“打开就闪退”“卡住不动”。最开始我们很困惑数据明明没问题用户为什么还在骂深入排查后发现崩溃分析平台统计的主要是Java崩溃和Native崩溃中能被SDK捕获并上报的部分。但真实用户侧的“App不好用”往往是另一类情况进程被系统在某些极端情况下杀死这属于系统级终止不会产生标准的崩溃堆栈还有ANR卡在主线程超过阈值被系统弹窗也不一定归类到崩溃报表里。也就是说崩溃率低并不等于流畅这只是说明“能被采集到的Java崩溃少”。所以我们后来又做了三件事。第一是上线更细粒度的自定义事件上报把关键页面的进入和退出都埋了事件第二是开启ANR采集能力如果平台提供的话把卡死事件也纳入监控范围第三是给远程日志设置触发条件用户一旦遇到特定错误App自动把本地logcat上传到服务端。6.2 远程日志定位ANR的最后一根稻草远程日志是我们后来觉得最被低估的功能。有一次用户反馈某个页面总是卡死复现路径不确定崩溃分析里看不到对应堆栈。我们就在页面初始化、网络回调、UI更新三个关键位置加了日志Log.i(BizPage, onCreate: start); Log.i(BizPage, onCreate: request data, time System.currentTimeMillis()); Log.i(BizPage, onRender: data received, size list.size());然后在用户端遇到问题时引导用户通过“设置—帮助与反馈”里的按钮上传日志。后台拉到的日志直接显示网络回调已经返回了但UI迟迟没刷新说明问题出在主线程的消息队列被某个第三方组件持锁阻塞。后来锁定位到某个第三方SDK的同步初始化代码换成异步初始化后问题消失。这个排查过程如果只依赖崩溃堆栈几乎不可能找到根源。经验就是EMAS这类平台的价值不是让你只看一个数字而是提供一套组合拳——崩溃分析告诉你“崩了”远程日志告诉你“哪里先出问题的”自定义事件告诉你“用户实际路径是什么”。三者结合起来线上问题才能变成可复现、可定位的工程问题。7. 重新集成一次EMAS我会把这5件事当工程规范7.1 时间规划厂商通道申请要和开发并行厂商通道的开发者账号、审核材料、App创建这些流程和代码无关但优先级最高。项目启动第一天就去申请申请期间正常做代码集成两边并行不要等SDK接完了再等审核。7.2 工程规范统一依赖版本和初始化顺序所有EMAS相关SDK的版本收拢到同一份版本管理文件里避免和工程内其他阿里系SDK冲突。Application的初始化顺序写进团队规范EMAS的推送和热修复必须是第一个和第二十个不是前两个没有例外。调试日志默认关闭只有内部测试包打开。7.3 混淆规则从第一个release包开始维护keep规则宁多勿少SDK文档给的规则原样保留。mapping.txt归档为构建产物按版本号管理。不要等出了崩溃才去找映射文件那时候大概率已经不在了。7.4 真机矩阵准备两台不同系统的测试机一台干净系统、一台开启严格省电优化和后台限制的系统。每次发版前用这两台机器验证推送通道、热修复补丁、通知权限弹窗。预算够的话再准备一台更老的系统版本设备Android碎片化问题在推送领域尤其严重。7.5 监控告警把“到达率”和“崩溃率”设成团队指标推送到达率、热修复补丁成功率、崩溃率、ANR率这些指标不要只看周报要配置告警。到达率突然下降、崩溃率连续两个时段上升都应该触发即时通知。我们后来把告警接进了办公协同软件运营每次发推送后都会盯着到达率数字看有问题可以立刻撤回或调整。现在这个项目还在迭代EMAS也已经升级了好几个大版本。我们每次踩过的坑都会顺手记录到组里的Wiki后面接手的人基本不会在同一个位置再卡一次。如果让我给一句最直白的经验那就是集成工具平台之前先把你自己的构建规范、混淆规范、真机测试矩阵定好平台才会变成帮手而不是坑源。
