iOS开发中的小坑(持续更新中)
-
时间差了8小时 跟时区有关
时间差了8小时 跟时区有关
-
viewdidLoad里面 view还没孕育完全(会有一些属性在这里获取会错误)
尤其是从ViewControl从xib中获取的view 在viewDidLoad中的frame还是xib中的大小 ,直到viewWillAppear才屏幕大小
-
多个scrollView叠加的处理
处理方式: 1手势冲突的处理 2设置scrollEnable=NO frame=content.Size(即动态大小 高度)
-
如何修改没有暴露出ui属性
1要么用lldb po下 遍历它的子控件 2kvc修改私有属性
-
(void)setNavigationBarHidden:(BOOL)hidden animated:(BOOL)animated;
这个方法很有意思，跟直接调navigationBar的hidden不一样 项目中要统一一下不然会出问题
-
属性中有block 时 要非常注意循环引用 oc还好有提示 但是swift没有
-
[NSDictionary dictionaryWithObject:[UIColor yellowColor] forKey:UITextAttributeTextColor];
可以通过字典的知传入属性，设置title的样式；
key 分别有
UITextAttributeTextColor 设置title的文字颜色
UITextAttributeFont 设置title的文字字体
UITextAttributeTextShadowOffset 设置titlewz阴影的平移量
UITextAttributeTextShadowColor 设置titlewz的阴影颜色
- OC中的方法 如果有返回值,没有参数, 可以用点语法 (跟swift中的计算型属性类似)
-
xib创建视图 修改frame 有时布局会错误 , 忘了调整autoresizing!!!(创建xib,用view适合全屏的view, emty适合 小viwe)
-
后端增加了新的属性,结果 本地数据没有更新了 ,没做判断,app崩了
-
环信的初始化功能会卡主线程
-
连续动画 (如果uiview实现不了) 用baseAnimation !!记得 ani.isRemovedOnCompletion = false
-
tableView的reload不是同步的, 是下个循环开始(理解为异步)
-
uibuttton的contentEdgeInsets imageEdgeInsets titleEdgeInsets会因为机型不同 位置改变,推荐用layoutSubview
-
子线程发出的 通知 , 主线程是收不到的
tableView性能建议
- 尽量少计算,提前准备
文字的计算尺寸 和 视图的sizeToFit很影响性能,要提前计算好 (数据计算 最好放在网络请求那里计算)
行高一定要缓存(对性能影响大!) - 控件不要圆角,图片渲染属性要注意
(1 尽量少设置透明图片 2图片尺寸不要拉伸) - 不要动态创建视图,最好提前准备好, 在显示时隐藏或显示
-
cell控件层次越少越好
-
autolayout对性能要求高的项目,影响大
xib sb对大型项目来说,性能优化难度大 -
布局x y 避免小数点,容易造成图片失真(即图片文字糊了)
-
复杂工作丢到子线程
补充:个别性能做的好 直接用渲染,(btn img等 直接画上去,但是很麻烦) -
离屏渲染: 在进入屏幕前绘制好视图, 好处:更快 坏处:消耗cpu
self.layer.drawsAsynchronously = YES(离屏渲染-异步绘制)(在tableView设置这个会更流畅)
-
栅格化 (性能会提升 分辨率降低 记住要指定分辨率)
self.layer.shouldRasterize = YES;
self.layer.rasterizationScale = [UIScreen mainScreen].scale;指定分辨率
(栅格化 - 异步绘制之后会生成一张独立的图像, cell在屏幕上滚动的本质上是 滚动的是这张图片)(cell优化,要尽量减少图层数量,滚动时就相当于一个图层 ,停止滚动后 可以监听点击)
- 可以用CFRunLoopObserverCreateWithHandler来更新数据,把数据计算放在了间隙,但是此函数不要做复杂操作和
值得注意:
如果cell的性能已经很好了,就别离屏幕渲染!
(离屏渲染需要在CPU和GPU之间快速切换,耗电会厉害)
(每次性能优化都是付出其他代价,如果性能好就别优化了)
scrollViewDidEndDragging 这个方法里还有一个Decelerating yes代表停止拖动时减速 no代表停止
scrollViewDidEndDecelerating 这个方法代表减速停止
-
观察者模式再不需要时,要释放
1通知中心, 不释放,什么也不会发生,但会内存泄露,会有多次注册的可能
2kvo 会崩溃 (因为传值给已经释放的对象) -
uiview封装旋转动画 1默认顺时针 2就近原则
小技巧:
1: M_PI-0.01这样 先顺时针转过去 在逆时针 转过来(用在刷新控件上)
2:如果想要实现360度 旋转,需要核心动画 CABaseAnimation
-
不要盲目依赖ARC,CoreFoundation对象不在ARC管理下
-
子线程开启了runloop,如果在其他线程里,移除这个runloop的资源, 会造成僵尸线程(资源移除不干净,可能是系统问题,没研究)(常用注意场景:子线程加入定时器,定时器当然就加入了runloop,如果不在同一线程移除,就造成了僵尸线程!!!)
-
拉文件的三种方式:
- 黄色文件夹,打包的时候,不会建立目录,主要保存程序文件(素材文件不允许重名)
- 蓝色文件夹,打包时会建立目录,可分目录建立素材(素材可重名,主要用于游戏场景,皮肤等素材 切忌:不要程序文件放入,不会被编译)
- bundle (可保留目录,避免重名)
(与蓝色文件夹区别,通常用第三方框架素材,它就是可以用黄色文件夹拖拽方式. 这样保证其他文件容易读取!!!又能不改变文件夹结构)
(蓝色文件夹内部还有文件夹,还有其他.h.m文件,会使.h.m文件拿取不方便,而黄色拉(含bundle,.h.m)则方便很多)
-
通常delegate和block可以混用,但是如果 像cell之类的多处设置,delegate更合适一些,因为block是复制代码里面的内容传值过去,而delegate是传递指针地址过去
*线程相关
######常驻线程:
那么想要这个线程能并发处理任务，就相当于在线程里再开一个线程，所以常驻线程没必要.如果任务串行还不如弄个串行队列。 做个常驻自己的队列是可以的
(个人看法常驻线程 没必要 ,倒不如常驻队列)
######常驻队列:
在里面我们可以控制手动开启的线程数
而设置开启的线程数的目的:减少单点压力
例如:我在图片下载的时候，客户端的带宽是有限的，同时开多个线程和有限个线程，下载带宽不会超过总带宽
在这个情况下，适当减少并发下载数，有两方面的优势：1、当前的几个下载会因为没有其他线程竞争带宽，而完成的更快 2、并发数量少，系统相对空闲
-
安全方面:
介绍
网络和本地!!! 不允许传输用户隐私的明文!!!!
1.用base64编码后,在保存本地(虽然可以反编码,但是起码不是明文)
*可以对任一二进制数据编码也就是说所有文件喽),会使文件增大近1/3
*偏好设置存储也是可以到沙盒拿到数据的
*服务器日志是黑客最爱,故不能明文
2.RSA 公钥加密 私钥解密
*破解: 用最好的计算机因式分解 50年
3.Hash 哈希(散列函数) (例:MD5 SHA1 SHA256)
*特点:1算法公开 2对相同数据加密,结果一样 3. 不同数据加密,结果定长
*MD5加密--> 32个字符 外号:信息摘要,即信息的"指纹",是用来做信息的识别 不能反算
*用途: 1密码 2搜索 3版权
*破解: 1 MD5被破解,SHA1在破解边缘 2 散列碰撞
4.对称加密算法(例:DES 3DES AES)
*AES(高级密码标准,美国国家安全局使用) (电脑破解几千万年)
5.非对称加密算法(例:RSA)
方式
1.base64编码(只是编码方式,把明文换成暗文)
2.MD5加盐(前期使用,用户量大还要升级)(可被反编译破解)
3.HMAC(也是散列)(原理:用一个密钥,对明文两次散列)(实际密钥从服务器获取,在我们注册获取key,保存本应用程序下,每个用户每个key都不一样)
*例:要求每次发送的密码都不一样:---->
方式一:
注册:
1.在注册的时候,用账号,向服务器获取key
2.可以用 (用户密码+key) ->加密后的密码 发给服务器
但这相当于设备锁,一旦换设备挺麻烦:
登陆:
1.客户端先检测本地是否key,如果没有,向服务器要key,(要向上个客服端验证)
方式二:
("密码"+MD5)HMAC+ 时间 特点:1.时间一直到分钟,没有秒钟 2."密码"是服务器 客户端都有的那个已经处理过得密码
个人感觉这么调整:
1.(("密码"+时间)MD5)HMAC
2.(("密码"+MD5)HMAC) 加上 (("时间戳"+MD5) 更狠点接下来乱序或密码增减
补充:指纹识别(方法简单)
指纹代表这个人是手机的主人
密码代表这个人是这账号的主人
-
runloop存在的意义:(孙源视频)
----没有则命令式执行, 有则Event执行
*程序一直运行并接受用户输入
*决定程序何时应该处理哪些Event
*调用解耦(Message Queue):比如说手势划一下,产生若干事件,主调方会被卡住,故用runloop解耦,主调方把事件放入队列来解耦
*节省CPU时间
相关类:
NSTimer UIEvent Autorelease
NSObject(NSDelayedPerforming) NSObject(NSThreadPerformAddition)
CADisplayLink CATransition CAAnimation
dispatch_get_main_queue()-->所有不能说runloop是GCD的封装,是跟GCD平级的.main_queue中的block分发到mainRunloop中执行
NSURLConnetion 回来的数据和代理都是在runloop里跑的(我估计NSURLSession也一样吧)
FEF7181F-30BF-47CC-8B6E-6A9EC90B2299.png
- CGAffineTransformMakeTranslation每次都是以最初位置的中心点为起始参照
CGAffineTransformTranslate每次都是以传入的transform为起始参照
CGAffineTransformIdentity为最初状态，即最初位置的中心点
