git创建远程仓库命令
git init --bare --shared sum.git
备忘!
git创建远程仓库命令
git init --bare --shared sum.git
备忘!
DOM操作主要分为页面渲染与资源清理(heap控制),两者之间又相辅相成,若是DOM操作一块处理不好,其产生的感觉就不再是慢,而是卡,所以DOM操作优化的主要目的就是消灭页面卡的问题,这个在移动端尤为重要。
浏览器会解析三个东西:HTML、Javascript、CSS
浏览器首先会根据HTML生成DOM Tree,其次会根据CSS生成CSS Rule Tree,javascript可以通过DOM API与CSS API操作DOM Tree与CSS Rule Tree,从而引起页面变化。
浏览器解析结束会通过DOM Tree与CSS Rule Tree形成render tree,只有display不为none的元素才会形成render Tree,render Tree形成后浏览器会调用GUI绘制页面,在此之前做的一件事情便是layout或者说reflow。上面的描述简单而言可以分为以下流程:
l 生成DOM树
l 计算CSS样式
l 构建render tree
l reflow,定位元素位置大小
l 绘制页面
在这个过程中,若是javascript动态改变DOM Tree便会引起reflow,页面中的元素改变,只要不影响尺寸,比如只是颜色改变只会引起repaint不会引起回流否则,reflow不可避免,这个时候便需要重新计算形成render Tree,reflow分为局部回流与全局回流,会影响下面的,不会影响上面的元素。reflow耗用的系统资源较大,DOM Tree中受到影响的节点皆会reflow,然后影响其子节点最坏的情况是所有节点reflow,该问题引发的现象便是低性能的电脑风扇不停的转,手机变得很热,并且非常耗电,以下操作可能引起reflow
l 操作dom结构
l 动画
l DOM样式修改
l 获取元素尺寸的API
static元素处于文档流中,其渲染速度是最快的,我们做过一个测试:
100个absolute元素与100个static元素渲染时差在0.01-0.007ms
100000个元素渲染差距便增至30ms左右,这个微小的时差在移动端变得尤为明显,比如:
小米/三星手机(1000左右),便存在明显的渲染问题,具体表现为:
l 定位元素在手机上不能显示。
l 定位元素动画效果失效。
以上问题便是UI渲染失效多导致,最好的解决方案是减少使用定位元素,否则只能引起强烈reflow才能解决。
另外,产品经常会有fixed的相关需求,比如支付按钮一直出现在低端,这个需求会造成两个问题:
l fixed元素遭遇文本框时失效,可能会飘到页面中间阻挡输入
l 影响效率
问题一原因与移动端的实现有关,暂时没有完美的解决方案,问题二便与渲染直接关联
滚屏时,页面上所有的像素会跟着滚动,显卡对全屏幕上下移动的处理很快,但是若是出现一个fixed元素或者有元素不跟着一起滚动,那么滚动对手机浏览器来说就是一个负担,这种滚动的性能甚至体现在了iphone 4s,因为滚动可能会造成reflow,这个现象体现在:
使用absolute配合javascript模拟fixed效果时,会有断片的效果,该问题在iphone5s便不会出现这个问题。
当然,我们不能忽略产品的需求,fixed类需求应该在技术上得到解决,还用户一个良好的体验。
虚拟键盘导致fixed元素错位
fixed元素一定会伴随虚拟键盘的出现,但是虚拟键盘只是“贴”在了viewport上,表面上不会对dom产生“任何”影响,但是这个时候fixed元素表现却变得怪异起来,会错位。
应用层面解决问题方案是,虚拟键盘弹出时将fixed元素设置为static,虚拟键盘消失时候设置回来。
由于虚拟键盘出现并未抛出事件,而检测scroll或者resize事件,皆会有一定延迟,会出现闪烁现象,所以现有最好的方案是setinterval定时器监控当前获取焦点元素是否为文本元素,若是是的话便需要处理,如此便可解决fixed元素错误问题。
fixed元素滑动惯性平滑度
我们常常遇到这种产品需求,tab标签栏开始固定,当滚动向下超过该标签栏后便会变成fixed元素,一直出现在头部,这样的需求在电脑上没有问题,但是在iPhone5s以下的手机常常会出现小范围错位或者快速移动大范围错位的问题。
这个时候我们可以引起reflow迫使浏览器重绘以解决这个问题,这里推荐一个奇怪的hack写法:同时设置三个image元素的src属性,便可以全范围解决该难题, 该方案被团队证实并得到应用。
//三图片src,引发reflow,处理fixed方案惯性问题
var el = this.els.ctlc.find(‘img’);
$(el[0]).attr(“src”, ‘http://res.m.ctrip.com/html5/Content/images/144.png’);
$(el[1]).attr(“src”, ‘http://res.m.ctrip.com/html5/Content/images/144.png’);
$(el[2]).attr(“src”, ‘http://res.m.ctrip.com/html5/Content/images/144.png’);
另外,上图中的tab标签下面的蓝线具有动画,但是在小米或者三星手机上可能不会移动,这个时候也可以动态引起reflow解决这个BUG。
l CSS选择器尽量使用id与class,避免过度层叠
l 避免使用数值,比如:border: none不会引起渲染,而boder: 0会
l 动画时候让元素脱离文档流,以免导致大量reflow
l 避免逐条修改DOM样式,改以className实现同样功能
l 操作DOM时将display设置为none,因为这种元素不会影响渲染,或者操作fragment对象取代操作显示在页面上的DOM
l 避免将获取DOM样式属性的操作写在循环中,可能引起重复reflow
首先,移动端的性能与PC端的性能完全不在一个数量级上,比如,我哥做过一个测试,使用innerHTML绘制大段,之后想获取HTML的ID节点,事实上是获取不到的,这种问题在单页模拟多页,动态创建DOM会经常发生
var element = $(‘<div id = “test”>…大量结构…</div>’);
$(root).html(element)
$(‘#test) //为空
这类问题匪夷所思,因为页面UI渲染与DOM操作是互斥的,但是就算出现了这个问题,一个解决方案是使用settimeout,更好的方案是使用DOMNodeRemoved事件监控页面DOM改变,将我们的DOM操作回调放入以确保渲染结束。
以上问题只是为了说明移动端的性能问题,这类性能问题会导致很多莫名其妙的问题,而且很多与渲染有关。但是这也从侧面说明了移动端资源的紧缺,若是heap值过大,会导致操作出现卡的现象,更有甚者,会引起页面假死直接退出。
webapp的模式,完全依赖于浏览器的垃圾回收,基本就是作死,因为传统页面一旦刷新页面整个资源完全释放,而webapp没有刷新这类操作,只有一个状态到两一个状态,不相关的内存会保留,资源必须手动释放,或者说,框架必须提供垃圾释放的机制。
这个由图表heap值变化可以清晰看出。
而view切换过程中,不用的资源若是不手动设置为null会导致变量得不到回收便脱离框架控制而失控了。所以我们在webapp的过程中需要注意:
l 释放没有使用的闭包
l 观察者需要得到清理
l 释放定时器
l view切换过程中,在destroy中释放view相关资源
——感谢艾伦友情支援
在我们工作过程中,滥用局部变量极有可能引起闭包陷阱,这个问题不止是性能问题,在逻辑上会引起错误,而且不易发现,比如,在AMD闭包中使用一个局部变量
var _attributes = {};
callback ($.extend(_attributes, opts));
如此操作,会改变_ attributes对象,若是一个实例还无问题,但是两个实例的话便会发生变量污染。
这只是一个例子,但是在代码中滥用局部变量可能会引起不必要的隐忧,戒之慎之。
根据前面的描述,我们可以得出一个结论:
无论是view还是UI组件我们得提供统一的destroy接口,以便让用户继承释放资源。
若是view的资源得不到释放导致heap值过高,webapp模式的网站其价值大减。这里有几点可以考虑:
l webapp中view实例保存不超过5个,多了便释放dom结构以及内存引用(临界值自己判断最优)
l view隐藏时释放内部资源,解除DOM事件句柄
l UI组件与view相同,需要统一释放机制
但是单页应用由于页面不会刷新,总有一些资源得不到释放,此问题任重道远,平时编写过程可以做以下优化:
l 使用函数替换逻辑
让我们的函数产生一个返回值替换函数中的大段逻辑,这样的第一个好处便是逻辑清晰,第二个好处是这些函数在不同的函数中,这个函数被使用后便会自动得到释放。
l 清理闭包引用
当一个闭包函数或者什么使用结束后,若不会再使用,便需要手动清理该变量,以便解除闭包之间的引用关系,从而释放资源。
l 使用对象属性或者方法
一个对象可以引用其他对象的属性或者方法,比如obj.foo = thatObj;这种情况下,我们可以随时删除对象解除引用关系,然后便可以清理资源。
动画而言建议采用CSS3实现动画,CSS3中又推荐采用最新的接口,比如使用transform取代top/lelf操作,这样操作效率搞得多。
若是采用动画可以将对应元素设置为absolute以减少回流,另外最关键一点还是
避免移动DOM树过多的节点,这个时候需要驳回产品无理需求,比如:
产品要求日期滚屏组件,显示半年的数据,这半年的数据便是180个DOM树
这个级别的DOM一旦移动整个手机会直接卡死,甚至构建DOM树,渲染页面也会出现假死现象,该问题需要规避。
Application Cache是HTML5为webapp离线使用而增加的API,与localstorage、cookie等不同,Application Cache存储的是一系列请求资源允许浏览器在请求资源时不必通过网络,设计得当的话可以实现离线应用。
使用Application Cache主要是在网络性能上提升,有效降低了网络延迟,提升请求加速
但是也会有一些问题,比如新版本缓存不立刻生效;manifest中的请求路径相对于manifest文件,而非加载页面;更新/回滚等问题,所以使用与否还得论证。
camera.setDisplayOrientation(90);
不知道为什么,Zxing用的是横屏,也许是因为外国人习惯横屏拍照的原因把,但是,在国内,很多人不习惯,呵呵,我用着也不习惯.所以还是该成竖屏,以适合国内人的习惯吧.
修改方法:
1.在DecodeHandler.java中,修改decode方法
PlanarYUVLuminanceSource source = CameraManager.get().buildLuminanceSource(data, width, height);
为
byte[] rotatedData = new byte[data.length]; for (int y = 0; y < height; y++) { for (int x = 0; x < width; x++) rotatedData[x * height + height - y - 1] = data[x + y * width]; } int tmp = width; // Here we are swapping, that's the difference to #11 width = height; height = tmp; PlanarYUVLuminanceSource source = CameraManager.get().buildLuminanceSource(rotatedData, width, height);
2.在CameraManager.java中,修改代码:
// 注释掉 // rect.left = rect.left * cameraResolution.x / screenResolution.x; // rect.right = rect.right * cameraResolution.x / screenResolution.x; // rect.top = rect.top * cameraResolution.y / screenResolution.y; // rect.bottom = rect.bottom * cameraResolution.y / screenResolution.y; //修改成这样的 rect.left = rect.left * cameraResolution.y / screenResolution.x; rect.right = rect.right * cameraResolution.y / screenResolution.x; rect.top = rect.top * cameraResolution.x / screenResolution.y; rect.bottom = rect.bottom * cameraResolution.x / screenResolution.y;
3.在CameraConfigurationManager.java中,在setDesiredCameraParameters方法中添加一句
camera.setDisplayOrientation(90);
4.在AndroidManifest.xml中,把Activity的属性android:screenOrientation="landscape" 改为
android:screenOrientation="portrait"
最近,升级了朋友服务器 (LNMP),nginx 也跟着升级了,但是升级之后,发现,朋友的 ecshop 登录不了了。现象是,输入错误的密码,报告正常,输入正确的密码,就刷新一下,又回到了登录页面。
仔细观察,发现,页面是跳转到了index.php的,只是因为网速快,一下就又跳回来了,感觉只是刷新下,没有变化,呵呵100M宽带也能带来不少麻烦 ((*^__^*) 嘻嘻……)。
结果查看源码,发现了了问题是出在 https 安全登录检测上的。
在文件 includes/cls_ecshop.php 156 行左右有如下代码
/** * 获得 ECSHOP 当前环境的 HTTP 协议方式 * * @access public * * @return void */ function http() { return (isset($_SERVER['HTTPS']) && (strtolower($_SERVER['HTTPS']) != 'off')) ? 'http://' : 'http://'; }
因为检测 isset($_SERVER[‘HTTPS’]) 是 true 而且 里面的值是空,不为off;所以返回了 https
为什么 更新了 nginx 之后就这样呢,大家可以看下nginx的配置文件。
/etc/nginx/fastcgi_params
fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SCRIPT_FILENAME $request_filename; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param REQUEST_URI $request_uri; fastcgi_param DOCUMENT_URI $document_uri; fastcgi_param DOCUMENT_ROOT $document_root; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param GATEWAY_INTERFACE CGI/1.1; fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; fastcgi_param REMOTE_ADDR $remote_addr; fastcgi_param REMOTE_PORT $remote_port; fastcgi_param SERVER_ADDR $server_addr; fastcgi_param SERVER_PORT $server_port; fastcgi_param SERVER_NAME $server_name; #因为下面这项配置,导致了,https是一定会被设置的,如果你不想修改ecshop,又刚好有权限修改配置文件,可以把这个给注视了 fastcgi_param HTTPS $https; # PHP only, required if PHP was built with --enable-force-cgi-redirect fastcgi_param REDIRECT_STATUS 200;
而朋友的ecshop不是在https上工作的,是在http上的,所以,就不停的跳到了登录页面,更详细信息的,可以再百度下。
呵呵,最近掉坑里了,换了支付宝高级支付之后,接口没有修改。回来,发现会员的充值,没有付款的,也给他充值了,原因是。支付宝修改了即时到帐的通知方式。
TRADE_FINISHED状态原本的通知方式,应该会员付款,之后,支付宝发来TRADE_FINISHED状态,现在,高级版的做了调整,发来TRADE_SUCCESS状态,因为,之前做担保交易的时候,处理了TRADE_SUCCESS状态。又处理了TRADE_FINISHED状态,导致给用户充值了2次!
呵呵,做PHP开发的,是不是经常会用utf-8编码呢?用了utf-8编码,是不是经常有各种奇怪的错误呢?是不是总是再说,utf-8的坏话呢。
其实这不是utf-8的错,是你用的记事本的问题吧,换个编辑器就好了,另外,觉得,尽可能不要在记事本里面编辑utf-8的文件了。
出问题的是记事本在文件加了bom头标记,想知道上面是bom头就自己百度好了吧。
下面说下,这么找到有bom头的文件,Linux系统下的,执行下面命令
grep -r -I -l $'^\xEF\xBB\xBF' ./
执行完后,会列出当前文件夹里面包含bom头的文件,用编辑器去掉就好了,我之前是用 zend studio,不过现在不用了,用nodepad++
Centos 7 发布了,发现,用起来很多都不相关了,呵呵,是我不相关了还是Centos 7 变动有点大了呢。
也许是因为好久没有弄Centos了吧,呵呵。不管太多,他变总有变的道理,就按照他的来就可以了。
1、防火墙变了
默认使用了 firewall 防火墙
下面常用命:
systemctl stop firewalld #关闭 systemctl start firewall #启动 systemctl restart firewall #重启(猜的)
也可以用原来的server 命令,不过,好像centos 现在比较推荐使用这个命令。
2、mysql 数据库换了
mysql在centos 7啊安装源里面已经没有了,现在默认使用 mariadb。功能和使用习惯、配置文件等还是和 mysql 的差不多。就是名字变长了,唉,英文不行背半年啊!
yum install mariadb-server #安装 mariadb 数据库 systemctl start mariadb #启动 yum install mariadb #安装 mariadb 客户端 记得这个是客户端哦,不是服务端
今天记一下Ubuntu14.04 server版 修改静态IP的方法。呵呵,只因为最近在Centos 7 和Ubuntu14.04上切换来切换去的,两个修改IP的格式有点不一样,头有点大,一时就修改错了,先记下来,等过几天又切换到Centos7的时候,再把Centos的修改方法给记下来吧。
1、找到相应的文件(/etc/network/interfaces )
sudo vi /etc/network/interfaces
auto eth0 # 这个要用 ifconfig 确认下是不是这个名字 iface eth0 inet static address 192.168.0.220 gateway 192.168.0.1 #这个地址你要确认下网关地址,在路由器那边 netmask 255.255.255.0 #这个基本上都是这个
2、修改DNS,原本是动态获取dns,但是修改成静态ip后,也不会去获取dns了,所以不改的话,上不了网。
这里,14.04 server 修改dns不能使用 /etc/resolv.conf 文件,这个文件修改是一次性的,重启后就没有了,所以想要永久修改,想要修改 /etc/resolvconf/resolv.conf.d/base 这个文件,呵呵,这个是和之前版本不一样的地方。
sudo vi /etc/resolvconf/resolv.conf.d/base
加入如下内容(google提供的dns),主要是为了让电信和联通的用户容易修改吧,呵呵,不要误会,如果你有电信或联通的dns ,也可以用电信或联通的。
nameserver 8.8.8.8 nameserver 8.8.4.4
3、重启networking服务,不过在重启之前,可以先关闭网卡
sudo ifdown eth0 # 关闭网卡,不知道为什么有时候重启了IP没有改过来,所以关闭下网卡 sudo service networking restart sudo ifup eth0 #打开网卡
好了,就写到这里,修改dns的就完了,下次接下去写Centos的,现在没有开Centos的机器。呵呵!
最近一直在研究系统,主要原因是,哪怕效率再高的语言,在并发面前,其所谓的效率都只是浮云!
所以,在这样的情况下,研究负载均衡(或者说流量分发)就变得很有必要。下面收集一些负载均衡的常用实现方法。用于日后参考。
1、NDS轮询
RR-DNS(Round-Robin Domain Name System) 轮流排程的方式是:在DNS服务器中,可以为多个不同的IP地址配置同一个名称,当客户端查询这个名字时将在解析这个名称时得到其中的一个地址。因此,对于同一个名字,不同的客户端会得到不同的地址,他们也就连结不同地址上的Web服务器,从而达到负载平衡的目的。例如 : 当客户端连结 www.muti-ip.com.tw这名称时,DNS 有能力依序将名称解析到 202.1.1.1 、 202.1.1.2 、202.1.1.3和 202.1.1.4等不同的网络地址,而这些是提供相同服务的主机,让客户端不自觉有不同。
优点:
成本低,几乎为不需要成本,现在一般的域名提供商,都提供该功能,只需要设置下,就可以使用。
缺点:
为了使本DNS服务器和其他DNS服务器及时交互,保证DNS数据及时更新,使地址能随机分配,一般都要将DNS的刷新时间设置的较小,但太小将会使DNS流量大增造成额外的网络问题。
单点故障,一旦某个服务器出现故障,即使及时修改了DNS设置,还是要等待足够的时间(刷新时间)才能发挥作用,在此期间,保存了故障服务器地址的客户计算机将不能正常访问服务器。
DNS负载均衡采用的是简单的轮循负载算法,不能区分服务器的差异,不能反映服务器的当前运行状态,不能做到为性能较好的服务器多分配请求,甚至会出现客户请求集中在某一台服务器上的情况。
要给每台服务器分配一个internet上的IP地址,这势必会占用过多的IP地址。
2、LVS
LVS是一个开源软件,可以实现LINUX平台下的简单负载均衡。LVS是Linux Virtual Server的缩写,意思是Linux虚拟服务器。
LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序。
3、Nginx
Nginx作为负载均衡服务器:Nginx 既可以在内部直接支持 Rails 和 PHP 程序对外进行服务,也可以支持作为 HTTP代理服务器对外进行服务。Nginx采用C进行编写,不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多此次应用Nginx实现多台web服务器的简单负载均衡,直观了解负载均衡的工作原理。
这是Ubuntu 14.04 163 的更新源 ,更新速度要比ubuntu 中国区服务器好很多,呵呵,提供上来,方便大家使用。
deb http://mirrors.163.com/ubuntu/ trusty main restricted universe multiverse deb http://mirrors.163.com/ubuntu/ trusty-security main restricted universe multiverse deb http://mirrors.163.com/ubuntu/ trusty-updates main restricted universe multiverse deb http://mirrors.163.com/ubuntu/ trusty-proposed main restricted universe multiverse deb http://mirrors.163.com/ubuntu/ trusty-backports main restricted universe multiverse deb-src http://mirrors.163.com/ubuntu/ trusty main restricted universe multiverse deb-src http://mirrors.163.com/ubuntu/ trusty-security main restricted universe multiverse deb-src http://mirrors.163.com/ubuntu/ trusty-updates main restricted universe multiverse deb-src http://mirrors.163.com/ubuntu/ trusty-proposed main restricted universe multiverse deb-src http://mirrors.163.com/ubuntu/ trusty-backports main restricted universe multiverse
163对应镜像下载 http://mirrors.163.com/ubuntu-releases/14.04/
事实上,人家如果要安装ubuntu 也可以选择在163这里下载,下载速度也比ubuntu中国区服务器好。另外,如果大家选择在线安装,那一定是要用这个源的了,呵呵。因为在线安装对网速要求比较高,如果网速不好,成功的机会很小,或者,装到你不想在装了!