1.抄一个产品是很容易的，损一个产品也是很容易的，知道别人的产品为什么那么做，自己的产品怎样做会更好，是比较难的。

2.影响一个产品发展的只有核心的几个点，其他细节做到极致跟做到60分+对产品的影响微乎其微。细节不会决定成败，核心细节才会。

举个例子，苹果把手机系统/应用生态/品牌营销做到最好就行，AppStore iCloud iTunes 这些做得再糟糕，只要60分能用就够了（甚至AppStore老是不能用），不会对苹果销量产生多大影响。

当然整个 App 各个细节都做到极致是好的，但细节是工作量堆出来的，理想情况下资源应该尽量用在更能推动产品前进的点上，也就是用在更有性价比的地方，资源有限的情况下，理想的分配是，重要的功能点多花时间打磨细节，不重要的功能点快速做到60分，而不是追求每一个点都做到极致。资源充足或过剩的情况请便。

3.产品人员本身的想象力对团队效率影响很大，理想情况下设计时就能在脑里想象做出后的效果，并串上真实数据，假想各种条件下这样的设计会不会有问题。当然一般做不到像真实体验那样的程度，但应该尽力想象。

4.开发接到产品的需求不假思索马上动工做，看似尽责，实际很不靠谱，有时产品设计功能太多，对具体一功能一时想得不周全，或者产品不清楚技术具体实现难度/代价导致错误设计，这时开发应该补全这个缺口，有问题在动手之前沟通好。

5.有些产品新功能，开发咋一看很不靠谱，实际上产品在设计时有自己的思考逻辑，得理解他们的思考逻辑后才好吐槽。

6.做产品没有唯一正确的方式，技术导向，产品导向，传统制度，独裁都能做出好的产品。facebook是技术导向，line是传统制度，微信是独裁产品导向。

7.交互的效率第一，效果第二。只提升视觉效果，没提升效率，或者降低效率的交互是不会流行的。典型的如一些3D桌面，交互很炫，效率很低，玩完就扔。下拉刷新，既提升视觉效果又提高效率，变成标配。iOS Tabbar 视觉效果不好，但效率奇高，也成为最流行的交互。创新的交互本身就会降低效率，因为用户有学习成本，若不能带来效率的提升，就会难以为继，如facebook paper。

JSPatch 开源以来大部分被用于 hotfix，替换原生方法修复线上bug，但实际上 JSPatch 一直拥有动态添加功能模块的能力，因为 JSPatch 可以创建和调用任意 OC 类和方法，完全可以用 JSPatch 写功能模块，然后动态下发加载。只是之前在性能和开发体验上有些问题，还没有太多这方面的应用。这次 JSPatch 做了较大的更新，扫除这些问题，让用纯 JS 写功能模块变得实用。这里有个用 JS 写的 Dribbble 客户端 Demo，可以体验下效果。

来看看这次更新做了什么。

性能优化

通过工具可以看到使用 JSPatch 写功能模块时，耗时较多的点在于 JS 和 OC 的通信，以及通信过程中参数的转换，于是在这块寻找优化点。写功能时需要新增很多类和方法，例如：

defineClass('JPDribbbleView:UIView', {
  renderItem: function(item) {
    ...
  },
})

defineClass('JPDribbbleViewController:UIViewController', {
  render: function(){
    var view = JPDribbbleView.alloc().init();
    view.renderItem(item);
  }
});

上面两个都是新增的类，两个方法也是新增的，按之前的流程，这里的定义会传入 OC，在 OC 生成这两个类，并在这个类上添加这里定义的方法，调用时进入 OC 寻找这些方法调用。

（更多…）

看了 Limboy(文章1 文章2) 和 Casa (文章) 对 iOS 组件化方案的讨论，写篇文章梳理下思路。

首先我觉得”组件”在这里不太合适，因为按我理解组件是指比较小的功能块，这些组件不需要多少组件间通信，没什么依赖，也就不需要做什么其他处理，面向对象就能搞定。而这里提到的是较大粒度的业务功能，我们习惯称为”模块”。为了方便表述，下面模块和组件代表同一个意思，都是指较大粒度的业务模块。

一个 APP 有多个模块，模块之间会通信，互相调用，例如微信读书有 书籍详情 想法列表 阅读器 发现卡片 等等模块，这些模块会互相调用，例如 书籍详情要调起阅读器和想法列表，阅读器要调起想法列表和书籍详情，等等，一般我们是怎样调用呢，以阅读器为例，会这样写：

（更多…）

