2018到处叫惨，我也叫着，不过回头想想还好，无非是股票跌一半，JSPatch平台连连被干，还没到很惨的程度。

工作上今年经历比较多的变化，再一次深刻体验到阿里文化里的拥抱变化，跟腾讯人员组织架构长年不变形成强烈对比，各有利弊，职责的变化让我能得到更多信息，看到和理解更多的事情，也多了比之前大得多的压力。当不涉及具体技术细节，在解决问题思路/方法论/套路上，很多都是共通的，今年体会到很多技术以外的方法论通用性，仿佛刚踏进职场，体验到很多。

最近感受最深的是自身的思考不足，人为了逃避思考，愿意做任何事情，工作生活中碰到的事情和问题都去思考本质原因，是挺难做到的，需要有意识锻炼形成习惯，这点做得不好。经验和信息是数据，发现和解决问题的思维能力是算法，两方面都要提升。

另一点感受是科技与人文清晰的界限，工作上的经验和思维能力都可以归为纯理性的科技理科，这方面能力再强也无法代替感性的人文艺术带来的体验，有时候工作之余听到触动人心的一首好歌，看到一部好书好电影，会有种久旱逢甘雨的感觉。对美的感受力越强，就有越丰富的体验，学理科是为了解决问题，学文科是为了增强对美的感受力，这两者都值得一直mg游戏平台官方网站。

今年的贸易战和经济下滑，对我影响比较大的就是股票腰斩了，大部分钱都在股市上，回想去年年末股市顶峰期，当时在嘲笑自己胆小，面对一支自己认为永远涨的股票都不敢融资加杠杆，今年看来真是幸亏胆小，涨时想融资加仓，跌时想放着总会涨回来，小股民心态特别突出，作为厌恶赌博的人也陷入赌博的圈子，不过人在社会混很多行为都可以归为赌博。在金融公司工作，断断续续听到一些金融知识分享，感觉金融领域太专业，皮毛都还没学到，只有当韭菜的份。

没有被年末的裁员潮影响到，不过危机确实越来越近了，程序员行业在国内有明显的年龄歧视，到一定年龄达不到预期水平就会被市场抛弃，国内竞争压力很大，在大公司久了，得注意下荒野生存能力，否则到时可能会很被动。

JSPatch 8月开始遭受另一波审查升级，混淆的方案失效，mg游戏网站确实针对JSPatch做了比较厉害的扫描手段并在不断升级，今年跟审核团队沟通他们也是表示不喜欢JSPatch，还是那套审核后不能修改的说辞，就算解决了安全问题也没用，比较无奈，但热修复需求还在，JSPatch平台还是会继续找解决方案。

博客写得越来越少，没有去钻研一个个技术细节的机会，没多少技术内容可写，工作内容不适合写，纯思考的东西也不成熟，感觉现在不太敢发表一些看法，说话有压力，可以看到今年很多文章都在月末发，都是不想打破一个月一篇的惯例水出来的，以后应该不再遵循这个惯例了。

拍拖十周年，细水长流，后面还有很多个十年。小朋友三岁了，有次送她跟堂兄堂姐回老家住一段时间，小屁孩临别时开心得要命，完全不顾旁边落寞的老爹老娘的感受，堪称年度画面。这么快就长大了，可爱还是一如既往，话特别多，会说“我每天等你们上班等了好久”，不过每天下班看到我第一句话一定是“爸爸我可以看ipad吗”，(;-_-)。小孩的黄金年龄，好好珍惜。

打卡北海道，京都，大阪，硅谷，一号公路，南京，绍兴，普陀山，时不时回忆起来的画面是在北海道，厚厚积雪的街道静谧干净，很惬意，日本真是旅游体验很好的国家，去了两次还想再去。美国朝圣，看到人的多样化，勇士破旧的球馆，斯坦福的大学气息，一号公路的美景，FB小镇般的办公区，可惜没有体验到真正美国居民的生活。

对电子设备的兴趣依然很浓，Switch，Airpods，Apple Watch，最佳设备是 Airpods，一般人都买了就后悔，后悔没早点买。刷塞尔达，奥德赛，刷权利的游戏，延禧攻略，毒枭，刷漫画一人之下，零星看十来本书，十几部电影，娱乐比较匮乏。

2018年中规中矩，虽然有不少不如意，但自己与家人身体都健康，自己有一些进步，还算可以了。

2019年继续加油。

明天30岁生日，活了整30年。

