一些公司会采取361的绩效考核方式，即30%优秀，60%普通，10%差。

这是一个三层阶梯的考核方式，它的问题是，梯度差太大，可能会造成不公平。

一般考核者会对团队每个人的贡献度/kpi完成情况/影响力/主观能动性等因素一起综合考虑，给出团队里的人员排名，再进行评定。

假设团队有10个人，当第三名与第四名差距很小，第九名与第十名差距很小，一念之间排名就会变化的时候，就会显得很不公平。

第三第四是综合评价差不多的两个人，却划分到差距很大的两档，第九和第十同理。而且，第四跟第九本来是差距很大的两个人，却在同一档，拿到差不多的评价和奖励。

另外一个问题，如果给人打1，这个人有可能会离开，但如果你对团队较满意，在市场上都很难招聘到比团队里靠后更好的人，那就是在浪费资源。

有没有别的方法？这里的问题是梯度差大，如果降低梯度差，比如分成10档，奖金的分配可以根据排名平滑地递减下去，会怎样。

这样刚才说的那种情况，第三四名，第九/十名之间，就算一念之间调换个位置，也不会有太大影响，第三档和第四档之间的奖金分配等差距很小，而第四和第九的分配差距是明显的，整体上是相对公平的（我们假设排名是公平的）。

但据了解似乎没有大公司采用这样的方式做绩效考核，为啥呢？可能因为太温和了，不刺激，不残酷。

这样的考核方式，难以激发进取心理和恐惧心理，多劳多得，少劳少得，没什么大不了。

排名靠前没有仪式感的激励，就像体育比赛没有金牌银牌，竞争性和冲劲会减少，排名靠后没有一个断崖式的差距，让人少了恐惧带来的狂奔。

没有具体的标签，在晋升淘汰等机制上也少了参考依据。档次过多，也会让人纠结于排名的次序上，难以解释。

从大盘上来看，绩效考核是为了激励员工把工作做得更好，公平性并不是最重要的，在大环境下要想拿到最大的公平，就是避免落入两档边缘，争取无可争议的第一。

其实体育比赛/招聘/竞标等很多事物都是这样，跃迁是这个社会竞争的普遍规则。

我在 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，发展成工业化作坊才有发展的机会，此外独立开发者的孤独感强烈，估计得是强烈外向性格的人才能长期维持那种状态。

第一次去美国参加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 这种主要还是年轻人。

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

与小程序相同点

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 成本下降，这两个开发模式在很长时间内仍是融合的状态。

第一次来上海，第一次参加 QCon，说说观感。

AI

主讲 AI 的主题占到了差不多四成，虽然有主办方选题偏向的因素，但还是能说明 AI 的热度确实很高，是当前最火热的技术领域，火到感觉我作为客户端开发，再不学AI就要失业了。虽然有些虚火的嫌疑，但AI相关技术确实是解决了不少传统做法难以解决的问题。

开场危辉教授讲述人工智能这个概念的历史，表示目前人工智能能解决的问题仍只是在一些有限场景下有一些进展，只能解决一些明确的特定的问题，像取得突破的围棋只是因为它是规则简单边界明确的特定领域，但真正的通用人工智能关键的几个问题一个都没有解决，过去二十年人工智能流行过很多技术，连当年OOP面向对象都被认为可以实现人工智能，而现在流行的是深度mg游戏平台官方网站，有人说下一个流行的会是量子计算，人工智能就像一个圣杯，大家一直用各种技术方案在追逐，目前大家觉得接近了，但实际上我们离真正的模拟人脑能解决通用问题的人工智能还差得很远。

教授是从学术界的角度，从准确的定义上去说人工智能，当然没有错，但实际上一个流行词汇，很可能跟它实际所指的事物并不完全相符，只是方便炒作或方便理解。例如共享单车不是真的共享，HTML5不是HTML一样，现在流行的很多场景下说的人工智能也并不是真的指可以代替人脑解决通用问题的人工智能，主要指靠各种机器mg游戏平台官方网站算法去解决一些特定领域的传统算法难以解决的问题，例如图像识别分类，自然语言/语音识别，兴趣推荐等，查了下业内对这些应用还有个稍微准确点的称呼，叫弱人工智能(弱智???)。从业人士应该不会弄不清楚，也就一些媒体忽悠大众哗众取宠的时候弄混。

