不要再问我如何实现获取 IMEI、热更新、后台保活啦！
为什么说 IMEI、热更新、后台包活是黑产三件套
如果你是进来找解决方案的，那很可惜我要请你滚出去了，因为这里只会介绍为什么无法实现，以及为什么这些都是伪需求。
Q：如何获取 IMEI / 用户设备 ID / 设备 Mac 地址……？
能问出这样的问题，自己反思一下这个需求是否合理，自己是不是在做黑产灰产。无论是开发文档、法律法规，都在保护用户的个人信息不被泄露，而你想获取这些东西，你是想做什么？
现在已经获取不到这些信息了，或者说获取到了也是可能会变动的，用户切换网络环境、重启手机、卸载重装，都有可能重置掉这些看似可以标记用户的 id。
广告商为了能精准推送而跟踪用户，也不是记录 IMEI，现在都是讲大数据分析的，先发给用户一个 uuid，然后通过用户行为来归类用户群，再去给不同的群体投放广告，既做到合法合规，又达到了目的。
Q：如何在 Flutter 中实现热更新？
还是一样的原因，为了用户的安全，苹果商店是明令禁止热更新的，Google 商店也有对应的规定来约束开发者。所以客观来说，热更新是非法操作，它绕过了审核，为用户更新了不确定安全的功能。
但是肯定有人要杠两句说，之前都能做的，原生也能做，为什么来 Flutter 就不行，Flutter 不是有 ShoreBird 也可以实现热更新吗。我觉得你先别杠，先确定做好了 ShoreBird 提到的这些合规性问题，再来谈热更：https://docs.shorebird.dev/faq/
退而在言，有一些不得不热更新的场景，比如：
- 紧急修复严重 bug
- 商店发版太慢了，影响发版速度了
但可惜，这些都是伪需求。
为什么会有未经测试验证的 bug 进入 release？工程 SOP 做好了吗，有没有认真回归测试？代码是否干净而不致于新的 feature 导致了旧页面 bug？出现 bug 有没有备用措施，有没有渠道发布公告？什么都没准备好，只希望靠掩耳盗铃的悄悄修复掉 bug，简直就是为脆弱的开发流程找补，根本没有解决问题。
商店发版太慢？是什么样的需求会在用户手机上天天更新呢，好难猜啊。说白了发版慢就是客观正确的，用户没有理由一周更新 7 次软件。每次更新带来的新功能是否能带来新的获客和营收？天天都在更新的内容，是不是没有做好模版和数据的设计？商店审核慢，排期有没有预估进去？
热更新完全就是伪需求，很多问题都可以从工程的角度解决，商店也只希望你更新的内容不会参入一些未经审核的奇怪的功能进去，这样对用户才是良好的交付。
Q：如何实现后台保活？
也是一个伪需求，你先别急着搬出你的什么医疗软件必须实时连接用户的设备要常驻后台这种需求，先来了解系统是怎么调度后台的。
一般的，一个后台运行的程序都需要向系统申请某种功能的后台权限，Android iOS 都有。所以你确实可以将功能挂在后台，但是想一直保活是不可能的，系统的调度下，内存不够，省电模式，都有可能杀死 app，甚至有想后台唤起 app 这样的需求，都是不可能的，都是有系统限制的。没有用户会愿意手机上多一个流氓软件。
所以这其实和 Flutter 都没关系了，纯原生功能。其次真的需要后台的应用不会需要保活，需要保活的 app 是什么成分自己掂量。