沿着当前最普通的人生路径，过着最普通的生活，读书考试，应聘工作，结婚生子。碰到过挫折，但跟别人的对比起来挫折并不大，有各样的压力，但还在承受范围内，总的来说还是非常幸运的。在跌跌撞撞地成长中，见识，能力，思维，承受力，在不同时期不同平台都得到一定程度的锻炼，觉得还不错。

有些方面的成长严重拖后腿，情绪控制能力有倒退趋势，贪婪恐惧懒惰等人性也没见处理得比之前好。

能够理解越来越多的事情，包括信仰，活下去不是唯一的真理，可以认为人生过得开心最重要，也可以认为一切都是欲望，欲壑难填苦海无边不如修身养性六根清净，也可以认定献身一项伟大事业是值得的。以前看小说电视剧时不能理解这些行为，现在多少可以。

以前最看重自由，相信等价交换，现在这两个词很少在自己的世界里出现了，变成了责任和成长。

30年大部分体验到的是人生美好的东西，希望后续几十年也是这样。

信息就是资源，信息不对称可能是世上最主要的赚钱手段，多数有价值的信息存在于在于私密人际关系网上，所以跟人的连接越多，连接质量越高，能获得的信息资源就越多，程序员在这方面有劣势，多数时间在跟机器和互联网连接，能获得的信息太少。

人的生活有惯性，习惯懒惰就一直懒惰下去，习惯高压会觉得高压也没没什么，就像物理加速和匀速，切换状态时有不适应的感觉，进入轨道后就靠惯性持续下去了。

每个人都喜欢做新的东西，不喜欢维护旧的系统，创造新东西相比维护旧系统更容易产生成就感，也更容易汇报，但实际上产生的价值往往没有比维护旧系统多。

在批判中医在知识分子圈是政治正确，但身边太多西医没办法的小病中医治愈的例子，因为没有做过双盲实验就被一棒子打死，作为安慰剂和小概率事件看待。面对像人体这种复杂问题，大家更愿意用确定性的统一的框架和思维去理解，而选择性忽视不利于自己认知的事实。

人们对外总会展示自己好的一面，言语经过粉饰，文字更是经过重重筛选，只会透露对自己评价有利的想法，文字在网络上发出来目的就是获得赞赏，通过一个人的文字、朋友圈、微博是无法知道他的习性和真实想法的。

我在 2013 年开始做了很多 APP 在 AppStore 上出售，在当时有不错的收入成果，在前几年已经停止运营，分享下当年开发运营的一些经历和套路。

做什么 APP

如果是为了情怀做 APP，就做自己喜欢的，如果是为了赚钱，最好是去市场看看大众需要什么 APP，刷几遍 AppStore 各国家各分类的免费和收费排行榜，看哪些是需求大同时现有的 APP 做得不够好的，去做个更好的抢占市场，当时私人计算器就是这种方式做出来的，这种方式做出的 APP 占绝大部分收入，而我的其他靠自己想象出来来的创新 APP，在收入上并没有获得很好的成果。

设计和开发 APP 不多说，后面主要说一些运营方法。

AEO

AEO，AppStore 搜索引擎优化，零成本的推广方式，搜索也是用户触达 APP 最主要的方式，手段包括：

1. 标题加关键字，这在当年是最有效的做法，权重比 keywords 高很多，所以当时大部分 APP 名后面都跟着一长串介绍性关键字，比如私人计算器就是：Private Calculator – File Hider, Secret Photo Video Browser, Image Downloader and Note vault，不过现在被禁止了，独立了个 subtitle 出来，权重有所变化。
2. 多国语言，AppStore 是面向全球的应用市场，每个国家都有不同的搜索关键字，多支持一个语言就多一分被搜到的机会，私人计算器配置了十几个语言的标题和关键字，是有不错效果的。
3. 内购项目关键字，内购项目是可以命名成为搜索关键字的，曾经有段时间，AppStore 上搜什么都出喜马拉雅，似乎就是这个做法，不过当时我的APP没有内购模式，没有试过。
4. AEO 工具，当年还没有很好的工具，现在像 AppAnnie 可以帮你跟踪关键字效果，挑选效果最好的关键字。

AppStore 的搜索规则时刻在变，在我运营期间有好几次因为搜索规则变化导致收入突降，现在的搜索规则估计连在mg游戏网站开发 APP 搜索的人也摸不清楚，得时刻跟进才行。

限免

限免，收费APP在一两天时间内限时免费，在当年效果非常好，得到的好处包括：

