关于苹果警告

2017-3-9 评论(34) 分类:互联网

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

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

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

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

为什么

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

可控

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

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

安全

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

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

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

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

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

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

反应

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

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

开发方式

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

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

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

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

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

滥用

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

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

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

怎么办

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

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

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

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

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

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

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

如何面试iOS工程师

2016-9-1 评论(10) 分类:互联网

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

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

项目经历

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

深入研究

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

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

整体了解

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

基础知识

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

软实力

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

其他

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

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

最后

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

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

产品杂想

2016-4-21 评论(2) 分类:互联网

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

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

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

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

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

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

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

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

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

回应一下 JSPatch 安全问题

2016-1-30 评论(4) 分类:互联网

今天收到不少人给我发这篇新闻《曝苹果应用商店逾千款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 压力的产物。

设计符合直觉的用户界面(WWDC2014 #211)

2014-7-1 评论(1) 分类:互联网

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

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

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

为什么产品设计要符合用户直觉?因为这样用户用你的APP不用学习,不用思考,可以随心所欲,用起来很爽,就会去给好评,就会有更多人使用。

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

5.平台共性 (Platform Savvy)

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

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

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

4.易于导航 (Easy to Navigate)

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

逐级前进

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

可预期

不要轻易改变用户已经习惯的东西,有重新学习的成本。例如根据使用频率把导航列表的各选项调上调下,用户体验是很糟糕的。

让选择中状态清晰可分辨

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

连贯体验

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

提供暗示

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

少即是多

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

抽屉式侧滑导航问题

优点:
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 选易读的字体,不要用乱七八糟的花哨字体。

图标

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

动画

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

2.简单 (Simple)

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

1.专注 (Focused)

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

iPhone越狱的安全性

2014-4-5 评论(2) 分类:互联网

风险

理论上iPhone越狱没有安全性可言,所有安装在你手机的APP都以root权限运行,它们可以:

1.随意读取修改系统上任意文件,获取微信支付宝等APP的数据,上传到自己的服务器保存。

越狱后所有APP都有权限访问系统任意文件,系统上APP存放目录是固定的,也有配置文件定位指定APP的目录位置,可以直接获取到这些APP的数据库等敏感文件。很多APP的数据库是没有加密的,聊天记录/邮件/日记什么的随便看。支付宝数据库倒是加密了,而且貌似有些数据不是用sqlite存储,目前我不知道能取出什么信息,这类敏感APP应该都在安全性上下了功夫的。

2.删除系统文件,导致系统崩溃。

可以恶意删除手机上任何东西,目前没见过这样病毒式的APP,反正任何APP都有能力可以做到。

3.通过Cydia Substrate插入动态库,给APP注入程序。

Cydia Substrate给开发者提供了一个方便的代码注入框架,所有cydia上的iOS插件都依赖它,一般人用来开发iOS上的插件,但也可以用它给指定的APP注入程序。开发者可以做到写一段程序,绑定一个APP,在这个APP启动时这段程序可以同时运行,并侦听这个APP的事件,或者修改这个APP里一些函数。图谋不轨的人可以用它做什么……就靠想象力了。这里有给支付宝注入程序让手势解锁失效的例子

避免

以上安全风险都基于一个前提:安装了一个恶意APP或插件。所以只要自己注意不要下载到这些东西就不会有问题。越狱后不知名的APP就不要下了,特别是那些只有盗版市场有的APP。不知名的盗版市场最好也不好用,cydia的源不要随意添加,下载插件要谨慎。

另外实际上AppStore上的APP在越狱环境下也不是绝对安全的,因为苹果也检测不到这些APP有没有做以上那些不轨之事。对于在盗版市场下载知名APP,似乎跟在AppStore上下载没区别,目前没见到有安装包被注入程序,不像Android市场。

像支付宝这样敏感的APP数据是有加密的,就算获取了也没那么容易破解。所以也不用太担心在越狱机器上用它们不安全。

虽然越狱后的iPhone有这么高风险,比Android不安全得多,但因为市场环境好,没多少恶意APP出现,所以情况还是乐观的,了解清楚情况,只要稍微注意点就没问题,至今没听说有人因越狱了iPhone损失了什么。

题外话

因为越狱后APP可以修改任意文件,所以APP也可以修改自身的启动画面,这样就做到动态替换启动画面了。有些APP在显示了启动画面后会出现广告,其实可以考虑在越狱机器上直接用广告替换启动页面,不用白白等待看广告的时间,提升体验。前段时间自选股就是在启动后出现三四秒的广告,体验极差,后来被撤下了,若是启动屏就是广告,不至于体验差到要去掉。

微信怎样保持简洁

2014-1-27 评论(2) 分类:互联网

微信已经是很庞大的APP了,功能非常多,但在产品表现上还能做得很简洁,这点挺难得,说说它是怎么做的。

渐进增强

渐进增强是web前端开发的概念,因为web前端需要兼容许多新旧浏览器,新的浏览器可以做到很炫的功能和效果,旧的浏览器做不到,渐进增强的意思是先为旧浏览器做好到基本功能,再在不影响的旧浏览器的基础上针对新浏览器做更多功能和更炫效果。

新旧浏览器类比不同用户及不同层次的需求,微信的很多功能就属于渐进增强,你只会看到基本功能,但它也有高级功能,高级功能隐藏在背后,你需要时才会看到它。如5.2新增的语音转文字,要长按语音才会出现这个功能,隐藏了入口,不打扰原有界面和交互,需要它的人用过一次就知道它在哪里。又例如拍照或截屏后在聊天框自动提醒是否发送这张图片,优化了体验又完全不影响原有功能。还有很多地方是这样的体验优化:会话的图片墙,共享地理位置,转发聊天记录,多选聊天记录删除转发,双击全屏显示聊天内容,搜索聊天记录,聊天表情,收藏,群聊,二维码扫描里的封面/街景/翻译等。

个人觉得摇一摇里的摇歌功能也可以这样做,隐藏起来,有需要的人再去开启。摇歌和摇人有不同的用法和不同的场景,现在这两个功能并列在一起,感觉很突兀,把摇一摇搞混了,多了摇歌的功能又没给微信增色,完全没必要,实际上QQ音乐做这个事更合适,而且它也已经有这个功能了,不知为什么要留恋这样的小功能。

限制入口的增加

包括限制自身和外部功能入口增加。微信至今外部功能放在一级目录的只有游戏和支付,其他外部功能都在公众号和服务号二级目录下,需要时才会推送显示,显得很简洁。对比下电脑上的QQ,按钮有多少,再看看新浪微博APP,连发微博都分了9个按钮,什么签到秒拍红包飞好友圈,眼花缭乱,另外都不好意思说微博web版了。手机QQ在抄微信后简洁了很多,但在动态里还是多了像生活优惠/腾讯新闻/热门活动/阅读中心这些入口。微信作为一个大号APP,按钮入口价值连城,能做到限制入口增加,原因是:产品地位高,不差钱,负责人有产品洁癖,负责人话语权很高。

不过这点有时做得过火了,微信5.0还是5.1的时候,聊天框右上角的魔法棒没了,变成发起聊天,魔法棒下的扫一扫移到了发现tab下,跟摇一摇放一起。可能原意是保持产品逻辑合理,第一个tab就是微信核心聊天功能,扫一扫产品逻辑上不属于这里,所以移到发现tab里,另外也遵循了“一个功能只有一个入口”洁癖原则,不再增加快捷入口。修改后扫一扫的入口等级跟原来一样,都是点一下就能看到,原先是点右上角,现在是点tab,看起来似乎没问题。但这个修改非常失败,微信花了很长时间培养大家点右上角扫一扫的习惯,这样的改变让人很不适应,另外新的入口跟摇一摇放在一起,都是X一X,很难快速分清扫一扫在上面还是下面,经常点错,体验很差,最后还是改回来了。

二维码

要让产品简洁就要隐藏或加深入口,把功能隐藏或加深又不利于推广,怎么办?二维码不仅连通线上线下,还直接解决了功能入口这个问题,真是大杀器。有了二维码,微信可以不用给公众号任何入口,就像没有这个功能一样,只要用户有需要,通过扫一扫二维码,公众号的功能就出现,十分快捷简便。二维码本身就是个大入口,微信可以让很多功能隐藏在它背后,如web微信的登录,微信支付。二维码再配合聊天框、内嵌的网页可以很容易让微信扩展功能的同时保持简洁。

阿里与微信

2013-11-29 评论(3) 分类:互联网

淘宝

淘宝近期屏蔽了微信中指向淘宝的链接,用户无法在微信上浏览淘宝,卖家无法在微信上推销淘宝商品。

有人说这跟用户和卖家的需求背道而驰,但这跟几年前淘宝屏蔽百度是一样的,流量入口不能落入另一个巨头手里,当时如果淘宝没有屏蔽百度,大家逐渐习惯在百度搜东西再去淘宝购买,百度成了购物入口,淘宝活在百度的阴影下,任人宰割。而这次微信成了流量入口,不仅如此,微信除了是入口,还控制着整个浏览过程,用户浏览过程始终留在微信里,加上微信之前屏蔽了网页中跳转到第三方APP和AppStore的功能,显示出微信对在其中浏览的内容控制权,微信不允许从微信APP跳到淘宝APP,直接把整个购物过程包在自己地盘里,比百度更狠,更糟糕的是,以微信的流量,这样下去是有可能包揽淘宝大部分移动端流量的,淘宝应该在有这个苗头的时候就掐断。

那用户和卖家被损坏的利益怎么办?同样参考屏蔽百度的举动。在屏蔽百度里,卖家少了百度过来的流量,买家无法从最常用的搜索引擎中搜索他们想买的东西,看似损失很大,实际上没什么,大家全都到淘宝去就行了。现在也一样,卖家少了一个营销推广渠道,买家无法在常用的聊天工具上分享淘宝的东西(实际上这需求不多),相信淘宝会在淘宝APP或来往上设法弥补这些损失,不过来往是不可能做起来的,完全一样的产品形态很难击败已成熟的对手,况且还是IM这种没有关系链就玩不转的东西,况且微信团队各方面都比来往团队强(从来往的结果看),阿里还不如把搞来往的精力放在支付宝的线下支付。

支付宝

关于微信支付,看了知乎这篇回答后茅塞顿开,原来微信支付有这么大的能量,但有两个问题:

1.微信支付体验很好,绑定银行卡后每次支付只需要输入六位数字,钱就直接从你银行卡飞走了,不论是支付一分钱还是几千块钱,都是这样。体验是好了,但安全和体验是相对的,安全性越大体验越差,体验越好安全性越差,不知道是不是技术的突破打破了这种关系,但就用户角度来看,多数用户会怀疑这样简单的支付流程下的安全性问题,导致不绑定银行卡,至少不会绑定主要的银行卡,用户不想绑定余下的就走不通。

2.如果支付宝做的不是担保,而本身就是银行类似物呢?那支付宝就不是一个中介了,上面的文章提到的问题就没有了,余额宝的出现会逐渐让大家倾向于把钱放在支付宝(余额宝=支付宝)而不是银行,这样实际上用支付宝支付和在微信上用银行卡支付是一样的,甚至更便捷,支付宝的转账等功能远比银行卡转账方便快捷。如果说保守的人还是倾向于把钱放在银行卡而非支付宝,那因为这些人对钱财安全的重视,同样不会去把银行卡绑定微信。

线上支付已被支付宝包揽,线下支付是支付的主要竞争点,不过这个似乎实施起来难度巨大,微信的优势在于除了支付还可以为商家提供跟客户交流的公众号,不过从微信会员卡的实施情况来看,用户似乎并不买账,如果绑定银行卡的人少,将举步艰难,相对来说更看好支付宝,不过支付宝在这方面应该加把劲才行。

题外话,如果一个拥有庞大用户量的产品可以无限延伸做什么成什么,那全国只会有腾讯一家互联网公司,微信是很了不起,但媒体对微信的吹捧太过了,微信支付颠覆了支付宝,微信电商颠覆了淘宝,微信会员卡颠覆了大众点评,微信的公众号可以灭了所有媒体,微信的服务号可以灭了APP,最搞笑的是有人说微信游戏会把APP游戏灭了。。偶然看到这篇文章,感觉挺恶心。

伊书的几次更新

2012-8-14 评论(12) 分类:互联网

6月10日发布伊书以来,至今两个多月,又发了三个版本,从1.0到1.3,算起来两三周一个版本,这个节奏还挺快的,能这么快是因为我业余时间不知道要做什么,就只能做伊书了,提交一个版本后,会马不停蹄开始下一个版本的功能,AppStore审核周期又那么长,1.1和1.2都审核了两周,一般在上个版本上架时,新版本差不多做好了,这次1.2到1.3的更新只花了两周,就是因为这样,1.2上架时,1.3已经做好了,提交审核后6天就上架了。

记录一下这几次更新。

1.1完善了书籍阅读外围的事情,如导入导出书籍,书籍来源的增加,书籍分类等。(7.14)

这些功能最大头的是书籍分类,交互上有很多要做,较繁琐,也为设置按钮的摆放纠结了好一阵,尝试了多种方式都不合适,最终还是把它从书籍列表页去掉,只有阅读页有入口。

itunes导入书籍,需要遍历文件的创建时间以筛选出新文件,找了很久获取文件创建/修改时间的方法,object-c里提供的方法没有只有这个文件真正的创建时间,没有副本创建的时间,搜索很久才找到用C语言获取文件时间的方法stat()。底层知识不熟悉的代价。

1.2完善书籍阅读过程的事情,如书签笔记,字体导入。(8.2)

书签笔记,这四个字包含的工作量太多了。书签还好,只是有点繁琐,设计上花了一些时间。笔记这功能是最难的,因为CoreText渲染出来的文本,是没有选中功能的,需要自己实现文字的选中和操作。文字的选择在1.0版本发布之前就已经粗略调研过,参考了EGOTextView的程序,当时找遍网络关于CoreText文字选择的方法,幸好有EGOTextView,否则要我全部自己研究实现,不知要多久,所以我在第一版发布时就说“enormego是天使般的公司”。在文字选择的各种细节调整上花了非常多时间,还有解决文字标记,点选标记的功能,都碰到不少难题,有的解决了,有的在可接受范围内就不解决了,在“完美”和“完成”上我有我自己的平衡点,自己做APP感觉好的地方是,这个平衡点完全自己掌握。

字体的动态导入,一开始我以为这是做不到的,在能搜到的字体导入方法中,都是字体加入项目工程一起编译,不能让用户自己导入字体。后来有网友跟我说已经有APP实现,我才知道这是可行的,几经搜索终于找到方法。有时候一些事情别人能做到,确定可行,自己才能做出来,先行者与其他人的差别巨大。

1.3支持TXT格式,图片显示,微博分享,分类密码,章内快速翻页等。(8.14)

这个版本更新的内容较多较杂。每一个功能都有点不容易。

TXT格式,我自己不怎么喜欢,用这种格式书籍排版勘误分章什么的质量不会好到哪去,只是顺便支持下。自动分章的功能少不了,阅读软件们给分章起了个更好听的名字,叫智能分章,试一下后发现只是根据第X章X卷这样的关键字去匹配分章,连第X章出现在正文中间也照分不误,很简单,不怎么智能,我也差不多是这么分的,如果有些书籍没这样的关键字分章,就根据长度拆成多个部分。TXT格式的基本阅读是没问题了,当然没达到很好的程度。

书籍内容显示图片,其实在1.2已经有这功能了,不过1.2需要epub在HTML页面里显示指定图片的宽高才能显示出图片,大多数图片还是显示不了,到1.3做了自动读取图片识别宽高,所有图片都可以显示了。除此之外做了图片的放大缩小,因为整个阅读界面的手势太多了,View的层级也很多,比较复杂,费很大劲才把图片放大缩小这功能做出来。

分类密码实现简单,但其实并没有完全实现用户使用这个功能的原衷需求:隐藏不想让别人看到的书籍,因为分类密码在很显眼的分类选择处暴露了这个需要密码的分类的入口,让别人知道了你有这么个分类不想让人看到,会逼问你密码。更好的解决方法是直接隐藏掉加锁的分类,解锁时显示,但由于这样做产品逻辑太复杂,操作交互也繁琐,纠结很久,采用这种最简单的方法,这也是一个权衡。

快速翻页这个功能我自己是不需要的,但似乎很多人都有这个需求,由于伊书内容渲染实现的方式问题,暂时没法做到全书进度条拖动翻页,所以只做了单章内的快速翻页。但这个进度条的入口要放哪里也纠结很久,对于这种(我觉得)不常用的功能,不想为它在显著位置新增一个按钮,最后很隐蔽地需要在阅读时点击中下方,它才会出现。这太难发现了,只是暂时没办法的权宜之计。

微博之旅

2011-10-21 评论(3) 分类:互联网 Tags:

从08年3月开始用微博,到现在三年半了。至今认真用了四个微博,因为不同的原因迁移。

第一个用的是饭否,微博的先驱,有感情的一个平台。可惜用了一年半后,在09年7月7日饭否被关了,被迫迁移到第二个平台twitter,在twitter上混了一年,后来政府慢慢对twitter封得越来越紧,把中文圈全干掉了,我不想折腾,迁移到腾讯微博用了几个月,后来朋友们都去了新浪微博,起初我只是在新浪微博评论他们的微博,后来就慢慢迁移到新浪微博了。

在很早我就说过,我用哪个微博平台取决于我朋友们用哪个平台,相信这是大部分人的选择方式,还有一部分是看明星在哪个微博,不过如果不是狂热的明星粉丝,开个马甲关注足矣,决定真正使用哪个平台的,还是身边朋友。

前两次微博迁移是迫不得已,最后一次是新浪硬生生把人抢过去了,平台效应已经形成了,腾讯微博即使有内嵌QQ的方便,仍比不上新浪微博。不知道在其他人群是怎样,在我所接触到的人群范围内,除了同事 (我在腾讯),其他有用微博的都是新浪微博了。感觉腾讯微博已经输了,不过我猜可能90后那些喜欢玩QQ秀的比较多人用腾讯微博,没研究。

腾讯微博的活跃用户应该远少于新浪,用户数量水分很多,甚至活跃用户的水分也很多,很多是通过Q空间和签名同步,有的是从其他微博同步过去。腾讯微博僵尸粉丝很多,很长一阵子我一发微博就被不认识的人无评论转发,而且是即刻,貌似腾讯微博没严打这些用户,在新浪微博没出现过。在腾讯微博有1000个粉丝,可能只相当于在新浪有100个。

新浪腾讯微博同质化严重,微博这样的平台不需要两家一模一样的,就像QQ。MSN和QQ不是一样的,至少MSN是有主攻市场的,但现在腾讯和新浪就是一模一样的,微博没有用户就玩不转,用户只会越来越聚集在本来就多的那个平台。

新浪腾讯微博上娱乐信息过多,互联网十几年在BBS等地方积累下来的老段子在微博上不断转来转去,重复内容很多,无营养,无意义。不是说不关注某些人就可以避免这些内容,整体氛围如此,避不了。

挺羡慕其他国家有facebook的,微博对所有人都公开,跟facebook性质不同,偏向媒体/传播,个人品牌打造,facebook偏向个人生活,有隐私设置。我发的微博大多是生活,没办法,人人网太不争气了。

饭否在刚复出的时候还好,跟几个朋友在上面交流感觉不错,但一年过去了,饭否没什么跟新浪腾讯微博差异化的举动,只是做了几个应用,不免令人失望。twitter越来越少人上了,已经成为一个高端人群的微博,没事上去看看感觉挺好的。