ORM中对UPDATE的一点优化

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ORM中对UPDATE的一点优化相关的知识,希望对你有一定的参考价值。

参考技术A 这点在项目选型上是值得思考的一个问题,两种方式各有优劣,参考 dapper 给出的横向对比不难发现

ORM
编码便利,易于管理和维护
性能会打折扣

纯SQL
性能绝对没得比
管理复杂,容易引入因变动导致的错误

公司之前的项目一路过来也是由纯SQL引入ORM,历次的版本更新都比之前存SQL时代轻松的不少。

但,一直以来有个问题,那就是更新UPDATE的时候

假设我们有以下实体类

问题来了:ORM内部是通过反射将player对象转换成SQL语句

这里会把所有的属性字段都SET一遍,很多时候我们可能只改变了其中几个字段。这真是一种蛋疼的方式,如果模型的属性比较多,那真是悲剧了。

既然这块太臃肿了,我们希望只修改变动的字段。如何做呢?利用属性的set get方法,在属性赋值的时候记录下变动。

所以当我们在对对象属性赋值之后可以得到一个匿名类或者字典,这个根据自己使用的ORM框架或者自己的封装而定。改进后ORM UPDATE 的方法是这样的

在UPDATE 内部生成SQL的时候可以省去大部分没变的字段。

很多的ORM框架UPDATE的时候支持匿名函数传值

而这里的局限性是 obj 只能是在编码的时候固定字段,不能再程序运行期间动态增减字段。
而C#有的其他几个匿名类,构造出来的类型无法通过反射获取全部的property (尝试过很多方式,没成功,有好的思路欢迎推荐)

对于iOS性能优化的一点看法

在我们通常的开发工作中,每次需求定下来的时候,开发时间都是很紧张的,于是我们就抓紧时间开发,完成需求。在匆忙开发的过程中,或多或少的会有一些性能问题存在,在开发任务完成以后,我们都要进行性能优化。现将我在开发过程中的性能优化问题分享如下。

一、数据压缩

在程序的运行过程中,数据的传输也是影响程序性能的一个方面。在传输速度不变的情况下,数据量大,传输需要的时间就多,数据量小,传输需要的时间自然就少。传入需要的时间少,我们程序的响应速度自然就变快了。

1. 对网络传输的数据进行压缩

这一步需要和服务端配合,服务端需要开启数据压缩的配置。而对于移动端来说,网上开源的AFNetWorking框架已经帮我们实现了这个功能,我们只要在我们定义的网络请求基类中开启这个功能就可以了。

代码如下:

[objc] view plain copy
 
  1. /** 
  2.          *  请求数据开启gzip压缩 
  3.          */  
  4.         [self.sessionManager.requestSerializer setValue:www.boshenyl.cn  @www.wanmeiyuele.cn "gzip" forHTTPHeaderField:@"Accept-Encoding"];  

2.对下载的图片进行数据压缩

这一步对程序性能的提升效果很明显。我之前在的公司的App是做拍卖的,照片拍的很精细,有的一张图片好几M,下载到App,图片一解析,直接就闪退了。我们进行过跟踪,这种大图片下载下来一解析,手机内存直接爆了。所以我们对下载的图片进行了压缩。

2.1对图片的尺寸进行压缩

我们和服务端商量以后进行了改进。我们请求下载图片的时候,加上图片的尺寸,服务端返回给我们对应大小的图片。

客户端的优化方案:根据屏幕的宽度和设计师给定的尺寸,计算出当前手机需要的图片尺寸,然带上尺寸向服务端请求下载图片。

2.2对下载图片的数据量进行压缩

下载图片的数据量的压缩对性能提升效果是很明显的。SDWebImage/WebP对图片的压缩率高,肉眼看不出差异。只要安装了这个第三方库,我们可以像之前一样使用图片下载。

二、数据缓存

对于一些不需要实时更新的数据,比如图片、文本,我们可以缓存到本地,设置一个过期时间,不需要每次都去加载。这样既能节省用户的流量,也能提升我们程序的性能。