1. 限免后会有媒体或者限免平台推荐，在网络上的曝光增多。
2. 限免后顺利的话在AppStore上的排名会上升，好一点的APP加一点点运营迅速串到分类第一或总榜前几名是常事。
3. 恢复收费后的一天内，在AppStore上的排名曝光，以及网络曝光流量还在，会比平时多销售多很多，效果好的话是平时的几倍。
4. 限免后用户对 APP 的使用和留下的评论，对 AppStore 搜索效果有正面影响。

限免的效果好不好，取决于有多少媒体和平台推荐，这又取决于几个因素：

1. APP 自身质量，质量好有需求的 APP 媒体乐意自主推荐。
2. 人工运营，收集几十个限免推荐媒体和平台，在他们平台提交限免的 APP，或群发邮件告知他们。
3. 跟一些大的限免推荐平台达成合作，做独家限免，确保有平台推荐。当时跟 AppGratis 做过很多次合作，包括限免和降价，会抽取不少销售费用，但是总体下来还是很划算。

限免在当时是我最主要的运营手段，不知道现在效果会怎样，不过现在很多 APP 都是应用内付费的方式，直接收费越来越少，限免的手段和平台也就越来越少了。

套壳

AppStore 上出现一个神奇的运营推广方法，套壳，就是同一份 APP 代码，改改图标/应用名/介绍/以及内部某些UI，摇身一变成为另一个 APP，上架到 AppStore，它很有效，因为：

1. 曝光量变大，用户因某个需求搜一款 APP，很多人不会直接下载第一个，而是翻一翻，看多几个APP对比一下，这种情况下，一个 APP 就是一个曝光，一个广告位，占据得越多，被点击下载的概率就越大。
2. 关键字变多，多个 APP 可以设各种不同关键字，进一步增大曝光。
3. 审核风险，AppStore 的审核，谁试谁知道，分分钟让你崩溃，一个 APP 审核不通过，换一个账号提交可能就通过了，有一些灰色地带的功能，比如下载视频，多一个套壳 APP 就多一份审核通过的概率。

我做的套壳比较柔和，只套了几个，而且都有做一些改动，每个定位都不同。后来发现其他人是工业化的方式去做这个事，大量套，对于为了逃避审核去套壳的，一次性提交几十个APP，总有审核的漏网之鱼让APP顺利上架。

其他

1. 广告，如果 APP 的使用 PV 高，放广告效果是挺不错的，很小的日活就能有很好的收入。
2. 应用内互推，做 APP 矩阵，每个 APP 都推广自己其他的 APP，常规方法，这块感觉做得最好的是四叶。
3. 订阅模式，把一次性收费变成订阅，订阅是每一年或每一个月都收费，当年没有这个功能，没试过效果，据了解应该是个敛财利器，各收费App改成了订阅模式。
4. 流量运营，社交方面官方的facebook/instragram/twitter/公众号账号，媒体方面的软文/youtube视频，官网SEO，这里水太深没怎么涉及，独立开发者也很难做好这些运营。

这里只是分享我经验范围内的一些运营手段，没有多深入和专业，毕竟一个人能做的事有限。说些题外话，独立开发者个人觉得不是一个好路子，充满情怀的 APP 很难赚到生活费，除非你天赋异凛，为赚钱而开发的 APP，发展成工业化作坊才有发展的机会，此外独立开发者的孤独感强烈，估计得是强烈外向性格的人才能长期维持那种状态。

移动端开发从08年开始就有个大家前赴后继不断追求的目标：跨平台，15年时 nwind 有篇雄文，详细调研了跨平台各流派，其中最后的 Dart 栏可以看到现在 Flutter 的雏形。可以看出来，Flutter 是从精简浏览器的思路演化过来的，实际上 web 与 Flutter 从底层看是一致的，web 是提供了一层平台无关的独立引擎，可以看成平台只提供了画布，所有的UI组件、框架、事件处理都是 web 引擎封装处理。其实这种虚拟机方式是跨平台的正道，在 GUI 跨平台的道路上，JAVA 、FLASH 都是这种方式，在 PC 时代都取得过成功，只不过移动端时代只有 web 这种开放标准能平衡各大公司利益，延续下来了。

原本 web 作为跨平台的解决方案很完美，FB最初也信心满满用 web 技术做主 APP，但到最后还是搞不定性能问题，被迫回归原生。为什么web性能不行，上面雄文也说了，历史代码兼容，CSS复杂，DOM接口粒度大等问题，自然有牛人们继续不断去尝试解决这些问题，面对历史包袱满满的 web 引擎，首先尝试的当然是不断删代码删功能，做个精简版的 web 引擎，完全抛弃兼容性，只保留最主要的功能，据 Eric Seidel 说删完后快了 20 倍，于是朝这个方向经过几年的努力逐渐演化出 Flutter。（国外大厂可以花三四年时间做一个引擎且还在Beta，怕不怕？）

