代码优化

代码优化-多态代替IF条件判断

北城余情 提交于 2019-12-01 19:23:52
场景描述 在开发的场景中,常常会遇到打折的业务需求,每个用户对应的等级,他们的打折情况也是不一样的。例如普通会员打9折,青铜会员打8.5折,黄金会员打8折等等。在一般开发中最简单的就是判断用户的等级,然后对订单作对应的打折处理。 场景示例 写了一个简单的小示例,如下所示: //1 代表学生 2老师 3校长 int type = 1; if (1 == type) { System.out.println("学生笑嘻嘻的说话"); } else if (2 == type) { System.out.println("老师开心的说话"); } else { System.out.println("校长严肃的说话"); } 上面的代码,是我们经常的做法,代码少的时候,看起来非常清晰,但是代码多起来或者有了更多的判断条件,那上面的代码会更加的混乱,如果每次有修改,都要改动这部分代码。 解决方法 可以把上面的代码改成多态方式,创建三个类,学生Student,老师Teacher,校长HeadMater,父类为Person,这三个类都实现父类的方法say,如下所示: Person.class package me.xueyao.service; /** * @author Simon.Xue * @date 2019-12-01 14:31 **/ public interface

让你“过五关,斩六将”轻松入大厂。类比于微信,如何对Apk进行极限压缩,谈下Android压缩8大步

无人久伴 提交于 2019-12-01 15:39:14
本专栏专注分享大型Bat面试知识,后续会持续更新,喜欢的话麻烦点击一个关注 github面试↓专题链接 关于我 面试官: 类比于微信,如何对Apk进行极限压缩,谈下Android压缩8大步 (面试官是非常注重性能优化的,考求职者是否具备APK压缩技能) 求职者:应该从每一步压缩开始,压缩的过程本质是挤牙膏的过程,一步一步挤。将Apk压缩分为8个步骤 一.简介 随着项目的不断迭代,代码量跟资源文件不断增多。那么就会出现打包后的 APK 文件越来越大,如果突然有一天你们老板或领导叫你优化 APK 大小,你还不知道怎么优化那就有点说不过去了,这篇文章咱们就来一起分析并优化 APK 体积大小吧。 二.分析 APK 资源占用 注意: 在 GitHub 找了一个人气比较高的开源项目,需要的话自己可以点击 下载 ,自己动手尝试一番. 分析工具直接用的 AS Build/Analyze APK 从上面图中得出 assets > classes.dex > res > lib 其中资源文件占用最大。 下面我们就来看看怎么减小 APK 大小吧, 三.优化 APK 体积八大步 1. 将图片转换为 webp 格式 Webp 概念 WebP 是一种同时提供了有损压缩与无损压缩的图片文件格式,派生自视频编码格式 VP8。WebP 最初在2010年发布,目标是减少文件大小,但达到 和 JEPG

Java代码优化

