【简介】在2016年底前后一直在做智能家居APP，这个项目是利用 Objective-C 和 Swift 混编，至今看来混编会出现很多奇奇怪怪的问题。
遇到的代码问题以及解决方案
- OC中的对象属性(NSString *)在swift中使用或者映射时，Swift默认为不可选变量(String!)，但是OC的变量是可能为nil。
解决方案：
（1）在 Swift 中，必须对映射过来的OC对象属性进行判空。
（2）在 Swift 中，不方便判空的话，可以当做可选项(?)使用，在 swift2.3 中不会报错。
- UIView 的单例动画导致 CPU 占有率过高。在一个控制器里调用 UIView 的单例动画，如果发现==互调动画==的情况，可能会出现即使控制器已经deinit，该动画还存在并且一直在运行中，原因不明。
问题伪代码：
- (void)oneAnimating
{
[UIView animateWithDuration:kDuration animations:^{
//动画执行代码
} completion:^(BOOL finished) {
[weakSelf twoAnimating];
}];
}
- (void)twoAnimating
{
[UIView animateWithDuration:kDuration animations:^{
//动画执行代码
} completion:^(BOOL finished) {
[weakSelf oneAnimating];
}];
}
解决方案：
动画改用轻量级视图层动画(layer)主要优点：
1. 防止互调出现的循环引用
2. 减少CPU负担，提高性能
为了保险起见，可以再 deinit/dealloc 中调用去掉动画的方法
写代码的一些注意事项以及建议
把视图View设置以及用户交互和网络请求以及逻辑处理分开处理，这样有效方便以后的UI调试。
对UI控件进行一些必要的一些封装以便复用，但得保证功能单一，外露的设置数据以及状态方便。
HTTP网络请求把请求参数以及返回数据都格式化打印处理，这样有利于我们不用一个个接口调试定位。
HTTP网络请求返回的所有错误，尽可能进行相应的处理，不用处理的错误，在开发测试过程中可以进行弹窗处理，让测试人员、开发人员能够快速定位问题。
在收到TCP/UDP长链接中，最好用线程锁与普通HTTP网络请求的处理分隔开，确保两种操作互斥，确保线程安全。
在收到TCP/UDP长链接中的包，调试开发模式尽可能显示在APP上，可以利用UILabel放到对应的window进行实时显示。
设置一个开关、宏、全局变量对开发模式和生产模式进行切换，对日志的打印、调试弹窗以及调试的特有的key，hostAddress等参数能够改一个参数就可以切换。
遇到多个Tableview的处理，需要考虑子Tableview的数据源和委托放哪里比较好。有两种方案：
（1）把数据源以及委托代码放到 View 或者 UItableView 的子类里。
（2）复用所在控制器里的代理方法，也就是复用主Tableview的代理方法，在VC 中的代理方法里分类处理。
调试技巧
遇到不能进行调试，无法打印日志的情况下，可以考虑把需要知道的数据写进文件里，或者利用弹窗进行提示。
合理利用Xcode自带的Instruments工具集进行性能优化以及找出消耗性能大的一些bug。
需要监听第三方SDK的网络请求中的URL，可以写一个继承NSURLProtocol的一个类，并重写一个合适的方法打个断点，就可以监听到网络请求里用到的NSURL里的属性。
例子代码：
@interface TCustomProtocol : NSURLProtocol
@end
@implementation TCustomProtocol
+ (BOOL)canInitWithRequest:(NSURLRequest *)request
{
//可在这里打个断点监听
return NO;
}
@end
@interface AppDelegate : UIResponder <UIApplicationDelegate>
@property (strong, nonatomic) UIWindow *window;
@end
@implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[NSURLProtocol registerClass:[TCustomProtocol class]];
return YES;
}
@end
