必要的序
以后在写系列文章,准备把基本的规划和动机等,单独作为一个小的序言部分给独立出来.序言部分,可以较为完整地交待系列文章的写作动机,所展示的编码技术可能的应用场景等.个人,我还是比较看重文章或者书籍等的序言部分的.真有相对确定确实有价值的东西,才会进一步去阅读.所以,我觉得,序,总是必要的.
关于我写博客的节奏
我会尽可能地使每一个系列的文章,能相对完整.但是,就像你看到的这样,前一个系列还在讲Spark,这篇文章就开始讲 iOS 开发的一些问题.到底要闹哪样?
还能怎么样?开心就好!干嘛要让那些不存在的东西,束缚自己呢!我觉得,理想的生活节奏就是,做自己喜欢的事,然后分享给有需要的人看.这就够了.
所以说,未来不管你在博客中看到什么诡异的系列主题,都不用感到惊讶!如果刚好自己也感兴趣,一起来玩喽~
当然,有人说,天天BUG,还解不完呢,哪有闲心写BUG呢!这是问题,或许也是答案!你用来解决某个BUG的精湛技巧,或许在QA或者PM眼里,不过是理所当然地而已;就算他们给你一个赞,你也明白,其实他们可能根本就不懂你解决的这个问题的真正意义.
但是编码的众多有趣属性中的一种就是: 别人的不认同,并没有办法真正否定你天马行空般编码技术的价值和意义.写出来,哪怕只有一个人,能真心看懂,发自肺腑地给个赞--足矣!
为什么要实现iOS图片等资源文件的热更新化?
首先说一下,这个系列要做什么.要做的事,简单说,就是把图片,CSS样式等资源文件从项目中剥离出来,放到一个特定的目录里;然后,我们每次都这个特定地目录读取数据;最重要的是,我们可以动态更新这个目录,实现图片等资源文件的动态更新,即热更新.
这件事,本身思路并不难,各个技术细节,多花点时间,总是可以解决的.但考虑到,在实际地生产环境中,可能是App已经迭代更新了大半年了,图片PM脑袋一热说,我们要做个 换肤 功能.然后,自然要把所有涉及图片的操作剥离重写下,而且也要把图片资源从 Images.xcassets 导出.当然,从原始素材导出替换也是可以的,只要你有足够的时间,只要你不怕进度太慢被PM打死,都是OK的.哈哈!
所以说,本系列的重点不在于热更新技术本身,而是在于如何用最小的成本,赋予一个中规中矩的iOS App的资源部分,以热更新的能力!好吧,略显绕口,意会!事实也是如此!
作为资源热更新之外的附加收获,你的App资源文件体积,应该也可以缩小 2/3 左右,当然,也再也不用为了一个图片素材升级App了.另外,本系列所指的资源,也包括内置的js,css文件,通常是用来加速H5页面网络访问的,大家都懂的,不细说了,原理都差不多.
此系列文章规划
系列,争取本周内更新完毕,在不是很侧重的地方,会适当缩减篇幅.
实现iOS图片等资源文件的热更新化(一): 从Images.xcassets导出合适的图片
此文会基于一个已有的脚本工具自动导出所有的图片;最终给出的是一个从 Images.xcassets 到基于文件夹的精简 合适 的图片资源集的完整过程.难点在于从完整图片集到精简图片集,肯定是基于一个定制化的脚本,自定义导出的.如果自己手动导出?那,还有的忙喽~
实现iOS图片等资源文件的热更新化(二):自定义的动态 imageNamed
这篇文章,要解决的是,使用一个自定义的 imageNamed 函数来替代系统的 imageNamed 函数.内部逻辑,将贯穿对比论证 关于"合适"的图片的定义.对iOS加载图片的规则不是很熟悉的童鞋,可以着重看这篇.
实现iOS图片等资源文件的热更新化(三):动态的资源文件夹
此文,将尝试动态从某个不确定的文件夹中加载资源文件.文章,会继续完善自定义的 imageNamed 函数,并为下一篇文章铺垫.
实现iOS图片等资源文件的热更新化(四): 一个最小化的补丁更新逻辑.
以前写过一个补丁更新的文章,此处会做一个更精简的最小化实现,以便于集成.为了使逻辑具有通用性,将剥离对AFNetworking和ReativeCocoa的依赖.原来的文章,可以先看这里: http://www.ios122.com/2015/12/jspatconline/
实现iOS图片等资源文件的热更新化(五): 一个简单完整的资源热更新页面
一个简单的关于页面,有一个图片,版本号,App名称等,着重演示各个系列的文章完整集成示例.有耐心的,可以直接等着最后一篇文章更新.我还没写好呢,没法提前发. O(∩_∩)O哈哈~
系列专属github地址: https://github.com/ios122/ios_assets_hot_update