代码优化

一：轮播图样式 编程注意：把左右按钮放在一个盒子里 把单边播放 循环播放 也放在一个盒子里 分别绝对定位 都要在一个盒子里：方便编程 单边循环与循环播放的区别就在于 对index的处理不同： 添加一个bool 开关： 改进点击事件： 以上代码不好：代码耦合性高 来源： https://www.cnblogs.com/yzdwd/p/12636786.html

在编码中难免遇到if else过多情况，一方面是当初设计没有在意，另一方面可能是因为需求的不断变化。但代码中出现大量if else都知道这种情况不太好，那么我们就聊一下这种情况应该如何优化 if(条件1){ .... }else if(条件2){ .... }else if(条件3){ .... }else{ .... } 1.表驱动 表驱动是指用查表的方式获取值 private static Map<Status, Function<Integer, Integer>> conditions; static { conditions = new HashMap<>(); conditions.put(Status.CONDITION1,(t)->{ return t+1; }); conditions.put(Status.CONDITION2,(t)->{ return t+2; }); } @Test public void test(){ Integer apply = conditions.get(Status.CONDITION1).apply(1); System.out.println(apply); } enum Status{ CONDITION1,CONDITION2; } 2.责任链模式 当判断条件复杂多变时，就无法使用上述的驱动表了。

keil优化等级设置 优化级别说明（仅供参考）： 则其中的 Code Optimization 栏就是用来设置C51的优化级别。共有9个优化级别（书上这么写的），高优化级别中包含了前面所有的优化级别。现将各个级别说明如下： 0级优化： 1、 常数折叠：只要有可能，编译器就执行将表达式化为常数数字的计算，其中包括运行地址的计算。 2、 简单访问优化：对8051系统的内部数据和位地址进行访问优化。 3、 跳转优化：编译器总是将跳转延至最终目标上，因此跳转到跳转之间的命令被删除。 1级优化： 1、 死码消除：无用的代码段被消除。 2、 跳转否决：根据一个测试回溯，条件跳转被仔细检查，以决定是否能够简化或删除。 2级优化： 1、 数据覆盖：适于静态覆盖的数据和位段被鉴别并标记出来。连接定位器BL51通过对全局数据流的分析，选择可静态覆盖的段。 3级优化： 1、“窥孔”优化：将冗余的MOV命令去掉，包括不必要的从存储器装入对象及装入常数的操作。另外如果能节省存储空间或者程序执行时间，复杂操作将由简单操作所代替。 4级优化： 1、 寄存器变量：使自动变量和函数参数尽可能位于工作寄存器中，只要有可能，将不为这些变量保留数据存储器空间。 2、扩展访问优化：来自IDATA、XDATA、PDATA和CODE区域的变量直接包含在操作之中，因此大多数时候没有必要将其装入中间寄存器。 3、局部公共子式消除

由于文章特别长，建议先收藏再阅读。 在 Android 性能优化的知识体系当中，包体积优化一直被排在优先级比较低的位置，从而导致很多开发同学对自身应用的大小并不重视。在项目发展的历程中，一般可划分为如下三个阶段： 初创期 => 成长期 => 成熟期 通常来说，当应用处于成长期的中后阶段时，才会考虑去做系统的包体积优化，因此，只有在这个阶段及之后，包体积优化带来的收益才是可观的。 那么，包体积优化能够给我们带来哪些 收益 呢？如何全面对应用的包体积进行 系统分析 及 针对性优化呢？在这篇文章中，我们将一起进行深入地分析与探索。 1、瘦身优化及 Apk 分析方案介绍 1、瘦身优势 我们首先来介绍下，为什么我们需要做 APK 的瘦身优化？ 主要有 三个方面 的原因： （1）下载转化率 APK 瘦身优化在实际的项目中优先级是比较低的，因为做了之后它的好处不是那么明显，尤其是那些还没有到 稳定期 的项目，我们都知道，App 的发展历程是从 项目初期 => 成长期 => 稳定期，对于处于 发展初期与成长期 的项目而言，可能会做 启动优化、卡顿优化，但是一般不会做 瘦身优化，瘦身优化 最主要的好处是对应用 下载转化率 的影响，它是 App 业务运营的重要指标之一，在项目精细化运营的阶段是非常重要的。 因为如果你的 App 与其它同类型的 App 相比 Apk 体积要更小的话，那么你的 App

