平时在写js代码时会用到一些简单的计算,比方说系统中我们数据库储存的金额是分,前端展示的是元,所以在用户输入元之后要转成分传给后台,这个公式小学一年级就学过了
一般来说这个计算结果是没问题的,但是在js里面却有这样的尴尬
结果不是我们想要的111,类似的情况还有
一般遇到这种问题,我们都有成熟的解决方案解决
用着用着就习惯了,一直没有搞清楚为什么会有这样的误差。这两天正好有空,看了一些博客终于搞清楚了。
平时在写js代码时会用到一些简单的计算,比方说系统中我们数据库储存的金额是分,前端展示的是元,所以在用户输入元之后要转成分传给后台,这个公式小学一年级就学过了
一般来说这个计算结果是没问题的,但是在js里面却有这样的尴尬
结果不是我们想要的111,类似的情况还有
一般遇到这种问题,我们都有成熟的解决方案解决
用着用着就习惯了,一直没有搞清楚为什么会有这样的误差。这两天正好有空,看了一些博客终于搞清楚了。
最近整理项目,发现用到了很多第三方的SDK,这些SDK都是直接拖到项目里面的比较乱,打算把这些乱七八糟的第三方SDK全都交给 CocoaPods 来管理。
你不知道 CocoaPods 是什么?给你个传送门 https://cocoapods.org
这里我用微信 SDK 来举个栗子,从微信开发者中心下载对应的 SDK。
谷歌2016年出了一个基于Linux内核的 BBR 拥塞控制算法,虽然咱不懂咋回事,还是大概知道它也是通过优化 TCP 底层协议来实现网速加速,跟锐速的原理一样。我是通过搬瓦工的 KiwiVM 后台安装的,用了之后感觉不咋地,网上查了一下,大部分网友都说锐速的加速效果要好于BBR。锐速已经停止新用户注册和维护了,之前虽然收费,但是现在已经有破解版。BBR不好用,有大神就开始魔改了,出了一个魔改版的BBR,据说效果比锐速还好!
下文对于锐速和BBR魔改版安装都有介绍,你可以尝试一下,看哪个速度更快。
下文的环境基于:CentOS6 X64
搬瓦工VPS是我目前使用过性价比较高的 VPS,速度也比较稳定。
Vultr 也是一个比较不错的选择,不过没有搬瓦工稳定。当然其他海外的VPS也都是可以的,至于选哪个这个就根据个人喜好来选择吧。
如何购买比较稳定的 VPS 可以参考我之前写的VPS搭建高速SS服务器
距离我写的上一篇文章 Weex从入门到超神(一) 已经过了挺久了(惭愧而不失礼貌的微笑),起初写那篇文章的初衷是因为项目中使用到了 Weex ,所以准备对 Weex 做一个心得式的笔记,后来无意间发现简书“霜神”已经对 Weex 写过几篇剖析比较深刻的文章,还有其他一些原因(懒),所以就没有继续写下去。
最近由于Facebook的 BSD license,React 被前端社区的同学们推到了风口浪尖,React&RN、Vue&Weex 又成为了大家码前码后讨论的话题。Apache 社区还因为 Facebook 的 BSD license,全面封杀使用了 BSD license 的开源项目,貌似一切都很精彩,迫于前端同(da)学(lao)的淫威还有社区的强烈谴责,上周 Facebook 终于认怂了,承诺这周将 React 以及 gayhub 上面的其他几个项目的开源协议从 BSD 改成 MIT,下图是我脑补的场景:
鉴于对于项目中使用 Weex 的一些经验和心得,还是希望写出来和大家一起分享。
随着移动端发展进入白热化阶段,很多中小型公司越来越注重于APP的更新迭代速度。加上去年微信小程序的问世,前端同学似乎迎来了“第二春”,越来越多的 Native 开发者感受到了前所未有的压力,人家已经打到家门口了,难道就这样两眼旁观吗?
两年前 Facebook 团队发布了一个全新的移动端和前端无缝衔接的框架 React Native,很明显是用 React 开发的,支持在 Native 上运行的这么一个玩意,这相对于苹果漫长的审核机制的确是一个福音。可是 React 的学习曲线比较陡,网上大部分教程的性质都是 “React Native 从入门到放弃”,RN虽好,但是对于大多数移动开发者来说学习成本过高。
下文的讨论基于ARC
平时开发中我们遇到block里面引用self的情况,大部分都是这样处理的
|
|
转载请注明出处:来自LeonLei的博客http://www.gaoshilei.com
我们习惯了这样用,貌似这样用了之后可以解决循环引用的问题,而且可以保证block执行之前self不会被释放掉?真相总是残酷的,然而事实并非如此!下面将会对block中引用self的三种方式进行讨论,并给出原因和另外一种解决方案。