20年前电脑战胜国际象棋冠军时，很多幻想者开始幻想电脑以后如何拥有人类的思想，以后如何统治人类，自从我学习计算机后，就对这些幻想者嗤之以鼻，因为我知道了计算机程序的大致原理，只不过是一些逻辑和循环运算组成，能战胜国际象棋冠军主要是因为计算能力强速度快，象棋每一步可能的情况又很少，计算机可以穷举，再加上一些逻辑策略的优化可以战胜世界冠军，这种能力跟人类大脑完全不沾边，没有半毛钱关系。从战胜象棋冠军就开始幻想计算机可以拥有人类一样的思想，当时觉得这些想法很傻很天真。

直到5年前我看到一本书《人工智能的未来》，这本书阐述了大脑的工作原理，以及用计算机模拟这种工作原理，造出真正与人类大脑接近的人工智能的可能性，让我叹为观止，我一直觉得不可能的事情，原来是可能的，只不过因为我自己的无知和低水平，对计算机的认知停留在已有的范式上，又觉得大脑高深不可测，才觉得这是不可能的。

这种学潮持续发展，到今天计算机的机器学习领域已经很热门，就在今天基于机器学习的 AlphaGo 对围棋世界冠军李世石第三局结束，3-0领先，5-0几乎没有悬念，让人始料未及。10年前看漫画《棋魂》，台词说到计算机可以轻易赢象棋冠军，但要赢围棋冠军，至少得100年后，这也是大家普遍的观点，因为围棋的复杂度跟象棋不在一个量级，结果计算机10年就达到了这成就。按我理解围棋是特定领域，即使在围棋上赢了世界冠军，离真正的人类大脑还有很大差距，但已经不敢嘲笑幻想者们对这种可能性的想象了，这真是可能发生的事。

我们经常基于自己的经验，很轻易地说一些事情不可能，如果我生活在五六十年代，肯定会觉得计算机大规模应用不可能，它只不过提供了一些二进制运算和数字存储能力，怎么可能面向大众提供工作娱乐功能，但硬件半导体的发展跟软件开发的分层思想让这些成了可能。Google 佩奇说，“有一类事情，人们公认不可能实现，如果你不动手去做，它也就真的不会发生。”很佩服所有致力于把这些不可能的事变成可能的人。人与人之间的差距巨大，“改变世界”在我们发展中国家不过是一句忽悠台词，而他们是真正在实践。生活在这个时代很幸福，很期待未来的世界。

JSPatch 是一个 iOS 开源项目，只需在项目中引入极小的引擎，即可让 APP 拥有实时修复 bug 以及动态运营的能力，目前已得到广泛应用，据年前统计，已经有 1200+ 个 APP 接入 JSPatch。

JSPatch 的使用需要后台下发脚本，需要搭建后台，对脚本进行版本管理和分发，这对于很多中小 App 来说是很麻烦的事，很多小 App 甚至没有后台。另外 JSPatch 脚本权限很大，对于脚本的下发还需要考虑好安全问题，否则会有安全隐患。这导致 JSPatch 使用的门槛有点高。