会场上听到很多 AI 的应用，paypal 用它做反欺诈反洗钱服务，微博用来辅助检测恶意用户，流利说训练出适合中国人口音的英语发音打分模型，腾讯用AI+ROI把视频编码带宽降低20%，也做了AI自动裁剪视频生成短视频，Pinterset 做推荐系统和拉活，QQ邮箱用来优化文档边缘识别，等等，有些公司已经以AI为中心为业务提供各种支持，给人感觉产品要是不结合AI做点什么都不好意思拿出来说，真有一种拿着锤子四处寻找钉子的感觉。

我还没有实践过 AI 相关项目，听这些主题有些尴尬，只有笼统的观感。个人感觉，程序员就算不投身 AI 领域，也应该要了解下 AI 相关技术，了解在现有技术下的 AI 能做什么，毕竟它的套路跟传统确定性算法不一样，了解了才能在解决自身业务问题的时候多一个思路。现阶段的 AI 虽然没达到可以解决通用问题的程度，但对于那些定义和目标明确的问题都是可以或者说有希望解决的。

AI First

有公司已经从 Mobile first 转为 AI first，iPhone 刚出来前几年，大家对移动端还算挺重视，各个大公司会成立移动事业群/移动部门/移动组，一小拨人专门开发各个业务需要的移动产品，后来移动端越来越受重视，变成 mobile first，不再是专门一群人开发各个业务的移动产品，而是每个业务都自己组建移动端团队，移动渗透到公司每个团队，才能跟上时代。现在 AI First 也是有这样的感觉，现在还处于一个公司里一小拨人专门在做 AI 相关的工作，后续可能会发展到每个业务团队都需要具备 AI 的研发能力，AI 渗透到每个业务团队，才能应用 AI 技术去结合自身业务实现价值。

智能音箱

阿里分享和宣传了 AliGenie，AliGenie 类似 Siri，自然语言处理开放平台，目前应用在智能音箱天猫精灵上，类似 Homepod，以及接入阿里智能硬件，类似 Homekit，真是跟mg游戏网站干上了。

说说个人看法，智能音箱被认为可能是下一个入口，语音不仅包含的信息丰富，还解放了双手，相比键盘/鼠标/触摸灯方式，很多场景下效率提升很多，方便快捷，用户习惯养成后，用户可能越来越多使用智能音箱去完成需求和触达信息，可能用它来购物/支付/打车/听新闻等等，成为下一个入口。看起来确实是很好，但语音助手 Siri 推出到现在已经七年，到现在还没有成为主流，身边使用的人很少，智能音箱会有戏吗？虽然语音很方便，但有两个致命缺陷，就是暴露隐私和骚扰旁人，很多场景下这个缺陷大过带来的便捷性，也就很难去使用和形成使用习惯。若要让语音助手成为入口，需要找到特定的应用场景才行，个人觉得汽车内较有机会，因为多是独处时间，没有隐私和骚扰的缺陷，眼睛和双手被霸占，空间也有限，不会有接收不到或要吼的情况，而面向家庭的智能音箱就难了。

AR/VR

VR 研发热度一直没有火起来，感觉现在做VR有点像功能机时代做手游，硬件环境没跟上，时机还太早，现场只有腾讯分享了下VR的探索，用于做身临其境的游戏直播体验。

AR因为mg游戏网站和谷歌相继推出 ARKit 和 ARCore 又受到关注，不过这次分享都没有这两者，AR 的应用稍微多一些，因为手机上就能实现，不用像 VR 那样主要靠硬件，阿里对 AR 的探索较多，从小游戏到图书增强到家装应用到开放体系，走得很远，在营销上已经有不少应用，不知道数据和效果怎样。

