平时在写js代码时会用到一些简单的计算，比方说系统中我们数据库储存的金额是分，前端展示的是元，所以在用户输入元之后要转成分传给后台，这个公式小学一年级就学过了

1

1.11*100 = 111

一般来说这个计算结果是没问题的，但是在js里面却有这样的尴尬

1

1.11*100 = 111.00000000000001

结果不是我们想要的111，类似的情况还有

1
2
3
4

0.1+0.2 = 0.30000000000000004   //加法
0.27-0.11 = 0.16000000000000003 //减法
19.9*100 = 1989.9999999999998   //乘法
0.3/0.1 = 2.9999999999999996    //除法

一般遇到这种问题，我们都有成熟的解决方案解决

• Math.js
• decimal.js

用着用着就习惯了，一直没有搞清楚为什么会有这样的误差。这两天正好有空，看了一些博客终于搞清楚了。

最近整理项目，发现用到了很多第三方的SDK，这些SDK都是直接拖到项目里面的比较乱，打算把这些乱七八糟的第三方SDK全都交给 CocoaPods 来管理。

什么是CocoaPods？

你不知道 CocoaPods 是什么？给你个传送门 https://cocoapods.org

CocoaPods 新建本地仓库

这里我用微信 SDK 来举个栗子，从微信开发者中心下载对应的 SDK。

谷歌2016年出了一个基于Linux内核的 BBR 拥塞控制算法，虽然咱不懂咋回事，还是大概知道它也是通过优化 TCP 底层协议来实现网速加速，跟锐速的原理一样。我是通过搬瓦工的 KiwiVM 后台安装的，用了之后感觉不咋地，网上查了一下，大部分网友都说锐速的加速效果要好于BBR。锐速已经停止新用户注册和维护了，之前虽然收费，但是现在已经有破解版。BBR不好用，有大神就开始魔改了，出了一个魔改版的BBR，据说效果比锐速还好！
下文对于锐速和BBR魔改版安装都有介绍，你可以尝试一下，看哪个速度更快。
下文的环境基于：CentOS6 X64

1、准备 VPS

搬瓦工VPS是我目前使用过性价比较高的 VPS，速度也比较稳定。
Vultr 也是一个比较不错的选择，不过没有搬瓦工稳定。当然其他海外的VPS也都是可以的，至于选哪个这个就根据个人喜好来选择吧。
如何购买比较稳定的 VPS 可以参考我之前写的VPS搭建高速SS服务器

本文档主要用来记录自己借助Hexo搭建博客的一些步骤和命令，方便以后重装；新人也可以通过此篇文章快速搭建自己的个人博客。
下文的环境为:
VPS： CentOS6.9
本地： MacOS

搭建博客

1、安装 NodeJS 和 NPM

1

[root@California_VPS ~]# curl --silent --location https://rpm.nodesource.com/setup_8.x | sudo bash -

执行完这个命令之后就可以安装NodeJS

1

[root@California_VPS ~]# yum install -y nodejs

距离我写的上一篇文章 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的情况，大部分都是这样处理的

1
2
3
4
5
6

__weak typeof(self) weakSelf = self;
self.myBlock =  ^{
__strong typeof(self) strongSelf = weakSelf;
    [strongSelf doSomething]; 
    [strongSelf doSomethingElse]; 
};

转载请注明出处：来自LeonLei的博客http://www.gaoshilei.com

我们习惯了这样用，貌似这样用了之后可以解决循环引用的问题，而且可以保证block执行之前self不会被释放掉？真相总是残酷的，然而事实并非如此！下面将会对block中引用self的三种方式进行讨论，并给出原因和另外一种解决方案。

一、 RunLoop初识

日常的开发工作中，我们几乎很少注意RunLoop，因为我们基本上“用不到”RunLoop。包括我在内应该有很多人都不了解这个东西，只是听说过。最近有空查了不少资料终于把RunLoop运行原理搞清楚了。
本文会对RunLoop的原理进行深入探讨，但是不涉及底层的实现。
我们平时开发中的很多东西都和RunLoop相关，比如：

前言

以下所涉及的框架和库只针对iOS而言，不确保在其他平台也适用。

最近由于公司业务需要，要求封装一个支付SDK，需要用到微信支付和支付宝，之前做过的Framework没有依赖其他第三方的库所以比较好做，这次有所不同；一开始我想把支付宝和微信支付的SDK全部融合进来，折腾一天才发现我之前的想法有很多误区，这样是根本行不通的，不过最后还是封装成功了，下面把我的经验分享出来，供有需要的同学少走弯路。 制作之前最好把功课做足，看看静态库和动态库到底是什么东西。