30岁

2018-11-30 评论(1) 分类:随记

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

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

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

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

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

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

杂想

2018-10-31 评论(2) 分类:随记

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

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

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

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

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

如何在 AppStore 上赚钱

2018-9-30 评论(3) 分类:互联网

我在 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 的搜索规则时刻在变,在我运营期间有好几次因为搜索规则变化导致收入突降,现在的搜索规则估计连在苹果开发 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,发展成工业化作坊才有发展的机会,此外独立开发者的孤独感强烈,估计得是强烈外向性格的人才能长期维持那种状态。

闲聊 Flutter

2018-8-27 评论(5) 分类:技术文章

移动端开发从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 简单得多的引擎,源码很值得挖掘学习,现阶段国内关注 Flutter 也是学习居多,直接使用 Flutter 目前吸引力还不够大,但国内可能有另一个利用 Flutter 的途径:小程序。Flutter web 引擎简化中来,使用的也是 CSS flexbox 布局,但抛弃历史包袱重定规则,不兼容 web 也不是 dom 那套玩意,需要上层业务根据新规则限制写法,而小程序就是这样的限制框架,可以参考 Flutter 构建小程序渲染引擎,相对于 web 渲染性能好,相对 RN 渲染,同渲染引擎坑少,无需维护两个平台框架。可行性待研究,算是一个有趣的课题。

美国见闻

2018-7-30 评论(5) 分类:生活

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

加州

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

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

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

WWDC 2018 见闻

2018-6-13 评论(1) 分类:互联网

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

Keynote

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

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

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

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

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

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

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

Lab

未标题-2

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

审核

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

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

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

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

其他一些点:

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

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

TestFlight

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

这个东西一直没有对外是因为不了解苹果对这种做法的看法,这次在 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 的做法非常糟糕,感觉这些专注底层库的哥们对外界业务需求不太了解。

花絮

未标题-3

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

再游日本

2018-5-27 评论(4) 分类:生活

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

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

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

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

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

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

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

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

沟通杂想

2018-4-22 评论(2) 分类:随记

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

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

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

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

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

对快应用的看法

2018-3-21 评论(8) 分类:互联网

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

与小程序相同点

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

看法

移动开发向前端技术栈倾斜,原因:

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

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

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

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

北海道杂记

2018-2-25 评论(6) 分类:生活

过年前去日本北海道浪,说了三四年要去日本,这次终于成行了,第一次去日本,写篇体验杂记水文。作为一个从小受日本动漫和游戏熏陶的人,本来想去东京秋叶原这些地方,季节原因还是先去北海道转转。

北海道玩的就是雪和温泉,在登别玩白花花软绵绵厚厚的雪,走在洞爷湖边上纯白的湖畔小道,在札幌白色恋人公园体验大雪纷飞,确实都挺美的。北海道温泉特别多,连札幌市内的酒店都有温泉,不过还是登别的温泉最好,在室外天寒地冻边泡温泉边欣赏旁边雪景是挺不错的体验。不过温泉只能全裸不能穿泳衣导致必须男女分浴这点搞得挺没意思。
(更多…)