腾讯分享的云游戏是另一类前沿研究，通过视频回传游戏画面，随时随地只要有屏幕和网络就能玩任意游戏，也处于探索阶段，带宽成本高，解决延迟问题较困难，短期内没看到应用的前景，可能可以作为游戏试玩的方案。

前端/客户端

前端和客户端各只有4场分享，在整个QCon一百来场分享里占比可怜，真是药丸。当然技术媒体是追逐热点的，感觉这次追得有点过了，从旁人的反应来看效果不太好。

淘宝分享超级 App 的高可用性保障，也就是保障性能稳定性一整套系统，这块各个大APP都有自己的一套，趋于成熟，淘宝做得更细致些，除了性能数据的采集/监控和展示，也尝试在内存泄漏/资源泄漏/大图异常/线程异常等一些特定的问题上提升问题排查效率，通过记录堆栈追踪问题的来源，例如记录图片/线程/资源是在哪里创建的，从而能快速定位原因。为了解决一些很难排查的疑难杂症，做了更细致的追踪体系，毫秒级记录CPU/内存/存储，追踪方法调用和页面事件，收集数据后再通过分析引擎对比分析。

前端有两个新事物的实践分享，WebAssembly 字节码技术，饿了么于航实践和深入了解后表示 值得关注/标准未定/实践略坑，各大浏览器在实现的路上，短期内还没法用到生产环境。QQ 空间实践了 QUIC 协议，基于 UDP 改进的通信协议，解决 TCP 成为网络传输速度性能瓶颈的问题，目前应用上还有一些坑，用户的网络环境中 UDP 的端口可能会被禁，可能会被限速，也可能丢包率有异常，有些风险，另外目前移动端浏览器都不支持 QUIC，PC端只有少量个位数比例的用户支持，应用还不广泛。

前同事冯牮分享了在QQ邮箱客户端上实现 AI 辅助文档边缘检测。事先针对特定的问题，在后端训练出一个模型，再放到客户端上使用，使客户端本身具备 AI 的能力，这可能是客户端开发后续的一个方向。现在的应用场景是针对一些实时性要求高的，无法回传到后端进行计算的应用，像文档的边缘检测，以及支付宝出的扫描识花的功能，都是这种类型，其他的应用方式大家还在探索中。

其他

蘑菇街侯栋分享的关于黑产的攻防和产业链介绍挺有意思，社会上头脑灵活的人很多，有利益有漏洞就会被人钻，账号会被批量注册，有的用于刷单提升店铺销量信誉，有的通过批量退货赚取退货险的运费差价，有的配合假快递单号套取货品，惊讶于有人为了能套现电商信用卡的钱愿意付出30%的手续费，跟这帮人猫捉老鼠挺有趣的。

区块链有两个分享，都是宣传自家区块链云平台，云服务这个金矿也挺热的，只要自身搭建稍微有成本，就立马有人做出云服务（广告：JSPatch平台也算是热修复云服务）。粗略听下来只能知道区块链可以用于解决信任问题，有些数据放在一家公司里可能会被篡改，不受信任，用区块链可以解决这类问题，应用是可以很广泛的，我没完全搞懂区块链原理，就不多说了。

最后

去年参加 GMTC 有提到过对这种技术大会的看法，这种大会对广大技术人员自然是好的，各界讲师有动力精心准备演讲主题，输出很好的技术分享，但从参与者角度来说，如果单纯去听其实没什么用，时间成本高，单向分享也学不到什么，还不如后续看PPT和视频，参加线下分享会议最主要的还是面对面双向交流的机会，最好能看准人和主题和人，准备好具体问题过去交流，否则参加这个会议跟后续网上看PPT和视频唯一的区别就是更耗时间。

过来参加的大多是一线工程师，目测大部分是传统客户端/前端/服务端开发，而 QCon 的定位高端，现场听到不少人反馈听不懂/离实际太远/太高大上，也可能是AI的主题太多导致。从会场人数来看大伙喜欢听实践踩坑类接地气的主题，毕竟现场的CTO和架构师占比不会很高。本次 QCon 前端客户端相关主题太少，跟上一场 QCon 差别很大，导致作为客户端开发参加起来有些尴尬，希望下场选题上能再平衡下，祝 QCon 越办越好。

