Month: 4月 2019

移动端字体自适应

完美适口:

移动设备上的viewport就是设备的屏幕上能用来显示我们的网页的那一块区域
就是浏览器上(也可能是一个app中的webview)用来显示网页的那部分区域,但viewport又不局限于浏览器可视区域的大小,它可能比浏览器的可视区域要大,也可能比浏览器的可视区域要小。在默认情况下,一般来讲,移动设备上的viewport都是要大于浏览器可视区域的,这是因为考虑到移动设备的分辨率相对于桌面电脑来说都比较小,所以为了能在移动设备上正常显示那些传统的为桌面浏览器设计的网站,移动设备上的浏览器都会把自己默认的viewport设为980px或1024px(也可能是其它值,这个是由设备自己决定的),但带来的后果就是浏览器会出现横向滚动条,因为浏览器可视区域的宽度是比这个默认的viewport的宽度要小的。

为了使开发出来的应用或页面大小能适合各种高端手机使用,我们采用了h5的viewport来解决手机分辨率和屏幕大小的不同

    <meta name="viewport"
        content="
            height = [pixel_value | device-height] ,
            width = [pixel_value | device-width ] ,
            initial-scale = float_value ,
            minimum-scale = float_value ,
            maximum-scale = float_value ,
            user-scalable = [yes | no] ,
            

响应式网页设计–css设置网页字体大小自适应

响应式网页设计:rem、em设置网页字体大小自适应

「rem」是指根元素(root element,html)的字体大小,好开心的是,从遥远的 IE6 到版本帝 Chrome 他们都约好了,根元素默认的 font-size 都是 16px。这样一个新的单位兼容性如何呢?

IE9+,Firefox、Chrome、Safari、Opera 的主流版本都支持了,我可以放肆的使用 rem 了。

em 的计算是基于父级元素的,在实际使用中给我们的计算带来了很大的不便。所以 rem 的出现解救了我这样不会算术的人,再也不用担心父级元素的 font-size 了,因为它始终是基于根元素(html) 的。

比如默认的 html font-size=16px,那么我想设置12px 的文字就是:12÷16=0.75(rem)

当然,你可以引入 CSS 预处理工具(Sass、LESS 、Stylus等)自动计算 rem 值,这里就不一一举例了。

但是像我这样的懒人或者团队开发中还没有引入 CSS 预处理工具的该肿么办呢?只能搬个计算器啪啪啪了吗?别急,你还可以变通一下。我们改变一下 html 的默认 font-size=10px 不就好计算了嘛!Like this:

html{font-size:62.5%; 
            

php获取apk包信息的类

最近由于公司的需求,需要为游戏的开放平台做一个上传apk的功能其中需要获取包的一些信息,于是在网上扒来了一个获取apk信息的操作类,觉得写的挺好的,所以写下来和大家分享,同时记录一下。

由于js无法打开zip包,所以无法通过js来解析apk获取其中的信息,所以我们只能先将包上传到服务器,再用php来操作他(当然java于是可以滴),话补多说,先上代码:…

    

分布式系统关注点

                

每个程序员都应该知道的延迟数

L1 缓存 引用        ......................... 0.5 ns
分支预测错误        ............................ 5 ns
L2 缓存引用         ........................... 7 ns
互斥锁定/解锁       ........................... 25 ns
主内存引用              ...................... 100 ns
一次 CPU 上下文切换(系统调用)需要大约 ..........1500 ns
用 Zippy压缩1K字节   ............. 3,000 ns  =   3 µs
发送 2K 字节通过1Gbps内网  ....... 

我是一个CPU:这个世界慢!死!了!

让 CPU 告诉你硬盘和网络到底有多慢

简介

经常听到有人说磁盘很慢、网络很卡,这都是站在人类的感知维度去表述的,比如拷贝一个文件到硬盘需要几分钟到几十分钟,够我去吃个饭啦;而从网络下载一部电影,有时候需要几个小时,我都可以睡一觉了。

最为我们熟知的关于计算机不同组件速度差异的图表,是下面这种金字塔形式:越往上速度越快,容量越小,而价格越高。这张图只是给了我们一个直观地感觉,并没有对各个速度和性能做出量化的说明和解释。而实际上,不同层级之间的差异要比这张图大的多。这篇文章就让你站在 CPU 的角度看这个世界,说说到底它们有多慢。…

面试中关于Redis的问题看这篇就够了

就我个人而言,我觉得Redis的基本使用是我们每个Java程序员都应该会的。另外,如果需要面试的话,一些关于Redis的理论知识也需要好好的学习一下。学完Redis之后,对照着下面8点看看自己还有那些不足的地方,同时,下面7点也是面试中经常会问到的。另外,《Redis实战》、《Redis设计与实现》是我比较推荐的两本学习Redis的书籍。

  1. Redis的两种持久化操作以及如何保障数据安全(快照和AOF)
  2. 如何防止数据出错(Redis事务)
  3. 如何使用流水线来提升性能
  4. Redis主从复制
  5. Redis集群的搭建
  6. Redis的几种淘汰策略
  7. Redis集群宕机,数据迁移问题
  8. Redis缓存使用有很多,怎么解决缓存雪崩和缓存穿透?

下面就一些问题给大家详细说一下。

什么是Redis?

Redis 是一个使用 C 语言写成的,开源的 key-value 数据库。。和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash(哈希类型)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上,redis支持各种不同方式的排序。与memcached一样,为了保证效率,数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步。目前,Vmware在资助着redis项目的开发和维护。

Redis与Memcached的区别与比较

1 、Redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,zset,hash等数据结构的存储。memcache支持简单的数据类型,String。

2 、Redis支持数据的备份,即master-slave模式的数据备份。

3 、Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用,而Memecache把数据全部存在内存之中

4、 redis的速度比memcached快很多

5、Memcached是多线程,非阻塞IO复用的网络模型;Redis使用单线程的IO复用模型。

Redis与Memcached的区别与比较

如果想要更详细了解的话,可以查看慕课网上的这篇手记(非常推荐) :《脚踏两只船的困惑 - Memcached与Redis》www.imooc.com/article/235…

Redis与Memcached的选择

终极策略: 使用Redis的String类型做的事,都可以用Memcached替换,以此换取更好的性能提升; 除此以外,优先考虑Redis;

使用redis有哪些好处?

Redis 实现秒杀

导语

秒杀想必大家都了解,在短时间内请求访问会激增,同时要保证不会超卖和数据的准确,对于技术方面还是有些考验的。可惜的是,一直没有机会在项目中实现。再看了一些资料后,打算实验下。以下代码仅为测试所用,环境比较简单,请根据实际情况进行修改。…