Flutter 的推出为略为沉闷的移动端技术注入了一些活力，底子强，包装好，只要接入引擎就能获得跨平台+高性能的特性。不过 Flutter 还是有不少缺陷：

1. 动态化，国外对跨平台有偏执，国内对动态化的偏执更高，高速发展高压环境，随时发版修改是基础能力，Flutter Release 是 AOT 无法动态化，理论上可以用 JIT 模式做动态化，但目前 Release 上没有 JIT 模式，不确定是否有性能上的问题，国内大厂接入使用少了一个很重要的理由。
2. 体积，编译后iOS双架构15M+，Android单架构约7M，不算太大，对小APP可以接受，但在大厂大APP普遍严格控制体积的情况下，使用又多一个大障碍。
3. 语言，从 web 演化过来的框架，为什么不使用 JS 而是使用 Dart？可能出于性能考虑，Dart有 AOT 模式，但使用 Dart 绝对是 Flutter 推广的一大劣势，学多一门新语言就多一层障碍，Java 对 Android 开发的推动，JS 对 nodeJS 的推动，换个语言就不一样了。
4. 生态，Flutter 刚推出不久，组件功能的完善度和丰富程度自然不能跟发展了十几年的iOS/Android原生以及web相比，虽说生态都是慢慢建立，但这一个从语言到工具到组件都是几乎从零开始积累，无法借用强大的前端生态或其他生态，难度会高很多，堪忧。

不管怎样，Flutter是一个宝库，一个完整的比 webkit 简单得多的引擎，源码很值得挖掘mg游戏平台官方网站，现阶段国内关注 Flutter 也是mg游戏平台官方网站居多，直接使用 Flutter 目前吸引力还不够大，但国内可能有另一个利用 Flutter 的途径：小程序。Flutter 从 web 引擎简化中来，使用的也是 CSS flexbox 布局，但抛弃历史包袱重定规则，不兼容 web 也不是 dom 那套玩意，需要上层业务根据新规则限制写法，而小程序就是这样的限制框架，可以参考 Flutter 构建小程序渲染引擎，相对于 web 渲染性能好，相对 RN 渲染，同渲染引擎坑少，无需维护两个平台框架。可行性待研究，算是一个有趣的课题。

7月的博客，写写6月初参加WWDC时在美国的见闻感想。

加州

加州，最深的两个印象，就是充足的阳光和多样化。

每天都是蓝天大太阳，阳光从早上6点晒到晚上9点，关键是晒着还不热，非常舒服，据说一年四季都这气候，18°-25°，真是得天独厚，国内貌似没类似这样的地方。

多样化，不知是美国共性还是加州硅谷特别，世界各地的人，各色各样，各种肤色、装扮、身材、个性，人非常多样化，很喜欢有多样化人群的环境，可以从每个人身上看到mg游戏平台官方网站到不同的东西，我比较不喜欢广州的一点是大部分都是广东人，多样性较低，有趋同的习俗文化、关注点、生活方式，久了会觉得无趣。 （更多…）

第一次去美国参加WWDC，说说见闻。

Keynote

今年WWDC亮点较少，感觉一般，点也比较散，是各种小点拼凑，没看到主旋律主方向。

AR占了很大篇幅，是本次WWDC的主角，会场专门有块地方去让参会者玩使用了 ARKit2 新特性多人游戏的《Swift Shot》，现场玩了下，感觉一般般，一种不会火的既视感。mg游戏网站大力发展 AR，有意作为下一个大的技术点和平台，猜想应该会有硬件上的配合，现在用 iPad/iPhone 玩 AR 着实别扭，AR 还是需要眼镜的配合才能自然用起来，期待mg游戏网站的眼镜。这次 AR 支持的图像跟踪、场景保存和真实光反射，据了解效果确实不错，做 AR 的人都会挺兴奋。

AI 有不小的更新，新的 Create ML 可以更简单地训练 CoreML 模型，以前都是使用其他框架训练后再转换模型跑在 CoreML 上，或者用 Turi Create 去开发。mg游戏网站面向开发者的 AI 策略上，走的是傻瓜式路线，不需要懂 AI 相关技术和算法，按规则拖拽就可以使用，只提供有限的常用的几种应用场景，像图像分类，文本分类，特征预测。用迁移mg游戏平台官方网站的方式，在系统内置训练好的模型，用户只需训练最后一层，导致模型很小，很符合移动端应用的场。IDE做得非常好，真是零基础一分钟上手，但问题是无法跨平台，如果 Android 也要用就没辙了，只能用其他框架训练后转换。