昨天早上 iOS 开发者们陆续收到mg游戏网站邮件，警告去掉动态下发功能，覆盖面很广，内容没有明确指示是什么库，导致大家各种猜测。

其实上周已经有少量用户收到mg游戏网站这份警告邮件，当时还以为是特例，现在看来是在灰度测试扫描代码，可见这事mg游戏网站应该讨论已久，并专门排期开发测试了扫描程序，直到昨天才正式上线。

从各方信息看起来，很不幸主要禁的还是 JSPatch / wax/ rollout 这样的热修复框架，特点是可以通过 JS 脚本调用和替换任意 OC 方法，而像 React Native/ 小程序这样用 JS 做功能的暂时不受影响，Weex 不确定，至于其他库像 AFNetworking / SDWebimage 用到那几个接口的，应该只是误伤。

根据mg游戏网站要求，收到警告的同学只需要在下次提交版本时去掉相关框架就可以，没有时间期限，目前也不会强制下架。

为什么

mg游戏网站为什么这么做呢？mg游戏网站对热修复一直以来的态度都是不赞同也不拒绝，JSPatch 本身也并没有违反开发者条例，而且 JSPatch 大多数都用于修复 bug，提升 iOS 平台 App 的质量，对mg游戏网站也是件好事，为什么要禁？猜测原因有两点：可控和安全。

可控

mg游戏网站一贯作风是让所有事情可控，开发者能用什么不能用什么都尽量在自己的控制范围内。大多数人使用 JSPatch 修复 bug，或者弄一些临时运营的小功能配置，这些没有问题，但总会有少数用户使用 JSPatch 去调用私有API做些事，这是mg游戏网站不可控的，也无法知道有多少人这样做了。

不过其实在代码这块mg游戏网站其实一直可控程度有限，他会在提交时扫描你有没有用某些私有方法，但只要你对这些私有方法调用做一些变化，加解密字符串拼接什么的，就能绕过扫描，再通过后台配置调用，是一样的。JSPatch 只是让调用私有 API 变得成本更低更方便点而已，可控这里只是个小理由。

安全

去年 FireEye 分析了使用 JSPatch 的安全问题，当时我也写文章回应了，再复述一下，主要安全风险有三点：

1. 开发者自己本身对 APP 下发恶意代码。
2. 开发者没有做好加密传输和校验。
3. 开发者接入的SDK里接入了JSPatch，SDK 作者可以对这些 APP 下发恶意脚本。

第一点其实不算安全风险，因为开发者自己有恶意的话完全不需要借助 JSPatch。

第二点大多数用户使用 JSPatch 时都做好了非对称加密，保证不会在传输过程被第三方篡改。但这里技术上没法保证用户一定使用正确的加密方式，mg游戏网站无法知道有多少接入 JSPatch 的用户没有正确加密和校验，这是未知的安全隐患。

第三点在当时并没有什么第三方 SDK 接入 JSPatch，但现在像高德地图/个推等都接入了，如果他们要作恶，或者他们本身服务端被入侵，确实是个安全隐患。

iOS 平台是最安全的，也是最注重安全的，即使热修复带来了 App 质量更高的好处，也无法无视这里的安全隐患，现在 JSPatch 国内覆盖面很大，若出一个安全问题，会影响 iPhone 的声誉，因为这个风险，所以考虑禁掉。

反应

这个警告出来后，国内开发者有各种反应，各种表情贴图还挺搞笑的，不过大家放心，JS没事，iOS 开发该失业的还是失业:)

看到有一些人拍手称赞，赞的理由不是说mg游戏网站维护了平台安全，而是：1.国内开发方式low，2.产品经理滥用。这里我有一些想法说一下。

开发方式