JSPatch 平台 (http://jspatch.com)就是为了解决这个问题的，它可以让开发者无需自己搭建后台，也无需考虑安全问题，只需在平台注册上传脚本，App 接入 SDK 即可使用 JSPatch 为自己的 App 提供动态能力，降低 JSPatch 的使用成本。

接入 JSPatch 平台 SDK 的 App 需要在每次启动或每次唤醒时访问服务器询问是否有脚本更新，这些请求汇集到一个平台上后平台的请求量和流量都会很高，对服务器的性能和并发要求也很高。JSPatch 平台把脚本的分发逻辑转为静态文件，架构在七牛云存储上，云存储在分发静态文件上是高并发高稳定性的，所以平台在性能上没有问题，可以支持任意用户数的 App 接入并保证稳定性。

解决了服务器性能问题，还有资源消耗的问题。大量的请求会消耗不少云服务资源，而这些资源并不是免费的，需要有一定的投入。所以去年做完平台后一直没有开放注册，而是通过发邀请码的方式控制用户数量，也就一直没改进和推广。随着 JSPatch 的发展，近期还是想放开注册，同时想做一个尝试：收费。学习各个云平台，提供一定免费额度，超出的再按服务器的成本价收费，解决资源消耗问题。收费上简化为只对请求次数收费，无视带宽/存储/流量，实际上计算出来的费用是很低的，并且免费额度也足够支撑大部分 App，应该很容易接受，具体可见这里。

欢迎试用 JSPatch 平台，有问题可以直接邮件 bang590@gmail.com

前年五月开始入住广州碧桂园，至今接近2年，写写在这里住的感受到的它的优点和缺点，以及吐槽下一些做得不好的地方。

优点

1. 每一栋楼都是七层小楼，人口密度不大，小区宽敞开阔，绿化好，内部还有小公园，广场舞都集中在小区公园跳，不扰民，道路楼梯都有人打扫，绿化也有人修理，整体干净整洁，环境上确实不错。
2. 小区安全，出入门禁稍严，定期有保安巡逻，没听说过有偷盗事件，管理上除了下面吐槽的那些，其他还不错。
3. 建筑质量好，99年建的房子，外表看起来还很新，内部也没什么大问题，至今没发现质量问题。
4. 门口俱乐部有巨大的游泳池，夏天爽爽的，此外还有烧烤场、网球场、篮球场、羽毛球场，感觉不错。
5. 公共交通还不错，走路到地铁，也有不少公交。

（更多…）

今天收到不少人给我发这篇新闻《曝苹果应用商店逾千款iOS应用存安全漏洞》，以及其他媒体转载或翻译的一些类似的新闻(1 2)，每次我都要解释一遍，比较累，写篇文章说说具体情况。

起因是网络安全公司 FireEye 发表了一篇 JSPatch 安全研究报告，里面介绍了 JSPatch 的使用，并指出一些潜在的危害，分三种情况：

1.开发者自己本身有恶意，在自己开发的APP里加上 JSPatch 引擎，用户安装后开发者自己下发恶意脚本，可以做一些恶意的事情。但这里做恶意事情的权限并没有超出iOS的沙盒，也就是说，有没有用 JSPatch 开发者能做的事是一样的，没有 JSPatch 开发者同样能在代码里实现好恶意功能，通过苹果审核后再开启，所以这条挺废的。

2.开发者接入的一些第三方 SDK 里包含了 JSPatch，SDK 的作者再对这些 APP 下发恶意脚本。这种需要开发者防范，避免使用一些恶意 SDK，目前还没有发现有这样的恶意 SDK。

3.开发者自己在 APP 接入 JSPatch，若开发者没有针对传输的 JSPatch 脚本加密。攻击者就通过网络传输的中间人攻击手段下发恶意脚本到用户APP。这点确实比较危险，接入 JSPatch 时请做好加密传输，只要做 RSA 非对称加密传输就不会有问题。加密方式可以参考之前的文章《JSPatch 部署安全策略》，以及项目自带的 JPLoader 实现。

除了以上这三种情况，接入 JSPatch 的 APP 没有其他问题。据了解大部分使用 JSPatch 的 APP 都已经做好非对称加密，并没有什么安全风险。FireEye 上提到 1200 多个 APP 接入 JSPatch，上述媒体文章直接断章取义成上千款 iOS 应用存在安全漏洞，不知道是看不懂原文，还是 KPI 压力的产物。

2006年1月14日，我在闪吧开了个博客，写下第一篇文章，内容很短相当于现在的微博，当时我自己还觉得会三分钟热度，结果持续写了十年。十年前还在上着高二，捣鼓着flash，用着IE，玩着CS，看着CRT显示器，拿着山寨功能机，如今这些都是古董了。当时因为玩 flash 经常逛闪吧和闪客帝国，嫌当时如日中天的新浪博客样式太丑自由度太低，就在闪吧开了博客，直到09年才自己租空间搭了个wordpress。闪吧虽然很快没落了，但网站竟然一直保留着，没有变过，真是难得，还可以上去怀旧一把。

十年以来在这个博客发了四百多篇文章，用它吐槽生活，发表随想，发布作品，分享技术，收获不少，写博客可以针对一个主题完整思考，是记录也是创作，对个人很有好处。现在流行的微博朋友圈都是快销品，写了什么以后不会再去看它，博客不一样，现在回头看以前写的博客，还挺有意思，很多想法和见闻都记录下来了，很让人怀念。这个博客也算我的一个完整作品，很喜欢这个作品。

回顾我的博客，大致可以分成三个阶段。

第一个阶段 06-08 年，写了很多生活琐碎事，很多内容短得像现在的微博，算不上“博客文章”，这个时期可以看到一个敞开心扉的少年日常碎碎念，有时一些情绪也发上去了，像现在的“树洞”一样，因为放心周围不会有人看到我写的东西，是我的一大私人吐槽地，有些现在看起来还挺搞笑的。

第二个阶段 09-11 年，博客写得最多的时期，逐渐有人看了，也逐渐尝试写长的有主题的文章，推出“推特中文圈”后带来不少读者，当时 Google Reader / RSS 还流行着，大家都会订阅去看，写之前开始会考虑到“这是有人看的文章”，但又没有什么束缚，正值大学最自由信心最满的时期，写了一些我自己比较喜欢的文章，也有几篇被传播得较多的文章，感觉是这个博客最美好的时期。

第三个阶段 12-15 年，开始工作了，多了很多束缚，很少写生活的内容，也没那么多时间，技术文章占了大多数，勉力支撑。其实我并不喜欢在这里发太多技术文章，有时很想回到以前的状态，多写一些生活和随想，但发现已经做不到了。

十年以来做到每个月至少一篇博客，可惜的是大学入学军训那一个月没有机会发博客，只有那一个月漏掉了，有空再把当时军训期间手写的日记发上，补全这个缺口，让这个博客完满。