iOS_SN_UITableView的优化

最近面试老是被问到这个问题今天总结一下。

1.提前计算并缓存好高度(布局),因为heightForRowAtIndexPath:是调用最频繁的方法。

2.异步绘制,遇到复杂界面,遇到性能瓶颈时,可能就是突破口。

3.滑动时按需加载,这个在大量图片展示,网络加载的时候很管用。

4.尽量少用或不用透明图层。

5.减少subviews的数量。

6.尽量少用addView给Cell动态添加View,可以初始化时就添加,然后通过hide来控制是否显示。

7.避免使用图形特效。在 Cell 上,有越多的图形特效,那么渲染的过程就会越缓慢。

8.适当地复用 Cell。

9.懒加载子视图。

10.异步加载图片。

时间: 2024-10-07 06:09:57

iOS_SN_UITableView的优化的相关文章

iOS开发——项目实战总结&UITableView性能优化与卡顿问题

UITableView性能优化与卡顿问题 1.最常用的就是cell的重用, 注册重用标识符 如果不重用cell时,每当一个cell显示到屏幕上时,就会重新创建一个新的cell 如果有很多数据的时候,就会堆积很多cell.如果重用cell,为cell创建一个ID 每当需要显示cell 的时候,都会先去缓冲池中寻找可循环利用的cell,如果没有再重新创建cell 2.避免cell的重新布局 cell的布局填充等操作 比较耗时,一般创建时就布局好 如可以将cell单独放到一个自定义类,初始化时就布局好

Java性能优化之JVM GC(垃圾回收机制)

Java的性能优化,整理出一篇文章,供以后温故知新. JVM GC(垃圾回收机制) 在学习Java GC 之前,我们需要记住一个单词:stop-the-world .它会在任何一种GC算法中发生.stop-the-world 意味着JVM因为需要执行GC而停止了应用程序的执行.当stop-the-world 发生时,除GC所需的线程外,所有的线程都进入等待状态,直到GC任务完成.GC优化很多时候就是减少stop-the-world 的发生. JVM GC回收哪个区域内的垃圾? 需要注意的是,JV

MySQL 索引优化原则

一.索引优化原则 1.最左前缀匹配原则,联合索引,mysql会从做向右匹配直到遇到范围查询(>.<.between.like)就停止匹配,比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引,d是用不到索引的,如果建立(a,b,d,c)的索引则都可以用到,a,b,d的顺序可以任意调整. 2.=和in可以乱序,比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序,mysql的查询优化器会帮你优

sql优化

1.all: 全表扫描,遍历全表找到匹配的行 index:索引全扫描,遍历整个索引来查询匹配的行 range:索引范围扫描,常见于<,>,>=,between等操作符 ref: 使用非唯一索引扫描或唯一索引的前缀扫描,返回匹配某个单独值的记录行 eq_ref:类似ref,区别就是使用的索引是唯一索引,对于每个索引键值,表中只有一条记录匹配.简单来说,就是多表连接中使用primary key或者unique index 作为关联条件 const/system:单表中最多有一个匹配行,查询起

试试SQLSERVER2014的内存优化表

原文:试试SQLSERVER2014的内存优化表 试试SQLSERVER2014的内存优化表 SQL Server 2014中的内存引擎(代号为Hekaton)将OLTP提升到了新的高度. 现在,存储引擎已整合进当前的数据库管理系统,而使用先进内存技术来支持大规模OLTP工作负载. 就算如此,要利用此新功能,数据库必须包含"内存优化"文件组和表 即所配置的文件组和表使用Hekaton技术. 幸运的是,SQL Server 2014使这一过程变得非常简单直接. 要说明其工作原理,我们来创

Linux性能优化之磁盘优化(三)

前言 关于本章内容,设计的东西比较多.这里会有关于文件系统.磁盘.CPU等方面的知识,以及涉及到关于这方面的性能排查等. 术语 文件系统通过缓存和缓冲以及异步I/O等手段来缓和磁盘的延时对应用程序的影响.为了更详细的了解文件系统,以下就简单介绍一些相关术语: 文件系统:一种把数据组织成文件和目录的存储方式,提供了基于文件的存取接口,并通过文件权限控制访问.另外,一些表示设备.套接字和管道的特殊文件类型,以及包含文件访问时间戳的元数据. 文件系统缓存:主存(通常是DRAM) 的一块区域,用来缓存文

一个配置表优化的想法

今天下班在班车上想了一个关于配置表存储的小优化,起因是早上的时候发现了一个bug,这个bug是由于在运行时动态更改了一个列表配置导致的. 其实关于这种运行时"偷偷"改配置的问题我之前也有考虑过,这种应该是一不小心就会写出的,这不终于都出了一个. 至于如何预防这种问题,我认为在python里面似乎也没有什么好的解决方法,因为它不像c++有const语义,但有一个稍尽人事的预防措施就是把列表型的配置读成元组(tuple).而由此衍生出的一个想法便是:把配置表中所有的列表型配置都读成共享的元

web单机优化

又得开始写博客了,目测又要一周一篇了,当然了这不算python跟前端的,个人喜欢notepad++可惜不能放图片,word什么的太讨厌了 为什么要单机优化呢,很简单,因为不论以后是各类集群也好,物理机虚拟机也好,只有将个人优势发挥到最大才能提升整体的最低限度,因为木桶原理嘛:再一个,穷啊,玩linux那就是得优化,极尽的压榨操作系统的性能.集群什么的都是从单机演化出来的,so,优化好单机是你继续下一步的初始条件 我们从一个请求连接的总流程来看一下我们可优化的点(运维角度) 其实这中间的每一个步骤

前端优化

代码层面:避免使用css表达式,避免使用高级选择器,通配选择器. 缓存利用:缓存Ajax,使用CDN,使用外部js和css文件以便缓存,添加Expires头,服务端配置Etag,减少DNS查找等 请求数量:合并样式和脚本,使用css图片精灵(sprite),初始首屏之外的图片资源按需加载,静态资源延迟加载(懒加载). 请求带宽:压缩文件,开启GZIP, 代码层面的优化 用 hash-table 来优化查找 少用全局变量 用 innerHTML 代替 DOM 操作,减少 DOM 操作次数,优化 j