他们说国外开发不理解国内为什么要用热修复，国外很少使用，国外开发流程很好很规范，会做好充分的 codereview 和测试，上线后没什么 bug，不需要热修复，也不会有产品经理乱提需求，迭代没像国内这么快，使用热修复是本末倒置，不去考虑提高 APP 质量，国内开发方式太 low，国外的才是正道。

这里有个问题，就是什么是好的开发方式？以什么标准界定？上面的说法可以看出他们是把工程的严谨性，流程的规范性作为好坏的依据。虽然我是个程序员，觉得工程严谨和流程规范确实是好东西，但我比较实用主义，更倾向于以结果作为标准，也就是能不能更低成本更高效地开发出质量更好的产品作为标准。

如果我使用热修复能以更低的人力成本（工程师能力和薪水不如国外，人数少），更高效（测试时间缩短，不需要覆盖到0.01%几率出现的 bug / crash ），做出质量更高的产品（ bug / 特殊情况和需求反应速度快），为什么不是一个更好的开发方式呢？

另外客户端的开发方式本身就是落后的，不利于快速迭代，无法对线上产品有控制权，参考另一篇文章。这也就是为什么 Facebook 一开始要用 web hybird 的方式开发，现在又要做 React Native。热修复是这种落后开发方式的弥补。另外我没在国外公司工作过，但感觉他们对bug的容忍程度还是比国内高的，对比一下 IAP 和微信支付的失败率，做过的人都知道。

还有一个声音说国内的人喜欢违反规则，钻空子太不老实。首先前面也说了热修复的方式并没有违反规则，完全符合开发者条例，其次国外也有热修复 rollout，最后如果从开发者条例来说，React Native 反而是违反规则的，因为主要用途动态添加和修改 APP 的功能。

滥用

另一个说法是上了热修复后产品经理来劲了，产品时不时想到一个功能配置说上就上，开发者弱势只能跟着上。

这种情况在我这边团队还没遇到过，我的想法是：如果要上的功能配置对产品是有好处有必要的，开发维护成本又低，为什么不上？如果要上的功能配置是无关紧要的，或者开发维护成本太高，为什么不能讲理拒绝？

开发者把原因定位为自己“弱势”，就把自己从团队剥离开了，变成对人不对事，这种团队氛围是挺糟糕的，而这个锅也不是产品经理的。大家做的事都是为了产品更好，应该不会有那么多故意刁难不讲理的产品经理和老板。至于怎样界定对产品有没有好处和有没有必要，以及开发成本高低，这得自己协商了，以我们团队的做法是以做这个事的性价比计算。

怎么办

接下来如果还想用 JSPatch 怎么办？我没有跟mg游戏网站审核团队交流过，不知道他们的想法，短时间内是先不要用，后续再看情况。

热修复的需求很大，很希望mg游戏网站可以推出自己的方案，由系统做这个事是可以保证安全的，但现在看起来可能性较低，国外需求量不大，mg游戏网站也就不会重视这个需求，何况目前在大力推 Swift。

对于 JSPatch，mg游戏网站应该是扫描可执行文件里的关键字，从技术上说是很难禁掉的，可以做各种混淆去绕过检查，但若下发时被查到，会有政策风险，政策有待观察。

实际上动态化还是处于灰色地带，严格来说 RN 是不符合规则的，但还是被允许，只要不给mg游戏网站添麻烦，mg游戏网站就不会管，JSPatch 因为上面提到的两点风险被管了，怎样做到使用并不给mg游戏网站添麻烦呢？

1. 减少自行接入的使用人数。
2. 禁止 SDK 接入。
3. 接入保证传输安全和只用于修复 bug。

第一点警告邮件和代码检查使得自行接入 JSPatch 门槛变高了，显然会减少使用人数。第二点第三点只要有一个平台来管控，由平台保证安全性以及扫描下发的脚本，禁止私有API调用，禁止大量脚本下发，是可以做到的，可能的话希望能跟mg游戏网站审核团队协商。

附上 JSPatch 平台初定的解决方案。