T- SQL性能优化详解 http://www.cnblogs.com/weixing/p/3357519.html 故事开篇：你和你的团队经过不懈努力，终于使网站成功上线，刚开始时，注册用户较少，网站性能表现不错，但随着注册用户的增多，访问速度开始变慢，一些用户开始发来邮件表示抗议，事情变得越来越糟，为了留住用户，你开始着手调查访问变慢的原因。 　　经过紧张的调查，你发现问题出在数据库上，当应用程序尝试访问/更新数据时，数据库执行得相当慢，再次深入调查数据库后，你发现数据库表增长得很大，有些表甚至有上千万行数据，测试团队开始在生产数据库上测试，发现订单提交过程需要花5分钟时间，但在网站上线前的测试中，提交一次订单只需要2/3秒。 　　类似这种故事在世界各个角落每天都会上演，几乎每个开发人员在其开发生涯中都会遇到这种事情，我也曾多次遇到这种情况，因此我希望将我解决这种问题的经验和大家分享。 　　如果你正身处这种项目，逃避不是办法，只有勇敢地去面对现实。首先，我认为你的应用程序中一定没有写数据访问程序，我将在这个系列的文章中介绍如何编写最佳的数据访问程序，以及如何优化现有的数据访问程序。 　　 范围 　　在正式开始之前，有必要澄清一下本系列文章的写作边界，我想谈的是“事务性(OLTP)SQL Server数据库中的数据访问性能优化”，但文中介绍的这些技巧也可以用于其它数据库平台。 　

性能调优 不用运行的代码才是绝好的代码。其他只是好的代码。所以，性能调优时，最好的选择是首先确保运行尽可能少的代码。 OpCode 缓存 首先，最快且最简单的选择是启用 OpCode 缓存。OpCode 缓存的更多信息可以在 这里 找到。 在上图，我们看到启用 Zend OpCache 后发生的情况。最后一行是我们的基准，也即没有启用缓存的情况。 在中间行，我们看到较小的性能提升，以及内存使用量的大幅减少。小的性能提升(很可能)来自 Zend OpCache 优化，而非 OpCode 缓存。 第一行是优化和 OpCode 缓存后结果，我们看到很大的性能提升。 现在，我们看看 APC 之前和之后的变化。如上图所示，跟 Zend OpCache 相比，随着缓存的建立，我们看到初始(中间行)请求的性能下降，在消耗时长与内存使用量方面的表现都明显下降。 接着，随之 opcode 缓存的建立，我们看到类似的性能提升。 内容缓存 第二件我们能做的事是缓存内容——这对 WordPress 而言小菜一碟。它提供了许多安装简便的插件来实现内容缓存，包括 WP Super Cache。WP Super Cache 会创建网站的静态版本。该版本会在出现诸如评论事件时依照网站设置自动过期。(例如，在非常高负载情况下，您可能会想禁止任何原因造成的缓存过期)。 内容缓存只能在几乎没有写操作时有效运行

这段时间对项目做了一次整体的优化，全站有了20%左右的提升（本来载入速度已经1.2S左右了，优化度很低），算一算已经做了四轮的全站性能优化了，回顾几次的优化手段，基本上几个字就能说清楚： 传输层面：减少请求数，降低请求量执行层面：减少重绘&回流 传输层面的从来都是优化的核心点，而这个层面的优化要对浏览器有一个基本的认识，比如： ① 网页自上而下的解析渲染，边解析边渲染，页面内CSS文件会阻塞渲染，异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源，新开线程下载（有并发上限），在带宽限制的条件下，无序并发会导致主资源速度下降，从而影响首屏渲染 ③ 浏览器缓存可用时会使用缓存资源，这个时候可以避免请求体的传输，对性能有极大提高 衡量性能的重要指标为首屏载入速度（指页面可以看见，不一定可交互），影响首屏的最大因素为请求，所以请求是页面真正的杀手，一般来说我们会做这些优化： 减少请求数 ① 合并样式、脚本文件 ② 合并背景图片 ③ CSS3图标、Icon Font 降低请求量 ① 开启GZip ② 优化静态资源，jQuery->Zepto、阉割IScroll、去除冗余代码 ③ 图片无损压缩 ④ 图片延迟加载 ⑤ 减少Cookie携带 很多时候，我们也会采用类似“时间换空间、空间换时间”的做法，比如： ① 缓存为王，对更新较缓慢的资源&接口做缓存（浏览器缓存

