Introduce:
ios暗黑模式,多主题多皮肤设计,用于解决在ios上实现可跟随系统主题变更,也可不跟随实现自定义主题模式设计。本sdk可以支持任意多个主题。开发习惯上极度契合ios开发习惯,对于复杂的主题设置类,均可使用对象的tkThemeChangeBlock进行回调设置变更。优势:
1.代码无侵入,轻量级SDK。上手简单。完美解决多任务后台主题即时变更,屏幕快照变更主体。
2.全局控制,效率极高。用hashmap的形式管理block指针对象,轻量。
3.一切OC对象皆tkThemeChangeBlock主题回调,根据主题的目前的索引变更主题。
4.常用的UIKit的组件,赋予主题属性,主题方法等。直接设置主题颜色、图片数组即可。完全契合系统设置属性,方法习惯。
5.设计原理完美,弱引用的形式回调,不会对项目产生内存泄漏,内存占用不释放问题。UIKit-View层即用即注册,跟随对象释放即销毁。主题回调block即用即注册,跟随对象释放即销毁。
movie show
效果视频如下:(ps:没办法,简书只支持优酷/腾讯视频 没法去广告 想看大视频,点链接:https://v.youku.com/v_show/id_XNDcwNTcxODMwNA==.html)
How To Get Started
1.导入 pod 'TKThemeConfig' //(ps: 本人会对sdk一直维护,放心使用 )
2.在使用到的地方 #import <TKThemeConfig/TKThemeConfig.h>
程序加载完毕初始化
How To Usage
1.便捷用法
sdk封装可常见的view控件。对于这些常见的控件,比如CALayer,UIView,UIImageView,UIButton, UILabel等15个组件进行了贴合开发者的属性定制,在原属性上加前缀TKTheme。能满足80%以上的开发需求。 剩下的用万能方法即可。有时间功夫的小伙伴可以加入一起完善便捷用法哦。 示例如下: // UIButton like //UIImageView like //CALayer like 。其它的可自行看头文件
layer.tkThemebackgroundColors = @[UIColor.brownColor,UIColor.darkGrayColor];
[themeSeting setTkThemebackgroundColors:@[UIColor.redColor,UIColor.brownColor]];
[imageViewsetTkThemeimages:@[[UIImage imageNamed:@"001.jpg"],[UIImage imageNamed:@"002.jpg"]]];
2.万能用法
一切皆object对象,一切对象具备tkThemeChangeBlock(NSObject+TKUpdate.h),变更主题会触发 任意对象的tkThemeChangeBlock回调,可以在这个回调做主题设置。 本回调为主线程,进行UI主题变更,但是不要做耗时操作,耗时操作放到异步非主线程即可。 示例如下: //view.tkThemeChangeBlock //navigationBar.navigationBar
self.view.tkThemeChangeBlock= ^(id _Nullableitself,NSUIntegerthemeIndex) { //设置主题 }
self.navigationController.navigationBar.tkThemeChangeBlock = ^(id _Nullable itself, NSUInteger themeIndex) { //设置主题 }
项目地址:https://github.com/Tkoul/TKThemeConfig
本文为原创,啃了几天泡面搞出来的。转载注明出处。喜欢的给个小星星。对不足的地方,可以一起交流,提升。邮件:Tkoull@163.com
对简书编辑器玩不转,有点丑!设计思想后续补上。
PS:设计思路 2020-11-6
鉴于目前直逼6K的阅读量,再懒我也得补上承诺的设计思路以及思想。(😶 我是真的懒)。
API怎么设计?多主题拓展怎么设计?NO,NO,NO 对于我这种懒人来说,不讲这些基础东西了。咱们就讲多主题设计的核心:
1.怎么跟随设置,同步的去变更所有的展示层UI以及栈里面的视图UI.
2.改变主题的即时性
3.对主app的性能影响
4.代码执行效率
5.对主APP代码的侵入
以上以重要程度列出。主体变更,联动所有的UI变更。
实现思路一:通知
有人说简单,通知完事,实际上业界内很多开源的就是这么设计实现的。写一个根类或者拓展类,注册通知不就OK啦,然而真的这么简单吗?
通知实现原理:通知实际上是利用runtime动态的创建类,创建的规则是监听某个类的属性时,会动态的创建这个类的子类,并且初始化也是对这个子类操作的。比如现在有AClass,监听它的属性,runtime会临时动态的创建它的子类,如subAclass(实际是有一套规则,好像是noti—aclass,别在意细节,了解就行),同时把AClass的isa指针指向subAClass。那么后续,你对AClass所有的操作,方法调用,实例化等其实都是在操作subAClass。你打印实例对象的Class的时候,依然返回的是AClass,什么?不是说isa都是指向subAClass了吗?对的,没错,只不过为了很像,这种情况,系统api重写了class方法,强制的反回了AClass。表面上看着对象是AClass,操作的却是subAClass,实际都是假象,为了达到看着这样的效果,设计这个模式的大神是做了很多蒙蔽我们的工作。在subAClass里面会重写监听的属性的方法,达到监听效果。
敲桌子1:回味下,注册一个通知的代价。。。
继续:每次注册通知,都会在通知中心重新注册一次,即使是同一对象,监听同一个消息,而不是去覆盖原来的监听。这样,当通知中心转发某一消息时,如果同一对象多次注册了这个通知的观察者,则会收到多个通知。
敲桌子2:如果写for循环推出来10000个UIViewContrl,每个UIViewContrl上有很多子view,那么这时候会注册多少通知,对多少个类进行动态变更,创建呢?思考下。
结论:通知量级很重,通知是在某些场景下做通知,而不是用在这个场景。也不建议在开发过程中注册太多的通知,避免滥用。
百度做的性能对比:(借鉴下数据😀)
条件:在上万个视图量级下真机iphone5s初始化CPU消耗初始化耗时!
系统暗黑 CPU消耗:50% 初始化耗时:3312ms
HashTable CPU消耗:50% 初始化耗时:3341ms
Notification CPU消耗:99% 初始化耗时:5115ms
实现思路二:重写object类,用全局hashmap记录所有的栈里的对象。存起来,变更主体设置,再去这个hasmap里面读所有的对象变更主题。有这么简单吗?hashmap(我们的字典,数组均叫hashmap,不行就hasarry呗,别在意细节😀)
1.存时机 初始化的时候存,还是加载到视图存,是共性全存还是需要的视图去存。
2.循环引用问题。 NSMutableArry存的东西那么就会强制引用,那么不去手动释放,移除,会导致视图不会被释放,内存泄漏。有的小伙伴说,我存weak指针,不好意思,存进来了,你敢释放,我NSMutableArry就敢崩溃给你看。敲桌子,留给爱探索的小好伙伴(那么我weak对象+NSPointerArray)呢?tips NSPointerArray和我们常用的数组一样,但是他可以存空对象,为什么不用呢,甚至在开发中几乎很难看到这个容器对象。
3.release时机和把控会很难
结论:依赖hashmap直接存储对象以及通过UIView的didAddSubview,didMoveToSuperview重写方法等很难实现。即时实现,也不是好的设计,有点类似为解决问题而解决问题。同时对APP代码入侵严重,内存释放同样不好把控。
以上囊括了业内的大多设计思路和实现。在我看来,均不是很理想。
通知方式虽然方便,入侵少,但是效率性能消耗极大,被我首先pass掉。思路二,效率ok,性能略有欠缺,入侵性大,错误率高,稳定性差,内存容易泄露,会连环导致均不被释放。
怎么做到轻量,效率高,性能好,完全稳定,我们就需要各管各的,无论怎么设计,谁干谁的事情,谁改变对别人没影响。TKThemeConfig设计实现,就具备这些特性。
即用即创建,一管理,一嗅探,一释放。(专业点😀 :哨兵)
1.即用即创建:对象需要具备变更主题的能力,但是在创建的时候才会具备这个能力。并且只在初始化创建一次。
2.hashMap管理。管理的不是跟主题相关的对象(一般指继承UIView的视图,但是有很多继承obj的对象也具备主题颜色设置,这也是思路二无法万能的痛点),而是对象实例方法内部变量block。结合反向block方式。在类初始化方法创建block,同时全局hashMap(TKThemeConfig使用了单利)储存该blcok。 解决了全局hashmap跟该对象的引用关系,即它俩没关系。存的是方法内部初始化的blcok,block内部用的是对象的weak,不相互持有。这里涉及三者,1.全局hashmap 2.对象实例方法内部block(兴趣的可以研究下globblock,staticblock,mallocblock),3.对象本身。三者只有hashmap和block强持有,block和对象弱持有。hashmap和对象无关。对象在自己的生命周期内,释放时机均自己把控即依然遵循系统ARC管理,无侵入,完美!就是这个关键设计解决最核心的问题。
3.一嗅探,一释放。由于对象和blcok弱关系,那么视图对象释放掉,对于视图对象而言就结束了,但是block还被hashmap强持有,怎么去释放它呢?敲桌子,嗅探-(我觉得是天才灵感,有木有😀),在一段时间去反向回调blcok,去试探与他相关的weak类对象是否还在,一旦嗅探到weak==nil,说明跟block引用的对象已经释放了,那么blcok就告诉hashmap说,哥们,我管理的对象不在了,我也没啥用了,你把我弄死吧。那么hashmap就把blcok取出来置空,杀死,释放回收blcok所占的内存。具体实现,去down源码阅读即可,嗅探我这设置的15秒一次,因为我允许hashmap多持有blcok一会,blcok本身就是一个很轻量的元素,存的一个指针而已,占内存可以忽略。同时遍历很快,遍历上万次并移除都不到2毫秒,在牛的app也不会有上万个视图层吧😀。ok,这就是TKThemeConfig设计思想。
敲黑板,这是一种思想,可以应用于类似场景的任何地方,一种解决思路,也是灵感所致。希望对读者有所启发。读懂了会对你很有帮助。