iOS12的特性，感觉亮点是防沉迷防打扰，跟微信4.2发布时的“是时候放下手机，跟朋友面对面”这个口号有点像。统计APP使用时间，限制单个APP使用时长，对我来说是很有需求的功能，但对于大众来说不一定，很少人会去限制自己。倒是家长控制这个功能应该会比较受欢迎，人们不喜欢限制自己，但对于限制孩子是喜闻乐见的。新增的各种 notification 的特性确实解决了各种手机打扰的问题，也强调APP不要以拉活为目的去推送消息，而是给用户带来便利和有用信息的目的去推，这些特性是以用户价值为中心去做的。

在美国电视上看到三星S9的广告，肆无忌惮讽刺老 iPhone 慢的问题，加上之前的电池门，导致 iOS12 十分重视针对低端机器的性能优化，性能优化是 iOS12 最早提到的一个点，sharesheet，keyboard打开速度翻倍这些感觉不值一提，比较黑科技的一点是，iOS12可以结合硬件，在APP启动瞬间提高CPU的性能(超频?)，提升打开速度，再快速降下去省电，这真是软硬件一体的公司才能做到的优化。

Mac 系统的升级，大篇幅讲黑夜模式，呃可能有需求的人很兴奋，实现工程可能也比较大，但感官上觉得只是个小特性。对开发者来说亮点是将在明年支持使用部分UIKit的组件去开发mac应用，这样iOS应用就可以低成本迁移到mac了。这是个大工程，目前mg游戏网站官方的股票、新闻等 APP 上就尝试用这种方式开发 mac 应用，一套代码服务iOS/iPad/Mac，用内部业务先趟坑，趟得差不多再推出，难怪今年这些APP会大更新，基础的更新需要业务的配合。

其他特性 Animoji，FaceTime，照片，siri shortcut等就不说了，各个 Session 的细节网上各种翻译文章陆续推出，我也不凑热闹了。

Lab

实际上除了第一天的总结性 keynote 必须朝圣式地在现场听，其他的 Session 分享其实完全没必要在现场，后续自行在网上听是一样的，还可以快进重复自由自在。Session 结束后也没有提问环节，所有的交流都在 lab。所以现场参加 WWDC 的重点只有两个：lab上与mg游戏网站员工面对面交流，以及认识其他开发者。我也尝试去lab问了些问题。

审核

有机会面对 AppStore 审核人员，自然要问下 hotpatch 相关的事情。

Lab 上得到的回复并不那么让人满意，主要在重复一点：不能绕过审核。但绕过审核这一点实在很难说清楚，只要有网络，一个请求字段就能改变所有功能绕过审核，没办法说某个技术能不能绕过审核，感觉她自己都绕不过来了。

在另一个较高层的会议上，提到 hotpatch 时得到很感性的答复：We don’t like it。总体听下来感觉，即使 hotpatch 在中国是个强力的需求，但mg游戏网站并没有意愿花大精力去满足中国开发者这样的需求，JSPatch 这种权限过大的方案触及安全底线，他们没法去一个个检查是否有做好安全措施，没法检查有没有审核后私自动态调用私有 API，最简单的做法就是一刀切，会一直切下去。

mg游戏网站不拒绝动态更新，只要更新的内容跟审核时的内容没有大出入，不是为了绕过审核去做动态更新就可以接受。对于各种新的动态化方案像 RN / Flutter 他们会去评估这些技术有没有风险，会不会被滥用，观察线上 APP 都用它们来做什么，再决定审核措施。

其他一些点：

1. 审核人员会根据情况对APP进行延迟审核的惩罚，目测是针对故意违反规则或连续违规的 APP。延迟的时间长度没有期限，内部怎么定的时间不透露。
2. 审核时会横向跟同个账号的其他 APP 做参考，看是否其他 APP 也有违反规则的行为，综合审查。
3. 一般非常恶劣的情况才会直接对一个 APP 下架，至少会提前一两天通知，一般不用担心审核不通过会影响线上版本。

在 facebook 交流时问了他们怎么应对需要 hotfix 的情况，他们是直接更新版本，若特别紧急的话，有专门对接mg游戏网站公司的人可以得到快速审核响应。

TestFlight