对于一些耗时但是又不需要变动的计算结果,我们可以把它缓存下来。比如动态cell的行高,耗时的计算结果。

三、使用lazyload加载UI和数据

使用lazyload对UI和数据进行加载。lazyload叫懒加载或者延迟加载,是等到真正需要这个控件或者数据的时候才去进行加载,尽可能的保证值加载当前需要的控件或者数据,减少加载的任务。不要一进入VC就把所有的数据和UI控件都加载好,这样会影响加载速度,从而影响用户体验。所以不管是对于数据,还是UI控件,我们应该在需要的时候才去加载,把加载过程分散出去,使程序加载尽可能的快

四、使用Instruments对App进行检测

我们在一个阶段的开发任务完成以后,一个使用Instruments对我们的程序的性能进行检测,从而有针对性的进行优化。

需要进行优化的点如下:

  1. 使用Leaks检测是否有内存泄漏。
  2. 使用Core Animation进行图层检测。这篇文章介绍的很详细。
  3. 使用Time Profile检测是否有比较耗时的操作,从而进行对应的代码优化。

五、集合的使用

在开发过程中,对于一些只用于存储和读取,中间不用进行更新的集合,我们应该尽量使用不可变的集合,因为可变集合会占用比不可变集合更多的内存空间。例如:NSArray/NSMutableArray,NSDictionary/dasheng178.com/ NSMutableDictionary
在操作集合的时候,使用正确的集合操作方法。

六、使用GCD来进行优化

对于一些比较耗时的操作,我们应该使用GCD开启新的一步线程来进行操作,使得 App 能够运行的更加流畅响应更快。但是使用 GCD 时需要注意避免可能引起线程爆炸和死锁的情况,还有非主线程处理任务也不是万能的,如果一个处理需要消耗大量内存或者大量CPU操作 GCD 也没法帮你,只能通过将处理进行拆解分步骤分时间进行处理才比较妥当。

七、I/O性能优化

I/O 是性能消耗大户,任何的 I/O 操作都会使低功耗状态被打破,所以减少 I/O 次数是这个性能优化的关键点,为了达成这个目下面列出一些方法。
  • 将零碎的内容作为一个整体进行写入
  • 使用合适的 I/O 操作 API
  • 使用合适的线程
  • 使用 NSCache 做缓存能够减少 I/O

八、在耗内存操作中合理的使用AutoReleasePool

对于一些大循环或者耗内存的循环,我们应该在循环的内部使用AutoRelasePool来进行内存的释放,这样的话可以保证内存尽快的被回收。降低系统的内存压力。

九、耗时操作的缓存

在开发的过程中,如果遇到类似日期格式转换的操作,我们应该对这样的操作进行缓存,因为使用instrument对它进行性能检测,我们会发现,这是比较耗时的操作。
实际案例:在之前的开发中,我们发现有一个计算ID的操作非常耗时,每次都去计算,非常影响程序的性能。于是我们对计算得到的ID进行缓存,在之后的操作中,不再进行计算,直接读缓存结果。我们发现性能有了明显的提升。

十、算法优化

开发过程中我们前期可能为了赶项目进度,只是尽量快的去完成开发任务。当我们再回头看代码的时候,发现有的算法是比较耗时的,还可以对其进行进一步的优化,使我们程序的性能更佳。所以,我们在开发任务不是很重的时候,应该对之前写的一些算法进行检查,优化。

十一、安装包瘦身

安装包的大小,对于程序的性能还是有一定影响的。在我们的不断的版本迭代过程中,或多或少的产生了一些不再需要的图片、文件,这些文件我们在打包的时候也会打包进去,这些文件以防是安装包变大,另一方面影响我们程序的性能,我们应该将其删除。

 



以上是关于ORM中对UPDATE的一点优化的主要内容,如果未能解决你的问题,请参考以下文章

Python3中对Dict的内存优化

ffmpeg播放RTSP的一点优化

对于iOS性能优化的一点看法

如何在C#中对单元测试性能优化进行单元测试?

关于Kafka部署优化的一点建议

与下位机或设备的通信解析优化的一点功能(续补):动态编译