假如想象 提交于 2019-12-01 15:13:29
(1)尽量指定类、方法的final修饰符 带有final修饰符的类是不可派生的。在Java核心API中,有许多应用final的例子,例如java.lang.String,整个类都是final的。为类指定final修饰符可以让类不可以被继承,为方法指定final修饰符可以让方法不可以被重写。如果指定了一个类为final,则该类所有的方法都是final的。Java编译器会寻找机会内联所有的final方法,内联对于提升Java运行效率作用重大,此举能够使性能平均提高50%。 (2)尽量重用对象 特别是String对象的使用,出现字符串连接时应该使用StringBuilder/StringBuffer代替。由于Java虚拟机不仅要花时间生成对象,以后可能还需要花时间对这些对象进行垃圾回收和处理,因此,生成过多的对象将会给程序的性能带来很大的影响。 (3)尽可能使用局部变量 调用方法时传递的参数以及在调用中创建的临时变量都保存在栈中,速度较快,其他变量,如静态变量、实例变量等,都在堆中创建,速度较慢。另外,栈中创建的变量,随着方法的运行结束,这些内容就没了,不需要额外的垃圾回收。 (4)及时关闭流 Java编程过程中,进行数据库连接、I/O流操作时务必小心,在使用完毕后,及时关闭以释放资源。因为对这些大对象的操作会造成系统大的开销,稍有不慎,将会导致严重的后果。 (5

webpack 构建性能优化策略小结

北战南征 提交于 2019-12-01 11:59:09
背景 如今前端工程化的概念早已经深入人心,选择一款合适的编译和资源管理工具已经成为了所有前端工程中的标配,而在诸多的构建工具中, webpack 以其丰富的功能和灵活的配置而深受业内吹捧,逐步取代了grunt和gulp成为大多数前端工程实践中的首选,React,Vue,Angular等诸多知名项目也都相继选用其作为官方构建工具,极受业内追捧。但是,随者工程开发的复杂程度和代码规模不断地增加,webpack暴露出来的各种性能问题也愈发明显,极大的影响着开发过程中的体验。 问题归纳 历经了多个web项目的实战检验,我们对webapck在构建中逐步暴露出来的性能问题归纳主要有如下几个方面: 代码全量构建速度过慢,即使是很小的改动,也要等待长时间才能查看到更新与编译后的结果(引入HMR热更新后有明显改进); 随着项目业务的复杂度增加,工程模块的体积也会急剧增大,构建后的模块通常要以M为单位计算; 多个项目之间共用基础资源存在重复打包,基础库代码复用率不高; node的单进程实现在耗cpu计算型loader中表现不佳; 针对以上的问题,我们来看看怎样利用webpack现有的一些机制和第三方扩展插件来逐个击破。 慢在何处 作为工程师,我们一直鼓励要理性思考,用数据和事实说话,“我觉得很慢”,“太卡了”,“太大了”之类的表述难免显得太笼统和太抽象,那么我们不妨从如下几个方面来着手进行分析:

Java并发:线程安全与锁优化

时间秒杀一切 提交于 2019-12-01 11:07:08
概述 人们很难想象现实中的对象在一项工作进行期间,会被不停地中断和切换,对象的属性(数据)可能会在中断期间被修改和变“脏”,而这些事情在计算机世界中则是很正常的事情。有时候,良好的设计原则不得不向现实做出一些让步,我们必须让程序在计算机中正确无误地运行,然后再考虑如何将代码组织得更好,让程序运行更快。对于“高效并发”来说,首先需要保证并发的正确性,然后在此基础上实现高效。 1.线程安全 《Java Concurrency In Practice》的作者Brian Goetz对“线程安全”有一个比较恰当的定义:“当多个线程访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那这个对象是线程安全的”。 这个定义比较严谨,它要求线程安全的代码都必须具备一个特征:代码本身封装了所有必要的正确性保障手段(如互斥同步等),令调用者无须关心多线程的问题,更无须自己采取任何措施来保证多线程的正确调用。这点听起来简单,但其实并不容易做到,在大多数场景中,我们都会将这个定义弱化一些,如果把“调用这个对象的行为”限定为“单次调用”,这个定义的其他描述也能够成立的话,我们就可以称它是线程安全了。 1.1 Java语言中的线程安全 按照线程安全的“安全程度”由强至弱来排序

一篇文章搞定前端性能优化面试

时光总嘲笑我的痴心妄想 提交于 2019-12-01 09:52:59
前言 虽然前端开发作为 GUI 开发的一种,但是存在其特殊性,前端的特殊性就在于“动态”二字,传统 GUI 开发,不管是桌面应用还是移动端应用都是需要预先下载的,只有先下载应用程序才会在本地操作系统运行,而前端不同,它是“动态增量”式的,我们的前端应用往往是实时加载执行的,并不需要预先下载,这就造成了一个问题,前端开发中往往最影响性能的不是什么计算或者渲染,而是加载速度,加载速度会直接影响用户体验和网站留存。 《Designing for Performance》 的作者 Lara Swanson 在2014年写过一篇文章 《Web性能即用户体验》 ,她在文中提到“网站页面的快速加载,能够建立用户对网站的信任,增加回访率,大部分的用户其实都期待页面能够在2秒内加载完成,而当超过3秒以后, 就会有接近40%的用户离开你的网站 ”。 值得一提的是,GUI 开发依然有一个共同的特殊之处,那就是 体验性能 ,体验性能并不指在绝对性能上的性能优化,而是回归用户体验这个根本目的,因为在 GUI 开发的领域,绝大多数情况下追求绝对意义上的性能是没有意义的. 比如一个动画本来就已经有 60 帧了,你通过一个吊炸天的算法优化到了 120 帧,这对于你的 KPI 毫无用处,因为这个优化本身没有意义,因为除了少数特异功能的异人,没有人能分得清 60 帧和 120 帧的区别,这对于用户的体验没有任何提升

C/C++ Volatile关键词深度剖析

别来无恙 提交于 2019-12-01 08:14:32
背景 此微博,引发了朋友们的大量讨论:赞同者有之;批评者有之;当然,更多的朋友,是希望我能更详细的解读C/C++ Volatile关键词,来佐证我的微博观点。而这,正是我写这篇博文的初衷:本文,将详细分析C/C++ Volatile关键词的功能 (有多种功能)、Volatile关键词在多线程编程中存在的问题、Volatile关键词与编译器/CPU的关系、C/C++ Volatile与Java Volatile的区别,以及Volatile关键词的起源,希望对大家更好的理解、使用C/C++ Volatile,有所帮助。 Volatile,词典上的解释为:易失的;易变的;易挥发的。那么用这个关键词修饰的C/C++变量,应该也能够体现出”易变”的特征。大部分人认识Volatile,也是从这个特征出发,而这也是本文揭秘的C/C++ Volatile的第一个特征。 Volatile:易变的 在介绍C/C++ Volatile关键词的”易变”性前,先让我们看看以下的两个代码片段,以及他们对应的汇编指令 (以下用例的汇编代码,均为VS 2008编译出来的Release版本): 测试用例一:非Volatile变量 b = a + 1;这条语句,对应的汇编指令是:lea ecx, [eax + 1]。由于变量a,在前一条语句a = fn(c)执行时,被缓存在了寄存器eax中,因此b = a + 1

移动App性能评测与优化

扶醉桌前 提交于 2019-12-01 07:59:47
针对测试的点: 耗电量 优化方法一:CPU时间片 优化方法二:wake lock 优化方法三:传感器 优化方法四:云省电策略 流畅度 Android提供 两个很好用的工 具:Traceview以及Systrace 导航评测 网络 自己动手对几种典型的运营商网 络(移动2.5G,联通2G/3G等)进行测试,抓包分析 安装包瘦身 1)代码部分:冗余代码、无用功能、代码混淆、方法数缩减。 2)资源部分:冗余资源、资源混淆、图片处理(压缩、图片转 换、点9图化等)。 3)对整个安装包做7zip极限压缩。 来源: https://www.cnblogs.com/mobies/p/11671574.html