我们在公司内部做了 iOS 灰度系统，通过自己的邮箱去收集所有的 TestFlight 的邀请码，再在 APP 内直接给用户使用，做到用户不需要离开 APP 不需要填邮箱就可以参与内测，可以回收邀请码，充分利用 1w 个邀请码。这个最早是QQ邮箱的idea，我们把这个过程自动化了做成系统，所有APP都可以使用，并实现了突破1w个邀请码的限制，后续可以再详细介绍。

这个东西一直没有对外是因为不了解mg游戏网站对这种做法的看法，这次在 lab 上问了相关人员，得到的答复是这样做是没有问题的，虽然不推荐，但是是完全允许的。另外因为我们系统请求量大，他们也注意到了，也开始考虑到了中国用户不喜欢用 email，TestFlight 原生满足不了需求，于是他们推出了 TestFlight Public Link，可以不需要用户提供 email，直接打开链接就可以匿名参加内测，这个是个很好的改变。不过还没有给出具体上线时间，只是说 This summer。

iTunesConnect (改名 AppStore Connect) 这次开放了不少API，之前做灰度系统很多 API 都是自行在网站上抓包看请求去拿到，没有标准接口，经常有接口更改的风险，这次完善后持续集成会更好了，还支持了linux，不需要搞台mac机器去跑部署了。

Technique lab

跟同事一起去 technique lab 问动态库加载小概率失败的问题，现场上 github 看 dlopen 的源码，得出结论是内存不足，可能是 APP 体积过大导致，没有明确的原因，并喷了一下我们100多M的体积太大了，他们不认为一个 APP 需要做到这么大，我说 FB 更大，他说 FB 是个 bad case 不应该拿来对比，直接喷 FB 的做法非常糟糕，感觉这些专注底层库的哥们对外界业务需求不太了解。

花絮

1. WWDC 提供的午餐很黑暗，尤其是第一天的汉堡，是我吃过最难吃的，又冷又硬，令人发指。后面几天有鱼排什么的还好接受点，虽然都是冷的。
2. WWDC 周四有 bash，一个户外聚会和演唱会，效果非常赞，这次演出请了挺有名的 Panic! At The Disco 乐队，很擅长调动气氛，摇滚得很，全场很high，差不多算是 WWDC 的闭幕式了。不过有点尴尬的是因为加州九点才天黑，演唱会全程在阳光下进行，夜生活真是跟加州无关。
3. 硅谷在残障人士的支持上做得很好，WWDC 都能看到盲人参加，lab 上也有坐轮椅的员工解答问题，看到不止一个。
4. mg游戏网站的 lab 里有听过年纪较大的程序员在解答问题，目测至少50+，工作就是写代码，据了解是mg游戏网站这样的公司才会比较多，像 FB Google 这种主要还是年轻人。

五月再去了次日本，这次主要带家人去转转，非个人休闲游，角色主要是家庭服务员，还是再写写一些见闻感想。

我对三种旅游感兴趣，一是壮阔的自然风光，草原瀑布沙漠高山之类的，二是休闲度假，海边躺着的那种，三是体验不同的文化和生活方式，就是日本这种。旅游的部分意义在见识更多生活的可能性，避免在日常中碰到一些小问题就觉得是全世界，一叶障目，不过正常观光旅游只能见到些皮毛，如果找一个本地导游带领深度体验当地生活可能会好点，不过这个行业似乎还没起来。

上次是冬天去北海道，这次是夏天去关西，两次体验不太一样，这次感觉会更好一点，上次北海道没有体验到传说中的日本干净，这次体验到了，感觉很神奇，不是街道没有垃圾的干净，这种杭州也差不多，是没有灰的那种干净，路上每辆车都刚洗过的样子，房子外墙也是发亮看似不会旧的材质，地面也没有灰尘，再加上空气好，随便一个街道感觉景色都很好，即使路上铺满电线杆。不太了解这种干净是不是有日本是海岛的原因。干净的环境和空气让人感觉很舒服，加上房子都是小栋别墅，很惬意。看起来日本人是很爱干净的，但是去奈良时，看到巨多的小鹿在街上跑，人与动物和谐相处是挺好，只是动物不会上厕所，搞到很多地方很脏，也有些气味，这种情况日本人就能忍受了，感觉挺奇怪的。

日本人有礼貌这点也是体验到不少，遇到90%的人都是各种客气礼貌，走廊碰到个陌生人都点头微笑，有些不知所措，但也挺舒服，看起来是他们一贯的习惯，为什么会形成这样的习惯呢，有人说社会发达了素质提高了压力小了，这种对陌生人的和善是自然会有的，但日本压力似乎也不小，香港这个发达社会表现出来的是相反的，还是文化的因素较大。

