非常好用的DNS服务器清单

DNS是把方便用户记忆的域名转换成网络可辨别使用的IP地址,全称Domain Name System,即域名解析系统。在网络已经相当普及的今天,DNS劫持和污染也成为国内电信运营商干扰用户正常上网的手段,使得用户不得不忍受广告弹窗,并且一些常用的国外服务也无法正常访问,在这里介绍一些国内外常用的DNS服务器地址,供大家选择使用,尽早脱离DNS挟持和污染。
(建议网络小白不要轻易改DNS,有些宽带属于二级代理运营商,改了DNS,网络或许会抽风,如果修改后遇到访问不了网站的情况请重置网络设置。)
1.114DNS
老牌的DNS解析服务,电信联通移动,全国通用DNS,分的种类也较多,根据需要选择。
纯净无劫持,无需再忍受被强扭去看广告或粗俗网站之痛苦:
114.114.114.114
114.114.115.115
拦截钓鱼病毒木马网站,增强网银、证券、购物、游戏、隐私信息安全:
114.114.114.119
114.114.115.119
学校或家长可选,拦截色情网站,保护少年儿童免受网络色情内容的毒害
114.114.114.110
114.114.115.110
114DNS–抗攻击DNS,超高可靠,提供智能DNS解析。公众DNS服务地址为114.114.114.114
114DNS–抗攻击DNS,超高可靠,提供智能DNS解析。公众DNS服务地址为114.114.114.114
2.阿里DNS
阿里DNS是阿里巴巴集团推出的DNS递归解析系统,面向互联网用户提供快速、稳定、智能的免费DNS递归解析服务,现在我也经常使用。
223.5.5.5
223.6.6.6
3.SDNS
SDNS是由中国互联网络信息中心(CNNIC)与国内外电信运营商合作推出的免费公共云解析服务(SecureDNS,简称SDNS),旨在为用户提供高速、安全、智能的上网接入解析服务。
这个对广告挟持的问题解决的最彻底。(如果用这个请务必谨慎,毕竟是官方DNS,多余的话我就不说了)
1.2.4.8
210.2.4.8
4.中科大的DNS
据一些网友反映:无污染、速度快。不过考虑到中科大的教育性质和有名的Ubuntu源的速度,应该可用。(我没有用过,也不知道目前这个是否可用)
202.38.64.1
202.112.20.131
202.141.160.95
202.141.160.99
202.141.176.95
202.141.176.99
5.OneDNS
创立于2013年的DNS服务,比较新,没使用过,不过他们的口号挺吸引人:OneDNS是一个安全、快速、免费的小众DNS服务。通过它,您可以时刻畅享来自云端的恶意网站屏蔽服务,彻底摆脱无良ISP的DNS污染与劫持,同时,横跨南北的高速线路加速您的网络连接。
112.124.47.27 南方首选/北方备用
114.215.126.16 北方首选/南方备用
oneDNS是一个安全、快速、免费的小众DNS服务。通过它,可以时刻畅享来自云端的恶意网站拦截和广告过滤服务,摆脱无良ISP的DNS污染与劫持。横跨南北的高速线路加速您的网络连接,更有国外网站加速功能等你来体验。
6.DNS派
360的合作伙伴,口号:让网上冲浪更加稳定、快速、安全;为家庭拦截钓鱼网站,过滤非法网站,建立一个绿色健康的网上环境;为域名拼写自动纠错,让上网更方便。没使用过,不过看这口号没太大吸引力。
电信:首选地址:101.226.4.6, 备用地址:218.30.118.6
联通:首选地址:123.125.81.6,备用地址:140.207.198.6
移动:首选地址:101.226.4.6, 备用地址:218.30.118.6
铁通:首选地址:101.226.4.6, 备用地址:218.30.118.6
DNS派是聚流科技旗下的DNS服务平台,为个人用户、网站主、企业提供各种有关DNS业务的服务,包括个人上网的域名解析服务、网站授权解析服务、企业域名解析服务等。 同时为站长免费提供网站防火墙、DDOS保护、 CC保护、智能DNS解析、盗链保护、页面压缩、缓存加速、永久在线和动态域名绑定等服务。
7.Google DNS
说到DNS就绕不过去的槛,是Google于2009年12月5日起提供的一个免费域名解析服务。国外是王者风范,国内就残了一半。(据说最近使用这个DNS可以打开一些被禁的国外网站,不知真假)
8.8.8.8
8.8.4.4
8.OpenDNS
创建于2006年,国际大牌,解析功能稳定而全面,但在中国还是有点水土不服。
208.67.220.220
208.67.222.222
9.Norton DNS
Norton DNS是资深安全厂商诺顿针对家庭和企业用户推出的一项安全DNS服务。它的功能也挺全面,将DNS地址分类三类安全等级,分别是:
A – 安全性(恶意软件,钓鱼网站和诈骗网站)
199.85.126.10
199.85.127.10
B – 安全+色情
199.85.126.20
199.85.127.20
C – 安全+色情+非家庭
199.85.126.30
199.85.127.30
10.V2EX DNS
由V2EX站长提供,延迟有点高,偶尔掉包。之前为了提升App Store的访问速度时设置过,不是很稳定,解析的网站也不是很全面,偶尔为了特殊目的可以尝试下。(这个加速App Store的功能还是很实用的)
178.79.131.110
11.腾讯DNS
119.29.29.29
在分享一个网址,这里面有全国各地运营商的DNS地址,有需要的可以自行收藏:‪http://publicdns.cn/‬