参加了内部面委会的一个分享，结合我自己的方式，说说怎样面试一个普通的iOS工程师。

一般我倾向的考察分两个主要的部分，第一是在简历里提到的项目经历中找挖掘点，第二是基础知识考察。另外也会看情况做一些软实力的考察和性格特征的判断。

项目经历

如果顺利的话这第一步占的比例会很大，因为每个程序员都不会方方面面知识都熟悉，但至少他写在简历上的做过的项目是熟悉的，讲自己熟悉的东西容易让他进入状态，展示好的一面。这里主要考察两方面，一是有没有在某些点上有过深入研究。二是对项目整体了解如何。

深入研究

在中大型的公司里比较注重工程师有深入研究的能力，如果能把一个功能讲得很清晰是比较好的加分项，这里会问实现的思路，通过追问去了解候选人在这块深入的程度，从思路到方法，从上层API调用到框架流程再到底层实现。如果候选人在讲述时有一条逻辑主线，例如讲述业界普遍是怎么做的，自己在业界方案基础上做了什么改进，怎样做到更好，进一步改进的思路是怎样，这是最好的。如果还能把解决问题的方法归纳起来运用在其他地方，能举一反三，包装成通用解决方案，或者做开源贡献，就更好了。

一般会问候选人哪一个项目技术点最能体现自己的技术，然后不停追问技术细节，例如做了一个相册项目，觉得列表优化是最能体现技术点的，会问这里优化的思路是什么，怎样评估，遇到过什么困难，怎么解决的，如果用到图片缓存开源项目，说说它具体做了什么事，缓存策略是什么，从下载到显示的整个流程是怎样的，还有没有更好的方案，追问到一定程度后也会发散去问跟这个话题相关联的问题，例如如果有部分用户反馈图片显示不了，你会怎样排查问题，排查修复后怎样监控，就会过度到一些网络和运营监控方面的内容，也会顺便问到一些基础知识。

整体了解

问完自己职责范围内的功能技术点后，还会看看对项目里其他的实现有没有了解，特别是项目的大致架构和核心功能，最好能画出项目大致结构，看情况问问网络层和数据层是怎样实现的，为什么这样实现，项目最核心功能是怎样实现的，例如做读书的至少要知道项目里的排版引擎的大致实现方式，做QQ的要知道消息收发的机制，如果不知道，也可以说说如果自己实现会怎么做。这里主要看看有没有技术好奇心，会不会积极主动了解项目里已有的非职责范围内的技术点，主动和好学这两点是很重要的。

基础知识

如果项目经历里能问出大部分东西，这部分比例就会比较少了，这是比较好的情况，否则就按套路去多考察一些基础知识，包括iOS开发的基础和计算机基础，像内存/网络/存储/线程等，例如 ARC 是怎样做到自动管理内存的，跟java/js的垃圾回收的区别，网络http协议是怎样的，用过什么数据库框架，db索引是什么，多线程开发要注意什么，跟runloop的关系是什么等等，这类问题在网上都有很多，就不多说了。数据结构和算法在笔试时会涉及，面试会比较少，如果问算法的话只会问问思路，一般我觉得如果项目经历方面不太好，才会考虑考考算法作为辅助判断。

软实力

一些通用能力像逻辑思维能力，沟通能力，自我驱动能力等都可以在上面那些问题的交流中表现出来，另外像团队协作能力、抗压能力和性格特征这些也会看情况考察一下，例如问问如果产品让你做个需求，你觉得不靠谱，会怎样做，设计让你做个很难实现的效果，你会怎样评估？或者问个低级问题，故意说个错误的答案，看看他的反应是怎样，是表现出嘲笑和攻击性，还是怀疑自己，还是细心求证。抗压能力的考察有些人比较喜欢，我是觉得面试还是轻松一点好。软实力方面的考察在一面会比较少，或者不会涉及，实际上这方面我也没太多经验，也在摸索中。

其他