日本守规矩到偏执的程度，也不会去想是否合理。在京都御所，入口出口在同一地方，在入口不远处看俩外国人往回走，在找出口想出去，结果被工作人员截住了，意思不能往回走，本来出口近在咫尺走几步就能到了，工作人员非得让他们按规定的路线往前走绕一整个御所走到出口，而不能回头走几步到出口，为了守规矩，让人多走十几倍的路程，也是醉了。另一个例子，很多地铁扶手电梯只站一边，人多时也是这样，导致排队很长，这做法似乎很文明合理，但是不想想为什么要只站一边，是为了给有急事的人让道，但是电梯旁边就有楼梯，有急事的人大可跑楼梯，所以这个行为一点意义都没有，单纯为了守规矩降低通行效率。

这次再度体验日本的线下支付，理解了为什么中国移动支付普及率领先世界，因为我们没有基础设施，切换的性价比很高，每个商家小贩用户有足够的动力去支持移动支付，像日本这种发达国家各种支付设施足够方便，切换成移动支付收益不高，商家用户都没有动力去换。 首先国外刷信用卡并不比移动支付慢，不需要输密码不需要签名，掏出信用卡的动作也并不比打开手机APP慢，用户能体验到的移动支付带来的便利只有少带一张卡。其次自动贩卖机特别多特别发达，各种面额纸币硬币都能用，很多饭店还有现金点菜机，替换这些机器的成本太高，并没什么动力可以把这些机器换成移动支付。同时也可以理解为什么 ApplePay 的方案是纯绑卡， 为什么一些产品不够本地化就无法推行。

在日本的时候正好 Google IO 大会在召开，公布唬人的 AI 帮你打电话预定功能，然后宣传称该 AI 在预定领域已可以通过图灵测试。同时我在日本使用 Google 翻译日文，发现 Google 把中文翻译成日文后，日本人很多情况下都看不懂翻译的结果。可能大公司要的是噱头可宣传的产品，而不是可能更有价值的对一个产品细细耕耘做到真正好用。

这次去对日本的兴趣更大一些，回来后看了些日本的资料，看起来日本不好的方面跟好的一样多，不好的主要是在日本工作生活才会体验到，像关系处理繁杂，极注重机器主义忽略个人，教条主义，歧视，失败容忍度低等，这些东西比国内的雾霾和高压难容忍多了，不知道真实普遍情况是不是确实这样。日本好的部分尽情开放给游客了，游客看到的是缺点少优点多的日本，难怪喜欢，有机会再去东京转转。

一个人做一个项目，效率是最高的，各模块间的接口，前后端联调，产品策略，视觉还原，灰度部署方案，运营方案，都在一个人脑里，各块以毫秒级速度进行沟通，瞬间能完成，这里的沟通成本是没有的。

一旦涉及到团队合作做一个项目，沟通成本就上来了，随着项目越来越大，分工越来越细，项目的沟通也细分了很多个层级，同个小团队间的沟通最快，然后是跨团队，跨部门，跨事业群，跨公司。而这里的沟通往往除了项目本身确定性的方案对齐外，更多的是其他额外的不确定因素，像任务排期（优先级不统一）、权力和意愿（不配合，层层批准）、信息不对称（不知道谁负责，不知道为什么这样做）、意见不统一等，导致沟通成本不可控，一个中大型公司很大一部分工作就花在研究如何减少沟通成本上。

技术层面上，接口封装就是减少沟通成本，省去不同模块的的开发者之间沟通细节的成本。全栈也是种减少沟通成本的方式，一个前端页面，是跟其他页面需要沟通协调的内容多，还是跟后端联调接口的沟通多？大部分情况是后者，所以如果前后端一个人做，可以省去这里的沟通成本。产品PRD/运营方案文档/统一的视觉规范等自然也是为了减少沟通而产生的。

非技术层面上，很多组织架构的调整都是在寻找减少沟通成本以提高效率，像腾讯早期各产品的交互和视觉设计由一个部门负责，其他产品团队以提需求的方式跟设计团队合作，好处是专业度高和风格统一，结果每个产品跨部门沟通成本太高，现在都改成各个产品线配自己的设计团队。对于大公司，目前看到的比较好的常见做法是，大型固定的业务成立部门，备齐所有工种人员，包括技术产品设计运营等，需求在部门内完成，减少跨部门沟通成本。各工种仍是独立自己的团队，比如技术团队/产品团队，保持自己的专业度，而做一个个具体项目时，通常需要各团队人员协作完成，可以各团队抽人组成虚拟组，配一号位人员总体负责，减少因为跨团队跨组带来的沟通成本。不过这个虚拟组和一号位人员得有组织上/实际行动保证才能起作用，否则真的是纯虚拟了，变成仍然是跨团队沟通。