压缩Oracle表空间

SELECT a.File#, a.Name, a.Bytes / 1024 / 1024 Currentmb, Ceil(Hwm * a.Block_Size) / 1024 / 1024 Resizeto, (a.Bytes -
        Hwm *
        a.Block_Size) / 1024 / 1024 Releasemb, 'alter database datafile ''' ||
        a.Name || ''' resize ' ||
        Ceil(Hwm * a.Block_Size / 1024 / 1024) || 'M;' Resizecmd
FROM   V$datafile a, (SELECT File_Id, MAX(Block_Id + Blocks - 1) Hwm
         FROM   Dba_Extents
         GROUP  BY File_Id) b
WHERE  a.File# = b.File_Id(+) AND (a.Bytes - Hwm * Block_Size) > 0

 

Oracle UUID SYS_GUID

Oracle里面用RAW(16)保存SYS_GUID()的结果,不过字节顺序(byte order)和标准的GUID不同。如下

标准GUID: 265B113F-0E9D-F44D-A9D4-18BC4D3E836C

RAW(16) : 3F115B26 9D0E 4DF4 A9D4 18BC4D3E836C (实际没有空格,这里是为了显示方便)

为了方便查看,可以用正则表达式进行简单的转换。

SELECT Regexp_Replace(Lower(Sys_Guid()),
                       '(.{2})(.{2})(.{2})(.{2})(.{2})(.{2})(.{2})(.{2})(.{4})',
                       '\4\3\2\1-\6\5-\8\7-\9-') AS Dummy
FROM   Dual
CONNECT BY Rownum <= 20;

 

TPC,TPCC,TPMC(计算机性能衡量指标)

第一章 什么是TPC和tpmC?
1 TPC
TPC(Transaction Processing Performance Council,事务处理性能委员会)是由数10家会员公司创建的非盈利组织,总部设在美国。该组织对全世界开放,但迄今为止,绝大多数会员都是美、日、西欧的大公司。TPC的成员主要是计算机软硬件厂家,而非计算机用户,它的功 能是制定商务应用基准程序(Benchmark)的标准规范、性能和价格度量,并管理测 试结果的发布。
TPC的出版物是开放的,可以通过网络获取(http://www.tpc.org)。TPC不给出基准程序的代码,而只给出基准程序的标准规范(Standard Specification)。任何厂家或其它测试者都可以根据规范,最优地构造出自己的系统(测试平台和测试程序)。为保证测试结果的客观性,被测试者(通常是厂家)必须提交给TPC一套完整的报告(Full Disclosure Report),包括被测系统的详细配置、分类价格和包含五年维护费用在内的总价 格。该报告必须由TPC授权的审核员核实(TPC本身并不做审计)。现在全球只有几个审核员,全部在美国。
TPC已经推出了四套基准程序,被称为TPC-A、TPC-B、TPC-C和TPC-D。其中A和B已经过时,不再使用了。TPC-C是在线事务处理(OLTP)的基准程序,TPC-D是决策支持(Decision Support) 的基准程序。TPC即将推TPC-E,作为大型企业(Enterprise)信息服务的基准程序。
2 tpmC
tpmC值在国内外被广 泛用于衡量计算机系统的事务处理能力。但究竟什么是tpmC值呢?作者曾向一些 用户、推销人员乃至某些国外大公司的技术人员问过这个问题,但回答的精确度 与tpmC值的流行程度远非相称。tpmC这一度量也常被误写为TPM或TPMC。
TPC-C模拟一个批发商的货物管理环境。该批发公司有N个仓库,每个仓库供应10个地区,其中每个地区为3000名顾客服务。在每个仓库中有10个终端,每一个终端用于一个地区。在运行时,10×N个终端操作员向公司的数据库发出5类请求。由于一个仓库中不可能存储公司所有的货物,有一些请求必须发往其它仓库,因此,数据库在逻辑上是 分布的。N是一个可变参数,测试者可以随意改变N,以获得最佳测试效果。
TPC-C使用三种性能和价格度量,其中性能由TPC-C吞吐率衡量,单位是tpmC。tpm是transactions per minute的简称;C指TPC中的C基准程序。它的定义是每分钟内系统处理的新订单个数。要注意的是,在处理新订单的同时,系统还要按表1的要求处理其它4类事务 请求。从表1可以看出,新订单请求不可能超出全部事务请求的45%,因此,当一个 系统的性能为1000tpmC时,它每分钟实际处理的请求数是2000多个。价格是指系 统的总价格,单位是美元,而价格性能比则定义为总价格÷性能,单位是$/tpmC。
tpmC定义: TPC-C的吞吐量,按有效TPC-C配置期间每分钟处理的平均交易次数测量,至少要运行12分钟。
(吞吐量测试结果以比特/秒或字节/秒表示。)
第二章 TPCC
1 基准测试
TPCC值被广泛用于衡量C/S环境下,由服务器和客户端构筑的整体系统的性能,它由事物处理性能委员会(TPC,Transaction Processing Corp)制定,TPC为非赢利性国际组织。
TPCC值可以反映出系统的性能价格比。TPCC测试系统每分钟处理的任务数,单位为tpm,(transactions per minute)。系统的总体价格(单位为美元)除以TPCC值,就可以衡量出系统的性价比,系统的性价比值越大,系统的性价比越好。
需要注意的是,TPC-C值描述的是C/S整体系统的性能,它与系统的服务器和客户机的性能都有关系,也就是说,同样的服务器配置不同的客户端将会影响TPCC值,任何厂商和测试者都可以根据TPC提供的测试规范构造出自己最优的系统,当然测试的结果要经过TPC审核。
—————————————————————————————————————
2 性能测试指标介绍
TPC-C
作为一家非盈利性机构,事务处理性能委员会(TPC)负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试,并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境,并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。
相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证,并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。
TPC-C是一种旨在衡量联机事务处理(OLTP)系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。
TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务(tpmC)吞吐量。特别值得一提的是,它将专门测量系统在同时执行其它四种事务类型(如支付、订单状态更新、交付及证券级变更)时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证,同时,TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。
3 TPC-C规范概要
TPC-C是专门针对联机交易处理系统(OLTP系统)的,一般情况下我们也把这类系统称为业务处理系统。
TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商,它拥有若干个分布在不同区域的商品库;每个仓库负责为10个销售点供货;每个销售点为3000个客户提供服务;每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货,需要由其他区域的仓库来供货。
该系统需要处理的交易为以下几种:
New-Order:客户输入一笔新的订货交易;
Payment:更新客户账户余额以反映其支付状况;
Delivery:发货(模拟批处理交易);
Order-Status:查询客户最近交易的状态;
Stock-Level:查询仓库库存状况,以便能够及时补货。
对于前四种类型的交易,要求响应时间在5秒以内;对于库存状况查询交易,要求响应时间在20秒以内。
4评测指标
TPC-C测试规范经过两年的研制,于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果,随着计算机技术的不断发展,这些测试结果也在不断刷新。
TPC-C的测试结果主要有两个指标:
①流量指标(Throughput,简称tpmC)
按照TPC的定义,流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时,每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。
流量指标值越大越好!
②性价比(Price/Performance,简称Price/tpmC)
即测试系统价格(指在美国的报价)与流量指标的比值。
性价比越大越好!
第三章(TPCC)如何衡量计算机系统的性能和价格
在系统选型时,我们一定不要忘记我们是为特定用户环境中的特定应用选择系统。切忌为了“与国际接轨”而盲目套用“国际通用”的东西。在性能评价领域,越是通用的度量常常越是不准确的。据我所知,美国的一些大用户从不相信任何“国际通用”的度量,而是花相当精力,比如预算的5%,使用自己的应用来测试系统,决定选型。在使用任何一种性能和价格度量时,一定要弄明白该度量的定义,以及它是在什么系统配置和运行环境下得到的,如何解释它的意义等。下面我们由好到差讨论三种方式。
1在真实环境中运行 实际应用
最理想的方式是搞一个试点,要求制造商或系统集成商配合将系统(含平台、软件和操作流程)在一个 实际用户点真正试运行一段时间。这样,用户不仅能看到实际性能,也能观察到系统是否稳定可靠、使用是否方便、服务是否周到、配置是否足够、全部价格是否合理。如果一个部门需要购买一批同类的系统,这种方式应列为首选,因为它不仅最精确、稳妥,也常常最有效率,用户还可先租一套系统作为试点。用这种方式得到的度量值常常具有很明确和实际的含义。
2使用用户定义的基准程序
如果由于某种原因第一种方式不可行,用户可以定义一组含有自己实际应用环境特征的应用基准程序。 我举两个例子:近年来,由于R/3软件是应用层软件,SAP公司的基准程序获得了越来越多国外企业的认可;中国税务总局最近也开发了自己的基准程序,以帮助税务系统进行计算机选型。这种方式在中国尤其重要,因为中国的信息系统有其特殊性。
3使用通用基准程序
如果第1种和第2种方式都不行,则使用如TPC-C之类的通用基准程序,这是不得已的一种近似方法。因 此,tpmC值只能用作参考。我们应当注意以下几点:
①实际应用是否与基准程序相符
绝大多数基准程序都是在美国制订的,而中国的企事业单位与美国的运作方式常常不一样(恐怕也不应该或不可能一样)。在使用TPC-C时,我们应该清楚地知道:我的应用是否符合批发商模式?事务请求是否与表1近似?对响应时间的要求是否满足表1?如果都不是,则tpmC值的参考价值就不太大了。
②TPC度量的解释
TPC基准程序是用来测系统而不是测主机的,厂家肯定要充分优化他们的被测系统。此处的“系统”包括主机、外设(如硬盘或RAID)、主机端操作系统、数据库软件、客户端计算机及其 操作系统、数据库软件和网络连接等。在很多厂家的TPC测试系统中,主机的价格只是系统总价格的1/4或更小,而硬盘的价格有可能占到总价格的1/3以上,因为TPC-C要求被测系统必须保存180天的事务记录。如果同样的主机被用到用户的环境中,厂家报的tpmC值就意义不大,因为用户的实际系统与厂家原来用于TPC测试的系统大不一样。当同样的主机用在不同的系统中时,tpmC值可能有相当大的变化,现在很多用户还没有意识到这一点。
我举一个例子。假设用 户希望购买一批同类系统,每一系统至少需要1GB的内存和50GB的硬盘。厂家A、B、C 各报了三个价格相当的系统,tpmC值分别为3000、2800、2600。用户是否应该选厂家A的产品呢?答案是:不一定。厂家用于测试tpmC值的系统与实际提供给用户的系统配置大不一样。tpmC最低的厂家C提供给用户的系统反而有可能性能最好,不 论是以实际系统的tpmC值还是以用户的实际应用性能来衡量。
③TPC测试的成本
TPC-C和TPC-D都是很复杂的基准程序,做一个严格的测试是很消耗资源的,厂家当然不会说出他们花费了多少钱和时间。但据国外知情人士透露,一个厂家做第一个TPC-C测试需 要几十万到上百万美元的资金和半年左右的时间投入。因此,很多TPC的度量值都 是估计的。由于计算机系统换代频繁,如果用户一定要用通过审核的度量值,就必 须多等待半年时间,因此而不能用最先进的系统。中国的厂家通过审核的时间则更长。
综上所述,我们对中国 用户(尤其是大用户)在计算机系统的选型方面有如下建议:
最好建立一个真实的试点,因为实际应用环境是检验计算机系统的最好标准。
中国的行业应该建立符合自己实际应用的基准程序和测试标准。中国税务总局的做法值得提倡。国家有关部门应该建立独立的测试中心,制定跨行业、符合中国企事业运作模式的性能测试标准。
“国际通用”的度量可以作为参考值,而不应作为必要条件。尤其是一定要弄清这些流行度量有什么含义,是在什么样的系统环境中测得的,以及基准程序是否符合企业真实的业务流程和运作模式。
作为一家非盈利性机构,事务处理性能委员会(TPC)负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试,并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境,并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。
相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证,并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。
TPC-C是一种旨在衡量联机事务处理(OLTP)系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。
TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务(tpmC)吞吐量。特别值得一提的是,它将专门测量系统在同时执行其它四种事务类型(如支付、订单状态更新、交付及证券级变更)时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证,同时,TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。
第四章 TPCC计算原则
1建议
不管是TPC-C还是SPECjbb2000,计算结果都只能作为一个横向比较的参考。在实际应用中,决定系统性能的因素除了硬件、系统软件外,与应用软件的设计也是有很大关系的,此外,基于系统可扩展性的考虑,更多时候也倾向于一次性的采购。
从长远考虑,以政府信息化主管部门的角度考虑,建立一套评估机制是非常有用的,这其中包括:
1、 通过对各单位业务系统运行情况的调查,进行历史数据的收集分析,按分类建立基准指标库。收集的信息包括:服务器的配置、并发用户数(每天业务量)、CPU负荷等;
2、 由厂商定期提供基准值,更新基准指标库;
有了基准指标库的信息参照,不仅可以用于评估项目建设方案中服务器选型,也可以对各部门进行系统架构设计的优化提供指导。如以下是一些指导原则:
1、 数据库服务器选型:采购两台相同配置的小型机,进行虚拟分区和并行处理,以提高系统资源的利用率;日后扩容时采取垂直扩展的方式进行升级;
2、 应用服务器:采用负载均衡的方式提高并发处理能力,一般可配置2台以上,每台的硬件配置完全可以不同,应首先考虑使用旧的数据库服务器(利旧),如需采购新的服务器,应采用水平扩展的方式逐步升级;
3、 WEB服务器,可以考虑采用刀片服务器,提高扩展性和可管理性。
2参考:某项目计算实例
参考1
为了方便计算数据库服务器的造型,我们约定:
” 系统同时在线用户数为1500人(U1);
” 平均每个用户每分钟发出2次业务请求(N1);
” 系统发出的业务请求中,更新、查询、统计各占1/3;
” 平均每次更新业务产生3个事务(T1);
” 平均每次查询业务产生8个事务(T2);
” 平均每次统计业务产生13个事务(T3);
” 一天内忙时的处理量为平均值的5倍;
” 经验系数为1.6;(实际工程经验)
” 考虑服务器保留30%的冗余;
服务器需要的处理能力为:
TPC-C=U1*N1*(T1+T2+T3)/3*5*经验系数/冗余系数
则应用服务器的处理性能估算为:
TPC-C= 1500*2*(3+8+13)/3*5*1.6/0.7= 274,285 tpmC
数据库服务器关系到整个系统的稳定运行,考虑到高可靠性和高可用性,并注重设备的可扩展性和性价比,系统将配置两台TPC-C值不小于28万的高性能数据库服务器。
参考2
以单台服务器性能进行计算,即确保单台服务器工作的时候可以满足系统正常运行的需要;
假设每天有1万人次来窗口办理业务,每人次办理一项业务。即以每日1万笔前台交易为例进行综合系数的推导:
1. 假设每月前台交易数(未来5年内的设计指标)为220,000 (有些业务在月初、月末的处理量比较高,按月统计可以平衡此项差异);
2. 每日前台交易数=220000/22=10,000 ,即每日 1万笔;
3. 忙时处理能力:每日交易的80%在4个小时内完成,即10000*80%/4=2000(笔/小时)
4. 峰值处理能力:2000*2=4000(笔/小时),即峰值处理能力为每小时4000笔,或 67笔/分,假设业务人员同时在线为100人,即每人每分钟处理0.7笔)
5. 假设每笔交易对应数据库事务数=20,基准TPC指标值对应的比例=8,cpu保留30%的处理能力冗余,计算值与公布值(最优值)的偏差经验值为4 (这几个参数估算的依据不足,更多的是经验值)
则 tpmC值为:
tpmC= 67*20*8*4/(1-30%)= 61257[颠峰处理能力时(笔/分)*每笔交易对应数据库事务数*基准TPC指标值对应的比例*计算值与公布值(最优值)的偏差经验值/(1- cpu保留30%的处理能力冗余)
倒算出 综合系数 = 61257/10000=6.1
即数据库服务器tpmC= 每日前台交易数 * 6.1 (实际计算值应不高于该值)
应用服务器的 tpmC = 数据库服务器 tpmC *50% (一般)
应用服务器的 tpmC = 数据库服务器 tpmC *70% (涉及大量计算的,如社保、税务)

SimCity BuildIt刷钱技巧4000虚拟币/分钟

这是一个从SCBuildit.com学过来的技巧,但是此方法你得放弃你的所有人口数量!!!比较适合新建城市。

准备工作:新手任务肯定要先完成的,因为需要工厂来生产“金属”,如果是已经建设过一段时间的城市,把所有能用的钱都去建工厂,并且随着级别升高,可以随时补免费工厂。可以先准备一些“钉子”以备不时之需。

第一步:拆除所有的住宅区,把人口降到0。

第二步:建两个住宅区。

第三步:两个住宅区里至少有一个是只需要“金属x1”就可升级的,我们先叫“A住宅”,那先把另一个“B住宅”移到不容易碰到的地方。

第四步:升级“A住宅”,然后马上点击右侧建筑住宅区的那个按钮,在“A住宅”升级完成前,放置另一个新的“C住宅”。因为“A住宅”正在升级,所以系统也会将“C住宅”的升级条件设定为“金属x1”。

第五步:“A住宅”升级会有700左右的收入,升级完成后直接拆除(最好在升级完成前不要退出建设住宅区界面。如果你对升级仓库和开拓土地有兴趣,可以等点掉市民意见之后再拆。),这时,“C住宅”就变成了除“B住宅”以外的唯一住宅了。

第六步:反反复复做第四步、第五步。直到钱非常非常多。

如果中间因为各种问题,比如:点错、手慢、应用切换、调整亮度等,出现两个住宅地基都需要“钉子x1”才升级了,那就都升级成住宅再全拆掉重来就好。到了21级以后最多可以同时有4个地基,但也请保持最多3个刷钱,多了可能会出问题。

按8~10秒拆建一个住宅算,每分钟有4200的虚拟币,去除中间去制造收集金属的时间,熟练以后手快的很容易达到3000~4000虚拟币/分钟的入帐。

等把能买的都买了,再发展人口吧。

此方法不需要越狱也可以使用,并且完全是游戏内部操作,不需要飞行模式禁用网络等,完全可以加Facebook好友。

视频链接:https://www.youtube.com/watch?v=T1PiKr7o3Yk

Strict mode – JavaScript

ECMAScript 5的严格模式是Javascript中的一种限制性更强的变种方式。严格模式不是一个子集:它在语义上与正常代码有着特意的差异。不支持严格模式的浏览器与同支持严格模式的浏览器行为上也不一样, 所以不要在未经严格模式特性测试情况下使用严格模式。严格模式可以与非严格模式共存,所以脚本可以逐渐的选择性加入严格模式。严格模式在语义上与正常的JavaSript有一些变化。 首先,严格模式会将JavaScript陷阱直接变成明显的错误。其次,严格模式修正了一些引擎难以优化的错误:同样的代码有些时候严格模式会比非严格模式下更快。 第三,严格模式禁用了一些有可能在未来版本中定义的语法。如果你想让你的JavaScript代码在严格模板下运行,可以参考转换成严格模式。
开启严格模式
严格模式可以应用到整个script标签或某个别函数中。不要在封闭大括弧( {} )内这样做;在这样的上下文中这么做是没有效果的。 例如,eval 代码,Function 代码,事件处理属性,传入 setTimeout方法的字符串 等等包括整个脚本中开启严格模式都会如预期一样工作。
为某个script标签开启严格模式
为整个script标签开启严格模式, 需要在所有语句之前放一个特定语句 “use strict”; (或 ‘use strict’;)

// 整个语句都开启严格模式的语法
"use strict";
var v = "Hi! I'm a strict mode script!";

这种语法存在陷阱,有一个大型网站已经被它坑倒了:不能盲目的拼合非冲突代码。如果串联一个严格模式的脚本和一个非严格模式的脚本:整个拼合后的脚本代码看起来成了严格模式。反之亦然:非严格串联严格看起来像是非严格的。拼合全为严格模式的脚本或全为非严格模式的都没问题,只有在拼合严格模式与非严格模式有可能有问题。建议按一个个函数去开启严格模式(至少在学习的过渡期要这样做).
您也可以将整个脚本的内容用包裹在一个函数里面,并在外部函数中使用严格模式。这样做就可以消除拼接的问题,但是这就意味着您必须要在函数作用域外声明一个全局变量。
为某个函数开启严格模式
同样的,各某个函数开启严格模式就放一句 “use strict”; (或 ‘use strict’;) 在函数体所有语句之前。

function strict()
{
// 函数级别严格模式语法
'use strict';
function nested() { return "And so am I!"; }
return "Hi! I'm a strict mode function! " + nested();
}
function notStrict() { return "I'm not strict."; }

严格模式有哪些不同
严格模式同时改变了语法及运行时行为。变化通常分为这几类:将问题直接转化为错误(如语法错误或运行时错误), 简化了如何为给定名称的特定变量计算,简化了 eval 以及 arguments, 将写”安全“JavaScript的步骤变得更简单,以及改变了预测未来ECMAScript行为的方式。
将拼写错转成异常
在严格模式下, 先前被接受的拼写错误将会被认为是异常. JavaScript被设计为能使新人开发者更易于上手, 所以有时候会给本来错误操作赋予新的不报错误的语义(non-error semantics). 有时候这可以解决当前的问题, 但有时候却会给以后留下更大的问题. 严格模式则把这些失误当成错误, 以便可以发现并立即将其改正.
首先,严格模式下无法再意外创建全局变量。在普通的JavaScript里面给一个拼写错误的变量名赋值会使全局对象新增一个属性并继续“工作”(仅管后面可能出错:在现在的JavaScript中有可能)。严格模式中意外创建全局变量被抛出错误替代:

"use strict";
mistypedVariable = 17; // 抛出 ReferenceError

其次, 严格模式会使引起静默失败(silently fail,注:不报错也没有任何效果)的赋值操作抛出异常. 例如, NaN 是一个不可写的全局变量. 在正常模式下, 给 NaN 赋值不会产生任何作用; 开发者也不会受到任何错误反馈. 但在严格模式下, 给 NaN 赋值会抛出一个异常. 任何在正常模式下引起静默失败的赋值操作 (给不可写属性赋值, 给只读属性(getter-only)赋值赋值, 给不可扩展对象(non-extensible object)的新属性赋值) 都会抛出异常:

"use strict";
// 给不可写属性赋值
var obj1 = {};
Object.defineProperty(obj1, "x", { value: 42, writable: false });
obj1.x = 9; // throws a TypeError
// 给只读属性赋值
var obj2 = { get x() { return 17; } };
obj2.x = 5; // throws a TypeError
// 给不可扩展对象的新属性赋值
var fixed = {};
Object.preventExtensions(fixed);
fixed.newProp = "ohai"; // throws a TypeError

第三, 在严格模式下, 试图删除不可删除的属性时会抛出异常(之前这种操作不会产生任何效果):

"use strict";
delete Object.prototype; // throws a TypeError

第四, 严格模式要求一个对象内的所有属性名在对象内必须唯一. 正常模式下重名属性是允许的, 重名的最后一个属性决定其属性值. 因为只有最后一个属性有效, 当修改代码要改变属性值而却不是修改的最后一个重名属性的时候, 这种重复就成了bug的温床. 在严格模式下, 重名属性被认为是语法错误:

"use strict";
var o = { p: 1, p: 2 }; // !!! 语法错误

第五, 严格模式要求函数的参数名唯一. 在正常模式下, 最后一个重名参数名会掩盖之前的重名参数. 之前的参数仍然可以通过 arguments[i] 来访问, 还不是完全无法访问. 然而, 这种隐藏豪无意义或者并不是故意为之 (比如, 就是一个打字错误), 所以在严格模式下重名参数被认为是语法错误:

function sum(a, a, c) // !!! 语法错误
{
"use strict";
return a + b + c; // 如果代码运行到这里,将会有一个bug
}

第六, 严格模式禁止八进制数字语法. ECMAScript并不包含八进制语法, 但所有的浏览器都支持这种以零(0)开头的八进制语法: 0644 === 420 还有 “\045” === “%”. 有些新手开发者认为数字的前导零没有语法意义, 所以他们会用作对齐措施 — 但其实这会改变数字的意义! 八进制语法很少有用并且可能会错误使用, 所以严格模式下八进制语法会引起语法错误:

"use strict";
var sum = 015 + // !!! 语法错误
197 +
142;

简化变量的使用
严格模式简化了代码中变量名字映射到变量定义的方式. Many compiler optimizations rely on the ability to say that variable X is stored in that location: 这对全面优化JavaScript代码至关重要. JavaScript有些情况会使得代码中名字到变量定义的基本映射只在运行时才产生. 严格模式移除了大多数这种情况的发生, 所以编译器可以更好的优化严格模式的代码.
首先, 严格模式禁用 with. with 所引起的问题是块内的任何名称可以映射(map)到with传进来的对象的属性, 也可以映射到包围这个块的作用域内的变量(甚至是全局变量), 这一切都是在运行时决定的: 在代码运行之前是无法得知的. 严格模式下, 使用 with 会引起语法错误, 所以就不会存在 with 块内的变量在运行是才决定引用到哪里的情况了:

"use strict";
var x = 17;
with (obj) // !!! 语法错误
{
// 如果没有开启严格模式,with中的这个x会指向with上面的那个x,还是obj.x?如果不运行代码,我们无法知道,因此,这种代码让引擎无法进行优化,速度也就会很慢了.
x;
}

一种取代 with 的简单方法是,将目标对象赋给一个短命名变量,然后访问这个变量上的相应属性.
第二, 严格模式下的 eval 不在为上层范围(surrounding scope,注:包围eval代码块的范围)引入新变量. 在正常模式下, 代码 eval(“var x;”) 会给上层函数(surrounding function)或者全局引入一个新的变量 x . 这意味着, 一般情况下, 在一个包含 eval 调用的函数内所有没有引用到参数或者局部变量的名称都必须在运行时才能被映射到特定的定义 (因为 eval 可能引入的新变量会覆盖它的外层变量). 在严格模式下 eval 仅仅为被运行的代码创建变量, 所以 eval 不会影响到名称映射到外部变量或者其他局部变量:

var x = 17;
var evalX = eval("'use strict'; var x = 42; x");
assert(x === 17);
assert(evalX === 42);

相应的, 如果函数 eval 在被严格模式下的eval(…)以表达式的形式调用时, 其代码会被当做严格模式下的代码执行. 当然也可以在代码中显式开启严格模式, 但这样做并不是必须的.

function strict1(str)
{
"use strict";
return eval(str); // str中包含的代码肯定会在严格模式下运行
}
function strict2(f, str)
{
"use strict";
return f(str); // f是个处于严格模式下的函数,或者f为eval且str中的适当位置处添加了"use strict"的情况下,str中的代码才会在严格模式下运行
}
function nonstrict(str)
{
return eval(str); // 只有在str中的适当位置处添加了"use strict",str中的代码才会在严格模式下运行
}
strict1("'Strict mode code!'");
strict1("'use strict'; 'Strict mode code!'");
strict2(eval, "'Non-strict code.'");
strict2(eval, "'use strict'; 'Strict mode code!'");
nonstrict("'Non-strict code.'");
nonstrict("'use strict'; 'Strict mode code!'");
Thus names in strict mode eval code behave identically to names in strict mode code not being evaluated as the result of eval.

第三, 严格模式禁止删除plain names. delete name 在严格模式下会引起语法错误:

"use strict";
eval("var x; delete x;"); // !!! 语法错误

让eval和arguments变的简单
严格模式让arguments和eval少了一些奇怪的行为。两者在通常的代码中都包含了很多奇怪的行为: eval to add or remove bindings and to change binding values, and arguments by its indexed properties aliasing named arguments. Strict mode makes great strides toward treating eval and arguments as keywords, although full fixes will not come until a future edition of ECMAScript.
首先, 名称 eval 和 arguments 不能被绑定(be bound)或赋值 in language syntax. 以下的所有尝试将一起语法错误:

"use strict";
eval = 17;
arguments++;
++eval;
var obj = { set p(arguments) { } };
var eval;
try { } catch (arguments) { }
function x(eval) { }
function arguments() { }
var y = function eval() { };
var f = new Function("arguments", "'use strict'; return 17;");

第二, strict mode code doesn’t alias properties of arguments objects created within it. 在正常模式下, 在第一个参数为 arg 的函数中, 设置 arg 的值会同时设置 arguments[0], 反之亦然(除非没有参数或者 arguments[0] 被删除了). 严格模式下, 在函数中的 arguments 对象存储其被调用时候的原始值. arguments[i] 不在追踪相应名称参数的值的变化, 名称参数也不在追踪相应的 arguments[i].

function f(a)
{
"use strict";
a = 42;
return [a, arguments[0]];
}
var pair = f(17);
assert(pair[0] === 42);
assert(pair[1] === 17);

第三点,不再支持arguments.callee属性.在非严格模式中,arguments.callee指向当前正在执行的函数. 这个用处很弱: 直接用名字就可以了! 此外, arguments.callee substantially hinders optimizations like inlining functions, because it must be made possible to provide a reference to the un-inlined function if arguments.callee is accessed. 严格模式下函数中的 arguments.callee 是一个不可删除属性, 被设置或读取都会跑出异常:

"use strict";
var f = function() { return arguments.callee; };
f(); // throws a TypeError

“Securing” JavaScript
Strict mode makes it easier to write “secure” JavaScript. Some websites now provide ways for users to write JavaScript which will be run by the website on behalf of other users. JavaScript in browsers can access the user’s private information, so such JavaScript must be partially transformed before it is run, to censor access to forbidden functionality. JavaScript’s flexibility makes it effectively impossible to do this without many runtime checks. Certain language functions are so pervasive that performing runtime checks has considerable performance cost. A few strict mode tweaks, plus requiring that user-submitted JavaScript be strict mode code and that it be invoked in a certain manner, substantially reduce the need for those runtime checks.
First, the value passed as this to a function in strict mode isn’t boxed into an object. For a normal function, this is always an object: the provided object if called with an object-valued this; the value, boxed, if called with a Boolean, string, or number this; or the global object if called with an undefined or null this. (Use call, apply, or bind to specify a particular this.) Automatic boxing is a performance cost, but exposing the global object in browsers is a security hazard, because the global object provides access to functionality “secure” JavaScript environments must restrict. Thus for a strict mode function, the specified this is used unchanged:

"use strict";
function fun() { return this; }
assert(fun() === undefined);
assert(fun.call(2) === 2);
assert(fun.apply(null) === null);
assert(fun.call(undefined) === undefined);
assert(fun.bind(true)() === true);

Second, in strict mode it’s no longer possible to “walk” the JavaScript stack via commonly-implemented extensions to ECMAScript. In normal code with these extensions, when a function fun is in the middle of being called, fun.caller is the function that most recently called fun, and fun.arguments is the arguments for that invocation of fun. Both extensions are problematic for “secure” JavaScript, because they allow “secured” code to access “privileged” functions and their (potentially unsecured) arguments. If fun is in strict mode, both fun.caller and fun.arguments are non-deletable properties which throw when set or retrieved:

function restricted()
{
"use strict";
restricted.caller; // throws a TypeError
restricted.arguments; // throws a TypeError
}
function privilegedInvoker()
{
return restricted();
}
privilegedInvoker();

Third, arguments for strict mode functions no longer provide access to the corresponding function call’s variables. In some old ECMAScript implementations arguments.caller was an object whose properties aliased variables in that function. This is a security hazard because it breaks the ability to hide privileged values via function abstraction; it also precludes most optimizations. For these reasons no recent browsers implement it. Yet because of its historical functionality, arguments.caller for a strict mode function is also a non-deletable property which throws when set or retrieved:

"use strict";
function fun(a, b)
{
"use strict";
var v = 12;
return arguments.caller; // throws a TypeError
}
fun(1, 2); // doesn't expose v (or a or b)

Paving the way for future ECMAScript versions
Future ECMAScript versions will likely introduce new syntax, and strict mode in ECMAScript 5 applies some restrictions to ease the transition. It will be easier to make some changes if the foundations of those changes are prohibited in strict mode.
First, in strict mode a short list of identifiers become reserved keywords. These words are implements, interface, let, package, private, protected, public, static, and yield. In strict mode, then, you can’t name or use variables or arguments with these names.

function package(protected) // !!!
{
"use strict";
var implements; // !!!
interface: // !!!
while (true)
{
break interface; // !!!
}
function private() { } // !!!
}
function fun(static) { 'use strict'; } // !!!

Two Mozilla-specific caveats: First, if your code is JavaScript 1.7 or greater (you’re chrome code, or you’ve used the right, won’t be able to use let/yield as identifiers. Second, while ES5 unconditionally reserves the words class, enum, export, extends, import, and super, before Firefox 5 Mozilla reserved them only in strict mode.
Second, strict mode prohibits function statements not at the top level of a script or function. In normal code in browsers, function statements are permitted “everywhere”. This is not part of ES5 (or even ES3)! It’s an extension with incompatible semantics in different browsers. Future ECMAScript editions will hopefully specify new semantics for function statements not at the top level of a script or function. Prohibiting such function statements in strict mode “clears the deck” for specification in a future ECMAScript release:

"use strict";
if (true)
{
function f() { } // !!! syntax error
f();
}
for (var i = 0; i < 5; i++)
{
function f2() { } // !!! syntax error
f2();
}
function baz() // kosher
{
function eit() { } // also kosher
}

This prohibition isn’t strict mode proper, because such function statements are an extension of basic ES5. But it is the recommendation of the ECMAScript committee, and browsers will implement it.
浏览器的严格模式
浏览器并未真的实现严格模式,所以请不要盲目的依赖严格模式。 Strict mode changes semantics. Relying on those changes will cause mistakes and errors in browsers which don’t implement strict mode. Exercise caution in using strict mode, and back up reliance on strict mode with feature tests that check whether relevant parts of strict mode are implemented. Finally, make sure to test your code in browsers that do and don’t support strict mode. If you test only in browsers that don’t support strict mode, you’re very likely to have problems in browsers that do, and vice versa.