SDK热更系列之SDKHotfix待优化点

写在前面

本文是SDKHotfix相关的SDK热更系列文章中的一篇，以下为项目及系列文章相关链接：

• SDKHotfix整体介绍：http://blog.bihe0832.com/sdk_hotfix_project.html
• SDKHotfix对应github地址：https://github.com/bihe0832/SDKHoxFix

这里主要介绍SDKHotfix没有添加进来但是热更相关的项目必须要考虑到的一些关注点，可以说都并非是待优化点，而是正式线上项目必须需要实现的基本功能。由于这部分内容与热更原理关系不大，而且不同项目差异性比较大，因此这里只提供一些思路和想法，不会做重点说明，后续会根据情况进一步完善。

关于安全

• 热更内容下发通道 怎么保证热更内容下发的安全性，保证下发的热更时自己的后台而且被劫持的后台下发
• 加载热更新前没有验证合法性 Demo中热更前没有校验热更文件的合法性，怎么保证加载的热更patch包时自己后台下发的，而不是第三方篡改过的非法patch
• 没有做版本匹配 热更新既然是更新，肯定有原始版本，怎么保证下发的patch包只有指定的版本可以加载，其余版本不会加载。这里包括

- 怎么保证后台不会下发
- 怎么保证即使后台下发了客户端也不会加载

• 怎么回滚 SDK的热更新如果遇到异常，怎么回退来降低风险，不让热更变为制造灾难的最后一根稻草

关于运营维护

• 热补丁和版本的匹配怎么维护 如果热补丁用来做功能发布的话，SDK版本和热补丁之前如果匹配就会很复杂，如果维护两者的对应关系？
• 热更相关的数据上报 热更新因为涉及到功能和bug修复，而且是关键逻辑，他发布以后就会立即生效，因此相关的crash数据、更新次数、成功率、异常问题问题统计等，怎么保证这些数据可以实时发现和查看
• 怎么控制热更发布 热更新因为涉及到功能和bug修复，而且是关键逻辑，他发布以后就会立即生效，因此他的发布流程就会比较重要，涉及到热更版本的测试要测试哪些内容、灰度发布的策略等。