一些公司的精英招聘策略也是能有效减少沟通成本，若一个人能力强工作效率高，产出能顶两个人，那实际上加上减少的沟通成本，带来的收益远不止两倍，而若招平庸或差一些的人，跟团队间沟通效率不匹配，带来的沟通成本上升效率下降也不止一个人力的范围内。一个组织大了就一定会有各种人相关的问题需要解决，精英小团队各种好，不好的是招聘困难，以及在铺业务时还是会面临人力不足问题导致扩招，难以控制。

国内厂商联合起来推出快应用，说说看法。

与小程序相同点

1. 前端技术栈：毫无疑问所有类似方案都只能是前端技术栈，从社区成熟度，开发者接受程度，开发效率各方面没有对手。
2. native 能力：都提供了比 web 更多的 native 能力。
3. 即时/离线：跟 web 一样即点即用，跟 native 一样离线使用，前提是应用不复杂，体积限制在1M以内，当然以后复杂了也可以做分包。

与小程序的不同点

1. native 渲染：快应用使用前端技术栈开发，native 渲染，性能体验会比较好，看代码挺像是直接拿 RN 改改用了，不过发布会上没提到 RN，而小程序目前是webview渲染。
2. 自定义框架和规范：与小程序不同的开发框架和规范，快应用更像 vue 的写法，文件结构不一样，样式上因为使用native渲染，只支持 flexbox 布局，CSS 属性的支持程度上不如 webview 渲染的小程序，能力会弱一些。
3. 系统级能力：目前看起来小程序没有的只有deeplink和push，通过url唤起快应用的deeplink，以及跟原生一样的push能力。

优势

1. 流量：目前看起来，对开发者来说，使用快应用最大的理由就是厂商的流量扶持，而这是不是个优势还得看各厂商的扶持力度。
2. 反垄断：小程序腾讯有绝对控制权，开发者把身家性命都放在腾讯的平台里，可能会导致任人宰割，自身对应用的控制力也弱，多一个渠道多一份活路。
3. 其他：native渲染，deeplink入口，原生桌面入口，push能力这些目前相对小程序算是有一些优势。

劣势

1. iPhone：联合再多的厂商，也联合不到mg游戏网站，中国高端手机市场 iPhone 份额高达85%，做快应用要不就是放弃这部分用户，要不就是针对 iPhone 再做一套，这个成本划不划算只能看能从厂商流量扶持里拿到多少好处，否则为什么不开发小程序。
2. 跨公司合作：一个大公司内跨部门协作都困难，何况跨N个公司的合作，而且还没有一个站在上一层的领导者，要做成非常困难。
3. 社交：快应用缺乏微信的社交场景能力和传播手段，推广拉新成本仍不低。

看法

移动开发向前端技术栈倾斜，原因：

1. 超级APP，业务越来越多，为了减体积和动态发布能力，大部分业务使用前端技术栈开发。
2. 普通APP，拉新成本高，用户装APP的意愿低，开始尝试转向即开即用的H5/小程序和类似平台拉新。

普通业务开发，按目前趋势越来越倾向前端技术栈，即使是独立APP，展示型业务在 APP 里也会倾向用前端技术栈开发，从开发效率/跨平台/动态性都很有优势，劣势是性能体验稍差，这点长期可以靠机器硬件的提升，短期可以用类似RN方案。

小程序为这样的需求提供了个很好的平台，但缺陷是开发者对应用没有控制力，无法 push 触达唤起用户，入口也一般，生命线掌握在腾讯上，快应用可以弥补这些缺陷，提供了另一个选择，不过不支持 iPhone 仍是个几乎无法解决的致命缺陷，加上上述提到的劣势，总体上不看好。这种事可能得由 google 联合mg游戏网站一起做才有戏。

native VS web 这个话题从 08/09 年开始开始到现在都没有结束，因为各有不小优势，即使是现在 web 技术栈占上风，原生 APP 的性能体验，快捷入口，品牌认知这些优势仍是不小，而且技术的发展同时给 native 和 web 两种模式提供了利好，并没有倾向其中一方：对于 web，硬件提升使得体验越来越好。对于 native，运营商无限流量的时代和越来越大的存储空间使得用户装 APP 成本下降，这两个开发模式在很长时间内仍是融合的状态。