作为程序员，如果有 github 开源项目是最好的，直接可以看到代码风格，代码质量，处理 issue 和 PR 的方式，如果有技术博客也是很好的，可以提前看到平时的一些技术积累，省了很多事。但如果 github 内容是培训班的那种仿写APP，博客内容是摘抄文章什么的就是负分了。

以上是正常套路，若候选人有特殊经历或技能，例如牛X大学毕业，ACM冠军，通读linux源码，php源码贡献者之类，会另当别论，针对性进行面试，这不是唯一的标准。另外针对不同的工作年限也有不同的问法和要求，工作年限越高要求越高。

最后

其实面试就是想低成本找到合适在团队里一起工作的人，因为如果通过一起工作一段时间去判断是否合适成本太高。这种低成本的代价就是会误判，有些工程师是理论型，有些是实践型，面试的方式会对实践型的人不利，尽管他们如果招进来会是适合的人，而且人会在不同环境下会有不同的表现，只根据过去的经历去判断有时是不准确的。只能尽量采取一些措施去减少误判的概率，例如提高面试官的判断能力，或多几轮面试。一般如果不是急招，策略都会是宁杀错不放过，所以其实就算面试被否了，也不一定代表能力不行。

另外每个面试官可能都有自己摸索出来的一种判断方式，并随着面试经验的丰富不断改进，达到更准的判断概率，这只是我个人在目前有限的经验里的一点小总结，仅供参考。

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

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

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

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

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

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

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

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

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

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

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

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

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 压力的产物。

看了WWDC2014 Session 211 – Designing Intuitive User Experiences，觉得挺不错，写下笔记。

–

用笔写字这个技能是我们从小就开始一直锻炼的，刚开始我们写得乱七八糟，后来慢慢变好，在这个训练过程中，书写这个技能已经变成肌肉记忆，在书写的过程中完全不用去思考，不会去注意到是怎样书写，怎样握笔，用了什么笔什么纸，一切都在无意识中完成，书写这一行为已经成为直觉。熟能生巧，这就是直觉的来源。

直觉是训练出来的，专业技能的直觉普通人是没有的，飞机几百个按钮飞行员可以不假思索找到需要的按钮，普通人不行，因为你可能有着别人没有的直觉，所以若纯粹按照你自己的想法做产品，可能会让部分用户用起来感到沮丧，你需要站在用户的角度和情景去设计，了解他们知道什么，不知道什么，直觉是什么。（按国内的说法就是让自己进入小白模式）

为什么产品设计要符合用户直觉？因为这样用户用你的APP不用mg游戏平台官方网站，不用思考，可以随心所欲，用起来很爽，就会去给好评，就会有更多人使用。

–

设计符合直觉的产品，有5个特点。

5.平台共性 (Platform Savvy)

世上有数不清的各种笔，但你知道他们都可以用于书写，你会用同样的握笔方式，书写方式使用它们，这是笔的平台共性，对一个个体的认识可以延伸到同一平台上其他相似物的认识。

iOS平台上有很多这样的共性，例如在iMail列表里，向左滑动会出现删除按钮，一旦你知道了这个操作，在iOS上其他APP的列表里，你想删除其中一项时你会尝试左滑，预期中它是应该会出现一个删除按钮的，如果没有出现，用户会觉得很沮丧，出现了会觉得很爽很流畅。如果你在一个平台上做的东西不符合这个平台的共性，用户就会觉得你这个APP很奇怪。

建议用iOS平台约定成俗的东西，例如返回按钮位置，按钮点击位置，图标大小，图片缩放等等，这样用户没有mg游戏平台官方网站成本。如果你想打破这些规则，做标新立异的APP，那你需要通过各种途径告诉用户。

4.易于导航 (Easy to Navigate)

1.告诉你现在你处于APP的什么位置。Tab Bar标签/Navigation Bar标题都是干这事儿的。
2.告诉你还能去哪里。用tab bar的优势是把你能去的地方全列出来了。
3.告诉你去到那个地方会有什么东西。把一堆功能分成清晰的几类，让人能从分类中就大概知道那里有什么。