深入了解GOT,PLT和动态链接

隐身守侯 提交于 2019-12-01 07:28:19
教材学习内容总结 实验楼部分 X86 寻址方式经历三代: 1 DOS时代的平坦模式,不区分用户空间和内核空间,很不安全 2 8086的分段模式 3 IA32的带保护模式的平坦模式 二进制文件可以用od 命令查看,也可以用gdb的x命令查看。有些输出内容过多,我们可以使用 more或less命令结合管道查看,也可以使用输出重定向来查看 od code.o | more od code.o > code.txt gcc -S xxx.c -o xxx.s 获得汇编代码,也可以用 objdump -d xxx 反汇编; 函数前两条和后两条汇编代码,所有函数都有,建立函数调用栈帧 64位机器上想要得到32代码:gcc -m32 -S xxx.c MAC OS中没有objdump, 有个基本等价的命令otool Ubuntu中 gcc -S code.c (不带-O1) 产生的代码更接近教材中代码(删除"."开头的语句) PPT部分 x86-64的CPU包含一组16个存储64位的通用目的寄存器,如图: MOV中的一些常见的数据传送指令 函数调用时栈帧相对应的变化 操作部分 ① 对教材P114的C语言文件 mstore.c 使用命令 gcc -Og -S mstore.c 可产生其对应的汇编文件 mstore.s 但是不做进一步操作;使用命令 gcc -Og -c mstore.c

【高级架构师实战】Spring Cloud微服务大型电商架构亿级流(免费不加密)

我的梦境 提交于 2019-12-01 07:24:15
第一版 001. 课程介绍以及高并发高可用复杂系统中的缓存架构有哪些东西? 002. 基于大型电商网站中的商品详情页系统贯穿的授课思路介绍 003. 小型电商网站的商品详情页的页面静态化架构以及其缺陷 004. 大型电商网站的异步多级缓存构建+nginx数据本地化动态渲染的架构 005. 能够支撑高并发+高可用+海量数据+备份恢复的redis的重要性 006. 从零开始在虚拟机中一步一步搭建一个4个节点的CentOS集群 007. 单机版redis的安装以及redis生产环境启动方案 008. redis持久化机对于生产环境中的灾难恢复的意义 009. 图解分析redis的RDB和AOF两种持久化机制的工作原理 010. redis的RDB和AOF两种持久化机制的优劣势对比 011. redis的RDB持久化配置以及数据恢复实验 012. redis的AOF持久化深入讲解各种操作和相关实验 013. 在项目中部署redis企业级数据备份方案以及各种踩坑的数据恢复容灾演练 014. redis如何通过读写分离来承载读请求QPS超过10万+? 015. redis replication以及master持久化对主从架构的安全意义 016. redis主从复制原理、断点续传、无磁盘化复制、过期key处理 017. redis replication的完整流运行程和原理的再次深入剖析