一、APP质量保证和性能监控
UI主线程监控
- 防止子线程访问UI
UIKit的大部分对象都不是线程安全的，所有继承自UIResponder的类都需要在主线程操作，如果在子线程更改了这些UI对象就会导致未知行为，比如随机出现丢失动画、页面错乱甚至crash。可以尝试一下以下代码，在子线程调用100次后，很可能会导致整个app丢失动画。
UIImageView *imageView = [[UIImageView alloc] initWithImage:image];
解决方案：
为了防止在子线程操作UI，我们在开发阶段hook掉UIView、CALayer的setNeedsLayout、setNeedsDisplay、setNeedsDisplayInRect:三个方法，当调用这三个方法时判断是否在主线程，如果不在主线程调用就让程序crash，在crash堆栈能看出是哪里的问题。
- FPS监控
在开发过程中遇到的难以重现的卡顿，推荐GYMonitor（用于监控iOS app性能状况的代码库，目前包括有FPS监控，发现FPS过低会自动产生堆栈，便于在开发过程中发现卡顿问题）。 - 线上用户监控（待集成）
iOS中主要是监控NSRunLoop的状态,通过CFRunLoopObserverRef可以实时获得一些状态值的变化,
NSRunLoop调用方法主要就是在kCFRunLoopBeforeSources和kCFRunLoopBeforeWaiting之间,还有kCFRunLoopAfterWaiting之后,也就是如果我们发现这两个时间内耗时太长,那么就可以判定出此时主线程卡顿.
一般是时间超过3秒就会捕获所有线程的堆栈，然后上报神策logger。
内存泄漏
内存泄露引起的性能问题是很难被察觉的，只有泄露到了相当严重的程度，然后通过Instrument工具，不断尝试才得以定位。
目前使用的解决方案：
具体的方法是，为基类 NSObject 添加一个方法 -willDealloc 方法，该方法的作用是，先用一个弱指针指向 self，并在一小段时间(3秒)后，通过这个弱指针调用 -assertNotDealloc，而 -assertNotDealloc 主要作用是直接中断言...
结果：发现app中一些模块的确是存在内存泄漏，目前已经解决了一部分，等待后续继续优化
主要着手点：
循环引用
1.block引用 2.timer释放 3.delegate
内存警告
1.大数据 2.无限动画 3.notification
二、按钮重复点击问题；
方案1：
设置全局状态，isClick = true；
=>点击第一个按钮（if isClick == false ，return） 设置为false ，
事件触发结束，return true；
static btnClickStatus = YES;
- (void)btn1Click {
if (btnClickStatus == YES) {
btnClickStatus = NO;
//执行btn1 action
}else {
return ;
}
}
- (void)btn2Click {
if (btnClickStatus == YES) {
btnClickStatus = NO;
//执行btn2 action
}else {
return ;
}
}
。。。
方案2：
前端术语：防抖和节流 （成熟）
函数防抖：将几次操作合并为一此操作进行。原理是维护一个计时器，规定在delay时间后触发函数，但是在delay时间内再次触发的话，就会取消之前的计时器而重新设置。这样一来，只有最后一次操作能被触发。
函数节流：使得一定时间内只触发一次函数。原理是通过判断是否到达一定时间来触发函数
三、ipa包体积优化
1.资源图片的下载：蓝湖工具自带的无损压缩，iOS和android目前使用png，可以尝试用webP格式，
***根据Google较早的测试，WebP的无损压缩比网络上找到的PNG档少了45%的文件大小，即使这些PNG档在使用pngcrush和PNGOUT处理过，WebP还是可以减少28%的文件大小。
2.Images.xcassets 图片的注意规范，iOS目前支持的最低版本是9.0，只需用到2x和3x图片；
3.本地的音视频资源压缩处理，gif动图等的压缩处理（目前资源占比不是很高，影响小）后期如果需要可以尝试lottie（支持android和iOS），直接加载json文件（不同于gif的序列帧动画），优点体现在内存&体积大小。
四、用WKWebView代替UIWebView
WKWebView支持iOS8+，iOS9以后更加完善，和LCB项目最低支持iOS9完全匹配，Advantages主要体验在：
(1) WKWebView为多进程组件，能在APP进程之外执行，不同于UIWebView，当超出系统分配的内存，不会crash，表现为白屏，app能收到系统通知，加处理后能reload页面；
(2)WKWebView使用和手机Safari浏览器一样的Nitro JavaScript引擎，相比于UIWebView的JavaScript引擎有了非常重要的性能提升；
(3)WKWebView是异步处理app原生代码与JavaScript之间的通信，因此普遍上执行速度会更快...
(4)消除触摸延迟，UIWebView和WKWebView浏览器组件会将触摸事件解释后发送给app，因此，我们无法提高触摸事件的灵敏度或速度。
存在的问题：
当应用退出并重新启动时，HTML5本地存储将被清除；
...
五、View层的组织和调用方案
目前LCB采用MVC，简单谈一下对iOS开发领域MVC的职能划分：
Model：
1.给VC提供数据，不仅有原始service api提供的字段，还应该有处理过后的属性，例如cell的动态行高等； 2.给VC存储数据提供接口，便于缓存操作；
ViewController：
1.管理view container的lifecycle； 2.负责生成所有的view实例并加入view container； 3.监听来自view与业务相关的事件，比如pop、push、弹框...
View：
1.响应与业务无关的事件，比如引发的动画效果; 2.界面元素表达；
依据MVC谈view层的开发规范，便于排查问题和页面刷新问题；
- (void)viewDidLoad
{
[super viewDidLoad];
[self.view addSubview:self.firstView];
[self.view addSubview:self.secondView];
[self.view addSubview:self.thirdView];
[self layoutPageSubviews];
}
- (void)layoutPageSubviews
{
[self.view addConstraints:xxxConstraints];
[self.view addConstraints:yyyConstraints];
[self.view addConstraints:zzzConstraints];
}
关于getter & setter
getter： 结合懒加载的思想，通常用于控件的创建和初始化；
setter： 一般结合点语法用于view层数据的更新操作；
#pragma mark - getters and setters
#pragma mark - getter
- (UILabel *)label {
if (!_label ) {
_label = [[UILabel alloc] init];
_label.text = @"1234";
_label.font = [UIFont systemFontOfSize:12];
... ...
}
return _label;
}
#pragma mark - setter
- (void)setModel:(NSObject *)model {
_model = model;
...
}
六、路由管理机制
目前LCB项目中起到整个page跳转的协调者为LCBPageManager，目前未发现需要大面积优化的点，总结一下LCB 项目组件化方案：
--------------------------------------
| [LCBPageManager sharedInstance] |
| |
| openUrl: <<<<<<<<< (AppDelegate) <<<< Call From Other App With URL
| |
| | |
| | |
| |/ |
| |
| parseUrl |
| |
| | |
| | |
.................................|...............................
| | |
| | |
| |/ |
| |
| performTarget:action:params: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Call From Native Module
| |
| | |
| | |
| | |
| |/ |
| |
| ------------- |
| | | |
| | runtime | |
| | | |
| ------------- |
| . . |
---------------.---------.------------
. .
. .
. .
. .
. .
. .
. .
. .
-------------------.----------- ----------.---------------------
| . | | . |
| . | | . |
| . | | . |
| . | | . |
| | | |
| Target | | Target |
| | | |
| / | \ | | / | \ |
| / | \ | | / | \ |
| | | |
| Action Action Action ... | | Action Action Action ... |
| | | |
| | | |
| | | |
|Business A | | Business B |
------------------------------- --------------------------------
调用方式
先说本地应用调用，本地组件A在某处调用[[LCBPageManager sharedInstance] performTarget:targetName action:actionName params:@{...}]向LCBPageManager发起跨组件调用，LCBPageManager根据获得的target和action信息，通过objective-C的runtime转化生成target实例以及对应的action选择子，然后最终调用到目标业务提供的逻辑，完成需求。
在远程应用调用中，远程应用通过openURL的方式，应用通过AppDelegate接收到URL之后，调用LCBPageManager的openUrl:方法将接收到的URL信息传入。当然，LCBPageManager也可以用openUrl:options:的方式顺便把随之而来的option也接收。传入URL之后，LCBPageManager通过解析URL，将请求路由到对应的target和action，随后的过程就变成了上面说过的本地应用调用的过程了，最终完成响应。
七、RN与Native目前通信的优化点；
可以尝试拆分bundle包，按需下载更新
RN的加载流程主要为几个阶段
- 初始化RN环境
（1）创建Bridge
（2）Bridge中的JS环境
（3）RN模块、UI组件 - 下载JS Bundle
- 运行JS Bundle
- 渲染页面
其中最耗时的为下载/运行JS Bundle
JS Bundle 是由 RN 开发工具打包出来的 JS 文件，其中不仅仅包含了RN 页面组件的 JS 代码，还有 react、react-native 的JS代码，还有我们经常会用上的redux、react-navigation等的代码，所以 JS Bundle文件大小是性能优化的瓶颈；
LCB APP中，包括了非常多的RN页面，但是在用户的常规使用中，很多页面访问频率极低甚至都不会被打开，这些相关的代码，在App启动的时候都是不需要的，那么，我们就可以考虑通过拆包来优化性能，把框架代码和业务代码单独出来，框架代码非常大，因此要分离出来单独前置加载，而业务代码则变成很小的JS代码单独发布，目前LCB APP就是采用的这种优化方式，所以即使是RN包需要更新，启动和首页下载、更新的耗时也不会太久。
八、离屏渲染
离屏渲染就是在当前屏幕缓冲区以外，新开辟一个缓冲区进行操作。
原理：CPU GPU 在绘制渲染视图时做了大量的工作。离屏渲染发生在 GPU 层面上，会创建新的渲染缓冲区，会触发 OpenGL 的多通道渲染管线，图形上下文的切换会造成额外的开销，增加 GPU 工作量。如果 CPU GPU 累计耗时 16.67 毫秒还没有完成，就会造成卡顿掉帧。
离屏渲染出发的场景以及优化方案：
- 圆角 （iOS中maskToBounds & layer.cornerRadius并用才会触发）
- 图层蒙版（考虑通过 CoreGraphics 绘制裁剪圆角，目前category 工具类正在封装中...，or 设计直接提供圆角图片）
- 阴影 （设置layer.shadowPath就不会产生离屏渲染）