移动端关注的一些指标
运行多少小时不崩溃；
多次打开页面，控制崩溃率；
界面优化，如何才能让用户不急躁、不烦躁；
服务器没有返回数据，是否会导致奔溃；
网络不好，数据来的太慢，界面是否不流畅；
从数据库读的数据太慢如何解决等。
网络不好的情况处理：
移动端界面应该有自己的逻辑，需要网络数据的地方，应该有默认值，这样在网络数据没有返回的情况下，让用户有数据可以看到。收到的网络数据应该是通过某种方式刷新到界面，而不是等到数据返回才刷新页面。当没有网络数据的时候，界面应该可以自成一体，走的通流程，不强依赖网络数据。
在弱网模式下调试是我们必备的功力，因为我们要考虑用户的实施环境通常都不会很好。把经常使用的数据，存到缓存，提高APP的运行效率、界面流程度。同时，我们需要具备收集奔溃日志的功能，这样才能更好的减少崩溃，提高用户体验。
通过 Storyboard 创建视图对象时，其资源消耗会比直接通过代码创建对象要大非常多，在性能敏感的界面里，Storyboard 并不是一个好的技术选择。
尽量推迟对象创建的时间，并把对象的创建分散到多个任务中去。尽管这实现起来比较麻烦，并且带来的优势并不多，但如果有能力做，还是要尽量尝试一下。如果对象可以复用，并且复用的代价比释放、创建新对象要小，那么这类对象应当尽量放到一个缓存池里复用。
对象销毁
对象的销毁虽然消耗资源不多，但累积起来也是不容忽视的。通常当容器类持有大量对象时，其销毁时的资源消耗就非常明显。同样的，如果对象可以放到后台线程去释放，那就挪到后台线程去。这里有个小 Tip：把对象捕获到 block 中，然后扔到后台队列去随便发送个消息以避免编译器警告，就可以让对象在后台线程销毁了。
NSArray *tmp = self.array;
self.array = nil;
dispatch_async(queue, ^{
[tmp class];
});
布局计算
视图布局的计算是 App 中最为常见的消耗 CPU 资源的地方。如果能在后台线程提前计算好视图布局、
并且对视图布局进行缓存，那么这个地方基本就不会产生性能问题了。
不论通过何种技术对视图进行布局，其最终都会落到对 UIView.frame/bounds/center 等属性的
调整上。上面也说过，对这些属性的调整非常消耗资源，所以尽量提前计算好布局，在需要时一次性调
整好对应属性，而不要多次、频繁的计算和调整这些属性。
Autolayout
Autolayout 是苹果本身提倡的技术，在大部分情况下也能很好的提升开发效率，但是 Autolayout 对于复杂视图来说常常会产生严重的性能问题。随着视图数量的增长，Autolayout 带来的 CPU 消耗
会呈指数级上升。如果你不想手动调整 frame 等属性，你可以用一些工具方法替代
（比如常见的 left/right/top/bottom/width/height 快捷属性），或者使用
ComponentKit、AsyncDisplayKit 等框架。
文摘出处 ： http://www.jianshu.com/p/f4adce56166f
感谢原作者 吴白
网友评论