一、Debug 和 Release 编译方式的本质区别 Debug 通常称为调试版本，它包含调试信息，并且不作任何优化，便于程序员调试程序。Release 称为发布版本，它往往是进行了各种优化，使得程序在代码大小和运行速度上都是最优的，以便用户很好地使用。 Debug 和 Release 的真正秘密，在于一组编译选项。下面列出了分别针对二者的选项（当然除此之外还有其他一些，如/Fd /Fo，但区别并不重要，通常他们也不会引起 Release 版错误，在此不讨论） Debug 版本： /MDd /MLd 或 /MTd 使用 Debug runtime library(调试版本的运行时刻函数库) /Od 关闭优化开关 /D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关(主要针对 assert函数) /ZI 创建 Edit and continue(编辑继续)数据库，这样在调试过 程中如果修改了源代码不需重新编译 /GZ 可以帮助捕获内存错误 /Gm 打开最小化重链接开关，减少链接时间 Release 版本： /MD /ML 或 /MT 使用发布版本的运行时刻函数库 /O1 或 /O2 优化开关，使程序最小或最快 /D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数) /GF 合并重复的字符串，并将字符串常量放到只读内存，防止 被修改

原文出处： 海子 相信String这个类是Java中使用得最频繁的类之一，并且又是各大公司面试喜欢问到的地方，今天就来和大家一起学习一下String、StringBuilder和StringBuffer这几个类，分析它们的异同点以及了解各个类适用的场景。下面是本文的目录大纲： 一.你了解String类吗？ 二.深入理解String、StringBuffer、StringBuilder 三.不同场景下三个类的性能测试 四.常见的关于String、StringBuffer的面试题（辟谣网上流传的一些曲解String类的说法） 若有不正之处，请多多谅解和指正，不胜感激。 一.你了解String类吗？ 想要了解一个类，最好的办法就是看这个类的实现源代码，String类的实现在 \jdk1.6.0_14\src\java\lang\String.java 文件中。 打开这个类文件就会发现String类是被final修饰的： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public final class String implements java.io.Serializable, Comparable<String>, CharSequence { /** The value is used for character

前言万金6.0平台搭建论坛：haozbbs.com Q1446595067 在看了uwa之前发布的《Unity项目常见Lua解决方案性能比较》，决定动手写一篇关于lua+unity方案的性能优化文。 整合lua是目前最强大的unity热更新方案，毕竟这是唯一可以支持ios热更新的办法。然而作为一个重度ulua用户，我们踩过了很多的坑才将ulua上升到一个可以在项目中大规模使用的状态。事实上即使到现在lua+unity的方案仍不能轻易的说可以肆意使用，要用好，你需要知道很多。 因此，这篇文章是从一堆简单的优化建议里头，逐步挖掘出背后的原因。只有理解了原因，才能很清楚自己做的优化，到底是为了什么，有多大的效果。 从最早的lua纯反射调用c#，以及云风团队尝试的纯c#实现的lua虚拟机，一直发展到现在的各种luajit+c#静态lua导出方案，lua+unity才算达到了性能上实用的级别。 但即使这样，实际使用中我们会发现，比起cocos2dx时代luajit的发扬光大，现在lua+unity的性能依然存在着相当的瓶颈。仅从《性能比较》的test1就可以看到，iphone4s下二十万次position赋值就已经需要3000ms，如果是coc这样类型的游戏，不处理其他逻辑，一帧仅仅上千次位置赋值（比如数百的单位、特效和血条）就需要15ms，这显然有些偏高。 是什么导致lua