Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

SDK 升级困难

  很多框架级组件都以 SDK 的形式提供出去,但是大多数使用方在首次接入 SDK 后就再也不会去升级它了。而 SDK 本身是一个静态的东西,无法知道哪些系统在依赖自己,甚至都没法统计。这时候如果 SDK 依赖的服务变更,必须升级到新版本,那么 SDK 的开发方就很难推进了。
  纯代码库级别的东西是很难推进更新的,比如现在的 Web 已经发展到这种程度了依然有很多古董项目在使用 jQuery 1.4 甚至更低版本。当一个库被项目使用之后,如果没有什么非修不可的 Bug,通常很少有项目会去冒险升级依赖。所以代码库级别的东西要想升级是非常困难的。不过代码库级的东西对升级的需求并不高,比如即便是 jQuery 1.4,它也可以正常使用,不会出现非升级不可的情况。但如果是一个基于其它服务的 SDK 呢?那就不同了。SDK 通常会依赖其它服务,当其它服务升级时 SDK 也必须升级。但是依赖方并不知道 SDK 的服务升级,那么就可能会错过升级,导致各种问题。
  使用 semver 可以解决部分版本自动升级的问题。但 semver 是需要依赖方去写的,作为一个 SDK,我们无法要求依赖放把版本写成 semver。很多依赖方也认为固定版本才是最稳定的,拒绝使用 semver。
  动态加载也是一个解决方案。比如微信内的 wx.js 就是一个动态加载的资源。微信方面可以直接修改 wx.js 内的代码让程序升级,不需要再让依赖方去主动升级版本。但是这么做就需要有自己的服务器、CDN、公网域名等,实现成本比较高。
  虽然动态加载的成本比较高,但我也没想到更好的办法了,剩下的只能让我们在这个技术上优化而已。比如不让用户每次都去加载这个文件,而是在 build 时加载一次。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^