本文是SDKHotfix相关的SDK热更系列文章中的一篇,以下为项目及系列文章相关链接:
SDKHotfix整体介绍:https://blog.bihe0832.com/sdk_hotfix_project.html
SDKHotfix对应github地址:https://github.com/bihe0832/SDKHoxFix
这里主要介绍SDKHotfix没有添加进来但是热更相关的项目必须要考虑到的一些关注点,可以说都并非是待优化点,而是正式线上项目必须需要实现的基本功能。由于这部分内容与热更原理关系不大,而且不同项目差异性比较大,因此这里只提供一些思路和想法,不会做重点说明,后续会根据情况进一步完善。
热更内容下发通道
怎么保证热更内容下发的安全性,保证下发的热更时自己的后台而且被劫持的后台下发
加载热更新前没有验证合法性
Demo中热更前没有校验热更文件的合法性,怎么保证加载的热更patch包时自己后台下发的,而不是第三方篡改过的非法patch
没有做版本匹配
热更新既然是更新,肯定有原始版本,怎么保证下发的patch包只有指定的版本可以加载,其余版本不会加载。这里包括
没有odex校验
这个我们的SDK没有考虑,因为如果可以替换odex,其实已经拿到了root权限,他其实可以做更多,所有的策略都会失效。
怎么回滚
SDK的热更新如果遇到异常,怎么回退来降低风险,不让热更变为制造灾难的最后一根稻草
热补丁和版本的匹配怎么维护
如果热补丁用来做功能发布的话,SDK版本和热补丁之前如果匹配就会很复杂,如果维护两者的对应关系?
热更相关的数据上报
热更新因为涉及到功能和bug修复,而且是关键逻辑,他发布以后就会立即生效,因此相关的crash数据、更新次数、成功率、异常问题问题统计等,怎么保证这些数据可以实时发现和查看
怎么控制热更发布
热更新因为涉及到功能和bug修复,而且是关键逻辑,他发布以后就会立即生效,因此他的发布流程就会比较重要,涉及到热更版本的测试要测试哪些内容、灰度发布的策略等。