逐级前进

在用户真正需要一个功能之前，不要把这个功能展示给他。可以通过加深分类层次做到这点。虽然这会增加用户选择点击次数，但如果分类清晰，用户不用思索就可以找到他想要的功能，这是更好的体验。

可预期

不要轻易改变用户已经习惯的东西，有重新mg游戏平台官方网站的成本。例如根据使用频率把导航列表的各选项调上调下，用户体验是很糟糕的。

让选择中状态清晰可分辨

Tab Bar的选中状态应该做成什么样？若是仅仅换个颜色，并不够突出选中状态，iOS的做法是把图标填充满，再换显眼的颜色。做选中状态的原则是，要让图标不换颜色时，用户都能隐约分辨这是选中状态。

连贯体验

iOS里相册点击一张图片，图片是从原来的位置放大的，让你确认点击的就是那张照片，返回也是，从大图缩回小图，让你知道这张图片在你缩略图列表的位置。若点击图片然后从右滑进一个大图则没有这种连贯的体验。

提供暗示

一些不易发现的交互方式要提供足够的提示。举例一个星辰APP，点击星辰本身不会去到详情页，要点旁边的(i)按钮才会，但点击星辰会让i按钮闪一下，表示可以点击这里。

少即是多

提供更少的选择，会让更多的用户去选择。若选择多了，用户不知怎么选，反而不选了。在mg游戏网站和梨中选一个很容易，在很多种水果中选一个很难。

抽屉式侧滑导航问题

优点：
1.不占用屏幕空间，省去了Tab Bar的空间
2.导航栏位置大，占满屏幕，甚至可以上下滑动

缺点：
1.无法解决上述“我在哪里”“我还能去哪里”这两个问题。导航被隐藏起来，不像Tab Bar一直在那里，让用户知道自己在哪里，还能去哪里。
2.切换点击次数多。Tab Bar只需要一次点击，瞬间去到目的地。侧滑需要点击汉堡图标，等动画做完，再选择目的地，再等动画做完，效率低。
3.要占用Navigation Bar一个按钮的位置。放左边会跟返回按钮冲突，一般解决方法是返回到最上级才出现这个导航图标，这是不好的体验。若导航按钮放右边，右边就不能放一些iOS上习惯放的按钮，如编辑，分享等，导致用户体验很怪。
4.侧滑导航把很多不常用的东西都放进去了，显得很杂乱。

3.清晰 (Clear)

语言

No big words 不要用晦涩的词，用所有人熟知的词。
Avoid jargon 不要用专业术语，除非你的用户群是专业人士。
Be descriptive 用语义清晰的词
Be succinct 简洁
Avoid truncation 避免句子太长被系统用省略号截断
Make text legible 选易读的字体，不要用乱七八糟的花哨字体。

图标

用大家都熟知含义的图标，例如信息图标和搜索图标。
用跟现实中大家熟知的物品形状相近的图标，如闹钟图标。另外别以为软盘是大家熟知的物品。
不要用一个图标代表不同意思，例如用搜索图标代表检查。
图标是不能被用户mg游戏平台官方网站的。
图标是很小的，避免用复杂的图形，不然缩小了不易辨识。

动画

有时用动画可以清晰引导用户。如iOS相机的聚焦，首先聚焦框从大到小缩放到聚焦位置，让你注意力集中到这个聚焦框上，然后框闪了两下，提示你聚焦已完成，可以拍照了。
另一个例子是锁屏输入密码，若输错密码，四个密码原点会跳一下，可以让用户很直观地知道密码错了，而不用去读文字。

2.简单 (Simple)

不要做一个复杂的APP，繁杂的功能会把真正用户需要的功能掩盖隐藏在深处（不适用于中国）。不要给用户一些他们不需要的功能（或者是80%的用户不需要），过多的功能让用户分心，难以找到他们想要的东西。

1.专注 (Focused)

一个APP应该专注做一到两件事。小而美，打磨精品，为用户提供最好的解决方案，才能在120万APP中脱颖而出。