IT瘾app推荐

案例拆解|T3出行用户激励体系

Fri, 29 Apr 2022 17:16:43 CST

导语：本文是产品的用户运营体系拆解案例，通过分析了业务模式、激励体系，详细拆解T3出行App的用户运营体系，推荐对app的用户运营体系拆解感兴趣的小伙伴阅读。

一、T3出行的现状及业务模式

T3出行作为一款打车软件，是用户日常使用频次较高的产品。其作为平台方，连接用户和司机，承担派单、导航、收款、客服等功能。

在疫情压制需求、出行服务平台竞争加剧的情况下，T3出行快速抢占市场， 订单量1月同比 增速144.6%（滴滴-8.9%，曹操出行+106.3%，美团打车+39.1%）； 市场占有率大幅提升，自7月的3.1%快速提升至1月的 11.6%，同比提升8.5pct份额； 活跃用户数1月同比 +103.8%（滴滴-35.6%，曹操出行+31%）。

*数据来源：国泰君安证券《2022年1月出行服务平台数据跟踪》

T3出行主要的业务模式有：

用户端：

1）个人用车：即时叫车、预约叫车、接送机、代叫车

2）企业用车：预付返现、授信结算

司机端：

1）带车加盟：无租金，抽佣

2）无车加盟：有租金，抽佣

3）出租车加盟：无租金，抽佣/服务费、

对T3出行而言，高价值的用户行为包括：

1）消费：频次＞单价

2）参与活动：签到、完成任务、积分兑换等

3）邀请好友：好友注册、首呼、首单、登录APP

由此推测，对用户运营而言， T3出行的核心运营目标为：

1）提升用户留存

2）提高用户ARPU

围绕这两个核心目标，T3出行建立了 自己的激励体系，本次拆解也以此为重点。

二、T3出行的用户激励体系

1. 免费会员成长体系

会员免费自动开通，按实付金额计算成长值， 3个月为一个会员周期，期间达到升级要求可升级，期满可能保级/降级。

T3的会员权益设计比较简洁实用，其中最核心的是 T币加倍、免费取消、优先派单，这几点已经能很好的满足围绕打车产生的核心需求： 便宜（更多积分能抵更多钱）、免取消费、减少等待时间，其中T币加倍结合积分体系，能增强用户感知，有效提高用户粘性。

另外，T3出行在设置会员保级的时间内，也是非常值得思考的。它没有像很多低频类的产品，比如携程，支付宝等平台的免费会员体系一样，设置的是一年的保级有效期，而是根据目前它产品的使用频率，设置的是3个月的有效期。猜测是， 这些免费会员的权益存在一定的成本，在产品的使用频率内，若用户没有再次回流，也就意味着对产品没有利润的贡献，则不能再享受这些会员的福利。

另外一个角度，大概是当用户发生降级行为时，也会持续给用户一些激励，让用户珍惜自己的会员身份而在平台上持续产生消费。

2. 积分体系

T币作为T3出行的积分，有以下几种获取与消耗方式：

在此浅算一下签到这个动作的价值和对应的 激励定价：

签到这种行为无疑能提高用户留存，但如何让用户提升留存的同时提升付费，也是比较关键的事情。

在T3出行的情景内，如果一个用户连续签到满7天，即使手上没有数据，也能大胆推测该用户本周至少会消费一次。而连续签到7天的奖励是10*6=60T币+5元优惠券，折现为60/50+5=6.2元。

假设平台抽佣20%，则用户消费的这单需要达到6.2/20%=31元，平台的此次激励才不亏。

以T3的计费规则，31元大约是7.5公里、15分钟左右车程，这个距离是比较常见的通勤距离，虽然无法确认平台的实际平均订单价，但推测这个金额还是比较容易达到的，更何况用户很有可能消费多于一次。

3. 限时活动

以任务形式出现，鼓励用户当月完成尽可能多单，每完成1单奖励1张折扣券，完成单数越多，折扣力度越深。

从历史任务来看，T3进行了几次迭代，从最初的完成1单就能获得7折券、3单就送8元券，到1单送8.5折券、2单送8折券…5单起每单送7折券，再到最近的1单送9.8折券、3单送9.6折券…5单起每单送9.5折券，优惠力度肉眼可见的缩小。

背后的原因有可能是用户量增加+用户教育逐渐成熟，优惠力度缩小也能维持相对稳定的参与率，还能带来更高的ROI回报。

三、从用户生命周期看T3出行的激励体系

会员体系和积分体系主要作用于用户的升值阶段， 通过核心的T币抵现，辅助以签到、任务，实现用户的留存和忠诚。

四、一些思考

抛开用户运营的身份，作为一个用户，T3出行最初吸引我的是什么？除了价格优惠外，统一的红旗电动车、穿制服的司机、全程不打扰的行车过程，都给我带来了很高的好感度，这也一度成为我心目中T3有别于其他平台的核心竞争力。所以， 除了用户运营体系，更底层的是平台的服务和体验，二者对于用户的留存是相辅相成的。

然而，2021年7月初，滴滴被被官方下架后，T3出行、曹操出行等网约车企业看到了新的发展机会，纷纷开启抢人模式，推出各种营销活动，以优惠券、红包等补贴吸引司机和乘客，尽快分食市场，网络上出现了非常多T3司机端的负面消息。而作为用户，虽然收到了很多大额优惠券，但服务体验明显出现了下降：近来在T3打到的车越来越多为非平台自营车辆，车内卫生、司机素质参差不齐，一度会忘记自己到底是从哪个平台打到的车。假如此时有另一个平台复制了积分抵现的玩法，同时提供更好的服务，T3的用户流失是迟早的事。

在网约车行业进入存量博弈的阶段后，各大平台恐怕需要把目光从“跑马圈地”重新回归“用户至上”，通过高质量的服务和精细化的用户运营，才能在竞争激烈的市场存活。

作者：运营汪成长日记微信公众号：运营汪成长日记（ID: yunyingwang001）

本文由 @ 运营汪成长日记原创发布于运营派，未经许可，禁止转载。

题图来自 pixabay，基于CC0协议

App深度链接与延迟深度链接

Tue, 18 Jan 2022 13:17:59 CST

APP唤醒与场景还原

在App投放推广中，唤醒用户是常见的运营策略。想要让用户重新活跃起来，转化用户的行为，必须从场景上还原用户的路径，从根本上找到用户增长的奥秘。

在这个广告漫天的时代，相信大多数用户在使用App的时候都遇到类似的场景：在使用某资讯类App的时候，浏览到了淘宝的商品广告，当你点击该广告内容时，自动打开了你手机上已经安装的淘宝App并且定位到了该商品的详情页。

作为用户，心里一定在想：“这购物真方便，都不要自己打开淘宝搜索商品了”。
作为广告主，心里在想：“又拉活了一个用户，说不定还能带来一笔转化”。

那么，资讯类App是如何唤醒淘宝App的呢，淘宝App又是如何跳转至用户浏览的广告页面呢？

唤醒&场景还原，作为运营常用的拉活增长手段，有利于提升老用户在App的活跃度，场景化的唤醒更能激发用户的转化意愿。

其适用于如下几个营销场景：

浏览器 -> 唤醒APP：用户A在手机上通过浏览器打开了某APP的M站或者官网，则引导用户打开该APP或者下载该APP。
微信、QQ等 -> 唤醒APP：用户通过某APP分享了一条链接至微信或QQ，用户B点开该链接后，引导用户B打开该APP或者下载该APP。
短信、邮件、二维码等-> 唤醒APP：用户A打开了某APP的推广短信，邮件或者扫描二维码等，引导用户打开该APP或者下载该APP。
其他APP -> 唤醒APP：用户A通过第三方APP分享了一条链接至用户B，用户B点开该链接后，引导用户B打开指定APP或者下载指定APP。

常见唤醒APP方式

URL Scheme

URI Schema 是这几种调起方式中最原始的一种，只需要原生APP开发时注册scheme，那么用户点击到此类链接时，会自动唤醒APP，借助于URL Router机制，则还可以跳转至指定页面。这种方式是当前使用最广泛，也是最简单的，但是需要手机APP支持URL Scheme。

iOS URL Scheme

iOS的沙盒机制

iOS选择沙盒来保障用户的隐私和安全，但沙盒也阻碍了应用间合理的信息共享，于是有了 URL Schemes 这个解决办法。一般来说，我们使用的智能设备上有许多我们的个人信息。比如：联系方式、银行卡/信用卡信息、支付宝/Paypal/各大商城的账户密码、照片甚至行程与位置信息等。

如果说，你设备上的每一个应用，不管是官方的还是你从任何商城安装的应用都可以随意地获取这些信息，那么你轻则收到骚扰信息和邮件、重则后果不堪设想。如何让这些信息不被其它应用随意使用，或者说，如何让这些信息仅在设备所有者本人知情并允许的情况下被使用，是所有智能设备与操作系统所要在乎的核心安全问题。

在 iOS 这个操作系统中，针对这个问题，苹果使用了名为「沙盒」的机制：应用只能访问它声明可能访问的资源。一切提交到 App Store 的应用都必须遵守这个机制。

在安全方面沙盒是个很好的解决办法，但是有些矫枉过正。敏感的个人信息我们不愿意透露，却不代表所有的信息我们都不想与其它应用共享。比如说我们要一次性地（没错，只按一次）把多个事件放到日历中，这些事件包含日期时间以及持续时间等信息，如果 App 之间信息不能沟通，就无法做到这点。类似于一次性添加多个日历事件这样的，我们在使用智能设备的过程中会遇到很多不必要的重复的步骤。大多数人对这些重复的步骤是不自觉的，就像当自己电脑里有一批文件需要批量重命名的时候，他们机械地重复着重命名的过程。但是当我们掌握了这些设备运行的模式，或者有了一些工具，我们就能将这些重复的步骤全部节省下来。在 iOS 上，我们可以利用的工具就是 URL Schemes。

URL Schemes 是什么

通过对比网页链接来理解 iOS 上的 URL Schemes，应该就容易多了。

URL Schemes 有两个单词：

URL，我们都很清楚，http://www.apple.com 就是个 URL，我们也叫它链接或网址；
Schemes，表示的是一个 URL 中的一个位置——最初始的位置，即 ://之前的那段字符。比如 http://www.apple.com 这个网址的 Schemes 是 http。

根据我们上面对 URL Schemes 的使用，我们可以很轻易地理解，在以本地应用为主的 iOS 上，我们可以像定位一个网页一样，用一种特殊的 URL 来定位一个应用甚至应用里某个具体的功能。而定位这个应用的，就应该这个应用的 URL 的 Schemes 部分，也就是开头儿那部分。比如短信，就是 sms:

你可以完全按照理解一个网页的 URL ——也就是它的网址——的方式来理解一个 iOS 应用的 URL，拿苹果的网站和 iOS 上的微信来做个简单对比：

	网页（苹果）	iOS 应用（微信）
网站首页/打开应用	http://www.apple.com	weixin://
子页面/具体功能	http://www.apple.com/mac/	weixin://dl/moments

在这里，http://www.apple.com 和 weixin:// 都声明了这是谁的地盘。然后在 http://www.apple.com 后面加上 /mac 就跳转到从属于 http://www.apple.com 的一个网页（Mac 页）上；同样，在 weixin:// 后面加上 dl/moments 就进入了微信的一个具体的功能——朋友圈。

但是，两者还有几个重要的区别：

所有网页都一定有网址，不管是首页还是子页。但未必所有的应用都有自己的 URL Schemes，更不是每个应用的每个功能都有相应的 URL Schemes。实际上，现状是，大多数的应用只有用于打开应用的 URL Schemes，而有一些应用甚至没有用于打开应用的 URL Schemes。几乎没有所有功能都有对应 URL 的应用。所以，不要说某某应用烂，不支持国内应用。一个 App 是否支持 URL Schemes 要看那个 App 的作者是否在自己的作品里添加了 URL Schemes 相关的代码。
一个网址只对应一个网页，但并非每个 URL Schemes 都只对应一款应用。这点是因为苹果没有对 URL Schemes 有不允许重复的硬性要求，所以曾经出现过有 App 使用支付宝的 URL Schemes 拦截支付帐号和密码的事件。
一般网页的 URL 比较好预测，而 iOS 上的 URL Schemes 因为没有统一标准，所以非常难猜，通过猜来获取 iOS 应用的 URL Schemes 是不现实的。

基本 URL Schemes

基本 URL Schemes 的能力虽然简单有限，但使用情境却是最普遍的。所谓的基本 URL Schemes，是指一个 URL 的 Schemes 部分，比如上文提到的微信的 weixin:。这个部分的唯一功能，就是打开相应应用，而不能够跳转到任何功能。

绝大多数所谓支持 URL Schemes 的应用，一般都是只有这么一个部分，它一般是这个应用的名称，比如 OmniFocus 这款应用，它的基本 URL Schemes 就是 Omnifocus:。如果应用的主名称是个中文名的话，它的 URL Schemes 也许会是应用名的拼音，比如墨客这款应用，它的基本 URL Schemes 是 moke:。但网页 URL 和 iOS 应用的 URL 的三个重要区别，其中第三项，就是 iOS 上的 URL Schemes 并不规范，一个应用的 URL 可以是各种各样的：

Coursera 的 URL 是：coursera-mobile:
Duet 这款游戏的 URL 是：x-kumo-duet:
Monument 这款游戏的 URL 是：fb690517270143345:
Feedly 的 URL 是：fb129765800430121:
扇贝新闻的 URL 是：wx95962d02b9c3e2f7:

它们目前并没有统一的规则，所以猜测一个应用的意义并不太大，你可以试试，但不要过于指望这种方式。下文会提到如何查找一个应用的基本 URL Schemes，只要那个应用支持 URL Schemes 就能找到。基本 URL Schemes 的能力虽然简单有限，但使用情境却是最普遍的。

复杂 URL Schemes

掌握复杂 URL Schemes 你才算初步有了打造适应自己使用情境的自动化流程的能力。iOS 应用的复杂 URL Schemes 就像网站的子页面的链接一样，在首页网址的基础上进行延伸。

具体来看，复杂 URL Schemes 有两种：一种是直接打开某个应用的某个功能，另一种是打开某个功能后直接填写预设的字符。就成为了一个更加实用的 URL Schemes，因为它不光直接让你进入了某个你需要的功能界面，还直接帮你填好了你需要的内容，而跳转后，你需要的只是按一下完成。

有了这样的 URL Schemes，应用之间才可以互相地协作。比如说，当我们在Mr. Reader上看到一篇文章里面写了一个不错的软件的时候，我们可以利用OmniFocus的 URL Schemes 将文章名保存到任务名的部分，把链接保存到备注的部分。在 iOS 8 的 Share Sheet 出现之前，这是唯一在 App 间传输信息的方式。

复杂 URL Schemes 有一个特殊的用例是 Jumpback，字典类 App 用它的很多，比如欧路词典。传统的使用欧陆字典查询单词的 URL Schemes 是：

eudic://dict/想查的单词

在这个基础上，加上一句 Jumpback：

eudic://dict/想查的单词?jumpback=指定URL

就能够做到查完单词以后，按左上角或左下角的返回按钮，回到你想要回到的 App。

并不是每个应用都有它的复杂 URL Schemes，但一般来说，有系统规范的复杂 URL Schemes 的应用都是同类应用中的佼佼者。

x-callback-URL

从一个应用的界面跳转到了另一个应用后，就会在左上角看到回到上一个应用的字样，轻触就能返回到上一个应用。这样的事情我们在打造自己的自动化操作的时候毫无疑问也会想要做到，前面说过的Jumpback是一个选择，除此之外还有更强力的代替者——x-callback-URL，它还有 iOS 9 上「返回上个应用」这一功能不能代替的地方。但是不可否认的是，x-callback-URL 的使用情境比较少，使用难度却又比较高。

我们前面谈到的 URL Schemes 都只有一个目的，不管结果是什么，跳转完成后就会停留在跳转后的应用的界面。但在使用 URL Schemes 的时候，运行结果有时候可能成功，有时候可能失败，有时候我们也会手动将其取消。

如果我们还想让应用根据不同的结果有对应的反应，就要用到 x-callback-URL。比如当上一个 URL Schemes 运行成功以后，我是要回到跳转前的应用？还是要接另一个动作（接上另一段 URL Schemes，打开另一个应用的某个功能）？无论是跳转回上个应用还是打开另一个动作，只要你在运行完一个 URL Schemes 后还想再利用一段新的 URL Schemes 做下一件事，就要靠 x-callback-URL，它的固定语法是：

在一个 URL Schemes 后面接&x-success，表示前一个 URL 成功以后下一步做什么；
在一个 URL Schemes 后面接&x-error，表示前一个 URL 失败以后下一步做什么；
在一个 URL Schemes 后面接&x-cancel，表示取消前一个 URL 的操作结果后下一步做什么；
还有一个&x-source 我们遇到了再说。

URL 编码（Encode）

URL 中的字符可以分为两类，一部分可以在链接中正常显示，比如字母、数字还有/等一部分符号。除此之外，全部不能正常显示，需要进行编码才能够作为 URL 的一部分出现。比如空格，在 URL 中就必须表示为%20转换的规则不用深究，网上有很多工具提供 URL 的编码和解码功能，可以把编码过的乱七八糟的 URL 解码为我们看得清爽的字符。这些工具当然也可以反过来把我们常用的字符转换成可以在 URL 中使用的字符。

所以理论上，所有 URL 不支持的字符，都要编码。

自定义 URL Scheme 进行跳转

如果我们希望别人打开我们的 app（名字叫做 SchemeDemo），需要注册自定义 URL Scheme，通过 info.plist –> URL Types –> item0 –> URL Schemes –> 你的TestScheme 来设置，详细步骤如下：

1、点击工程中的 info.plist 文件，当该文件显示在如下窗口时，在列表顶部鼠标选中 Information Property List，选择 +，然后向下滚动弹出的列表并选择 URL types，类型为 NSArray。

2、点击 URL types 左边剪头打开列表，可以看到 Item 0，一个字典实体。展开 Item 0，可以看到 URL Identifier，一个字符串对象。该字符串是你自定义的 URL scheme 的名字。建议采用反转域名的方法保证该名字的唯一性，比如 com.yourCompany.yourApp。

3、点击 Item 0 新增一行，从下拉列表中选择 URL Schemes，敲击键盘回车键完成插入。注意 URL Schemes 是一个数组，允许应用定义多个 URL schemes。

4、展开 URL Schemes 该数据并点击 Item 0。你将在这里定义自定义 URL scheme 的名字。只需要名字，不要在后面追加 ://，比如，如果你输入 iOSDevApp，你的自定义 url 就是 iOSDevApp://。

此时，整个定义如下图：

Android URL Scheme

Android中的自定义的URL Scheme是一种页面内跳转协议，也可以被称为URLRouter，就是通过类似打开网页的方式去通过路由打开一个Activity，而非直接通过显式Intent方式去进行跳转。这样隐式intent的方法跳转好处如下：

降低耦合性：不需要知道具体要跳转哪个界面，只需要根据需求，按照约定好的URL路由协议发送Intent即可；
更为安全：不显示Intent跳转，只要是符合协议的Intent都会有对应的Activity来匹配，避免了跳转到不该出现的页面；
更为灵活：有着更为广泛的应用场景，多种场景中都可以使用URL Scheme

URL Scheme协议格式

上文已经说过，URL Scheme是就通过类似打开网页的方式去通过路由打开一个Activity，其协议格式和我们打开网页输入的网址类似。

一个完整的完整的URL Scheme协议格式由scheme、host、port、path和query组成，其结构如下所示：

<scheme>://<host>:<port>/<path>?<query>

其中scheme既可以是Android中常见的协议，也可以是我们自定义的协议。Android中常见的协议包括content协议、http协议、file协议等，自定义协议可以使用自定义的字符串，当我们启动第三方的应用时候，多是使用自定义协议。

如下是一个自定义协议的URI：xl://goods:8888/goodsDetail?goodsId=10011002

通过上面的路径 Scheme、Host、port、path、query全部包含:

xl，即为Scheme，代表该Scheme 协议名称
goods，即为Host，代表Scheme作用于哪个地址域
8888，即为port，代表该路径的端口号
goodsDetail，即为path，代表Scheme指定的页面
goodsId，即为query，代表传递的参数

URL Scheme的使用方法

URL Scheme的使用方法简要言之就是先在manifest中配置能接受Scheme方式启动的activity；当需要调用时，将Scheme协议的URi以Data的形式加入到Intent中，隐式调用该activity。

1）在AndroidManifest.xml中对<activity >标签增加<intent-filter>设置Scheme

<activity android:name=".MainActivity">
    <intent-filter> <!--正常启动-->
        <action android:name="android.intent.action.MAIN"/>
        <category android:name="android.intent.category.LAUNCHER"/>
    </intent-filter>
    <intent-filter> <!--URL Scheme启动-->
        <!--必有项-->
        <action android:name="android.intent.action.VIEW"/>
        <!--如果希望该应用可以通过浏览器的连接启动，则添加该项-->
        <category android:name="android.intent.category.BROWSABLE"/>
        <!--表示该页面可以被隐式调用，必须加上该项-->
        <category android:name="android.intent.category.DEFAULT"/>
        <!--协议部分-->
        <data android:scheme="urlscheme"
            android:host="auth_activity">
    </intent-filter>
    <intent-filter>
        <action   android:name="emms.intent.action.check_authorization"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <category android:name="emms.intent.category.authorization"/>
    </intent-filter>
</activity>

上面的设置中可以看到，MainActivity包含多个<intent-filter>设置，第一个是正常的启动，也就是在应用列表中启动；第二个是通过URL Scheme方式启动，其本身也是隐式Intent调用的一种，不同在于添加了<data>属性，定义了其接受URL Scheme协议格式为urlschemel://auth_activity

这里需要说明下，URL Scheme协议格式中，组成URI的这些属性在<data >标签中都是可选的，但存在如下的依赖关系：

如果没有指定scheme，那么host参数会被忽略
如果没有指定host，那么port参数会被忽略
如果scheme和host都没有指定，path参数会被忽略

当我们将intent对象中的Uri参数与intent-filter中的<data>标签指定的URI格式进行对比时，我们只对比intent-filter的<data>标签指定的部分，例如：

如果intent-filter中只指定了scheme，那么所有带有该sheme的URI都能匹配到该intent-filter。
如果intent-filter中只指定了scheme和authority（authority包括host和port两部分）而没有指定path，那么所有具有相同scheme和authority的URI都能匹配到该intent-filter，而不用考虑path为何值。
如果intent-filter中同时指定了scheme、authority和path，那么只有具有相同scheme、authority和path的URI才能匹配到该intent-filter。

需要注意的是，intent-filter的<data>标签在指定path的值时，可以在里面使用通配符*，起到部分匹配的效果。

2）使用URL启动Activity

Uri data = Uri.parse("urlschemel://auth_activity");
 Intent intent = new Intent(Intent.ACTION_VIEW,data);
 //保证新启动的APP有单独的堆栈，如果希望新启动的APP和原有APP使用同一个堆栈则去掉该项
 intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
 try {
   startActivityForResult(intent, RESULT_OK);
 } catch (Exception e) {
   e.printStackTrace();
   Toast.makeText(MainActivity.this, "没有匹配的APP，请下载安装",Toast.LENGTH_SHORT).show();
 }

当然可以在网页中调用：

<a href="urlschemel://auth_activity">打开新的应用</a>

或者是在JS中调用：

window.location = "urlschemel://auth_activity";

3）如何判断URL Scheme是否有效

boolean checkUrlScheme(Intent intent){
    PackageManager packageManager = getPackageManager();
    List<ResolveInfo> activities = packageManager.queryIntentActivities(intent, 0);
    return !activities.isEmpty();
}

将子APP在Home Launcher中隐藏

有时候需要把一些辅助性的、较为独立的APP在Home Launcher中隐藏起来，只允许一些特定的APP调用。这个时候，我们可以利用URL Scheme协议来做到这一点，设置AndroidManifest.xml中对<activity >标签如下:

<activity android:name=".MainActivity">
    <intent-filter>
        <action android:name="android.intent.action.MAIN"/>
        <category android:name="android.intent.category.LAUNCHER"/>
        <category android:name="android.intent.category.BROWSABLE"/>
        <!--表示该页面可以被隐式调用，必须加上该项-->
        <category android:name="android.intent.category.DEFAULT"/>
        <!--协议部分-->
        <data android:scheme="urlscheme"
            android:host="auth_activity">
    </intent-filter>
</activity>

因为Home Launcher列出的应用图标要求必须有Activity同时满足：

<action android:name="android.intent.action.MAIN"/>
<category android:name="android.intent.category.LAUNCHER"/>

上面的配置中有多余的category和data限制存在，所以并不匹配，不会在Home Launcher出现，但是可以使用URL Scheme来启动。

Uri data = Uri.parse("urlschemel://auth_activity");
Intent intent = new Intent(Intent.ACTION_MAIN,data);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

这样就可以将一组APP设置一个统一的入口，然后根据实际需要在调用不同子APP，即所谓的APP业务组件化。

URL Scheme的缺点

提示框

我们只能通过固定协议格式的链接来实现跳转，而且打开H5页面时，会出现一个提示框：“是否打开XXX”。用户确认了才会跳转到App中，增加了用户流程。

未安装APP导致的异常

错误处理情况因平台不同，难以统一处理，部分APP会直接跳错误页（比如Android Chrome/41，iOS中老版的Lofter）；也有的停留在原页面，但弹出提示“无法打开网页”（比如iOS7）；iOS8以及最新的Android Chrome/43 目前都是直接停留在当前页，不会跳出错误提示。

场景支持情况

iOS在实际使用中，腾讯系的微信，QQ明确禁止使用，iOS9以后Safari不再支持通过js，iframe等来触发scheme跳转，并且还加入了确认机制，使得通过js超时机制来自动唤醒APP的方式基本不可用；Android平台则各个app厂商差异很大，比如Chrome从25及以后就同Safari情况一样。

命名冲突或劫持

如果手机中同時存在有两个应用都使用相同的 URL Scheme，那么唤起目标应用时，系统会优先唤起哪一个呢？Apple在后续iOS版本（iOS 11）采用了先到先得原则，如果使用了同一个URL Scheme，只有先安装的app会被启动。然而，攻击者还是可以通过其他方法来利用这个漏洞。

打开方式被禁

微信、QQ等把URL Scheme 打开App这种方式给禁了，但是它们都各自维护着一个白名单，如果Scheme不在该白名单内，那么就不能在他们的App内打开这个App（如果被封锁了那么用户只能通过右上角浏览器内打开App）

iOS Universal Links

Universal Link 是苹果在 WWDC 上提出的 iOS9 的新特性之一。此特性类似于深层链接，并能够方便地通过打开一个 Https 链接来直接启动您的客户端应用(手机有安装 App)。对比起以往所使用的 URL Scheme,这种新特性在实现 web-app 的无缝链接时能够提供极佳的用户体验。

当你的应用支持 Universal Link(通用链接)，当用户点击一个链接是可以跳转到你的网站并获得无缝重定向到对应的 APP，且不需要通过 Safari 浏览器。如果你的应用不支持的话，则会在 Safari 中打开该链接。

使用 Universal Link(通用链接)可以让用户在 Safari 浏览器或者其他 APP 的 webview 中拉起相应的 APP，也可以在 APP 中使用相应的功能，从而来把用户引流到 APP 中。这具体是一种怎样的情景呢？举个例子，你的用户 safari 里面浏览一个你们公司的网页，而此时用户手机也同时安装有你们公司的 App；而 Universal Link 能够使得用户在打开某个详情页时直接打开你的 app 并到达 app 中相应的内容页面，从而实施用户想要的操作(例如查看某条新闻,查看某个商品的明细等等)。比如在 Safari 浏览器中进入淘宝网页点击打开 APP 则会使用 Universal Link(通用链接)来拉起淘宝 APP。

Universal link 的特点：

唯一性: 不像自定义的 URL Scheme，因为它使用标准的 HTTPS 协议链接到你的 web 站点，所以一般不会被其它的 APP 所声明。另外，URL scheme 因为是自定义的协议，所以在没有安装 app 的情况下是无法直接打开的(在 Safari 中还会出现一个不可打开的弹窗)，而 Universal Link(通用链接)本身是一个 HTTPS 链接，所以有更好的兼容性；
安全: 当用户的手机上安装了你的 APP，那么系统会去你配置的网站上去下载你上传上去的说明文件(这个说明文件声明了当前该 HTTPS 链接可以打开那些 APP)。因为只有你自己才能上传文件到你网站的根目录，所以你的网站和你的 APP 之间的关联是安全的；
可变: 当用户手机上没有安装你的 APP 的时候，Universal Link(通用链接)也能够工作。如果你愿意，在没有安装你的 app 的时候，用户点击链接，会在 safari 中展示你网站的内容；
简单: 一个 HTTPS 的链接，可以同时作用于网站和 APP；
私有: 其它 APP 可以在不需要知道你的 APP 是否安装了的情况下和你的 APP 相互通信。

Universal Link的优点：

Custom URL scheme是自定义的协议，因此在没有安装该app的情况下是无法直接打开的。而Universal Links本身也就是一个能够指向一个web页面或者app中的内容页的标准的web link（形如https://example.com）因此能够很好的兼容其他情况。也就是说，当已经安装了这个app的时候，不需要加载任何web页面，app就会立即启动；当这个app没有安装的时候，就会默认地从当前浏览器中重定向到App Store中引导用户去下载安装这个app。
Universal links是从服务器上查询是哪个app需要被打开，因此不存在Custom URL scheme那样名字被抢占、冲突的情况。
Universal links支持从其他app中的UIWebView中跳转到目标app
安全性，用universl link去打开的时候，只有你可以通过创建和上传一个允许这个网页去通过这个URL去打开你的app的文件。
隐私性，提供Universal link给别的app进行app间的交流，然而对方并不能够用这个方法去检测你的app是否被安装。

Universal link 配置和运行

1）配置 App ID 支持 Associated Domains

登录https://developer.apple.com/ 苹果开发者中心，找到对应的 App ID，在 Application Services 列表里有 Associated Domains 一条，把它变为 Enabled 就可以了。

2 ）配置 iOS App 工程

Xcode 11.0 版本：工程配置中相应功能：targets->Signing&Capabilites->Capability->Associated Domains，在其中的 Domains 中填入你想支持的域名，也必须必须以 applinks:为前缀。

Xcode 11.0 以下版本：工程配置中相应功能：targets->Capabilites->Associated Domains，在其中的 Domains 中填入你想支持的域名，必须以 applinks:为前缀。

3）配置和上传 apple-app-association

究竟哪些的 url 会被识别为 Universal Link，全看这个 apple-app-association 文件 Apple Document UniversalLinks.html

你的域名必须支持 Https
域名根目录或者.well-known目录下放这个文件apple-app-association，不带任何后缀。
文件为 json 保存为文本即可
json 按着官网要求填写即可

apple-app-site-association模板：

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "9JA89QQLNQ.com.apple.wwdc",
                "paths": [ "/wwdc/news/", "/videos/wwdc/2015/*"]
            },
            {
                "appID": "ABCD1234.com.apple.wwdc",
                "paths": [ "*" ]
            }
        ]
    }
}

说明：

appID：组成方式是yourapp’s bundle identifier。如上面的 9JA89QQLNQ 就是 teamId。登陆开发者中心，在 Account -> Membership 里面可以找到 Team ID。
paths：设定你的 app 支持的路径列表，只有这些指定的路径的链接，才能被 app 所处理。星号的写法代表了可识别域名下所有链接。

上传指定文件:上传该文件到你的域名所对应的根目录或者.well-known 目录下，这是为了苹果能获取到你上传的文件。上传完后,自己先访问一下,看看是否能够获取到，当你在浏览器中输入这个文件链接后，应该是直接下载 apple-app-site-association 文件。

验证 Universal link 生效

可以使用 iOS 自带的备忘录程序，输入链接，长按链接，如果弹出菜单中有”在‘xxx’中打开”，即表示配置生效。或者将要测试的网址在Safari中打开，在出现的网页上方下滑，可以看到有在”xxx”应用中打开, 出现菜单。

当点击某个链接，直接可以进我们的 app 了，但是我们的目的是要能够获取到用户进来的链接，根据链接来展示给用户相应的内容。

在AppDelegate里中实现代理方法，官方链接： Handling Universal Links

Objective-C：

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray * _Nullable))restorationHandler {
    if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb])
    {
        NSURL *url = userActivity.webpageURL;
        if (url是我们希望处理的)
        {
            //进行我们的处理
        }
        else
        {
            [[UIApplication sharedApplication] openURL:url];
        }
    }
     
    return YES;
}

Swift:

func application(_ application: UIApplication,
                 continue userActivity: NSUserActivity,
                 restorationHandler: @escaping ([Any]?) -> Void) -> Bool
{
    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
        let incomingURL = userActivity.webpageURL,
        let components = NSURLComponents(url: incomingURL, resolvingAgainstBaseURL: true),
        let path = components.path,
        let params = components.queryItems else {
            return false
    }
    
    print("path = \(path)")
    
    if let albumName = params.first(where: { $0.name == "albumname" } )?.value,
        let photoIndex = params.first(where: { $0.name == "index" })?.value {
        
        print("album = \(albumName)")
        print("photoIndex = \(photoIndex)")
        return true
        
    } else {
        print("Either album name or photo index missing")
        return false
    }
}

Universal link跨域问题

Universal Link有跨域问题，Universal Link必须要求跨域，如果不跨域，就不会跳转（iOS 9.2之后的改动）要求具备跨域能力即可，假如当前网页的域名是A，当前网页发起跳转的域名是B，必须要求B和A是不同域名才会触发Universal Link，如果B和A是相同域名，只会继续在当前WebView里面进行跳转，哪怕你的Universal Link一切正常，根本不会打开App 2. Universal Link请求apple-app-site-association时机

当我们的App在设备上第一次运行时，如果支持Associated Domains功能，那么iOS会自动去GET定义的Domain下的apple-app-site-association文件
iOS会先请求https://domain.com/.well-known/apple-app-site-association，如果此文件请求不到，再去请求https://domain.com/apple-app-site-association，所以如果想要避免服务器接收过多GET请求，可以直接把apple-app-site-association放在./well-known目录下

Universal Link更新

apple-app-association的更新时机有以下两种：

每次App安装后的第一次Launch，会拉取apple-app-association
Appstore每次App的版本更新后的第一次Launch，也会更新apple-app-association

所以反复重新杀APP重开完全没用，删了App重装确实有用，但不可能让用户这么去做。也就是说，一旦不小心因为意外apple-app-association，想要挽回又让那部分用户无感，App再发一个版本就好了。

Universal Link用户行为

Universal Link 触发后打开App，这时候App的状态栏右上角会有文字提示来自XXApp，可以点状态栏的文字快速返回原来的AP

如果用户点了返回微信，就会被苹果记住，认为用户并不需要跳出原App打开新App，因此这个App的Universal Link会被关闭，再也无效。

想要开启也不是不行，让用户重新用safari打开，universal link的页面，然后会出现很像苹果smart bar的东西，那个东西点了后就能打开

H5 端的 Universal Link 业务部署

H5 端的 Universal Link 跳转，从产品经理的角度看，需要满足以下 2 个需求：

如果已安装 App，跳转对应界面
如果没安装 App，跳转 App 下载界面

H5 端部署 Universal Link 示例：

router.use('/view', function (req, res, next) {
    var path = req.path;
    res.redirect('https://www.xxx.com/view' + path + '?xxx=xxx');
});

整个效果就是

跳转https://www.xxx.com/view/*
- 已安装 App
  - 打开 App 触发 handleUniversalLink
  - 走到/view/分支，拼接阅读页路由跳转
- 未安装 AppWebView
  - 原地跳转https://www.xxx.com/view/*
  - 命中服务器的重定向逻辑
  - 重定向到https://www.xxx.com/view/*
  - 打开相应的 H5 页面

Chrome Intent

在很多应用中需要我们从浏览器中直接启动应用，大多数采用的是上面提到的第一种scheme的方式，问题是如果手机中没有应用，该url会跳转到一个错误的界面。

Google官方在chrome中推出了一种Android Intents的方式来实现应用启动，通过在iframe中设置src为：

intent:HOST/URI-path // Optional host
#Intent;
package=[string];
action=[string];
category=[string];
component=[string];
scheme=[string];
end;

mainfest文件中定义要启动的activity：

<activity
    android:name=".ui.activity.SplashActivity"
    android:exported="true"
    android:screenOrientation="portrait"
    android:theme="@style/NormalSplash">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
    
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:host="app.puxinwangxiao.com"
            android:scheme="pxwxstudent" />
    </intent-filter>
</activity>

定义一个a标签为

<a href="intent://app.domain.com/#Intent;scheme=xyz;package=com.xxx.xxx;end">open Android App</a>

在浏览器中点击a标签，就可以启动应用程序的对应activity了。如果手机中没有相应的应用，防止跳转到错误页面，将a标签设置为：

<a href="intent://app.domain.com/#Intent;scheme= xyz;package=com.xxx.xxx;S.browser_fallback_url=https://www.domain.com;end">open Android App</a>

这样如果没有对应应用，该链接就会跳转到==S.browser_fallback_url==指定的url上。

备注：很多第三方浏览器会拦截掉chrome intent启动应用的请求。

Android App Link

类似 Universal Links， Android App Link采取类似的机制：使用标准的 Web 页面 URL，同时绑定对应的 App。在 Android >= 6 的系统中支持这一机制。

Android App Links有以下几点好处：

安全性/特殊性：由于Android App Links使用了HTTP/HTTPS URL的方式向开发者的服务器进行连接认证，所以其他应用无法使用我们的链接
无缝的用户体验：当用户未安装我们的应用时，由于使用的是HTTP/HTTPS URL，会直接打开一个网页，我们可以在这个网页中展示应用介绍等，而不是显示404或者是其他错误页面
支持Instant Apps：可以使用App Links直接打开一个未安装的Instant App
支持Google Search或其他浏览器：用户可以直接在Google Search/Google Assistant/手机浏览器/屏幕搜索中直接通过点击一个URL来打开我们的指定页面

要添加Android App Links到应用中，需要在应用里定义通过Http(s)地址打开应用的intent filter，并验证你确实拥有该应用和该网站。如果系统成功验证到你拥有该网站，那么系统会直接把URL对应的intent路由到你的应用。

为了验证你对应用和网站的所有权，以下两个步骤是必须的：

在AndroidManifest里要求系统自动进行App Links的所有权验证。这个配置会告诉Android系统去验证你的应用是否属于在intent filter内指定的URL域名。
在以下链接地址里，放置一个数字资产链接的Json文件，声明你的网址和应用之间的关系：https://domain.name/.well-known/assetlinks.json

在app中激活App links

告诉安卓系统去验证app与域名之间的关系。因为我们已经在app中注册了该域名，就不会再出现弹框。找到AndroidManifest.xml文件，在处理深度链接路由的activity（第三步将讲解如何创建这样的Activity）中添加android:autoVerify=”true”到intent-filter：

<activity
  android:name=".ParseDeepLinkActivity"
  android:alwaysRetainTaskState="true"
  android:launchMode="singleTask"
  android:noHistory="true"
  android:theme="@android:style/Theme.Translucent.NoTitleBar">
  
  <intent-filter android:autoVerify="true">
    <data android:scheme="http" android:host="yourdomain.com" />
    <data android:scheme="https" android:host="yourdomain.com" />
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
  </intent-filter>
</activity>

这个配置告诉安卓去验证一个文件，这个文件地址是https://yourdomain.com/.well-known/statements.json。如果存在这个文件，同时验证成功，那么用户点击该域名之下的链接时，就可以直接到app，弹出框就可以避免。否则app就没有成为默认选项，弹出框就会呈现给用户。

上传web-app关联文件（statements.json）

基于安全的原因，这个文件必须通过SSL的GET请求获得。

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mycompany.myapp",
    "sha256_cert_fingerprints": ["6C:EC:C5:0E:34:AE....EB:0C:9B"]
  }
}]

可以在AndroidManifest.xml 文件中找到app的package name。还需要通过在终端中执行ava keytool 产生一个sha256指纹：

keytool -list -v -keystore /path/to/app/release-key.keystore

你需要向keystore添加持有app release keys的 app路径。这个路径依赖于项目设置，因此不同的app是不同的。可以在谷歌的文档中找到更多关于如何找到keystore的信息。

最后，上传这个文件到服务器的/.well-known/statements.json。为了避免今后每个app链接请求都访问网络，安卓只会在app安装的时候检查这个文件。如果你能在请求https://yourdomain.com/.well-known/statements.json 的时候看到这个文件（替换成自己的域名哈），那么可以继续下一步了。

注：目前可以通过http获得这个文件，但是在M最终版里则只能通过HTTPS验证。确保你的web站点支持HTTPS请求。

在app中处理applink

public class ParseDeepLinkActivity extends Activity {
  public static final String PRODUCTS_DEEP_LINK = "/products";
  public static final String XMAS_DEEP_LINK = "/campaigns/xmas";
  
  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
 
    // Extrapolates the deeplink data
    Intent intent = getIntent();
    Uri deeplink = intent.getData();
 
    // Parse the deeplink and take the adequate action 
    if (deeplink != null) {
      parseDeepLink(deeplink);
    }
  }
  
  private void parseDeepLink(Uri deeplink) {
    // The path of the deep link, e.g. '/products/123?coupon=save90'
    String path = deeplink.getPath();
 
    if (path.startsWith(PRODUCTS_DEEP_LINK)) {
      // Handles a product deep link
      Intent intent = new Intent(this, ProductActivity.class);
      intent.putExtra("id", deeplink.getLastPathSegment()); // 123
      intent.putExtra("coupon", deeplink.getQueryParameter("coupon")); // save90
      startActivity(intent);
    } else if (XMAS_DEEP_LINK.equals(path)) {
      // Handles a special xmas deep link
      startActivity(new Intent(this, XmasCampaign.class));
    }  else {
      // Fall back to the main activity
      startActivity(new Intent(context, MainActivity.class));
    }
  }
}

深度链接 Deeplink

深度链接是指当用户打开移动应用时向其提供个性化的内容，或将用户带到应用内特定位置的操作。通过这种操作，您可以为用户提供优质的用户体验，从而极大加强用户与应用的互动。

在浏览器或者短信中打开App，如果安装了就能直接打开App，否则引导下载。对于Android而言，这里主要牵扯的技术就是deeplink，也可以简单看成scheme。
其实，AppLink就是特殊的Deeplink，只不过它多了一种类似于验证机制，如果验证通过，就设置默认打开，如果验证不过，则退化为deeplink，如果单从APP端来看，区别主要在Manifest文件中的android:autoVerify=”true”。
还有在微信中，也可以作出这样操作。如果用户已经安装App，点击跳转App则会通过应用宝打开该应用并且跳转到相应的页面，这种也是一种AppLink。

总结来说，Deeplink，又叫深度链接技术，是指在App/短信/广告里点击链接，能直接跳转到目标App具体位置的技术，深度链接打破了网站与App间的壁垒，成为实现网站与App相互跳转的桥梁。开发者不仅可以通过deeplink实现网站到App互相跳转，也可以实现从多个平台（QQ、微信、微博、Twitter、Facebook、短信、各大浏览器等）到App内指定页的跳转。例如用户将电商App内的一个详情页链接通过短信形式发送给其他亲友，用户点击短信内的链接就能打开对应的H5页面，然后直接跳转到电商App内的指定详情页，而不是App首页。如果用户并未安装App，那么就会跳转到App下载页面。等用户安装打开App后仍然能跳转到指定页面。Deeplink技术不仅可以实现场景快速还原，缩短用户使用路径，更重要的是能够用于App拉新推广场景，降低用户流失率。

Deep Linking只是一个概念，是指通过一个链接进入另一个网站/App，并直接浏览其内部的某个页面。 Deep Linking 给用户带来的是非常顺滑的浏览体验，尤其在 Web 世界中 Deep Linking 的实现非常容易。

但如果要进入 App 并定位到对应的页面则较为困难，URI Scheme, Universal Links, Android App Links, 以及 Chrome Intent 都是为了解决从 Web 页面 Deep Linking 到 App 而做的尝试。

每种实现方式都有其适用的平台和浏览器，要兼容多数浏览器需要根据 User Agent 应用不同的策略。这些实现方式的行为也不一致，可能需要配合产品需求才能确定结合哪几种实现方式。这些实现在下文有详细的介绍，下表中先大概列举各种实现的区别：

技术	Universal Link	Android App Link	URI Scheme	Chrome Intent
平台要求	>= iOS 9	>= Android 6	Chrome 1 < 25, iOS	Chrome 1 >= 25
未安装表现	打开 Web 页面	打开 Web 页面	发生错误	可以打开 Web 页面
能否不发生跳转	不能	不能	能	能
能否去下载页面	能	能	不能	能
iframe 触发	不支持	不支持	Chrome 1 <= 18, iOS < 9	不支持
链接格式 2	正常的 URL	正常的 URL	自定义协议的 URL	intent 协议的 URL

JavaScript 获取成功与否

上述所有调起方式都必须通过页面请求（除了特定情况下的 iframe），没有 JavaScript API 可用。理论上不存在调起结果回调。

但实践上可以通过 setTimeout 来检查页面是否还在运行，以及页面是否中断过。原理是如果页面切走（这意味着成功调起），setTimeout 回调的触发时间点会延迟。这一方式不够准确，但只有这一种办法。

如果被判定为调起成功，则一定是调起成功的。
如果被判定为调起失败，则有可能调起成功。

即存在很大概率的 False Negative，但不存在 False Positive。

关于国产浏览器

这一部分讨论这三个浏览器的表现：UC, 微信，QQ。它们占据了系统浏览器之外的大多数市场份额，表现也惊人地一致。

Android 下它们会拦截掉所有页面调起。需要提示用户从系统浏览器中打开。
iOS 下它们会拦截 URI Scheme，既不会弹框也不会调起。对于 Universal Link 会直接打开 Web 页面而不调起。

其中 UC 浏览器在 iOS < 9 的环境下尝试 URI Scheme 调起很可能会直接崩溃。由于浏览器兼容性问题，以及 App 安装率不可能是 100%，调起成功率一般会很低尤其在 Android 下。

延迟深度链接(Deferred Deep Linking)

相比deeplink，它增加了判断APP是否被安装，用户匹配的2个功能；

当用户点击链接的时候判断APP是否安装，如果用户没有安装时，引导用户跳转到应用商店下载应用。
用户匹配功能，当用户点击链接时和用户启动APP时，分别将这两次用户Device Fingerprint（设备指纹信息）传到服务器进行模糊匹配，使用户下载且启动APP时，直接打开相应的指定页面。

通过上面的2个技术方案，不仅：

可以让被分享者更快更便捷的回到APP，且回到指定的活动页面，而且：
可以引导未安装APP的用户下载APP、
分享者和被分享者的关系链会通过设备指纹信息记录下来，在业务场景中给出相应的奖励。

Deferred Deeplink可以先判断用户是否已经安装了App应用，如果没有则先引导至App应用商店中下载App，在用户安装App后跳转到指定App页面Deeplink中。

除了上述Deeplink中的运营有点外，Deferred Deeplink在未安装App应用人群定向推广中效果更佳突出。另外国外的App运营在社交推广中广泛使用Deferred Deeplink技术，比如一个购物App中用户分享了一个自己喜欢的产品到社交账户中，如果没有使用Deferred Deeplink。其好友看到分享，点击下载安装打开App应用后，很可能找不到其好友分享的产品，导致较高的用户流失率。

Deferred DeepLink的实现思路

任何匹配的问题都可以转化到获取唯一标示的问题。很容易联想到http里面的session和cookies。由于手机系统的沙盒模式，阻断了App之间的数据共享。也就是说App的cookies跟手机浏览器的cookies是分开的，无法互通。

解决方案一：通过设备唯一ID

如Android的OIAD，iOS的idfv。此方案仅适合一个APP往另外一个APP引流的场景。

解决方案二：通过IP地址+设备信息（设备尺寸、操作系统等）+时间限定（比如10分钟）

解决方案三：剪切板方案

H5页面在点击下载时自动调用剪切板复制当前用户渠道ID（口令码方案），APP每次启动时调用剪切板内容格式符合则认定该用户和H5用户为同一用户。

第三方库

支持deep linking 和 deferred deep linking 的第三方服务，比如 AppsFlyer和 Branch。涉及内容较多，这里就先不做展开。后面会单独进行深入分析。

Android/iOS判断是否使用代理或VPN

Fri, 07 Jan 2022 18:57:06 CST

针对APP的黑产，我们提到部分用户会通过改变IP来绕过风控策略。更改IP比较方便的方法是使用代理IP或VPN。

在检测APP安全性是需要对是否使用代码和VPN做判断。以下为整理的一些代码供参考。

Android判断是否使用代理IP

private boolean isWifiProxy(Context context) {
    final boolean IS_ICS_OR_LATER = Build.VERSION.SDK_INT >= Build.VERSION_CODES.ICE_CREAM_SANDWICH;
    String proxyAddress;
    int proxyPort;

    if (IS_ICS_OR_LATER) {
        proxyAddress = System.getProperty("http.proxyHost");
        String portStr = System.getProperty("http.proxyPort");
        proxyPort = Integer.parseInt((portStr != null ? portStr : "-1"));
    } else {
        proxyAddress = android.net.Proxy.getHost(context);
        proxyPort = android.net.Proxy.getPort(context);
    }
    return (!TextUtils.isEmpty(proxyAddress)) && (proxyPort != -1);
}

Android判断是否使用VPN

boolean checkVPN(ConnectivityManager connMgr) {
    //don't know why always returns null:
    NetworkInfo networkInfo = connMgr.getNetworkInfo(ConnectivityManager.TYPE_VPN);

    boolean isVpnConn = networkInfo == null ? false : networkInfo.isConnected();
    return isVpnConn;
}

iOS判断是否使用代理IP

#import "CETCProxyStatus.h"

@implementation CETCProxyStatus

+ (BOOL)getProxyStatus {
    NSDictionary *proxySettings = NSMakeCollectable([(NSDictionary *)CFNetworkCopySystemProxySettings() autorelease]);

    NSArray *proxies = NSMakeCollectable([(NSArray *)CFNetworkCopyProxiesForURL((CFURLRef)[NSURL URLWithString:@"http://www.baidu.com"], (CFDictionaryRef)proxySettings) autorelease]);
    NSDictionary *settings = [proxies objectAtIndex:0];

    NSLog(@"host=%@", [settings objectForKey:(NSString *)kCFProxyHostNameKey]);
    NSLog(@"port=%@", [settings objectForKey:(NSString *)kCFProxyPortNumberKey]);
    NSLog(@"type=%@", [settings objectForKey:(NSString *)kCFProxyTypeKey]);

    if ([[settings objectForKey:(NSString *)kCFProxyTypeKey] isEqualToString:@"kCFProxyTypeNone"]) {
        //没有设置代理
        return NO;
    } else {
        //设置代理了
        return YES;
    }
}

iOS判断是否使用VPN

- (BOOL)isVPNOn
{
   BOOL flag = NO;
   NSString *version = [UIDevice currentDevice].systemVersion;
   // need two ways to judge this.
   if (version.doubleValue >= 9.0)
   {
       NSDictionary *dict = CFBridgingRelease(CFNetworkCopySystemProxySettings());
       NSArray *keys = [dict[@"__SCOPED__"] allKeys];
       for (NSString *key in keys) {
           if ([key rangeOfString:@"tap"].location != NSNotFound ||
               [key rangeOfString:@"tun"].location != NSNotFound ||
               [key rangeOfString:@"ipsec"].location != NSNotFound ||
               [key rangeOfString:@"ppp"].location != NSNotFound){
               flag = YES;
               break;
           }
       }
   }
   else
   {
       struct ifaddrs *interfaces = NULL;
       struct ifaddrs *temp_addr = NULL;
       int success = 0;
       
       // retrieve the current interfaces - returns 0 on success
       success = getifaddrs(&interfaces);
       if (success == 0)
       {
           // Loop through linked list of interfaces
           temp_addr = interfaces;
           while (temp_addr != NULL)
           {
               NSString *string = [NSString stringWithFormat:@"%s" , temp_addr->ifa_name];
               if ([string rangeOfString:@"tap"].location != NSNotFound ||
                   [string rangeOfString:@"tun"].location != NSNotFound ||
                   [string rangeOfString:@"ipsec"].location != NSNotFound ||
                   [string rangeOfString:@"ppp"].location != NSNotFound)
               {
                   flag = YES;
                   break;
               }
               temp_addr = temp_addr->ifa_next;
           }
       }
       
       // Free memory
       freeifaddrs(interfaces);
   }


   return flag;
}

一个 Hybrid SDK 设计与实现

Mon, 28 Jun 2021 11:12:12 CST

随着移动浪潮的兴起，各种 App 层出不穷，极速发展的业务拓展提升了团队对开发效率的要求，这个时候纯粹使用 Native 开发技术成本难免会更高一点。而 H5 的低成本、高效率、跨平台等特性马上被利用起来了，形成一种新的开发模式： Hybrid App

作为一种混合开发的模式，Hybrid App 底层依赖于 Native 提供的容器（Webview），上层使用各种前端技术完成业务开发（现在三足鼎立的 Vue、React、Angular），底层透明化、上层多样化。这种场景非常有利于前端介入，非常适合业务的快速迭代。于是 Hybrid 火了。

大道理谁都懂，但是按照我知道的情况，还是有非常多的人和公司在 Hybrid 这一块并没有做的很好，所以我将我的经验做一个总结，希望可以帮助广大开发者的技术选型有所帮助

Hybrid 的一个现状

可能早期都是 PC 端的网页开发，随着移动互联网的发展，iOS、Android 智能手机的普及，非常多的业务和场景都从 PC 端转移到移动端。开始有前端开发者为移动端开发网页。这样子早期资源打包到 Native App 中会造成应用包体积的增大。越来越多的业务开始用 H5 尝试，这样子难免会需要一个需要访问 Native 功能的地方，这样子可能早期就是懂点前端技术的 Native 开发者自己封装或者暴露 Native 能力给 JS 端，等业务较多的时候者样子很明显不现实，就需要专门的 Hybrid 团队做这个事情；量大了，就需要规矩，就需要规范。

总结：

Hybrid 开发效率高、跨平台、低成本
Hybrid 从业务上讲，没有版本问题，有 Bug 可以及时修复

Hybrid 在大量应用的时候就需要一定的规范，那么本文将讨论一个 Hybrid 的设计知识。

Hybrid 、Native、前端各自的工作是什么
Hybrid 交互接口如何设计
Hybrid 的 Header 如何设计
Hybrid 的如何设计目录结构以及增量机制如何实现
资源缓存策略，白屏问题...

Native 与前端分工

在做 Hybird 架构设计之前我们需要分清 Native 与前端的界限。首先 Native 提供的是宿主环境，要合理利用 Native 提供的能力，要实现通用的 Hybrid 架构，站在大前端的视觉，我觉得需要考虑以下核心设计问题。

交互设计

Hybrid 架构设计的第一要考虑的问题就是如何设计前端与 Native 的交互，如果这块设计不好会对后续的开发、前端框架的维护造成深远影响。并且这种影响是不可逆、积重难返。所以前期需要前端与 Native 好好配合、提供通用的接口。比如

Native UI 组件、Header 组件、消息类组件
通讯录、系统、设备信息读取接口
H5 与 Native 的互相跳转。比如 H5 如何跳转到一个 Native 页面，H5 如何新开 Webview 并做动画跳转到另一个 H5 页面

账号信息设计

账号系统是重要且无法避免的，Native 需要设计良好安全的身份验证机制，保证这块对业务开发者足够透明，打通账户体系

Hybrid 开发调试

功能设计、编码完并不是真正结束，Native 与前端需要商量出一套可开发调试的模型，不然很多业务开发的工作难以继续。

iOS调试技巧

Android 调试技巧：

App 中开启 Webview 调试(WebView.setWebContentsDebuggingEnabled(true);　)
chrome 浏览器输入 chrome://inspect/#devices 访问可以调试的 webview 列表
需要翻墙的环境

Hybrid 交互设计

Hybrid 交互无非是 Native 调用 H5 页面JS 方法，或者 H5 页面通过 JS 调 Native 提供的接口。2者通信的桥梁是 Webview。
业界主流的通信方法：1.桥接对象（时机问题，不太主张这种方式）；2.自定义 Url scheme

App 自身定义了 url scheme，将自定义的 url 注册到调度中心，例如
weixin:// 可以打开微信。

关于 Url scheme 如果不太清楚可以看看这篇文章

JS to Native

Native 在每个版本都会提供一些 Api，前端会有一个对应的框架团队对其封装，释放业务接口。举例

  SDGHybrid.http.get()  // 向业务服务器拿数据
SDGHybrid.http.post() // 向业务服务器提交数据
SDGHybrid.http.sign() // 计算签名
SDGHybrid.http.getUA()  // 获取UserAgent

  SDGHybridReady(function(arg){
  SDGHybrid.http.post({
    url: arg.baseurl + '/feedback',
    params:{
      title: '点菜很慢',
      content: '服务差'
    },
    success: (data) => {
      renderUI(data);
    },
    fail: (err) => {
      console.log(err);
    }
  })
})

前端框架定义了一个全局变量 SDGHybrid 作为 Native 与前端交互的桥梁，前端可以通过这个对象获得访问 Native 的能力

Api 交互

调用 Native Api 接口的方式和使用传统的 Ajax 调用服务器，或者 Native 的网络请求提供的接口相似

所以我们需要封装的就是模拟创建一个类似 Ajax 模型的 Native 请求。

格式约定

交互的第一步是设计数据格式。这里分为请求数据格式与响应数据格式，参考 Ajax 模型：

  $.ajax({
  type: "GET",
  url: "test.json",
  data: {username:$("#username").val(), content:$("#content").val()},
  dataType: "json",
  success: function(data){
    renderUI(data);           
  }
});

  $.ajax(options) => XMLHTTPRequest
type(默认值：GET)，HTTP请求方法（GET|POST|DELETE|...）
url(默认值：当前url)，请求的url地址
data(默认值：'') 请求中的数据如果是字符串则不变，如果为Object，则需要转换为String，含有中文则会encodeURI

所以 Hybrid 中的请求模型为：

  requestHybrid({
  // H5 请求由 Native 完成
  tagname: 'NativeRequest',
  // 请求参数
  param: requestObject,
  // 结果的回调
  callback: function (data) {
    renderUI(data);
  }
});

这个方法会形成一个 URL，比如：
SDGHybrid://NativeRequest?t=1545840397616&callback=Hybrid_1545840397616&param=%7B%22url%22%3A%22https%3A%2F%2Fwww.datacubr.com%2FApi%2FSearchInfo%2FgetLawsInfo%22%2C%22params%22%3A%7B%22key%22%3A%22%22%2C%22page%22%3A1%2C%22encryption%22%3A1%7D%2C%22Hybrid_Request_Method%22%3A0%7D

Native 的 webview 环境可以监控内部任何的资源请求，判断如果是 SDGHybrid 则分发事件，处理结束可能会携带参数，参数需要先 urldecode 然后将结果数据通过 Webview 获取 window 对象中的 callback（Hybrid_时间戳）

数据返回的格式和普通的接口返回格式类似

  {
  errno: 1,
  message: 'App版本过低，请升级App版本',
  data: {}
}

这里注意：真实数据在 data 节点中。如果 errno 不为0，则需要提示 message。

简易版本代码实现。

  //通用的 Hybrid call Native
window.SDGbrHybrid = window.SDGbrHybrid || {};
var loadURL = function (url) {
    var iframe = document.createElement('iframe');
    iframe.style.display = "none";
    iframe.style.width = '1px';
    iframe.style.height = '1px';
    iframe.src = url;
    document.body.appendChild(iframe);
    setTimeout(function () {
        iframe.remove();
    }, 100);
};

var _getHybridUrl = function (params) {
    var paramStr = '', url = 'SDGHybrid://';
    url += params.tagname + "?t=" + new Date().getTime();
    if (params.callback) {
        url += "&callback=" + params.callback;
        delete params.callback;
    }

    if (params.param) {
        paramStr = typeof params.param == "object" ? JSON.stringify(params.param) : params.param;
        url += "&param=" + encodeURIComponent(paramStr);
    }
    return url;
};


var requestHybrid = function (params) {
    //生成随机函数
    var tt = (new Date().getTime());
    var t = "Hybrid_" + tt;
    var tmpFn;

    if (params.callback) {
        tmpFn = params.callback;
        params.callback = t;
        window.SDGHybrid[t] = function (data) {
            tmpFn(data);
            delete window.SDGHybrid[t];
        }
    }
    loadURL(_getHybridUrl(params));
};

//获取版本信息，约定APP的navigator.userAgent版本包含版本信息：scheme/xx.xx.xx
var getHybridInfo = function () {
    var platform_version = {};
    var na = navigator.userAgent;
    var info = na.match(/scheme\/\d\.\d\.\d/);
 
    if (info && info[0]) {
      info = info[0].split('/');
      if (info && info.length == 2) {
        platform_version.platform = info[0];
        platform_version.version = info[1];
      }
    }
    return platform_version;
};

Native 对于 H5 来说有个 Webview 容器，框架&&底层不太关心 H5 的业务实现，所以真实业务中 Native 调用 H5 场景较少。

上面的网络访问 Native 代码（iOS为例）

  typedef NS_ENUM(NSInteger){
    Hybrid_Request_Method_Post = 0,
    Hybrid_Request_Method_Get = 1
} Hybrid_Request_Method;

@interface RequestModel : NSObject

@property (nonatomic, strong) NSString *url;
@property (nonatomic, assign) Hybrid_Request_Method Hybrid_Request_Method;
@property (nonatomic, strong) NSDictionary *params;

@end


@interface HybridRequest : NSObject


+ (void)requestWithNative:(RequestModel *)requestModel hybridRequestSuccess:(void (^)(id responseObject))success hybridRequestfail:(void (^)(void))fail;

+ (void)requestWithNative:(RequestModel *)requestModel hybridRequestSuccess:(void (^)(id responseObject))success hybridRequestfail:(void (^)(void))fail{
    //处理请求不全的情况
    NSAssert(requestModel || success || fail, @"Something goes wrong");
    
    NSString *url = requestModel.url;
    NSDictionary *params = requestModel.params;
    if (requestModel.Hybrid_Request_Method == Hybrid_Request_Method_Get) {
        [AFNetPackage getJSONWithUrl:url parameters:params success:^(id responseObject) {
            success(responseObject);
        } fail:^{
            fail();
        }];
    }
    else if (requestModel.Hybrid_Request_Method == Hybrid_Request_Method_Post) {
        [AFNetPackage postJSONWithUrl:url parameters:params success:^(id responseObject) {
            success(responseObject);
        } fail:^{
            fail();
        }];
    }
}

常用交互 Api

良好的交互设计是第一步，在真实业务开发中有一些 Api 一定会由应用场景。

跳转

跳转是 Hybrid 必用的 Api 之一，对前端来说有以下情况：

页面内跳转，与 Hybrid 无关
H5 跳转 Native 界面
H5 新开 Webview 跳转 H5 页面，一般动画切换页面
如果使用动画，按照业务来说分为前进、后退。forward & backword，规定如下，首先是 H5 跳 Native 某个页面

  //H5跳Native页面
//=>SDGHybrid://forward?t=1446297487682&param=%7B%22topage%22%3A%22home%22%2C%22type%22%3A%22h2n%22%2C%22data2%22%3A2%7D
requestHybrid({
   tagname: 'forward',
   param: {
     // 要去到的页面
     topage: 'home',
     // 跳转方式，H5跳Native
     type: 'native',
     // 其它参数
     data2: 2
   }
});

H5 页面要去 Native 某个页面

  //=>SDGHybrid://forward?t=1446297653344&param=%7B%22topage%22%253A%22Goods%252Fdetail%20%20%22%252C%22type%22%253A%22h2n%22%252C%22id%22%253A20151031%7D
requestHybrid({
  tagname: 'forward',
  param: {
    // 要去到的页面
    topage: 'Goods/detail',
    // 跳转方式，H5跳Native
    type: 'native',
    // 其它参数
    id: 20151031
  }
});

H5 新开 Webview 的方式去跳转 H5

  requestHybrid({
  tagname: 'forward',
  param: {
    // 要去到的页面，首先找到goods频道，然后定位到detail模块
    topage: 'goods/detail  ',
    //跳转方式，H5新开Webview跳转，最后装载H5页面
    type: 'webview',
    //其它参数
    id: 20151031
  }
});

back 与 forward 一致，可能会有 animatetype 参数决定页面切换的时候的动画效果。真实使用的时候可能会全局封装方法去忽略 tagname 细节。

Header 组件的设计

Native 每次改动都比较“慢”，所以类似 Header 就很需要。

主流容器都是这么做的，比如微信、手机百度、携程
没有 Header 一旦出现网络错误或者白屏，App 将陷入假死状态

PS： Native 打开 H5，如果 300ms 没有响应则需要 loading 组件，避免白屏
因为 H5 App 本身就有 Header 组件，站在前端框架层来说，需要确保业务代码是一致的，所有的差异需要在框架层做到透明化，简单来说 Header 的设计需要遵循：

H5 Header 组件与 Native 提供的 Header 组件使用调用层接口一致
前端框架层根据环境判断选择应该使用 H5 的 Header 组件抑或 Native 的 Header 组件

一般来说 Header 组件需要完成以下功能：

Header 左侧与右侧可配置，显示为文字或者图标（这里要求 Header 实现主流图标，并且也可由业务控制图标），并需要控制其点击回调
Header 的 title 可设置为单标题或者主标题、子标题类型，并且可配置 lefticon 与 righticon（icon居中）
满足一些特殊配置，比如标签类 Header

所以，站在前端业务方来说，Header 的使用方式为（其中 tagname 是不允许重复的）：

   //Native以及前端框架会对特殊tagname的标识做默认回调，如果未注册callback，或者点击回调callback无返回则执行默认方法
 // back前端默认执行History.back，如果不可后退则回到指定URL，Native如果检测到不可后退则返回Naive大首页
 // home前端默认返回指定URL，Native默认返回大首页
  this.header.set({
      left: [
        {
          //如果出现value字段，则默认不使用icon
          tagname: 'back',
          value: '回退',
          //如果设置了lefticon或者righticon，则显示icon
          //native会提供常用图标icon映射，如果找不到，便会去当前业务频道专用目录获取图标
          lefticon: 'back',
          callback: function () { }
        }
     ],
     right: [
      {
        //默认icon为tagname，这里为icon
        tagname: 'search',
        callback: function () { }
      },
      //自定义图标
      {
        tagname: 'me',
        //会去hotel频道存储静态header图标资源目录搜寻该图标，没有便使用默认图标
        icon: 'hotel/me.png',
        callback: function () { }
      }
    ],
    title: 'title',
        //显示主标题，子标题的场景
    title: ['title', 'subtitle'], 
    //定制化title
    title: {
      value: 'title',
      //标题右边图标
      righticon: 'down', //也可以设置lefticon
      //标题类型，默认为空，设置的话需要特殊处理
      //type: 'tabs',
      //点击标题时的回调，默认为空
      callback: function () { }
    }
});

因为 Header 左边一般来说只有一个按钮，所以其对象可以使用这种形式：

  this.header.set({
  back: function () { },
    title: ''
});
//语法糖=>
this.header.set({
    left: [{
        tagname: 'back',
        callback: function(){}
    }],
  title: '',
});

为完成 Native 端的实现，这里会新增两个接口，向 Native 注册事件，以及注销事件：

  var registerHybridCallback = function (ns, name, callback) {
  if(!window.Hybrid[ns]) window.Hybrid[ns] = {};
  window.Hybrid[ns][name] = callback;
};

var unRegisterHybridCallback = function (ns) {
  if(!window.Hybrid[ns]) return;
  delete window.Hybrid[ns];
};

Native Header 组件实现：

  define([], function () {
    'use strict';

    return _.inherit({

        propertys: function () {

            this.left = [];
            this.right = [];
            this.title = {};
            this.view = null;

            this.hybridEventFlag = 'Header_Event';

        },

        //全部更新
        set: function (opts) {
            if (!opts) return;

            var left = [];
            var right = [];
            var title = {};
            var tmp = {};

            //语法糖适配
            if (opts.back) {
                tmp = { tagname: 'back' };
                if (typeof opts.back == 'string') tmp.value = opts.back;
                else if (typeof opts.back == 'function') tmp.callback = opts.back;
                else if (typeof opts.back == 'object') _.extend(tmp, opts.back);
                left.push(tmp);
            } else {
                if (opts.left) left = opts.left;
            }

            //右边按钮必须保持数据一致性
            if (typeof opts.right == 'object' && opts.right.length) right = opts.right

            if (typeof opts.title == 'string') {
                title.title = opts.title;
            } else if (_.isArray(opts.title) && opts.title.length > 1) {
                title.title = opts.title[0];
                title.subtitle = opts.title[1];
            } else if (typeof opts.title == 'object') {
                _.extend(title, opts.title);
            }

            this.left = left;
            this.right = right;
            this.title = title;
            this.view = opts.view;

            this.registerEvents();

            _.requestHybrid({
                tagname: 'updateheader',
                param: {
                    left: this.left,
                    right: this.right,
                    title: this.title
                }
            });

        },

        //注册事件，将事件存于本地
        registerEvents: function () {
            _.unRegisterHybridCallback(this.hybridEventFlag);
            this._addEvent(this.left);
            this._addEvent(this.right);
            this._addEvent(this.title);
        },

        _addEvent: function (data) {
            if (!_.isArray(data)) data = [data];
            var i, len, tmp, fn, tagname;
            var t = 'header_' + (new Date().getTime());

            for (i = 0, len = data.length; i < len; i++) {
                tmp = data[i];
                tagname = tmp.tagname || '';
                if (tmp.callback) {
                    fn = $.proxy(tmp.callback, this.view);
                    tmp.callback = t;
                    _.registerHeaderCallback(this.hybridEventFlag, t + '_' + tagname, fn);
                }
            }
        },

        //显示header
        show: function () {
            _.requestHybrid({
                tagname: 'showheader'
            });
        },

        //隐藏header
        hide: function () {
            _.requestHybrid({
                tagname: 'hideheader',
                param: {
                    animate: true
                }
            });
        },

        //只更新title，不重置事件，不对header其它地方造成变化，仅仅最简单的header能如此操作
        update: function (title) {
            _.requestHybrid({
                tagname: 'updateheadertitle',
                param: {
                    title: 'aaaaa'
                }
            });
        },

        initialize: function () {
            this.propertys();
        }
    });

});

请求类

虽然 get 类请求可以用 jsonp 方式绕过跨域问题，但是 post 请求是一个拦路虎。为了安全性问题服务器会设置 cors 仅仅针对几个域名，Hybrid 内嵌静态资源可能是通过本地 file 的方式读取，所以 cors 就行不通了。另外一个问题是防止爬虫获取数据，由于 Native 针对网络做了安全性设置（鉴权、防抓包等），所以 H5 的网络请求由 Native 完成。可能有些人说 H5 的网络请求让 Native 走就安全了吗？我可以继续爬取你的 Dom 节点啊。这个是针对反爬虫的手段一。想知道更多的反爬虫策略可以看看我这篇文章 Web反爬虫方案

这个使用场景和 Header 组件一致，前端框架层必须做到对业务透明化，业务事实上不必关心这个网络请求到底是由 Native 还是浏览器发出。

  HybridGet = function (url, param, callback) {

};
HybridPost = function (url, param, callback) {

};

真实的业务场景，会将之封装到数据请求模块，在底层做适配，在H5站点下使用ajax请求，在Native内嵌时使用代理发出，与Native的约定为

  requestHybrid({
  tagname: 'NativeRequest',
  param: {
    url: arg.Api + "SearchInfo/getLawsInfo",
    params: requestparams,
    Hybrid_Request_Method: 0,
    encryption: 1
  },
  callback: function (data) {
    renderUI(data);
  }
});

常用 NativeUI 组件

一般情况 Native 通常会提供常用的 UI，比如加载层loading、消息框toast

  var HybridUI = {};
HybridUI.showLoading();
//=>
requestHybrid({
    tagname: 'showLoading'
});

HybridUI.showToast({
    title: '111',
    //几秒后自动关闭提示框，-1需要点击才会关闭
    hidesec: 3,
    //弹出层关闭时的回调
    callback: function () { }
});
//=>
requestHybrid({
    tagname: 'showToast',
    param: {
        title: '111',
        hidesec: 3,
        callback: function () { }
    }
});

Native UI与前端UI不容易打通，所以在真实业务开发过程中，一般只会使用几个关键的Native UI。

账号系统的设计

Webview 中跑的网页，账号登录与否由是否携带密钥 cookie 决定（不能保证密钥的有效性）。因为 Native 不关注业务实现，所以每次载入都有可能是登录成功跳转回来的结果，所以每次载入都需要关注密钥 cookie 变化，以做到登录态数据的一致性。

使用 Native 代理做请求接口，如果没有登录则 Native 层唤起登录页
直连方式使用 ajax 请求接口，如果没登录则在底层唤起登录页（H5）

  /*
    无论成功与否皆会关闭登录框
    参数包括：
    success 登录成功的回调
     error 登录失败的回调
    url 如果没有设置success，或者success执行后没有返回true，则默认跳往此url
*/
HybridUI.Login = function (opts) {
    //...
};
//=>
requestHybrid({
    tagname: 'login',
    param: {
       success: function () { },
       error: function () { },
       url: '...'
    }
});
//与登录接口一致，参数一致
HybridUI.logout = function () {
    //...
};

在设计 Hybrid 层的时候，接口要做到对于处于 Hybrid 环境中的代码乐意通过接口获取 Native 端存储的用户账号信息；对于处于传统的网页环境，可以通过接口获取线上的账号信息，然后将非敏感的信息存储到 LocalStorage 中，然后每次页面加载从 LocalStorage 读取数据到内存中（比如 Vue.js 框架中的 Vuex，React.js 中的 Redux）

Hybrid 资源管理

Hybrid 的资源需要 增量更新 需要拆分方便，所以一个 Hybrid 资源结构类似于下面的样子

假设有2个业务线：商城、购物车

  WebApp
│- Mall
│- Cart
│  index.html //业务入口html资源，如果不是单页应用会有多个入口
│  │  main.js //业务所有js资源打包
│  │
│  └─static //静态样式资源
│      ├─css 
│      ├─hybrid //存储业务定制化类Native Header图标
│      └─images
├─libs
│      libs.js //框架所有js资源打包
│
└─static
   ├─css
   └─images

增量更新

每次业务开发完毕后都需要在打包分发平台进行部署上线，之后会生成一个版本号。

Channel	Version	md5
Mall	1.0.1	12233000ww
Cart	1.1.2	28211122wt2

当 Native App 启动的时候会从服务端请求一个接口，接口的返回一个 json 串，内容是 App 所包含的各个 H5 业务线的版本号和 md5 信息。

拿到 json 后和 App 本地保存的版本信息作比较，发现变动了则去请求相应的接口，接口返回 md5 对应的文件。Native 拿到后完成解压替换。

全部替换完毕后将这次接口请求到的资源版本号信息保存替换到 Native 本地。

因为是每个资源有版本号，所以如果线上的某个版本存在问题，那么可以根据相应的稳定的版本号回滚到稳定的版本。

一些零散的解决方案

静态直出

“直出”这个概念对前端同学来说，并不陌生。为了优化首屏体验，大部分主流的页面都会在服务器端拉取首屏数据后通过 NodeJs 进行渲染，然后生成一个包含了首屏数据的 Html 文件，这样子展示首屏的时候，就可以解决内容转菊花的问题了。
当然这种页面“直出”的方式也会带来一个问题，服务器需要拉取首屏数据，意味着服务端处理耗时增加。
不过因为现在 Html 都会发布到 CDN 上，WebView 直接从 CDN 上面获取，这块耗时没有对用户造成影响。
手 Q 里面有一套自动化的构建系统 Vnues，当产品经理修改数据发布后，可以一键启动构建任务，Vnues 系统就会自动同步最新的代码和数据，然后生成新的含首屏 Html，并发布到 CDN 上面去。

我们可以做一个类似的事情，自动同步最新的代码和数据，然后生成新的含首屏 Html，并发布到 CDN 上面去

离线预推

页面发布到 CDN 上面去后，那么 WebView 需要发起网络请求去拉取。当用户在弱网络或者网速比较差的环境下，这个加载时间会很长。于是我们通过离线预推的方式，把页面的资源提前拉取到本地，当用户加载资源的时候，相当于从本地加载，即使没有网络，也能展示首屏页面。这个也就是大家熟悉的离线包。
手 Q 使用 7Z 生成离线包, 同时离线包服务器将新的离线包跟业务对应的历史离线包进行 BsDiff 做二进制差分，生成增量包，进一步降低下载离线包时的带宽成本，下载所消耗的流量从一个完整的离线包（253KB）降低为一个增量包（3KB）。

https://mp.weixin.qq.com/s?__biz=MzUxMzcxMzE5Ng==&mid=2247488218&idx=1&sn=21afe07eb642162111ee210e4a040db2&chksm=f951a799ce262e8f6c1f5bb85e84c2db49ae4ca0acb6df40d9c172fc0baaba58937cf9f0afe4&scene=27#wechat_redirect

拦截加载

事实上，在高度定制的 wap 页面场景下，我们对于 webview 中可能出现的页面类型会进行严格控制。可以通过内容的控制，避免 wap 页中出现外部页面的跳转，也可以通过 webview 的对应代理方法，禁掉我们不希望出现的跳转类型，或者同时使用，双重保护来确保当前 webview 容器中只会出现我们定制过的内容。既然 wap 页的类型是有限的，自然想到，同类型页面大都由前端采用模板生成，页面所使用的 html、css、js 的资源很可能是同一份，或者是有限的几份，把它们直接随客户端打包在本地也就变得可行。加载对应的 url 时，直接 load 本地的资源。
对于 webview 中的网络请求，其实也可以交由客户端接管，比如在你所采用的 Hybrid 框架中，为前端注册一个发起网络请求的接口。wap 页中的所有网络请求，都通过这个接口来发送。这样客户端可以做的事情就非常多了，举个例子，NSURLProtocol 无法拦截 WKWebview 发起的网络请求，采用 Hybrid 方式交由客户端来发送，便可以实现对应的拦截。
基于上面的方案，我们的 wap 页的完整展示流程是这样：客户端在 webview 中加载某个 url，判断符合规则，load 本地的模板 html，该页面的内部实现是通过客户端提供的网络请求接口，发起获取具体页面内容的网络请求，获得填充的数据从而完成展示。

NSURLProtocol能够让你去重新定义苹果的URL加载系统(URL Loading System)的行为，URL Loading System里有许多类用于处理URL请求，比如NSURL，NSURLRequest，NSURLConnection和NSURLSession等。当URL Loading System使用NSURLRequest去获取资源的时候，它会创建一个NSURLProtocol子类的实例，你不应该直接实例化一个NSURLProtocol，NSURLProtocol看起来像是一个协议，但其实这是一个类，而且必须使用该类的子类，并且需要被注册。

WKWebView 网络请求拦截
方法一（Native 侧）：
原生 WKWebView 在独立于 app 进程之外的进程中执行网络请求，请求数据不经过主进程，因此在 WKWebView 上直接使用 NSURLProtocol 是无法拦截请求的。

但是由于 mPaas 的离线包机制强依赖网络拦截，所以基于此，mPaaS 利用了 WKWebview 的隐藏 api，去注册拦截网络请求去满足离线包的业务场景需求，参考代码如下：

  [WKBrowsingContextController registerSchemeForCustomProtocol:@"https"]

但是因为出于性能的原因，WKWebView 的网络请求在给主进程传递数据的时候会把请求的 body 去掉，导致拦截后请求的 body 参数丢失。

在离线包场景，由于页面的资源不需要 body 数据，所以离线包可以正常使用不受影响。但是在 H5 页面内的其他 post 请求会丢失 data 参数。

为了解决 post 参数丢失的问题，mPaas 通过在 js 注入代码，hook 了 js 上下文里的 XMLHTTPRequest 对象解决。

通过在 JS 层把方法内容组装好，然后通过 WKWebView 的 messageHandler 机制把内容传到主进程，把对应 HTTPBody 然后存起来，随后通知 JS 端继续这个请求，网络请求到主进程后，在将 post 请求对应的 HttpBody 添加上，这样就完成了一次 post 请求的处理。整体流程可以参考如下：

通过上面的机制，既满足了离线包的资源拦截诉求，也解决了 post 请求 body 丢失的问题。但是在一些场景还是存在一些问题，需要开发者进行适配。

方法二（JS 侧）：
通过 AJAX 请求的 hook 方式，将网络请求的信息代理到客户端本地。能拿到 WKWebView 里面的 post 请求信息，剩下的就不是问题啦。
AJAX hook 的实现可以看这个 Repo.

python使用深度神经网络实现识别暹罗与英短

Mon, 05 Feb 2018 11:25:59 CST

先来上两张图看看那种猫是暹罗？那种猫是英短？
第一张暹罗

第二张英短

你以后是不是可以识别了暹罗和英短了？大概能，好像又不能。这是因为素材太少了，我们看这两张图能分别提取出来短特征太少了。那如果我们暹罗短放100张图，英短放100张图给大家参考，再给一张暹罗或者英短短照片是不是就能识别出来是那种猫了，即使不能完全认出来，是不是也有90%可能是可以猜猜对。那么如果提供500张暹罗500张英短短图片呢，是不是猜对的概率可以更高？
我们是怎么识别暹罗和英短的呢？当然是先归纳两种猫的特征如面部颜色分布、眼睛的颜色等等，当再有一张要识别短图片时，我们就看看面部颜色分布、眼睛颜色是不是可暹罗的特征一致。
同样把识别暹罗和英短的方法教给计算机后，是不是计算机也可以识别这两种猫？
那么计算机是怎么识别图像的呢？先来看一下计算机是怎么存储图像的。

图像在计算机里是一堆按顺序排列的数字，1到255，这是一个只有黑白色的图，但是颜色千变万化离不开三原色——红绿蓝。

这样，一张图片在计算机里就是一个长方体！depth为3的长方体。每一层都是1到255的数字。
让计算机识别图片，就要先让计算机了解它要识别短图片有那些特征。提取图片中的特征就是识别图片要做的主要工作。
下面就该主角出场了，卷及神经网络(Convolutional Neural Network, CNN).
最简单的卷积神经网络就长下面的样子。

分为输入、卷积层、池化层(采样层)、全连接和输出。每一层都将最重要的识别信息进行压缩，并传导至下一层。
卷积层：帮助提取特征，越深(层数多)的卷积神经网络会提取越具体的特征，越浅的网络提取越浅显的特征。
池化层：减少图片的分辨率，减少特征映射。
全连接：扁平化图片特征，将图片当成数组，并将像素值当作预测图像中数值的特征。
•卷积层
卷积层从图片中提取特征，图片在计算机中就上按我们上面说的格式存储的（长方体），先取一层提取特征，怎么提取？使用卷积核（权值）。做如下短操作：

观察左右两个矩阵，矩阵大小从6×6 变成了 4×4，但数字的大小分布好像还是一致的。看下真实图片：

图片好像变模糊了，但这两个图片大小没变是怎么回事呢？其实是用了如下的方式：same padding

在6×6的矩阵周围加了一圈0，再做卷积的时候得到的还是一个6×6的矩阵，为什么加一圈0这个和卷积核大小、步长和边界有关。自己算吧。
上面是在一个6×6的矩阵上使用3X3的矩阵做的演示。在真实的图片上做卷积是什么样的呢？如下图：

对一个32x32x3的图使用10个5x5x3的filter做卷积得到一个28x28x10的激活图(激活图是卷积层的输出).
•池化层
减少图片的分辨率，减少特征映射。怎么减少的呢？
池化在每一个纵深维度上独自完成，因此图像的纵深保持不变。池化层的最常见形式是最大池化。
可以看到图像明显的变小了。如图：

在激活图的每一层的二维矩阵上按2×2提取最大值得到新的图。真实效果如下：

随着卷积层和池化层的增加，对应滤波器检测的特征就更加复杂。随着累积，就可以检测越来越复杂的特征。这里还有一个卷积核优化的问题，多次训练优化卷积核。
下面使用apple的卷积神经网络框架TuriCreate实现区分暹罗和英短。(先说一下我是在win10下装的熬夜把电脑重装了不下3次，系统要有wls,不要用企业版，mac系统和ubuntu系统下安装turicreae比较方便)
首先准备训练用图片暹罗50张，英短50长。测试用图片10张。
上代码：（开发工具anaconda，python 2.7）

数据放到了h盘image目录下，我是在win10下装的ubuntu,所以h盘挂在mnt/下。

test的文件：(x指暹罗，y指英短，这样命名是为了代码里给测试图片区分猫咪类型)

test_data[‘label’] = test_data[‘path’].apply(lambda path: ‘xianluo’ if ‘x’ in path else ‘yingduan’)
第一次结果如下：

训练精度0.955 验证精度才0.75 正确率才0.5。好吧，看来是学习得太少，得上三年高考五年模拟版，将暹罗和英短的图片都增加到100张。在看结果。

这次训练精度就达到0.987了，验证精度1.0，正确率1.0 牛逼了。
看下turicreate识别的结果：

我们实际图片上猫是：(红色为真实的猫的类型-在代码里根据图片名称标记的，绿色为识别出来的猫的类型)

可以看到两者是一致的。牛逼了训练数据才两百张图片，就可以达到这种效果。

python使用深度神经网络实现识别暹罗与英短，首发于 Cobub。

欢迎来到后 ASO 时代

Thu, 06 Jul 2017 14:50:52 CST

6 月 WWDC 上所宣布的「App Store 将迎来大改版」的消息，给 ASO 界砸下了一枚重磅炸弹。虽说 iOS11 要到今年秋季才会正式推送，且正式版面世到大面积使用还需要一定时间，到底会不会迎来一个新的 ASO 时代，目前尚不可知。

为了做好迎接新时代的准备，咱们先来看看苹果砸下的到底是一枚什么样的「炸弹」。

搜索改动还算小

「搜索」入口所带来的可观流量，是我们「做关键词」的立足点。ASOer 的主要工作之一就是，做到当用户搜索相关关键词的时候，我们的 应用会出现在搜索结果中且排名前列。

到了 iOS11 之后搜索将会发生哪些变化呢？我们就按照「搜索 -> 应用详情 -> 下载」这条路径来看看。

搜索入口
- 搜索入口从右二被挪到到右一的位置
- 热搜词从 10 个降为 7 个
虽然官方从未公开过热搜词的筛选算法，但根据长期观察，我们发现 热搜词会受到搜索频次、短期下载次数、社会化分享、用户评分评论和苹果人为干涉等影响。

可以发现除了苹果人为干涉之外，其他几个影响热搜词的因素都是可控的，所以刷榜或是积分墙依然有存在意义，也将无法杜绝。
搜索结果
- 应用名不折行，「副标题」可能显示不全
- 应用名下方默认展示应用所在的次分类（是的每个应用可以设置主分类和次分类）
- 应用截图展示三张，应用视频可以展示三个
目前，为了扩张词库、增加关键词权重，我们所谓的副标题其实是在「应用名称」的位置，用连字符与应用名区分开。从本质上来说“企鹅FM-做电台直播, 听有声书情感音乐广播剧”应该都是算作「应用名称」。 在新版搜索结果中设置过副标题的应用名基本显示不全。

还好，此次大改版 新增了“subtitle”字段（注：后文均用 subtitle 表示苹果规定的副标题，以区分人为设置的副标题），也就是 App Store 的「亲生副标题」。如果设置了，它会出现在应用名称下方，也就是上图中应用次分类的位置。subtitle 对于关键词收录和用户查看应用详情页的可能性都会有影响。它似乎和安卓平台上的一句话简介有了相似的作用。

应用截图二变三、视频一变三，换言之，搜索结果中能传达给用户的信息更多了。听起来是个好事，但多不一定是好，也可能是一个坑。虽然系统升级了，但多数用户的硬件并没有升级，要在 iPhone6 或者 iPhone7 的屏幕上多塞入一张截图，就需要运营和视觉把控好传达的信息。画布没有变大，但能承载的信息变多了，也可以算是一种诱惑吧。
应用详情页
- 自然，应用名称显示完整。应用名下方默认显示次分类，有 subtitle 则显示 subtitle
- What’s new 被放到了第一屏，默认显示前三行
- 应用详情、评分评论和相关应用依次排列在应用截图之后，相关应用推荐甚至到了最后一屏
值得注意的是，原来被排在描述之后的 What’s new ，在大改版中突然翻身做主，坐到了黄金位置，虽然不知道官方的意图，但这无疑又是一块可运营的空间，值得思考如何将它变成一个拉新工具。

其实评分在 What’s new 上方也有，但是用户评论是在第二屏位置。笔者对于描述和用户评论无甚想法，但对被放到了最后一屏的相关应用推荐，就略有担忧。毕竟通过友链还是能引一部分流量的，现在位置被调整到了犄角旮旯，来自于此的流量多少将会受到影响。

榜单 Jobs 估计都不认识了

榜单改动虽大，但影响不及搜索。假如幸运地被推荐，很是可以捧着当日新增笑了。

tab 换血
- 「今天」取代「精品推荐」
- 「游戏」成为与 APP 同级的入口
- 「类别」和「排行榜」不再是一级入口
值得一说的是，「游戏」被升级为一个单独的 tab。笔者认为这可能是苹果在平衡 App Store 的公平性和调整营收力度：其他互联网产品的流量和游戏的流量都不在一个量级上，而游戏 App 所带来的营收也不是其他产品可以拍马追上的。
每日更新的「今天」
- 卡片式设计风格
- 庞大的人工编辑团队
- 从原来每周更新到每日更新
目前公认的未来最大流量入口就是「今天」，除了推荐 App 之外，还有专题、文章……这不仅仅是一个卖应用更新应用的杂货铺，是要发展成能看电影吃饭的购物商场，将用户更长久地留在 App Store 中。业界对于上推荐位的普遍看法是，如果 应用中使用到苹果主推的新技术（比如 AR）或者新 API，那么上推荐位的几率将大大提高。
收归了「类别」和「排行榜」的「APP」
- 取消「畅销榜」
- 「付费榜」、「免费榜」和「类别」依次在倒数第二屏到最后一屏的位置
- 「付费榜」和「免费榜」默认展示前三位，可左右滑动或点右上角「查看全部」查看榜单
传言取消畅销榜是因为刷榜太多，规则玩崩了，所以苹果直接取消畅销榜让刷榜没得玩。不过这个事情…笔者认为刷榜公司还是能够找到对策的。

对于不刷榜的我们受到更大影响的可能是「类别」的移动，这一举动相当于从一级入口到了三级入口（毕竟是最后一屏）。来自分类的流量将会受到一定影响，所以更要通过把握搜索来挽回损失的流量。

其他

除新增的 subtitle 字段之外，App Store 还新增了「宣传文本」字段，限制 170 字， 可以随时更改不需要审核。成功提交后，这段文字会出现在应用描述之上，应用截图之下，大概第二屏的位置。通常应用截图在第一屏是无法显示完整的，用户大概率上会看到第二屏，也就 很容易看到「宣传文本」。

这个新增字段对重运营的产品，可是个好消息。通常一个版本里运营会推好几拨活动，可惜描述不能随时更改，活动也无法同步到 App Store。「宣传文本」的存在，让 运营也能在 App Store 都做上文案推广啦。

总结

秋季 iOS11 才会正式推出，到完成市场占有还有挺长一段时间，但 iTunes Connect 已经可以提交这些新字段的内容了，各位 ASOer 做好如何准备准备，相信能够轻松平稳过渡到后 ASO 时代：

提交新字段「subtitle」，同时兼顾好副标题的展现效果
可以提供适配三张应用截图/三个应用视频的设计方案
根据运营节奏更新「宣传文本」字段
来自榜单和类别的流量可能减少，要抓紧搜索入口，可以从技术手段上争取苹果的推荐位

笔者认为 App Store 的大改版至少看到了官方的两个态度：打击刷榜；强调营收。最终目的都是调整流量。

打击刷榜就好比游戏公司不许外挂了，人民币玩家会不爽，但对于从不用外挂的普通玩家而言，目前还算是好消息。

虽然独立的「游戏」，调整了入口的「类别」和「排行榜」多少都会影响到流量的导向，但新出的 subtitle、「宣传文本」和应用截图展现等等都扩大了运营空间。

参考资料

App 繁荣时代已经过去，多数开发商面临增长困境

Fri, 10 Jun 2016 21:09:36 CST

在 App 刚兴起的几年，科技网站热衷于对比各平台的应用数量，如今，这样的新闻基本已经很少了。据 Recode 网站引用的一些数据表明，App 的繁荣时代的确已经过去了。

独立应用开发者或者发行商对此早已知晓。早在 2014 年 8 月，开发者 Dan Frommer 就在 QZ 网站表达过这种想法。当时的市场调研机构 comScore 的数据表明，65.5% 的美国用户每月的 App 下载量是 0。

如今，大型的 App 发行商也面临增长缓慢的局面了。上月，排名前 15 位 App 的下载量平均下降了 20%。

在美国以外，这些应用的平均增长率是 3%。

值得注意的是，Snapchat 和 Uber 是个例外，这两个应用的增长率仍然惊人。2015 年 5 月，Snapchat 的下载量是 1300 万次，而今年 6 月，下载量已经增长到 2700 万次，同比增长达到 109.9%；Uber 的下载量也从 530 万次增长到 1090 万次，同比增长达到 107.6%。

总之，在已经饱和的 App 市场，要取得突破已经非常困难了。不过，Recode 网站认为，下载量并不能完全反映 App 发行商的实际状况。以 Facebook 为例，虽然它的 App 下载量已经很难增长，但盈利却非常好，同时，目前的状况其实有利于 Facebook 的 App 安装广告，因为这种广告面向的是急于寻求用户的 App 发行商。

题图来自 tapsmart

积木

The wind is rising,we must try to live.

邮箱 Twitter 新浪微博 Google+ 4

#欢迎关注爱范儿认证微信公众号：AppSolution（微信号：appsolution），发现新酷精华应用。

爱范儿 | 原文链接 · 查看评论 · 新浪微博

App设计者需要注意的21条禁忌

Sat, 19 Sep 2015 14:04:46 CST

我们通常在做APP设计的过程中，遇到很多看似很小，且很容易被忽略的问题，正是这些小问题，一次次的撩拨用户的耐心，让用户对你的APP心生怨念。现在WeX5君呕血为大家整理出APP设计的21条禁忌，希望与APP设计者的您共勉。

1. 不要在没有流程图之就前开始设计或者画线框图

即便一个简单的 APP 也要有一个思虑周全的流程图，以确保在 APP 有合乎逻辑的、合理的导航结构。另一点值得关注的是确保核心功能所在的屏幕位于上层而不是被埋没在多层导航元素之下。

跳过流程图直接进进入开发会让开发变得复杂、不可控，很容易让用户迷茫，最后选择关掉或者卸载你的 App。

2. 分工要明确不要忽略开发预算

设计师创建的每一个细节都要经过开发者才能变得活灵活现。花几个小时和几天时间做出的简单设计更改对 App 功能的影响是截然不同的。还有，设计不能命令功能。比如，一个计划好的 App 可能有一个搜索框，设计师预想的是一个产生实时结果的键入搜索，但设计师不能是做这个重大决定的唯一决策人。

3. 不要随意使用介绍动画

在用户首次打开 App 的时候，给用户一个动画的介绍是个不错的想法，但不能太过火了。事实上，这些介绍动画也延迟了用户接触 App 的时间。如果你打算使用介绍动画，那要让动画时间尽可能短，设计尽可能精细以及足够吸引人，值得用户花费时间等待。

App 加载过程中会先展现图片，再过渡至动画。要确保这个过度是平滑的，贴切自然的。有的 App 从加载图片过渡至介绍动画设计的非常蹩脚，这就很无趣了。

4. 别让用户空等

App 加载时间过长很容易让用户以为出现了什么故障，也会带来糟糕的用户体验。App 加载的时候不要让用户看到空白的屏幕，使用加载指示条或者小动画让用户知道 App 处于正常运行当中。如果能加入一个加载进度指示条就更好了。

5、没有不可点击的效果

一般按钮会有四态，不可点击效果、可点击效果、聚焦状态、按下状态。

如果你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导。

6、菜单层次太深

菜单项以5~7个为宜，如果有二级菜单，就要注意合理的菜单分类，不能有太多层级的菜单，否则很难预期，也很难找到，寻找和返回都会变得很麻烦。

7、文字长度不加以限制

APP界面很小，寸土寸金，一页只能显示下6~10个列表，一行只能显示下10~16个字，标题栏的字数以5个以内为宜，标签栏也以2~3个为宜，那么这时候出现文字过长的情况，一定要定义一下处理方式，如果是选择型的，一般是截断或者打点缩略;如果是内容阅读型的，可以折行。但最合理的方式还是精简文字内容，缩短文字长度。

8、文字表意不明

由于APP是碎片时间、片段式阅读，所以APP界面上的文字表意性要求的更高，更苛刻，一定要在用户瞟到的瞬间，准确的传达信息。除了表意清晰之外，还要求语言精简，避免啰嗦;使用用户的语言而不是程序的语言;产品文案体现产品性格。

9、交互流程分支太多

做交互的时候一定要有一个任务流程的概念贯穿始终，用户是为了完成某个任务而使用软件的，交互设计师除了关注界面元素、跳转逻辑和交互反馈之外，还要关注用户任务，分得清主要任务和次要人物，给主要任务一个畅通无阻的清晰流程，不要给予太多可能的分支，干扰主要流程。

10、相关的选项离的很远

相关选项一定要具有操作上的延续性，虽然APP屏幕看起来比电脑屏幕要小的多，但是APP在屏幕上移动的代价，却要比鼠标在电脑上移动的代价大的多，如果手机上相关选选离得很远的话，用户一是容易迷失，找不到下一步操作，二是需要移动手指，到屏幕另一端触发操作。

11、一次载入太多的数据

流量、电量、速度和稳定性是APP产品的四个硬指标，如果你的应用不能合理的帮助用户节约流量、电量，提升浏览速度和浏览体验，保证应用的稳定性能，就不要谈什么用户体验。你可以利用预加载缓存、批量载入、动态刷新、服务端数据压缩等方式来保证省、快、稳基础体验。

12、按钮可点击范围比看起来小

我们都知道移动端有个神奇的数字“44”，根据食指最小点触距离7mm、拇指最小点触距离9mm，可以推导出做设计的时候，最小的点触距离是44*32 px。你可以设计一个精美的小图标，但是在定义它的点触大小的时候，却可以做放大处理，但你千万不要设计一个傻大的图标，点触范围却比图标要小，这样会给用户带来明显的误操作挫败感。

13、标签页跟内容没有从属关系

标签页跟内容需要有很好的联动关系，一般一个界面内有二级标签就足够复杂了，千万不要再有三级标签、四级标签。每个标签页都有自己特有的内容，当切换标签的时候，内容跟着切换。标签页如果是点击切换，内容部分可以整体刷新，标签页如果是滑动切换，内容页也要跟着滑动切换，千万不要一个点、一个滑。

14、把所有的操作都暴露出来

APP产品交互设计要经历缩减、隐藏、附加、组织的过程，千万不要妄图把什么功能、什么操作都暴露出来，以彰显强大。你需要把自己应用的所有功能所有操作做个优先级设定，那些常用的20%的功能，放在界面的主要位置上，其他80%的操作，放在次要位置或合理归类组织后，隐藏起来就可以了。

15、没有空数据界面设计

我们在做设计的时候，往往是提供理想化的场景，用户都已经进来了，我们怎么玩。但是，往往应用刚推出的时候，是没有用户的，甚至当应用有了一定用户基础的时候，新进来的用户打开应用的时候，应用仍然可能是一种没有数据的状态，再或者当用户清楚了全部数据，这三种情况下，用户都可能遇到空数据的界面。新手设计师往往不加设计，这时候用户就会看到一个空白界面，茫然失措。有经验的做法就是，提供一个情感化的界面，告诉用户当前没有内容;更具引导性的做法，就是引导用户去执行操作。

16、用户引导的滥用

去年就预言用户引导将要泛滥，很明显设计部门都喜欢用漂亮的引导界面告诉用户新增的功能或隐藏的应用，但不是所有的应用、所有的功能都需要花哨的引导的。如果是通用的功能、非重点的模块，根本就不需要引导;如果是功能告知，只需呀轻量级的引导;如果是版本更新说明，说明书式的引导可以采用，但是要言简意赅。

17、无加载中状态

APP产品只要是需要联网，需要交换数据，都需要提供一个加载中状态的，无论是菊花转还是Toast还是对话框，你需要给开发人员一个全局的定义，并且要告知加载中是模态(前台加载)的还是非模态的(后台加载)。且要考虑到加载时间过长、网络开关没有打开、网络不通等情况分别怎么去处理。

18、未定义Back的逻辑

在为Android做设计的时候，会涉及到硬件交互，其中Back键的使用，是一门学问，Android官方有一些指导原则可以借鉴，但是具体开发的时候，还是会有很多特殊情况，比如单一实例的替换、键盘及一些中间状态，这种情况下，Back可能需要被定义一下，该回到前一个实例(那就需要变成多实例了)还是该回到初始状态(清空输入内容或恢复初始状态)。

19、无横屏模式的设计

由于横屏模式下，纵向空间变得格外宝贵，导航栏、标签栏、键盘都需要被压扁，横盘模式一定要考虑是简单拉伸适配还是重新设计，如果你的应用不适合在横屏模式下使用，就屏蔽横盘，如果你的应用包括应用widget都需要支持横盘模式(甚至是带侧滑键盘的横屏机器)，就需要提供设计方案。

20. 不要忘记手势但不要滥用

不是每个元素都是可视化的，比如 iPhone Mail app 的删除进程。在收件箱内，用户可以猛击屏幕显示删除按钮，用户就不用点击“编辑”，选择信息然后再删除信息。不过，也不能说“编辑”菜单一点用处都没有，不知道快捷操作的用户还是需要的，而用户还可以通过“编辑”菜单一次性标注多条信息/邮件。

21. 不要觉得每个用户有着跟你一样的 App 使用方式

可用性测试是必须的，不管你的 App 看起来多么好。找值得信任的人(或者有经验的设计师)进行小范围封闭测试，在公开发布之前更新下界面。另一个简单易行的获得用户反馈的方法是在分类网站张贴广告招募合适的人进行焦点小组测试。

22.怎么才21条？

App江湖上传言多年的关于多屏、多分辨率、多端、多操作系统支持的若干注意呢？

在WeX5君的世界观里，移动开发者不需要、不应该操心这个问题。

作者：WeX5君

微信公众号：起步软件

互联网人士必备微信公众号：woshipm，雷军和周鸿祎都关注了，如果你已经关注了，证明你已经很牛逼了。

App Annie：2015年移动游戏收入占移动应用市场总收入85%

Thu, 11 Feb 2016 19:13:14 CST

2016年2月11日，市场研究公司App Annie公布报告称，2015年移动游戏收入在整体移动应用市场总收入中所占比例达到了85%左右，全球移动游戏收入达348亿美元。

这项数据是App Annie针对所有移动应用未来增长趋势而编制的一份广泛报告的部分内容，该报告预计到2020年时整体应用经济规模将从今天的510亿美元增长至1010亿美元。报告还称，2016年移动游戏收入将达415亿美元，到2020年则将达到746亿美元。如果将所有板块中的全部游戏相关收入都加到一起，那么人们就会发现，游戏市场的全球规模已经达到了令人瞠目结舌的极高水平。

报告预测，游戏应用的增长将来自于成熟市场强劲的商业化进程，尤其是中国的一、二线城市以及日本和韩国等市场的增长。

值得指出的是，其他一些预测来源对于游戏应用的前景则有着不同的展望。投资机构Digi-Capital的科技顾问预测，到2020年游戏软件行业的规模与2016年的900亿美元相比将增长22%，达1150亿美元。Digi-Capital称，游戏行业正在继续进行一场大规模的转型；随着各个板块的“潮涨潮落”，市场领导者正致力于巩固自身地位。现在的增长率是健康的，但已经不像过去几年时间里那样高了，原因是整体行业已变得更加成熟。

与此同时，市场研究公司EEDAR估测称，2015年游戏机软件和硬件市场的总规模为440亿美元。另一家研究公司Jon Peddie Research则预测，2016年全球个人电脑（PC）游戏硬件销售额将从2015年的246亿美元增长至261亿美元，到2018年则将增长至300亿美元。

另外，“开放游戏联盟”（Open Gaming Alliance）预测，到2018年时个人电脑游戏软件行业的规模将扩大至350亿美元，相比之下2014年为260亿美元。

您可能也喜欢的文章：
App Annie：新型应用市场展望（附报告）	App Annie：顶层发行商数量减少，收入增加	App Annie：2014年6月中国移动游戏应用指数排名	App Annie：2015 年全球移动应用市场回顾（附下载）	App Annie Japan：2014年日本和海外的移动APP、游戏动向
无觅

App Store编辑推荐背后的秘密：70%为游戏

Fri, 04 Mar 2016 20:34:27 CST

应用在AppStore上线之后，它的可发现性便成为了开发者们不得不去面对的问题。其实，除了在榜单及关键词中占位来吸引自然流量，苹果公司还为我们提供了一个能让应用获得大面积曝光的绝佳位置——AppStore首页精品推荐。而在此页中，最吸睛的版块当属“编辑选荐”。

如何才能登上“编辑选荐”，为应用争取到更多的关注和流量呢?近日，在美国著名移动广告公司网站上有一篇有意思的文章，里面详细介绍了那些登上过“编辑选荐”版块的应用所具有的特征。这些数据或许能让我们更加了解小编的“口味”，成功摘取小编心目中的”小金人“。接下来，就让我们详细了解一下。

游戏VS其他类别

2012年5月，苹果公司在AppStore推出了“编辑选荐”版块。当时第一个被放在该位置的应用是一款金融类应用。不过从那之后，“编辑选荐”位置再也没有出现过任何一款金融类应用。那登上“编辑选荐”位置的应用到底都是哪种类型的应用呢?

据调查结果显示，在“编辑选荐”版块所收录的应用中，游戏类应用占比最高，达到了65%(虽然在AppStore所有的应用中，游戏类应用仅占25%);仅次于游戏类应用的是教育类应用，占到9%;接着是健康健美、摄影与录像以及社交这三大类应用，分别占到5%。然后是效率和参考类应用，占了2%;最后是图书、娱乐等类别的应用，大约各占了1%。

　　除了以上数据之外，2014年，在登上“编辑选荐”版块的应用中，有55%的应用是游戏类应用。而2015年，这个数字达到70%。

“编辑选荐”版块中的游戏类应用比重越来越大的现象进一步证明了苹果公司对游戏类应用的重视。

AppStore管理得很像一个零售商店，什么挣钱就会卖什么。而目前游戏类应用比其他应用更能赚钱，所以苹果公司对它们的关注自然会更多。

除了遵循几个基本参数之外，苹果的小编会选择他们认为最畅销的应用，而现在最畅销的应用无疑是游戏类(在AppStore的畅销应用排行榜中，大约70%以上的应用是免费的游戏)。这表明，游戏开发者比其他类型应用的开发者拥有更多的机会得到“编辑选荐”这个位置。如果你是游戏开发者，不妨把登上“编辑选荐”作为目标之一。

免费VS付费

针对应用的免费以及付费情况进行了详细的研究，据调查结果显示，在“编辑选荐”板块所收录的所有应用中，免费应用大约占了2/3，而付费应用仅占1/3左右。

　　此外，2012年，在“编辑选荐”所收录的前30个应用中，只有47%的应用是免费的，也就说，有一半以上是付费的。而在“编辑选荐”最近收录的30个应用中，大约有70%是免费的。

虽然当前“编辑选荐”版块所收录的应用更倾向于免费应用，但苹果进行挑选的主要关注点并不在于应用是付费还是免费，而在于应用是否最具价值，且会不会为苹果带来更多利益并为AppStore的用户带去更多乐趣。

对接GameCenterVS没有对接GameCenter

GameCenter(游戏中心)是苹果公司专门为游戏玩家们设计的社交网络平台，类似于iTunes中专门为歌迷设计的Ping。通过GameCenter，不仅可以玩游戏，还可以和朋友共享游戏、查看自己在排行榜中的排名等。

对游戏类应用是否对接GameCenter也进行了一番研究，据调查结果显示，在被推荐到“编辑选荐”位置的游戏中，只有19%的游戏没有对接GameCenter。在那些没有对接GameCenter的游戏中，有80%的应用来自专业的游戏工作室。

　　随着手游市场的不断扩大，活跃在iOS平台上的游戏厂商们为了增加玩家的粘性，同时确保游戏的前途(GameCenter是苹果自家的，苹果喜欢“喜欢苹果”的人，其中的缘由不说，相信你也懂得)纷纷开始接入苹果的GameCenter。当然，这不是硬性规定，但如果你是游戏开发者且想获得更多博人眼球的机会，不妨考虑对接GameCenter。

苹果更愿意推荐那些拥有品牌特色的游戏，毕竟强大的品牌意味着更少的风险，且公司名称或IP也能驱动用户下载。

结论

AppStore中的应用越来越多，让应用迅速出现在用户眼前已不是轻易能做到的事情了。如果你想通过“编辑选荐”这个位置让应用获得大面积曝光，不妨让自己的产品更贴近以上特征，这样更容易赚取苹果小编的眼球。如果你的产品已经具备了这些特征，而你又不想把时间浪费在等待上，那就主动给苹果小编写封邮件介绍你的产品吧!相信最终的效果不会让你失望。

来源：腾讯游戏

您可能也喜欢的文章：
免费游戏统治了App Store 如何实现盈利？	Xyologic:苹果App Store游戏下载中40%为免费应用	Sensor Tower：2015年12月App Store游戏收入将近10亿美元	App Store十款最赚钱游戏：部落战争日赚400万	Distimo：App Store免费游戏榜单日均下载标准日均下载量需到2.5万次
无觅

摸透各大应用市场:靠什么厮杀？

Fri, 29 May 2015 17:55:00 CST

APP推广优质的资源和用户都相对集中在几个应用市场上，传统的移动互联网巨头更容易拥有大规模的用户、流量基础和高质量的开发者资源等。下面为大家列举几个国内比较热门的应用市场，逐一进行分析，看看这些应用市场靠什么在彼此拼杀。摸清他们的套路，渠道分发才能玩儿的好。

典型应用市场分析

图片来自：北京大学市场与媒介研究中心2014年6月份《移动分发市场研究报告》

百度应用分发平台

百度手机分发平台包括百度手机助手、安卓市场、91助手，在无提示第一提及率、应用安装使用率等方面，有显著的优势。百度应用分发平台整体安装率为70.4%，同上期（66.4%）相比，提升四个百分点，稳居市场第一位。其中百度应用分发平台下的三个应用市场均超过30.0%的安装率，同上期相比，百度手机助手的安装率提升近12个百分点。在使用率方面，百度应用分发平台达到62.1%，其中百度手机助手和安卓市场相对91手机助手更为强势。

（1）百度手机助手

百度手机助手以年轻和中年人为主，25-44岁比例较高，其中个人月收入税前6000元以上的人高于总体水平，占64%。

（2）91助手

91助手的女性用户及一线城市用户的比例在主要竞争对手中是最高的，主要为25-29岁的年轻人。月收入在4000-6000元的中等收入人群比例最高。

（3）安卓市场

安卓市场主要用户群为25-44岁人群，他们的手机以2500-3000元的中端机和3500-6000元高端机为主。其管理层用户群体在百度应用分发平台中最高，且比总体水平高出4.8%。另外，安卓市场用户的使用时长较长，居主要竞争对手中最高，有12.2%的人每次使用超过半小时，对于一个主要功能为寻找和下载app的应用市场来说，这样的使用时长是令人瞩目的。

2、360手机助手

目前360手机助手已经拥有超过4亿用户，累计下载应用数量超过320亿次。2014年，在360手机助手上首发的软件超过1500款，即平均每月有250款，每周首发软件数量高达60款。

其无提示第一提及率为21.1%，紧跟百度应用分发平台。应用安装率、使用率分别为53.1%与47.2%，对于单一应用商店来说，成绩不俗。

360手机助手的用户中，18-24岁及45岁以上中老年人偏多，有52.7%的用户属于6000元以下中低收入水平，且使用的多位2000元以下中低端机型。人群受教育程度多集中在大学以下，且二线城市用户最多，高于其他应用市场。

Hybrid APP架构设计思路

Thu, 07 Jan 2016 09:41:35 CST

关于Hybrid模式开发app的好处，网络上已有很多文章阐述了，这里不展开。

本文将从以下几个方面阐述Hybrid app架构设计的一些经验和思考。

原文及讨论请到 github issue

通讯

作为一种跨语言开发模式，通讯层是Hybrid架构首先应该考虑和设计的，往后所有的逻辑都是基于通讯层展开。

Native（以Android为例）和H5通讯，基本原理：

Android调用H5：通过webview类的 loadUrl方法可以直接执行js代码，类似浏览器地址栏输入一段js一样的效果
```
    webview.loadUrl("javascript: alert('hello world')");
```
H5调用Android：webview可以拦截H5发起的任意url请求，webview通过约定的规则对拦截到的url进行处理（消费），即可实现H5调用Android
```
    var ifm = document.createElement('iframe');
ifm.src = 'jsbridge://namespace.method?[...args]';
```

JSBridge即我们通常说的桥协议，基本的通讯原理很简单，接下来就是桥协议具体实现。

P.S：注册私有协议的做法很常见，我们经常遇到的在网页里拉起一个系统app就是采用私有协议实现的。app在安装完成之后会注册私有协议到OS，浏览器发现自身不能识别的协议（http、https、file等）时，会将链接抛给OS，OS会寻找可识别此协议的app并用该app处理链接。比如在网页里以 itunes://开头的链接是Apple Store的私有协议，点击后可以启动Apple Store并且跳转到相应的界面。国内软件开发商也经常这么做，比如支付宝的私有协议 alipay://，腾讯的 tencent://等等。

桥协议的具体实现

由于JavaScript语言自身的特殊性（单进程），为了不阻塞主进程并且保证H5调用的有序性，与Native通讯时对于需要获取结果的接口（GET类），采用类似于JSONP的设计理念:

类比HTTP的request和response对象，调用方会将调用的api、参数、以及请求签名（由调用方生成）带上传给被调用方，被调用方处理完之后会吧结果以及请求签名回传调用方，调用方再根据请求签名找到本次请求对应的回调函数并执行，至此完成了一次通讯闭环。

H5调用Native（以Android为例）示意图：

Native（以Android为例）调用H5示意图：

基于桥协议的api设计（HybridApi）

jsbridge作为一种通用私有协议，一般会在团队级或者公司级产品进行共享，所以需要和业务层进行解耦，将jsbridge的内部细节进行封装，对外暴露平台级的API。

以下是笔者剥离公司业务代码后抽象出的一份HybridApi js部分的实现，项目地址：

hybrid-js

另外，对于Native提供的各种接口，也可以简单封装下，使之更贴近前端工程师的使用习惯：

  // /lib/jsbridge/core.js
function assignAPI(name, callback) {
    var names = name.split(/\./);
    var ns = names.shift();

    var fnName = names.pop();
    var root = createNamespace(JSBridge[ns], names);

    if(fnName) root[fnName] = callback || function() {};
}

增加api：

  // /lib/jsbridge/api.js
var assign = require('./core.js').assignAPI;
...
assign('util.compassImage', function(path, callback, quality, width, height) {
    JSBridge.invokeApp('os.getInfo', {
        path: path,
        quality: quality || 80,
        width: width || 'auto',
        height: height || 'auto',
        callback: callback
    });
});

H5上层应用调用：

  // h5/music/index.js
JSBridge.util.compassImage('http://cdn.foo.com/images/bar.png', function(r) {
    console.log(r.value); // => base64 data
});

界面与交互（Native与H5职责划分）

本质上，Native和H5都能完成界面开发。几乎所有hybrid的开发模式都会碰到同样的一个问题：哪些由Native负责哪些由H5负责？

这个回到原始的问题上来：我们为什么要采用hybrid模式开发？简而言之就是同时利用H5的跨平台、快速迭代能力以及Native的流畅性、系统API调用能力。

根据这个原则，为了充分利用二者的优势，应该尽可能地将app内容使用H5来呈现，而对于js语言本身的缺陷，应该使用Native语言来弥补，如转场动画、多线程作业（密集型任务）、IO性能等。即总的原则是H5提供内容，Native提供容器，在有可能的条件下对Android原生webview进行优化和改造（参考阿里Hybrid容器的JSM），提升H5的渲染效率。

但是，在实际的项目中，将整个app所有界面都使用H5来开发也有不妥之处，根据经验，以下情形还是使用Native界面为好：

关键界面、交互性强的的界面使用Native

因H5比较容易被恶意攻击，对于安全性要求比较高的界面，如注册界面、登陆、支付等界面，会采用Native来取代H5开发，保证数据的安全性，这些页面通常UI变更的频率也不高。

对于这些界面，降级的方案也有，就是HTTPS。但是想说的是在国内的若网络环境下，HTTPS的体验实在是不咋地（主要是慢），而且只能走现网不能走离线通道。

另外，H5本身的动画开发成本比较高，在低端机器上可能有些绕不过的性能坎，原生js对于手势的支持也比较弱，因此对于这些类型的界面，可以选择使用Native来实现，这也是Native本身的优势不是。比如要实现下面这个音乐播放界面，用H5开发门槛不小吧，留意下中间的波浪线背景，手指左右滑动可以切换动画。

导航组件采用Native

导航组件，就是页面的头组件，左上角一般都是一个back键，中间一般都是界面的标题，右边的话有时是一个隐藏的悬浮菜单触发按钮有时则什么也没有。

移动端有一个特性就是界面下拉有个回弹效果，头不动body部分跟着滑动，这种效果H5比较难实现。

再者，也是最重要的一点，如果整个界面都是H5的，在H5加载过程中界面将是白屏，在弱网络下用户可能会很疑惑。

所以基于这两点，打开的界面都是Native的导航组件+webview来组成，这样即使H5加载失败或者太慢用户可以选择直接关闭。

在API层面，会相应的有一个接口来实现这一逻辑（例如叫 JSBridge.layout.setHeader），下面代码演示定制一个只有back键和标题的导航组件:

  // /h5/pages/index.js
JSBridge.layout.setHeader({
    background: {
        color: '#00FF00',
        opacity: 0.8
    },
    buttons: [
        // 默认只有back键，并且back键的默认点击处理函数就是back()
        {
            icon: '../images/back.png',
            width: 16,
            height: 16,
            onClick: function() {
                // todo...
                JSBridge.back();
            }
        },
        {
            text: '音乐首页',
            color: '#00FF00',
            fontSize: 14,
            left: 10
        }
    ]
});

上面的接口，可以满足绝大多数的需求，但是还有一些特殊的界面，通过H5代码控制生成导航组件这种方式达不到需求：

如上图所示，界面含有tab，且可以左右滑动切换，tab标题的下划线会跟着手势左右滑动。大多见于app的首页（mainActivity）或者分频道首页，这种界面一般采用定制webview的做法：定制的导航组件和内容框架（为了支持左右滑动手势），H5打开此类界面一般也是开特殊的API：

  // /h5/pages/index.js
// 开打音乐频道下“我的音乐”tab
JSBridge.view.openMusic({'tab': 'personal'});

这种打开特殊的界面的API之所以特殊，是因为它内部要么是纯Native实现，要么是和某个约定的html文件绑定，调用时打开指定的html。假设这个例子中，tab内容是H5的，如果H5是SPA架构的那么 openMusic({'tab': 'personal'})则对应 /music.html#personal这个url，反之多页面的则可能对应 /mucic-personal.html。

至于一般的打开新界面，则有两种可能：

app内H5界面

    指的是由app开发者开发的H5页面，也即是app的功能界面，一般互相跳转需要转场动画，打开方式是采用Native提供的接口打开，例如：

    JSBridge.view.openUrl({
    url: '/music-list.html',
    title: '音乐列表'
});

    再配合下面即将提到的离线访问方式，基本可以做到模拟Native界面的效果。

第三方H5页面

    指的是app内嵌的第三方页面，一般由`a`标签直接打开，没有转场动画，但是要求打开webview默认的历史列表，以免打开多个链接后点回退直接回到Native主界面。

系统级UI组件采用Native

基于以下原因，一些通用的UI组件，如alert、toast等将采用Native来实现：

H5本身有这些组件，但是通常比较简陋，不能和APP UI风格统一，需要再定制，比如alert组件背景增加遮罩层
H5来实现这些组件有时会存在坐标、尺寸计算误差，比如笔者之前遇到的是页面load异常需要调用对话框组件提示，但是这时候页面高度为0，所以会出现弹窗“消失”的现象
这些组件通常功能单一但是通用，适合做成公用组件整合到HybridApi里边

下面代码演示H5调用Native提供的UI组件：

  JSBridge.ui.toast('Hello world!');

默认界面采用Native

由于H5是在H5容器里进行加载和渲染，所以Native很容易对H5页面的行为进行监控，包括进度条、loading动画、404监控、5xx监控、网络诊断等，并且在H5加载异常时提供默认界面供用户操作，防止APP“假死”。

下面是微信的5xx界面示意：

设计H5容器

Native除了负责部分界面开发和公共UI组件设计之外，作为H5的runtime，H5容器是hybrid架构的核心部分，为了让H5运行更快速稳定和健壮，还应当提供并但不局限于下面几方面。

H5离线访问

之所以选择hybrid方式来开发，其中一个原因就是要解决webapp访问慢的问题。即使我们的H5性能优化做的再好服务器在牛逼，碰到蜗牛一样的运营商网络你也没辙，有时候还会碰到流氓运营商再给webapp插点广告。。。哎说多了都是泪。

离线访问，顾名思义就是将H5预先放到用户手机，这样访问时就不会再走网络从而做到看起来和Native APP一样的快了。

但是离线机制绝不是把H5打包解压到手机sd卡这么简单粗暴，应该解决以下几个问题：

H5应该有线上版本

    作为访问离线资源的降级方案，当本地资源不存在的时候应该走现网去拉取对应资源，保证H5可用。另外就是，对于H5，我们不会把所有页面都使用离线访问，例如活动页面，这类快速上线又快速下线的页面，设计离线访问方式开发周期比较高，也有可能是页面完全是动态的，不同的用户在不同的时间看到的页面不一样，没法落地成静态页面，还有一类就是一些说明类的静态页面，更新频率很小的，也没必要做成离线占用手机存储空间。

开发调试&抓包

    我们知道，基于file协议开发是完全基于开发机的，代码必须存放于物理机器，这意味着修改代码需要push到sd卡再看效果，虽然可以通过假链接访问开发机本地server发布时移除的方式，但是个人觉得还是太麻烦易出错。

为了实现同一资源的线上和离线访问，Native需要对H5的静态资源请求进行拦截判断，将静态资源“映射”到sd卡资源，即实现一个处理H5资源的本地路由，实现这一逻辑的模块暂且称之为 Local Url Router，具体实现细节在文章后面。

H5离线动态更新机制

将H5资源放置到本地离线访问，最大的挑战就是本地资源的动态更新如何设计，这部分可以说是最复杂的了，因为这同时涉及到H5、Native和服务器三方，覆盖式离线更新示意图如下：

解释下上图，开发阶段H5代码可以通过手机设置HTTP代理方式直接访问开发机。完成开发之后，将H5代码推送到管理平台进行构建、打包，然后管理平台再通过事先设计好的长连接通道将H5新版本信息推送给客户端，客户端收到更新指令后开始下载新包、对包进行完整性校验、merge回本地对应的包，更新结束。

其中，管理平台推送给客户端的信息主要包括项目名（包名）、版本号、更新策略（增量or全量）、包CDN地址、MD5等。

通常来说，H5资源分为两种，经常更新的业务代码和不经常更新的框架、库代码和公用组件代码，为了实现离线资源的共享，在H5打包时可以采用分包的策略，将公用部分单独打包，在本地也是单独存放，分包及合并示意图：

Local Url Router

离线资源更新的问题解决了，剩下的就是如何使用离线资源了。

上面已经提到，对于H5的请求，线上和离线采用相同的url访问，这就需要H5容器对H5的资源请求进行拦截“映射”到本地，即 Local Url Router。

Local Url Router主要负责H5静态资源请求的分发（线上资源到sd卡资源的映射），但是不管是白名单还是过滤静态文件类型，Native拦截规则和映射规则将变得比较复杂。这里，阿里去啊app的思路就比较赞，我们借鉴一下，将映射规则交给H5去生成：H5开发完成之后会扫描H5项目然后生成一份线上资源和离线资源路径的映射表（souce-router.json），H5容器只需负责解析这个映射表即可。

H5资源包解压之后在本地的目录结构类似：

  $ cd h5 && tree
.
├── js/
├── css/
├── img/
├── pages
│   ├── index.html
│   └── list.html
└── souce-router.json

souce-router.json的数据结构类似：

  {
    "protocol": "http",
    "host": "o2o.xx.com",
    "localRoot": "[/storage/0/data/h5/o2o/]",
    "localFolder": "o2o.xx.com",
    "rules": {
        "/index.html": "pages/index.html",
        "/js/": "js/"
    }
}

H5容器拦截到静态资源请求时，如果本地有对应的文件则直接读取本地文件返回，否则发起HTTP请求获取线上资源，如果设计完整一点还可以考虑同时开启新线程去下载这个资源到本地，下次就走离线了。

下图演示资源在app内部的访问流程图：

其中proxy指的是开发时手机设置代理http代理到开发机。

数据通道

上报

由于界面由H5和Native共同完成，界面上的用户交互埋点数据最好由H5容器统一采集、上报，还有，由页面跳转产生的浏览轨迹（转化漏斗），也由H5容器记录和上报

ajax代理

因ajax受同源策略限制，可以在hybridApi层对ajax进行统一封装，同时兼容H5容器和浏览器runtime，采用更高效的通讯通道加速H5的数据传输

Native对H5的扩展

主要指扩展H5的硬件接口调用能力，比如屏幕旋转、摄像头、麦克风、位置服务等等，将Native的能力通过接口的形式提供给H5。

综述

最后来张图总结下，hybrid客户端整体架构图：

其中的 Synchronize Service模块表示和服务器的长连接通信模块，用于接受服务器端各种推送，包括离线包等。 Source Merge Service模块表示对解压后的H5资源进行更新，包括增加文件、以旧换新以及删除过期文件等。

可以看到，hybrid模式的app架构，最核心和最难的部分都是H5容器的设计。

强悍的纽约设计师妹子教你App设计四大原则

Thu, 23 Jul 2015 09:05:16 CST

设计最有趣的地方在于它的通用性，不论是音乐、建筑还是工业，设计的规则大同小异。今天这篇文章来自纽约的产品设计师妹子Melissa，她从建筑系毕业之后并未从事她的本职工作，2014年11月学习了两个半月的网页设计之后开始转战产品和UI设计了，目前供职于Percolate。不要小瞧她的设计素养，建筑系的系统学习赋予她对于广泛意义上的设计更深入的认知，这篇文章就是这半年多来的一个阶段性答卷。

这篇文章总结了从建筑到产品UI的四个设计的基本原则。

一、轴

轴在UI设计中是最基本、最常见的概念，也是用来组织界面结构的重要核心。简单说来，轴是在设计的时候组织一系列元素的假象线，在下面的设计图中，轴以虚线的方式被标注出来。

1、对齐

轴最常见于对称元素的使用，当元素被布置成轴对称的布局的时候，会给人有序感。就像生活中绝大多数的事情一样，我们更倾向于享受有序的的东西，它们令人感觉平稳、舒适、平易近人。最简单的一个例子就是iTunes 程序中的专辑列表的设计，所有的专辑列表在界面的左侧保持对齐，围绕虚线轴轴对称。

2、强化

虽然轴是一条假想的线，但是如果周围的元素的边缘控制得足够整齐，这跳线会在视觉中变得更加“明显”的。最好的例子是城市中的路灯构成了道路两旁建筑物之间的轴，如果一边有建筑一边没有，那么这种轴线的感觉不会那么强烈。

从产品设计的角度上来看，Twitter 的时间线设计就是一个很好的案例，左侧的头像和右侧的推文共同塑造出缝隙中轴线的感觉。

3、运动

当我们碰到某先线条的时候，视觉会很自然地沿着这些方向运动，就如同我们站在街上，会自觉地沿着街道的两头走动。两个端点决定了线，界定了开始和结束的地方，线，或者说轴线的存在会引导和提示运动的方向。

SoundCloud中，音轨沿着一条既定的水平轴线运动，随着音乐的播放，音轨自然地自左向右匀速运动。

4、连续性

如果终点是不确定的，那么你通常会沿着轴线的方向浏览/运动，直到你找到感兴趣的东西，或者感到厌倦并关闭应用。在建筑学中，未清楚界定的终点非常少见，因为建筑的修建通常没法永远持续下去，但是UI设计则不一样，无限地滚动下去是无比受欢迎的设计手法。

Pinterest的APP中就是这样做的，持续不断的图片沿着中轴线的方向持续不断地滚动下去，只要你有兴趣一直观看下去。

二、对称

当元素被均匀地放置在轴线的两侧之时，他们构成了对称的关系。当元素被精准地在轴线两侧一一对应之时，它们就形成了完美对称。

1、平衡

对称令整个设计更加平衡。当元素与控件在轴线两侧处于相同位置之时，会给人以协调和谐的设计感。当我们在规划街道两侧的房屋建设的时候，如果左右两侧都是5间大小一致的房子，当你走在街上的时候这种平衡的设计会令人非常舒适，这是平衡给人的感受。

Rdio的APP设计就遵循着这样的设计规则，屏幕两侧的控件是相同的规格，这类布局很适宜阅读，用户会自觉地自上到下，从左向右查看。

2、不对称

如果轴线两侧的控件布置不再是一一对应尺寸相近，那就是不对称的设计。不对称的设计会给人明显的失衡感，可能会令人不舒服，但是也能造就残缺美，当然这要看你具体怎么做。

虽然Pinteret 的APP设计在整体上是沿着中轴线对称的（宽度一致），但是两边的界面控件并非是对称的，它们的高度并不一致，位置也是错落的。稍微一点的落差都会被眼睛捕捉到，而这样的差异让用户无法准确地左右顺序阅读。不对称设计打破了设计的平衡性和舒适性，但是也可以缓解了规律性设计带来的视觉疲劳。

三、层级

当某个元素出现在比其他元素更重要的位置的时候，层级就出现了。

1、尺寸

如果一个设计元素在尺寸上比其他的控件更大，就会区分出层级。毫无疑问，我们查看某个设计的时候，通常会被最大的元素吸引到。如果一个建筑物有5个出窗户，其中一个是其他四个的两倍大，我们的注意力自然而然会被吸引过去。

通过尺寸来区分文章列表层级的典型就是稍后读应用Pocket。顶部的轮播文章拥有更大的图片，它的位置和尺寸会令我们一眼注意到。

2、形状

如果一个控件在形状和形态上同其他的不一样，也可以让它独立出一个层级。不规则的设计同样会令人侧目。建筑物的正面拥有五个相同的窗户和一闪大门，你会立刻注意到门的独特之处。

在Instagram的个人信息页中，圆形的个人头像在方形的图片中别具一格，非常抓人眼球。它会让人意识到，这个独特的东西，更为重要。

3、位置

位置的存在同样能彰显层级的不一样。在圆圈之内，中心位置的东西比边缘部分的看起来更重要。位于轴线顶端的控件会显得比其他部分的优先级更高。

以设计应用Path的设计为例，时间轴顶点处的用户头像就明显比时间轴上的其他部分更重要，而这个地方正好展示的也是用户头像。

四、韵律

UI设计和建筑设计同样有着韵律之美，重复的模式会营造出独特的节奏之美。

1、模式

理解韵律最直接的方式就是听歌。音乐拥有节奏感，绝大多数的音乐遵循着相同的节拍，节拍就是音乐模式的一部分。

这方面最典型的APP是Airbnb，APP列表中每一间房子都占据一个模块，模块中有着大小相同的图片，价格、位置和房东信息和图片的相对位置一定，且排版匀称舒服，两个模块之间的间距也相同，当你浏览的时候，熟悉的节奏会让你清楚地知道上哪看关键信息。

2、间断

当节奏被间隔打断的时候，会形成不同的层级。听歌的时候，均匀的节奏被其他的音乐元素打断的时候，你会意识到这是比较特别的部分。

在Twitter的APP中，推文和推文保持着相同的样式，均匀的节奏，但是其中的“推荐用户”一项有着不同的样式，它插入到推文列表中，打破了整个信息流的节奏，凸显出不同的层级，会很快抓住你的注意力。

译文来自： 优设

原文地址： learndesignprinciples

优设译者： @陈子木

互联网人士必备微信公众号：woshipm，雷军和周鸿祎都关注了，如果你已经关注了，证明你已经很牛逼了。

聚合新闻Flipboard 、 ZAKER竞品分析

Sun, 12 Jul 2015 21:49:31 CST

市场分析

庞大的用户基础，移动互联时代的新闻传播方式依然发生着巨大变化。对比杂志类APP分析中，可以看出Flipboard和Zaker占据着首席，一个是海归派，一个是本地通，UV表现不俗。

产品对比

Flipboard和Zaker同是杂志类新闻资讯类产品，面向用户对象类似，同时产品还是各有自己的特点。注重的细节以及地域等因素各有千秋。

产品结构

作为新闻资讯App，两者都做到了个性化订阅、高品质、碎片化的阅读模式，基本都有搜索、个人管理、社交互动等功能，明显Flipboard比Zaker的结构来得更加简约，就我个人来说是比较喜欢Flipboard的结构设计的。

功能对比

功能分析

产品特色

盈利模式

迭代分析

总结

本文由 @Eric－Chen 原创投稿，并经人人都是产品经理编辑。未经许可，禁止转载。

互联网人士必备微信公众号：woshipm，雷军和周鸿祎都关注了，如果你已经关注了，证明你已经很牛逼了。

最佳（也许）实践：开始用Cordova + Ionic + AngularJS 开发你的 App

Thu, 02 Jul 2015 16:54:50 CST

本文是一篇关于我本人在使用 Cordova + Ionic 以及 AngularJS 开发移动App的过程中的经验的总结，它不是一篇基础入门教程，而是和大家探讨一下关于如何更好的使用这些技术开发一个更好的App，文章会每天抽一点时间完成，如果您有什么问题或者想与我交流的经验，欢迎随时在本文下方评论或者邮件给我：54778899 [at] qq.com。

声明：这是一篇中立的文章，我无意于挑起孰好孰坏的争论，这只是一篇经验分享文，至于为什么选择这种技术，因为我会这个，感觉还不错。

Cordova, Ionic, AngularJS 都是什么？

Cordova

Cordova是一款开放源代码的App开发框架，旨在让开发者使用HTML、Javascript、CSS等Web APIs开发跨平台的移动平台应用程序，其原名称之为 PhoneGap，Adobe 收购Nitobi 公司后，PhoneGap 商标保留，代码贡献给了 Apache 基金会，而Apache 将其命名为 Apache Callback，其后发布新版本时，定名为 Apache Cordova。

Cordova是一个行动设备的API接口集，利用JavaScript存取这些接口可以调用诸如摄影机、罗盘等硬件系统资源。配合上一些基于HTML5、CSS3技术的UI框架，如jQuery Mobile、Dojo Mobile或Sencha Touch，开发者得以快速地开发跨平台App而不需要编写任何的原生代码。

注意到因为Cordova本身仍是一个原生程式，为App打包时依然需要用到这些系统平台的SDK。

本文将结合 Ionic 前端框架进行开发

Ionic

Ionic是一个新的、可以使用HTML5构建混合移动应用的用户界面框架，它自称为是“本地与HTML5的结合”。该框架提供了很多基本的移动用户界面范例，例如像列表（lists）、标签页栏（tab bars）和触发开关（toggle switches）这样的简单条目。它还提供了更加复杂的可视化布局示例，例如在下面显示内容的滑出式菜单。

Ionic宣称他们极度强调性能，并且通过限制DOM交互、完全移除jQuery以及使用像translate(z)这种特定的硬件加速的CSS滤镜触发移动设备上GPU——与由动力不足的移动浏览器提供的交互相比这种方式提供了硬件加速的交互——等方式使速度最大化。

AngularJS

AngularJS是建立在这样的信念上的：即声明式编程应该用于构建用户界面以及编写软件构建，而指令式编程非常适合来表示业务逻辑。[1]框架采用并扩展了传统HTML，通过双向的数据绑定来适应动态内容，双向的数据绑定允许模型和视图之间的自动同步。因此，AngularJS使得对DOM的操作不再重要并提升了可测试性。

设计目标：

将应用逻辑与对DOM的操作解耦。这会提高代码的可测试性。
将应用程序的测试看的跟应用程序的编写一样重要。代码的构成方式对测试的难度有巨大的影响。
将应用程序的客户端与服务器端解耦。这允许客户端和服务器端的开发可以齐头并进，并且让双方的复用成为可能。
指导开发者完成构建应用程序的整个历程：从用户界面的设计，到编写业务逻辑，再到测试。

Angular遵循软件工程的MVC模式，并鼓励展现，数据，和逻辑组件之间的松耦合。通过 依赖注入（dependency injection） ，Angular为客户端的Web应用带来了传统服务端的服务，例如独立于视图的控制。因此，后端减少了许多负担，产生了更轻的Web应用。

开发环境

我所使用的开发环境包括下面这些：

工作站：一台13寸的 MacBook Pro Retina + iPad Mini

使用Mac开发前端有很多优势，对于我来讲，最大的优势就在于我还是一个Linux用户，很多的Linux习惯在Windows下面总是会有一些不适应，再者，OS X的系统稳定性以及各种各样优秀的App，也让它一直都成为我的工作利器。

我没有像很多牛逼的大神们购买多块屏幕，我只有一台iPad Mini，然后还有一个叫作 Duet 的App，它可以让我把 iPad 作为我的 Mac 的第二块屏幕，一般不需要，但是它真的能提高我的工作效率，而且可以直接使用到 iPad 的触摸屏，这对于移动开发来讲，很好。

我还有一台 Lenovo 的 Yoga 3，装了 Ubuntu，不过很少用，显示有点儿别扭，但是，比起其它的PC机，这台还是很不错了，大家也可以试试。

开发工具

以前是Notepad++ 的忠实用户，然后还有 Coda、TextMate、BBEdit、SublimeText 等等的，现在用的（而且可能以后会一直使用的）——WebStorm。

如何选择首发渠道？APP运营的8大潜规则

Wed, 01 Jul 2015 18:40:43 CST

首先我们先来了解下App运营这个职位。运营这样一个岗位包含的内容很杂，有渠道推广，有数据分析，有产品包装，有活动策划等等。在2012年到2013年这两年，事实上，各家公司的运营核心是放在渠道上，对产品的真正运营相对来说较少，而且停留在表面上，没有深入到产品数据分析和用户挖掘上，也没有在老用户的留存率上做文章，而更多的是做渠道，做用户。

大部分App创业公司的运营岗位就是渠道推广，就是通过跟安卓市场，360手机助手，91助手这样的渠道商做关系或者买广告位。因为App的用户增长主要来源于此，如果跟这些渠道搞好关系，争取到诸如首发这样免费推荐位，将能对用户量有质的提升。所以，更多的公司的运营主要做的工作就是做预算，然后找渠道。

跟这些渠道的合作方式无非三种：

付费合作，那很简单，谈好价格付钱；

免费，主要是就是首发，还有就是跟渠道的运营小伙伴搞好关系让帮忙给个免费的位置等；

活动奖品合作。

简而言之，就是渠道商会逢年过节策划些活动，需要奖品赞助然后提供给赞助的CP一些推荐位，还有就是原来安卓和安智会搞些论坛活动（转化率不高，不建议做）。

在上家公司，小编亲力亲为的跟渠道打了半年的交道。当时我自己整理了一个表，将各个渠道分为三个等级，分别是高、中、低三档。其中高等级的渠道包括有googleplay，豌豆荚、小米应用商店、安卓市场、360手机助手、腾讯应用宝、91手机助手、百度等。中等的包括移动MM、华为智汇云、安智市场、机锋市场、应用汇、N多市场、木蚂蚁、联通沃商店、电信天翼商店、联想乐商店等。低等级的就是当时已经用户量很少的渠道如十字猫等。

一、渠道合作

1、高级渠道

对于高等级的渠道是重点维护对象，关注频率是每日。这些渠道的用户量比较大，所以需要每天观察渠道的用户增长情况，看位置的变化等，这些高等级的渠道也是产品新版本首发的主要选择。根据我的经验，豌豆荚和360手机助手，还有腾讯应用宝和百度这几家渠道的首发效果是最好的。其次是小米，安卓市场等。

2、中级渠道

对于中等级的渠道是次要维护对象，无需每日关注，可以留意下他们的活动什么的，跟渠道的小伙伴搞好点关系，争取些免费的推荐位，或许能带来一些量。但不到万不得已，不要跟他们做产品首发合作，效果将很不理想，我记得有一次跟天翼商店合作首发，一天来了不到一百的量，差点哭了。

3、低级渠道

对于低等级的渠道基本上保持更新就行，基本上不用花精力在上面。因为无论你再如何努力，它也给不了你用户。因为它本身就没用用户。大浪淘沙，如今有量的渠道也就那么十来家了。而且这些渠道基本上也是向钱看齐了。对于一些土豪公司来说，你们就找准给力的渠道抡起袖子砸钱吧，而对于一些屌丝创业公司来说，做App运营想免费求用户量真是比登天更难了。

二、App运营的潜规则

1、关于首发

豌豆荚、360手机助手、小米等每月都可以申请一次免费首发的机会。首发联系人是他们的运营人员。具体谈首发的时候，要有理有据有礼有节，适当为市场的运营们想想，让大家做事都方便一些。目前接触到的豌豆荚的运营比较nice，但是比较忙，一般就是发邮件确认，安卓市场和小米商店的运营也很好，360手助的运营比较忙，都是小姑娘，可以好言好语哄着。百度的首发需要填一堆条条框框，按照规矩填了就好。还有首发最好提前一周或更早一点预约安排，不然很可能没有排期。

2、一些免费可利用的资源

如豌豆荚可以申请优质应用，还可以申请产品设计奖，如果申请成功，也可以得到一定的推荐位。360手机助手也会时常搞一些活动，跟运营的关系好说不定也可以蹭蹭。

3、产品特权功能

将产品收增值服务费的功能免费提供给市场，换取市场的广告推荐位。这是一个在没有充足预算的情况下，一个妥协的做法，相当于跟市场进行资源置换。

4、关于抓包

通过各大安卓市场，都会互相抓包。如果你没及时更新某一家市场，这家市场就可能将其他渠道的安装包直接抓过来，这样就会导致你的数据出现问题。首发的这家渠道数据可能虚高，而抓包的市场就会数据呈现下降趋势。这个时候如何判断首发的效果好坏？就要对比总量有没有提升，而不是单独看首发的渠道的数据。

5、关于App应用内互相推荐

也就是所谓的换量。应用内的推荐，如果位置比较深，且对方的用户量不大，基本上不会有效果。除非是那种用户规模过千万甚至是过亿的App而且位置比较明显，才可能有效果，否则几乎不会效果，不要讲精力放在这块。

6、关于资源互换

有一种资源互换的情况是，你可以作为一个中介，利用信息不对称，互相导量，比如你联系A和B两家CP，然后让A推荐B，让B推荐你，你去推荐A。通过这些来回倒手，你可能会挣点差量。干这个事儿需要脑子好使，会卖萌机灵的小姑娘。倒来倒去，没准还能挣一笔。

7、关于数据分析

谈到运营，就不能说数据分析，如果没有数据支撑，去谈运营就是瞎扯。只有能够看到每天的数据，每月的数据，才能有参照物，才能有的放矢。一般来说，每个市场都需要单独打包上传，但目前商店分布来看，可以选择重要的商店打包上传，其他的渠道可以不必单独打包。一般来说，最常用的统计的数据有日新增，日注册，渠道分布及排行，设备分布等。

8、关于刷量和刷评论

现在有很多刷量的水军，可以把你在某个市场的下载量刷上去，然后提高排名获得更多的曝光。对于这种还是小心尝试，不要刷的太明显被下架，那就得不偿失了。评论我到是觉得可以适当刷一下，但也不要太过分，最好能是手工刷，刷一些好评，也可以增加下载的几率。

Android APP安全测试基础

Sun, 08 Feb 2015 04:05:10 CST

自从去了新公司之后，工作太忙，变的有点懒了，很久没有更新Blog。今天跟几个小伙伴一起吃饭，小伙伴提起我的Blog，想想是该更新更新了，就把我投稿给sobug的这篇转过来吧，关于Android app安全测试的基础东东，在Sobug 的url:

https://sobug.com/article/detail/7

背景

最近这两年移动端真是非常火，每个单位或多或少都会有那么几款App，对于我们Web安全攻城师来说，App安全也需要或多或少的了解一些。年初单位来了一位对App安全略有研究的小伙伴，某日闲来无事教了笔者几招，分享给大家。有句古语:”工欲善其事，必先利其器”，我们要研究App安全，没有几款高大上的神器是会非常麻烦的，因此本文主要给大家分享一下笔者学到的一些基础知识，主要是一些移动端测试辅助工具的使用。

模拟器

模拟器笔者经常使用有两款，一款是BlueStacks，这款个人感觉是做的非常不错的，一般安装操作App非常流畅，不会有卡死的情况。另外一款就是SDK模拟器(Software Development Kit)了，这款是特别高大上的，类似虚拟机vm一样，可以建立多个虚拟机，安装不同的android系统。

BlueStacks

下载地址：

1	`http://www.bluestacks.net.cn/Download/`

安装的时候会提示安装”给力助手”，给力助手是辅助操作的，可以安装电脑上下载的app安装包到模拟器，也可以卸载已经安装的，还有很多针对模拟器的设置功能，如图：

BlueStacks安装之后，安装APP，打开App界面如图：

功能方面使用都非常简单，本文就不做介绍了。

Software Development Kit

下载地址：

1	`http://developer.android.com/sdk/index.html`

下载之后打开包中的eclipse，然后进行模拟器Android镜像的下载，包中自带的镜像是Android 5.0的镜像，建议下载老版本的，方便测试App，新版的镜像部分App在安装的过程中可能会有不兼容的情况。
SDK Android镜像的下载如下图所示：

下载完Android镜像之后就可以安装虚拟机了，具体如下：

抓包神器

抓app包的方法有很多种，比如手机设置代理用BurpSuite进行抓包，或者可以用fidder抓包。我比较习惯用一款小工具smsniff进行抓包，使用起来比较方便，抓到的包再放到Burpsuite进行修改提交等。工具如图：

这款工具比较小巧，占用资源较少，有些时候用burp等抓包会发生错误，或者直接导致虚拟机上的app无法连接网络，用这款就不会发生以上说的情况。

SDK小工具

SDK中自带了几款很不错的小工具，我比较常用的有adb和emulator。ADB是一个客户端-服务器端程序，其中客户端是你用来操作的电脑，服务器端是android设备。SDK包中默认就有这俩款小工具

Adb

Adb命令如下：
adb devices 查看启动的虚拟机设备，如图：

adb install，安装app到已经打开的虚拟机中，如图：

这样就将本地下载的app安装到了已经启动android虚拟机中了。

adb shell，登录设备shell，如图：

adb push，将电脑上的文件发送的android虚拟机上；adb pull，将android虚拟机上的文件发送到电脑上，如图：

Adb命令非常强大，以上只是列出了比较基础的几个，详细的大家可以百度。

Emulator

Emulator命令我目前常用的就两招，启动android虚拟机，以代理模式启动android虚拟机。命令分别如下：

1 2	`Emulator @xiaomi` `Emulator -http-proxy 127.0.0.1:8080 @xiaomi`

其中xiaomi是我新建的android虚拟机的名字，设置代理启动之后，就可以用burp进行抓包了。

反编译工具

反编译app主要用apktool和d2j-dex2jar.bat，我比较常用的是dex2jar。
Apktool反编译命令如下：

1	`apktool.jar d e:\Appsec\xxx.apk`

命令执行之后会在apktool.jar所在目录下生成一个app的目录。
d2j-dex2jra.bat反编译方法如下：
用rar打开apk文件，将其中的classes.dex解压出来，然后执行命令d2j-dex2jar.bat d:\Appsec\xx\classes.dex
执行完成之后会在d2j-dex2jar.bat相同目录下生成一个.jar的文件，可以用jd-gui.exe直接打开.jar来查看app的源代码，如图：

案例分享

App安全测试，我只能测测简单的，大多是权限绕过类的，比如绕过锁屏密码、任意用户登录等。基本都是因为app代码设计缺陷或者权限验证不足导致的。

任意用户登录

某次测试一个app，RP比较好，发现一任意用户登录漏洞。在本地的配置文件中有登录用户的帐号和密码，APP设计比较奇葩，只是验证了用户登录邮箱，没有验证密码，导致通过修改本地的配置文件就可以实现任意用户登录，登录之后能够查看别人的订单等数据。在android虚拟机中安装的app都在/data/data目录下，大概的目录结构如下：

app安装目录下的结构都是差不多的，主要有缓存文件、数据库目录、本地文件、配置文件等。比较重要的目录有databases、shared_prefs。分别保存了数据库文件和配置文件。
言归正传，查看了安装app的shared_prefs目录，发现其中一个文件内容如下：

可以看到有用户的登录邮箱和密码，将邮箱修改成存在的用户邮箱，密码随意输入，然后adb shell之后，用linux命令删除android虚拟机上已经存在的配置文件，再用adb push将修改后的文件发送到android虚拟机，再打开app发现已经用其它用户成功登录了。

写在最后

APP安全接触的不多，技术比较菜，因此本文分享的基本都是工具的使用，比较基础。非常感谢夕阳童鞋，是我的App安全启蒙老师！

5种实用App导航菜单设计方案

Thu, 08 May 2014 09:04:28 CST

手机分辨率比桌面平台小很多，所以设计手机网站或是移动应用的时候，导航菜单都需要考虑周全，尽量保持简约和易用性高，这里我们整理了5种实用的移动手机App导航菜单设计方案，你可以尝试这些菜单设计模式用在你的新设计项目上，好用而且有新鲜感。

这5种App菜单设计方案也许有很多设计师已经在使用，但不能否认它是目前实用的，而且能提高用户体验的菜单设计方案。下面摘选移动手机UI设计美观、时尚，希望你看了后会有灵感收获，能把你的菜单设计得更棒，好好学习吧。

APP导航设计类型：

列表式菜单
矩阵、网格式菜单
底部菜单
顶部菜单
扩展菜单

一、列表式菜单

列表式菜单设计这个从网站到手机APP上都很常用的，遵循由上至下的阅读习惯方式，所以使用起来用户不会觉得困难。另外我们可以通过漂亮的配色、图标组合来设计，使得菜单更多加美观。

GIF Aimation

Elevatr

HabitClock App

Instagrab for iOS

二、矩阵、网格式菜单设计

网格式菜单就类似于metro UI的堆砌色块，优点简约而不简陋，导航清晰、明显，并能提高效率。但设计时切记不分青红皂白的去使用色彩哦，这可能会让用户不知所措和产生疲倦感。

Vectra

Arrivo Mobile App

Abracadabra App

TRAVERSE

三、底部菜单

底部菜单主要是列出应用程序重要的功能。

Badoo concept

Animated sliding tab bar

四、顶部菜单

顶部菜单和底部意义差不多，把菜单放在顶部，可以遵循上至下的阅读习惯，不过我认为有个缺点就是不能单手操作。

Horner

Discovery Channel

Air flow calculation app

Shario App

五、扩展菜单

扩展式菜单设计现在连网站也很常用，当我们觉得菜单比较点用位置的时候，可以尝试用这种方式来隐藏菜单，需要注意的是设计展开菜单按钮大部设计在左或右上角这些显示的位置。

MuSeek

Univit UI

SVOY app design

Időkép

总结

从上面5个菜单设计方案中可以看出都有自己的优缺点，所以我们应该选择对你项目最为有效的方案，并能提高用户体验。

原文地址：shejidaren

您可能也喜欢：
手机界面常用导航设计分析	APP 创业煎熬生存的持久战	Web导航设计二三事	在屏幕上画个C—基于人机工程学的安卓导航碎片化解决方案	如何输出有效的设计方案
无觅

（关注更多人人都是产品经理观点，参与微信互动（微信搜索“人人都是产品经理”或“woshipm”）

手机App仍不会取代浏览器

Mon, 20 Apr 2015 12:27:58 CST

我这几年一直在思考“手机App会不会完全取代手机浏览器，后者是否会逐渐消亡”，观点也几度变化，在当前时间点（2015年4月），我的观点是，移动端浏览器在暂时H5的体验仍旧无法达到原生效果的此时，固然在重度、用户重感知的需求上会让步于App，但在可以预见的未来来看，仍旧始终会是一个大型入口，不会被完全取代。

早几年，苹果还未搭建起那么吸引人的App大环境，浏览器非常常用，因为人们的手机端需求早于厂商们的App出现，人们不得不在手机上浏览拙劣的未经适配优化的电脑网页，还备受网速、流量的困扰。（我是在描述当时高中/大学的自己）

而现在，移动端浏览器发展到今天，各家宣扬的点已经从最初的“省流量”（UC浏览器就是靠此起家）、“速度快”变为了“设计轻”、“嫁接读书/视频内容”、“应用大全”了。早几年的激烈厮杀已经让这块市场基本只剩下了几家巨头产品，比如我个人换机后会装的UC和QQ浏览器（前者感觉比较顺畅，我一直没有弄清楚是动效原因还是真有技术区别，后者是因为是东家的产品），搜狗浏览器、Opera、Chrome（我最常用的其实是这个..）都是比较小众的了。

可能许多同学和我一样，并不会在移动浏览器上使用它的应用大全（Web App）啥的，但即使这样，移动端浏览器仍旧会是一个大型入口。 因为，对于长尾需求、H5/App体验差别不大的需求、搜索等需求形态来说，仍旧是浏览器比App更适合。

一个个看。

1、搜索
搜索对我来说，是一个要用时必须要能马上做到，但频次又不那么多的需求。这类需求很适合在浏览器上来做，因为每次用户换机后，可能不会马上遇到搜索的需求，但总会隐隐感觉需要安装一个App，这就是因为潜意识需要有一个东西可以马上打开www.baidu.com来搜索。这里想到一个事情，UC浏览器团队可能也看出来了未来搜索会是移动端浏览器的很大需求原因，因此自己早早推了神马搜索（当时说实话我没看明白，现在发现当时的决策者的确是前瞻性强）。

2、长尾需求
长尾需求的典型特征是不值得、懒得安装/不记得要安装这个APP，但是又偶尔出现需求，这时通常就用百度搜索，然后网页解决了，这时也不得不依赖移动浏览器了。实际上，手机百度App目前做到App前5，原因就是人们的搜索需求和长尾需求加起来很多，又实际都是通过浏览器来作为产品形态承载，手机百度就自己做了一个浏览器（手机百度App实质上就是一个不用输入URL的浏览器，实际上是UC和QQ浏览器的重要竞争对手）。

3、缺乏App而App没用/做得太烂的情况
我们知道，某些网站是没有App的，就不得不用浏览器。比如论坛，虎扑，猫扑等一些网站，还有一些常用但特殊的站点，譬如某榴。或者是App太烂了，和网站没区别，比如贴吧（贴吧稍微做好点，都没same啥机会）。

4、App和网页的体验差距不大的需求类型
在体验上，并不需要特别的动效体验的需求类型，或者说白了，就是在原生APP上和在H5页上拉不开体验差距的需求类型，也始终是更适合浏览器。典型的例子就是纯粹的阅读，包括阅读小说、看笑话等。如果你只阅读不笔记什么的，浏览器完全够用了，如果你看糗百不会发小纸条上面的，网页版糗百也完全够用了。特别是对基础用户，上面现象更明显，比如我看书，会记笔记，会加色Mark，就得用QQ阅读，而我爸爸，就始终只用浏览器看小说，我跟他说QQ阅读体验更好，翻书效果更舒服，他说哦哦，然后下次回家他还是在用浏览器（我分析根本原因是他觉得没啥区别，那个翻书效果他不在乎，所以他懒得换，保持现状）。小说这一点上，我认为它绝对是除搜索外、移动浏览器里面使用率最高的需求，没有之一，甚至超过看新闻。这一点我纯粹靠个人在身边的观察和臆断，但还算比较有信心，有知道的同学可以与我交流看看。

说到未来的长远发展方向，我倒不太明了，倒也没深入想过，但觉得，在H5越来越强的未来，说不定Web APP会开始成为新的热门的服务形式（不过国内，微信公众号也在准备这一方面的事情），届时浏览器又可能有新的机遇。不过说实话，我个人对H5体验的未来始终看不明朗，毕竟对这块技术不甚了解，这又是另一个话题了。

微信搜索“邹剑波Kant”即可关注我的公众号，扫描二维码可以请我喝杯茶。

移动APP项目研发流程及版本规划

Mon, 20 Apr 2015 21:00:26 CST

一个移动APP项目研发规模可大可小，但都离不开以下几个成员：产品经理、ui设计师、前端开发、后端开发、测试等。如何合理安排项目成员工作、确保项目顺利进行呢？一个清晰合理的项目研发流程控制很重要。

项目研发流程一般来说分3个阶段

第一阶段：需求策划。

在需求阶段产品经理内部进行需求讨论：讨论下版本需求重点是什么，做什么功能，怎么做。通过反复调研、讨论、输出交互方案。

确认需求可行性：产品在输出交互方案后找相应的开发讨论需求方案是否可行，这个讨论阶段产品和开发的思维方式不同，往往会擦出新火花、新惊喜；但讨论控制不好或者会演化为产品和程序员的撕逼大战，呵呵。

UI设计：设计师将产品的交互方案变得更生动精美，不过精美的设计稿不见得都能实现出来。在这个过程中产品经理需要协调设计师和前端人员的沟通，制定设计规范。同时保证设计稿的质量，出稿进度。需求宣讲：产品经理将交互方案和实现逻辑完善以及将上版本的bug、其他优化需求等整合出完整的版本需求文档后，拉上项目所有成员宣讲。宣讲目的主要让项目成员清楚新版本需求的重点是什么，做什么功能，为什么做（重点讲）；简单介绍怎么做，讲解交互方案或设计稿，给大家有一个整体的印象，让大家都了解版本功能的意义。

第二阶段：需求研发。

项目启动：需求宣讲后，开发根据产品需求文档进行需求评审，评估出研发周期、提测时间、预发布时间点、正式发布时间点。

产品根据评审结果发送项目启动邮件。研发：需求研发过程中，产品跟进研发进度，保持与开发沟通确保需求被正确理解，及时解决研发过程中发现的新问题。测试用例：产品、测试、开发共同确认版本测试用例，并同步研发过程中变更的需求和细节。

提测：产品验收开发输出的功能模块，并输出体验回归文档；测试根据用例验证需求逻辑，提bug、优化给开发。内网环境测试通过后，测试继续验证预发布环境、正式环境。

第三阶段：版本发布。

客服培训：测试验证的过程中，版本发布前，产品提前给客服培训新版本内容。

发布：后端开发、运维人员将代码发布外网环境，前端输出外网正式包。产品运营将正式包上传各大安卓市场或ios -appstore提审。

升级：所有安卓渠道包更新好，或者appsore审核通过，新版本也没有发现什么问题时，后端开发和运营人员打开升级配置，并发送升级通知。运营报告：版本发布完毕还未算完呢，运营人员在新版本发布后，收集用户反馈，进行数据监测、数据分析；评估新版本功能效果和影响，验证新版本功能以及输出下版本需求开发和优化建议。

从以上APP项目研发流程来看，每一个版本研发都要经历以上3个阶段12环节，理论图上看是一条完整的流水线，但是如何保证流程顺畅进行？如何使项目成员工作效率最大化？这十分考验产品经理/项目经理的版本规划能力。当然项目成员间的默契和沟通也很重要。

从笔者实践经验来看，要保证流水线顺畅，理想情况产品需求文档要领先前端开发2个版本，设计领先前端开发1个版本，后端开发领先前端开发半个版本。即在当前项目启动同时，产品经理已经在调研讨论下下版本需求；设计开始搞下版本的稿子；当前项目进行到一大半时，后端已经完成当前版本的需求，并开始准备下版本的需求预研。

版本规划是产品经理根据需求优先级和开发进度预估定出来的，即每个版本要做什么，重点是什么，研发时间，上线时间等。一般来说，项目每发布一个版本都应该有它的意义和主打功能。

App首个版本相对来说时间较长：app需要搭配开发环境，确定app技术框架，以及研发各种基础系统等。像这样时间较长的版本研发，产品经理和技术在需求评估时要将开发需求分阶段进行并且设置里程碑（尽量不超过3个），在每个里程碑（最长不超过1周）时间点，产品经理需要确认完成的情况，发现问题及时调整研发计划，控制项目风险，保证项目如期完成。

后续开发的每一个版本都应该至少有一个重要功能，版本研发周期最好控制在2周-3周内。这样的好处一方面是保证项目成员有个良好的开发节奏，使研发效率最大化；另一方面保证每个版本有新东西给到用户体验，以及符合各大市场申请首发条件，获得免费的推广资源（ps：一般首发活动可以获得几千到几万的免费用户，还是挺吸引的）。当然重大功能上线的话，确保上线后版本的稳定性，可以将研发周期延至1个月，或者进行灰度发布。要尽量避免安排超过一个月研发周期的版本，否则要将长版本设置为若干个里程碑验收。经验来看研发周期过长往往会导致研发技术人员精力分散，工作拖沓，积极性下降。

一般情况不建议频繁发布小版本，因为每个版本发布都需要测试，打包，发布市场，发升级配置和升级提醒等。频繁发布小版本造成测试和运营重复性工作增加，造成资源浪费；用户侧看频繁的升级提醒也是件很讨厌的事情。另外，建议外网运营客户端版本最多不要超过4个。维护老版本成本还是比较高的，比如做新功能还要考虑新老版本兼容情况，和各种后台数据接口升级、更新的兼容问题等。

在特殊的情况下，有紧急的bug和漏洞时，才建议紧急发布一个bugfix版本。

source：简书

互联网从业者必备微信公众号：woshipm，如果你已经关注了，证明你已经很牛逼了。

如何使用ASO优化提高排名？看完这篇文章你就明白了！

Tue, 31 Mar 2015 09:45:03 CST

现在越来越多的团队公司做app开发的，开发后上传到app store。经过严厉的审核，本以为万事大吉，岂料，一场没有硝烟的战争正悄然而至。我们整体来分析一下，一款IOS应用上线app store之后，主要的流量来源。

一、为什么做关键词优化

1.1 精品推荐

这是app store的第一个页面【精品推荐】，很多用户是从这边下载app的。可是，一般情况下，app能上【精品推荐】，说明这app已经做得相当不错了，所以，并非是每个app都能上【精品推荐】，但可以成为每家app奋斗的目标。

1.2 排行榜

排行榜一共有3栏，付费榜（购买个数的排名）、免费榜、畅销排行榜（单价X购买个数的排名），每一栏都显示排名top150的应用。所以，最多只有150 * 3 = 450款app出现在这里，因此竞争相当激烈。

1.3 探索

【探索】顾名思义就是用户在这里可以探索一些app，这里罗列的24个类目，每个类目下面都有排名，我们称之为分类榜排名。这里也是必争之地，毕竟总榜top150位置竞争更激励，而做到分类榜比较靠前的位置相对容易一点，而且流量也是比较客观的。

1.4 搜索

如果之前的都是用户无心插柳，随心下载的话。那么，来到这里的用户，都是有明确需求的。用户想下载一款【旅游】的app，大部分用户会搜索【旅游】，然后挑一款排名比较靠前app下载，这也是大部分用户的行为。

【总结】

一款IOS app在app store的主要流量来源是哪些？现在，我们可以总结如下：

IOS流量 = 精品推荐 + 排行榜 + 分类榜 + 搜索

大部分app是上不了精品推荐的，而且app进入到总榜前150名也是比较困难的。不过各个分类榜的排名还是可以尝试一下的，在24个类目中每个类目的top100有流量的话，也就惠及近2.5k个app，可是毕竟有100多万app呀，因此还是比较激烈的。最后一个是搜索，每个app都有100个字符的关键词来设置，设置之后就可以搜索到你的app。研究表明一款IOS应用，60%-70%的IOS流量来自于用户的搜索流量。所以，对于大部分应用来讲流量来源应该是这样的：

IOS流量 = 榜单 + 搜索

既然大部分用户都是来自搜索，那么我们主要关注下关键词搜索这块。而关键词的搜索优化，这也就是我们所要讲的ASO（App Store Optimization）

二、怎么选取关键词

2.0 概念

关联性（Relevance）：某个特定的关键字与你的应用以及目标用户之间的相关性，不相关的关键字很难产生有效的转化率。

难度（Difficulty）：某个特定关键字的竞争激励程度，这个值越高意味着它更难进入前列排名。

流量（Traffic）：某个特定关键字的抢手程度，在搜索中被搜索的次数越高，这个值就越高。

2.1、分析竞争对手的关键词

首先，我们可以通过一些工具，了解你竞争对手的关键词，比如，你是做旅游app的，那么你可以从通过使用工具（appannie）发现你的竞争对手（途牛）可能会用到的关键词，比如自助游、出境游等（appannie是第三方工具，显示的数据未必是app真实提交到app store的关键词，可能会有一些出入，但是可以作为分析的工具）。

2.2、关键词选取优先级

常规关键词的选择分三个方向：

1、品牌词 2、关联词 3、竞品词。

举个例子，如果你是去哪儿旅行App

品牌词：去哪儿、去哪儿网、qunaer；

相关词：旅游、旅行、酒店预订、机票预订、特价酒店、特价机票；

竞品词：携程、艺龙

当然这些词从搜索到下载的转化率依次是：

品牌词>行业相关词>竞品词。

关键词选择的核心就是“相关性”。比如你开发一款数学游戏，但是你却把关键字定义为“游泳”，虽然说游泳有着相当出色的流量和中级难度，可是它跟你的产品完全无关。如果有一个玩家想要找一款游泳app，前十名搜索里确实出现了你的数学游戏产品，可是他们会下载么？只有具有关联性的关键字才能产生有效转化率2。

2.3、结合难度和流量分析

另外，还可以从难度和流量来入手，难度和流量是两个概念。虽然很容易混淆但还是有所差别的。比如一款做旅游的app，搜特价机票，排名可能是100+名，可是这个词的流量并不是很大，由于排名太靠后。因此，难度是很大的。所以说，难度是跟关键词目前的排名是有关的，而流量是跟关键词搜索热度是有关的。

【结论】

从竞争对手或者自身的理解，选取关键词、建立关键词库，然后按照品牌词、行业关键词、竞品词的顺序来对关键词进行排序，之后结合难度和流量来进一步筛选关键词，最后确定100个字符的关键词。

三、提升关键词排名

关键词确定好了，也经过反复迭代、替换关键词。可是，如果你不做功夫，提高关键词的排名。那么，即使反复迭代，可优化的空间是有限的，那么接下来要做的就是选取相关的、有流量的、难度适中的关键词来提高关键词的排名。

那么，问题来了。关键词的排名跟什么因素有关呢？实践表明，关键词的排名跟app自身的下载量、评论数以及关键词搜索量有关，尤其是关键词的搜索量，占据了比较大的权重。因此，目前提升关键词排名的一种行之有效的方式，就是让真实用户搜索关键词，找到你们的app下载并激活，足够多的用户如此操作，该关键词的排名就会提升。

作者：梅森

来源：类类有话说

互联网从业者必备微信公众号：woshipm，如果你已经关注了，证明你已经很牛逼了。

移动端Hybrid应用与响应式

Fri, 31 Jul 2015 10:06:35 CST

前端是一个非常庞大和复杂的领域。

如果说多年前的前端只是需要学习几个 HTML 标签，看到别的网站用了狂拽酷炫的特效就 copy 下来，稍微懂点 jQuery 做日常使用，再了解几个 Prototype 和 MooTools（貌似都不再维护了）等高冷脱俗的库做装X用就能显得很“专家”了。那么现在要还是持这样的想法，就不适合搞前端。

且不说 JavaScript 在与时俱进，更新出了 ES6，增加了茫茫多的特性，用 CSS 也可以做一些简单动画了。当一个新的 JS 库或者框架发布时，它可能在 0.x 的版本就能火起一片天，又或者马上出现竞争对手，多的是我们听都没听过的工具。另一方面，连我们使用的设备也从 PC 的一统天下慢慢转成了移动端的主场。

响应式与混合应用的概念

收，这篇文章的重点还是在于如何去考虑做移动端的响应式布局。

响应式（Responsive Web Design）是一个很早就出现的概念，当时人们就预想到 mobile 的占有率会飙升吧。 它指的是同一个页面能够适应不同尺寸的屏幕进行布局。这里说尺寸是因为我们大部分时间是在关注屏幕大小，而不是它用的是多少比例的屏幕、设备的颜色深度等等，所以其他一些用途就没必要说了，实行一下28原则吧（20% 的概念可以解决 80% 的问题）。

然后说 Hybrid 应用，它同样不是一个新词。很多专注于业务而非性能的 APP 都会采用这种方式去开发。它指的是用前端技术（HTML, CSS, JS）配合中间件（比如 cordova）去开发一个移动端应用。因为 WebView 的存在使这些都成为了现实。

它并不是什么高深的技术，只要稍微懂点英文单词，根据它官方文档描述的内容，花半天去看就能配出一个 apk 来了。

难的永远不是框架或者工具，而是思考问题的角度和解决问题的方式。

毕竟从 apk 走到产品还是有很长一段路的。

屏幕尺寸

前端的同学应该对兼容性是恨透了，那做混合型应用的话就很少会有兼容性问题了，然而换来的却是另一个问题——屏幕适配。

移动端屏幕尺寸的碎片化非常严重，小的有 320 * 480，大的有 1920 * 1080，然后你知道手机都支持旋转的吧，所以这些尺寸的宽高对调一下又是一副新面孔。但只要有问题就有解决办法，毕竟市面上那么多页面都显示的好好的，它们是怎么做到的呢？

乔布斯还活着的时候，他坚持认为 3.5 英寸的手机是最符合人体工学的，但我们知道，iphone 4s 比 iphone 3gs 的像素高。这是因为有个度量单位叫 PPI (Pixels per Inch)，指的是每英寸的长度上有多少像素。

也就是说 320 * 480 的屏幕上一个像素，相当于 640 * 960 的屏幕上的四个像素。如果纯粹按照像素来算的话，显然后者可以在同样大小的屏幕上显示更多内容，这会导致有些内容甚至小到看不清。

缩放比例

我们希望对于同样物理大小的屏幕，能有相同的布局，尽管他们的实际像素可能差几倍。所以这里又有一个倍率的概念。之前提到响应式中的尺寸，就宽度来说的话，有两种，一个是 width，另一个是 device-width 。前者是实际宽度，比如某手机屏幕的宽是 1080 像素；后者指的是按照倍率缩放之后的宽度，比如这款手机是 3 倍率的，那么 device-width 就是 360 像素了。

很多大屏手机，或者不同分辨率的手机，经过倍率的换算之后，device-width 是相当统一的。

所以这就是为什么我们会在手机端的页面上设置如下标签：

  html  <meta name="viewport" content="width=device-width, initial-scale=1">

就是为了让 CSS 在设置大小（盒子宽高、行高、间距、字体大小等）时，按照 device-width 而不是实际像素来计算。

这样子的话，同样的页面，在 1 倍率的 320 * 480 屏幕，和在 3 倍率的 960 * 1280 屏幕上会有一模一样的布局。

至于如何计算这个缩放比例，很简单，用

  javascript  window.devicePixelRatio

一般桌面浏览器的 devicePixelRatio 是 1，手机上就会有 1.5, 2, 3 等值，然后与

  javascript  screen.width

结合换算一下就能得到我们需要适配的屏幕宽度了。

关于响应式布局的几点建议

选择断点

首先需要明确的一点是，我们是 针对屏幕尺寸布局，而不是针对设备布局。

所以，如果用 @media 做判断的话，不需要针对 iphone 几，或者 samsung 多少而无谓增加各种条件，只需要问自己，在 320 像素、360 像素、768 像素等宽度的屏幕中，页面应该做怎样的调整。

各位应该都知道，响应式布局中有一个“断点”的概念，就是说，假设有

  css  @media (max-width: 768px) {
  /* 针对 768px 宽以下的屏幕 */
}

那么 768px 的宽度（如果在 meta 中设置了 width=device-width，这里的宽度就指的是 device-width）就是一个临界点，小于等于 768px 的屏幕会执行这段 css，而大于 768 px 的屏幕就不会。

可能说屏幕大家会误会，手机端的屏幕宽度就是视口（viewport）宽度，因为它不支持调整窗口大小，而 PC 端的浏览器可以调大小，那屏幕宽度确切地来说应该是视口宽度了，也就是网页可视区域的宽度。

至于你应该怎样去挑选断点，就需要根据应用场景来决定了。我一般是开了 Firefox 的响应式设计模式，那里预置了很多尺寸，如果用户对象是移动端，那么 360 * 640 就挺常见的。如果不知道应该怎么选的话，可以尝试用一下。

利用 GPU 减少 DOM 操作

既然是做响应式，那么很多兼容性问题都不需要考虑了，毕竟只有 IE 9+ 才支持 @media 指令，那手机端就更不用说了。

CSS 3中新增了 transform 和 transition 这两个和动画相关的属性。以往如果要实现将一个方框从 100 * 100 放大到 200 * 200，可能需要用 JS 去定时改变 style 中的 width 和 height 属性，后果是每次 style 的改变都会引发 DOM 重绘。用 transition 可以这么来做：

  css  .box {
  width: 100px;
  height: 100px;
  transition: all ease-in .3s;
}

.box.active {
  width: 200px;
  height: 200px;
}

需要放大的时候，通过 JS 给 .box 加上 active 类就可以了，GPU 会帮你完成过渡效果。当然，深入研究的话还有很多知识可以讨论，只不过我想引出的就是， 能用 CSS 完成的效果就不要用 JS 去做，各司其职。

从另一个角度谈性能

性能，经常看博客的同学可能都知道：压缩 CSS 和 JS，做 sprite 图，将图片（要优化的话，图片往往是重头）部署到静态资源服务器，用 CDN，等等。

但是那么多条条框框下，我们可以做到什么？对于很多前端工程师来说，这些事情是不需要自己去做的，公司中自然有专门的构建工具帮你部署。在学校中的同学，从来不会考虑这些方面，甚至没有专门做前端的，就像本文开头所说的，从别的网站上挪几段样式表过来。

然后，我们比较两款产品，搜狗输入法和QQ输入法（好吧，虽然跟前端没太大关系）。如果尝试过各种输入法的话，你会发现搜狗输入法的启动速度很慢。我无数次卸载过，换成必应输入法、百度输入法、QQ输入法……但他们的皮肤都没搜狗做的好，于是又可耻地装了回来。

所以我觉得比性能更重要的产品特色。可能做前端的不会去多考虑产品相关的领域，但具体问题具体分析，不要为了刻意去提高性能而花很多工时在优化上。计算机界不是有句话很有名么：

过早的优化是万恶之源。

并不是说不需要提高性能了，而是说，搞清楚什么时候该做什么事情。

倒是有些优化在编码的时候就能做到的，就比如之前所说的利用 CSS 动画而非 JS 去模拟。在用高级的 CSS 属性时，想一想代价，能用低级的属性就用低级的。意思就是说，用 flex 可以实现任何布局，但它的计算代价非常大，所以不到万不得已就不用。

如果能保持一种代码整洁的强迫感，那在优化这条路上就会走的很顺畅吧。

（小结放到文章开头了……）

以色列为啥叫创业的国度？这篇文章告诉你其中的奥秘

Tue, 12 May 2015 15:02:01 CST

刘芮含, 专注以色列创新创业方面业务,前期是主题游学切入。在此，将个人与以色列往来的一些感触与大家分享。

一、创业的出发点

首先从创业说起。我发现，大多中国创业者和国外创业者最大的区别，在于创业的出发点完全不同。很多中国当代创业者都是抱着视死如归的态度创业，和赌徒没什么分别。我曾和国人讨论过原因，他们认为是中国创业者失败的成本高。我并不认可。我觉得或许是国内人与人攀比成性，看不得别人好而自己不好（没有正确的标准），不能用平常心对待失败（不知道何谓真正的成功），而且总认为失败就再也没有机会了。恐惧失败，因为中国人大多不认为在最失败的时候会有帮助他们的力量。

我看过一篇报道，几乎99%的以色列人都相信，在他们最艰难的时候，上帝会帮助他们。

所以，在以色列，如果你失败了，没有人会笑话你，再重新开始就可以。我认为这是我们应该学习的地方。我们为什么不愿意承认失败，或者公开自己的失败？是因为没有一个宽容的环境。此外，你自己要先宽容自己，世界上不是只有赚钱这一条路才能让你幸福。道路有太多种，只是当下大家把创业当成流行。

二、正确的金钱观

“钱”是什么？在你心里，钱的地位和重要性如何？这个问题大家可以好好想想。我们中国人当下比较重视钱，称钱是价值的体现，把一切都按钱的多少来分等级。钱在天朝国人心中其实是万能的，国人愿意为钱付上一切代价——辛勤工作（无底线加班且炫耀这是勤奋的代表）、透支健康（晚睡+强迫跑步以显示自己的毅力耐力）、透支亲情（陪家人的时间越来越少）。

我这不是发牢骚，是客观地说出一些流行现象。我自己也曾经认为，12点前睡觉都不好意思说自己在创业。但是，当我跟N多个以色列人（并不代表全部犹太人）沟通后，他们几乎一致认为钱只是工具。大家很难想象，每周从周五日落到周六日落（安息日），犹太人什么工作都不做。和家人在一起、晚餐、去犹太教堂敬拜上帝，完全地休息。手机、电器都不用，车也不开。最开始，我是不相信的，虽然我也信上帝。但是，有一天，和以色列一个非常成功的钻石商一起度过安息日后，我发现是真的。他们守安息日（不是全部犹太人，只是信仰上帝的犹太人）是真的守着与上帝的约定。而且，他们证明了安息日不仅不会耽误事情，反而更加让人得到力量——从上帝来的力量，所以他们不会用命去换钱。犹太民族被称为最会赚钱的民族。是的，他们非常精明，但是有底线。做事的初心，是让事情有益于人，同时再赚钱，当然他们当中也有不好的人，我只是说大方向的风气。比如，他们不会为了多赚钱让奶牛喝三氯氰胺，这就是赚钱底线的体现。

三、契约精神和严谨态度

之前，我一直做to B的青少年素质培训项目。几乎天天眼见中国人的不守契约、不守诚信，欺骗、故意拖延等劣行。而在与以色列人合作的过程中，我明确感受到他们不会这么做。我与美国人合作，他们也不会承诺做不到的事，也不会承诺的事不去做（不是全部，哪里都有不好的人，只是在说大方向）。

以色列人做事比较严谨，跟他们建立信任很不容易（介于他们尝到过中国人的厉害）。而且在他们的社会里，信息传播非常快，结构扁平化。如果你不诚信，很难再混得下去。他们对于没有建立信任的合作，不会拿出最好的技术（因为中国人常常以考察的名义去抄袭）。只有他真正信任你了，才会拿出最好的给你。

四、平等、自由和感恩

在中国人眼里，对待所谓“高贵的人”（有权有钱有位有名）要低人三等；但在以色列，则非常平等，这是我亲身感受过的。无论他们多么有钱，多么高地位，依然会平等地和你对话，和你讨论。比如我——中国人眼中的屌丝——和以色列驻华大使聊天，虽然我英语不是很好，但是他还是会和我聊。比如，以色列一些所谓的富翁，他们都很平等地对待轻人。而我和中国某些牛人们见面，他们身上总是盛气凌人。我相信不只我一个人有这种感觉。

以色列人不会为维护某人的面子而忽略他们犯得错误。而中国人常会觉得，一个人好，连他身上的虱子都是镶着金边的。这个在他们的世界里不是这样的：好的地方就是好，不好就是不好。最多就是不说，但不会掩盖事实。

还有，他们无论自己的生意做多大，也愿意做小事赚小钱。比如，我有个小生意想和国内某名人合作，就遭遇明显地不屑一顾的态度。认为这么小的生意（10万美金差不多）来找我做吗？但是以色列不是。第一次合作的时候，他们的总裁会过问每一个细节，亲自服务客户，当然这是我所在行业的环境。

自由的体现，在于他们没有固定统一的标准答案，他们称为“常规答案”。犹太人自己也说,，有两个犹太人，对于一件事情的看法就会有3种或更多。犹太人每个人都有自己独立的观点，这也是他们这么创新的关键之一。他们不会被思维限制，他们在各种磨难（追杀或灭族的灾难）面前都能坦然开脑洞。

我发现犹太人很爱中国人，对中国人很友好。他们到现在都感恩，二战期间，中国开放收留犹太人。有一次，我们一起吃饭，一个犹太姑娘说，我代表以色列感谢中国。我从来没想过，我会代表中国感谢谁，而他们对人常有感恩之心。人和人沟通也相对真实，不用听一半猜一半。

我认为，本质的区别在于他们有信仰。他们相信万物之上，有一位上帝在看着一切。而国人的上帝是钱、是自己，所以做事经常没有底线。所以作为众多创业伙伴中的一份子，我衷心与大家共勉，要想创业成功：1.不要迷信资；2.自身要建立可持续的商业（业务）；3.不要过度崇拜某名人（他们和你一分钱关系都没有，即使你们一起自拍过）；4.摆正心态，失败就重新来；5.不要贪大，总想找百亿级的市场份额（以色列全国才800万人，全国才北京这么大）；6.从道德、从价值观改变，不要投机取巧，即使换到钱最终受害的还是自己；7.要有信仰。

社交产品的本质类似传销！你玩的微信、QQ不是社交

Tue, 12 May 2015 15:15:22 CST

前几天写了篇《产品从0到1的真正边界是什么？》，接着就有做社交的朋友来找我，让我帮他们找找，他们产品的0到1在哪，顿时我觉得我让自己掉坑里了。但后来冷静想想，其实他们跟我之前的心态一模一样，幻想用一些小的创意点去做社交，然后通过把这个点打到极致，就可以把社交做起来。他们也和之前的我一样，关注0到1更多的不是因为关注人性本身，更多的是希望能够找到一个迅速让自己项目成功的捷径，对自己的项目有一种一步登天的侥幸。

当然，也感谢这些朋友的逼问，再加上我这两年的爬坑，也倒逼着我想把社交的底层逻辑全部想清楚，希望各位能够和我一样尽早跳出妄想与执念。

社交底层人性是“中心化”

社交这个东西应该直接倒回到古人时候看，以求知为例，无论东方还是西方，都是有一种顶层设计的规则，大家来这里都是首先对知识感兴趣，然后聚拢到最有学问的老师身边，而老师则看到一些不错的学生，将其提拔为学长，而下面求学的人向老师无法请教的时候，就选择向这些学长求教。这个例子不是特别恰当，是帮助各位对社交本质的初步理解。

接着谈论坛BBS，当前的社交APP本质上就是BBS，回头会细谈变与不变，现在总体谈一下BBS的游戏规则。

首先这个BBS论坛社区有一套自顶向下的游戏规则，话语权最大的是管理员，管理员可以掌控每个版块的生杀大权，接着是版主，版主可以管理每一个用户的发言，可以对好的内容进行置顶。于是，游戏规则就形成了。刚开始，管理员自己是各个版块的版主，通过发现里面的一级活跃用户，不断对其优质的发言内容进行置顶，让其获得成就感。然后根据深入交往后，选择每个版块所对应的版主，接着版主也开始重复这个路径，在板块下面看到不错的内容就进行不断的置顶，而被置顶的人会因为内容置顶而不断发表更多优质内容。那些被置顶多的活跃用户于是就成为这个版块的小红人，大家都认识，他的发言下面也会有很多回复，小红人也很享受，大家也很享受这个社区，这个社区也让他们找到存在。

管理员培养版主，版主培养小红人，小红人不断活跃发表优质内容，这些内容再把其他用户留住参与。

所以整个流程是一套中心化体系，与平时聊的什么互联网去中心化完全不是一回事，互联网不是去中心化的过程，而是减弱非互联网时代原有的中心化格局，重新建立中心化的过程。

整个亚洲由于其农耕文化的渊源，其集体主义的文化更为显著，其亚洲的互联网社交比美国呈现出更为中心化的特点，新浪微博与twitter最大的区别就在于中心化的强度，新浪微博通过明星、公知、段子手建立了一套比twitter更为强大的中心化体系。而新浪微博也是当时几家微博中有着最强中心化的一家，所以做成了。

所以，做社交如果不站在中心化话语权的理解上，是一定会失败的，任何希望通过一个创意点，建立一个去中心化的社交不可能存在。不理解中心化，就是不理解人性，一定做不好社交。这里有人可能要反驳，微信是去中心化的，这点我放到后面再讨论。

APP社交的变与不变

变：由于手机的便携性，今天的社交APP在社交上融入了更多其他元素，语音、图片、视频、地理位置。这些再加上其他各种组合可以变化出无穷的各种社交产品。这是变。

不变：今天的一切社交APP和过去的社交BBS论坛没有任何区别。在BBS诞生之初并没有运营这个工作，而随着上网的人越多，中心化的社群越来越多，所以运营这个工作也就诞生了。其本质上不过是对管理员和版主工作内容的系统化，标准化的建立与执行，其工作本质与之前没有任何变化，就是为了建立中心化话语体系，让更多用户追随。

所以我再强调一遍，当前的APP依然是BBS的还原，只不过被融入了各种元素而已。如果这个系统中没有中心化的话语体系，就没有吸引人的内容呈现，就更不会有追随与停留的用户。

所以，如果一个团队要做社交项目，没有运营能力或者运营资源那一定是必死无疑的。

微信不是社交，是基础设施

接着谈一下为什么微信和QQ不是社交。其实也很简单，我们看所有微信和QQ之外的其他全部社交产品，全部都是从公司层面直接通过运营介入用户中的，而微信和QQ就没有。

因为微信和QQ做的是熟人关系，不是陌生人。微信和QQ更应该是底层的水、电与空气，陌生人关系一定会在其基础上自动生长出来，各种中心化的微信群被用户自发建立起来，微社区也是用户自己建立。而朋友圈表面上是去中心化的，但实际上并非如此，朋友圈依然是中心化的，在你的小圈子中注定有几个是红人，他们发什么都注定会得到比别人更多的点赞，这一切也是用户自发形成，无需腾讯通过顶层介入。所以微信和QQ本质上一个工具，互联网是第一层，而他们只是在这之上再加了一层。

这时候又有人会质疑，QQ里面有一个“QQ部落”是一个类似贴吧的社交社区，这不就说明QQ还是社交吗？这又是没看到本质了，熟人层面，腾讯是没有介入的机会的，腾讯介入的是陌生人层面，腾讯也同样是在通过工具切入陌生人社交市场，这只是一个附加的模块，而不是其核心。

还有一个可能的质疑就是，像微信和QQ在诞生之初，用户在上面加的都是陌生人，微信还通过摇一摇发现陌生人，这不是说明QQ和微信还是社交吗？这也是一个误区，我们要看到，这其中没有公司层面运营的介入，没有建立中心化体系，这在本质上依然只是工具，只不过寻找陌生人这是其原始爆发的人性本能动力，但本质还是一个工具。

此外陌陌在爆发初期也是一种去中心化的方式去爆发，本质上也是一个工具，其如果成功，那么未来的路径与微信和QQ一样，就是熟人市场。但由于微信更出色，并且捷足先登，所以陌陌又只能折回陌生人市场，从工具转变为社交，通过强运营手段维护用户。比如在刚开始建群的时候唐岩就管得很严，需要通过控制分散的中心化，来控制好底用户使其更活跃，随后也开辟了陌陌吧这些能够加强运营的功能，培养更多红人。这次6.0改版，就是全面的将工具转向运营，意味着彻底放弃熟人市场，对自身最为彻底的一次清晰的重新定位。

另外像米聊、遇见、比邻、无密这样的产品和陌陌微信本质逻辑一致，属于工具，但是现在和陌陌一样，已经没有了成为底层基础设施的机会，也在反过头来做社交，都在想办法运营，而这三者中无密的运营模式最为简单，但无密无法产生红人，只能靠编辑这个唯一的中心化管理者，非常单薄，所以更接近一个看内容的新闻阅读平台。

熟人层面的连接不能称为社交。互联网是为我们连接更有效率而铺出的第一层基础设施，互联网是一个工具，那么在这一层基础上，我们人与人之间原本就存在的关系需要被还原，所以还需要在互联网这层工具上面再做一层工具，这就是QQ和微信了，它们本质上应当称为关系还原的工具。

所以微信和QQ做的不是社交，做的是原本就存在关系的还原工具，然后让用户在上面自然的拓展社交。但是一上来就做社交的公司，就不是在做关系的还原，因为这些关系是原本不存在的，这些社交产品做的是建立新关系，也就是重建中心化，所以必然需要运营强势介入。

一针捅破天理论不适用社交

这两年一直很火一个理论，就是一针捅破天理论，傅盛每次出台都要为该理论摇旗呐喊，而很多互联网人都开始信奉这套理论，认为只要找到了这个极致的“点”，“0”到“1”的奇迹就会出现，就能够马上进行颠覆式创新了。

但跟着我仔细分析一下这个理论，找到一个“点”来做到极致，如果要让很多人用，那么这个“点”必定是切中了所有人的需求，切中所有人需求的点一定是也只能是工具，比如清理内存，Wi-Fi连接，拍照等等这样的工具，这是没有什么中心化的东西在里面的，这是每个人都平等的，这里面是没有运营的，有运营也是在这个工具产品的论坛里面和产品自身没关系。

所以“一针捅破天”理论一定仅仅适用于工具。

我们现在对社交产品其实有一个最大的妄想，也是我之前最大的毛病，就是通过这么一个工具化的“点”，只需要通过少量运营，就能够让所有用户都被自动卷入其中，所以一大堆创业团队会围绕在文字、语音、图片、视频、地理位置等等这些点上轮番找新意，做出小创意的东西，弄出各种产品来。

这么弄可以，但是有两条路径。

先说第一条路径，创业团队就是通过这样的一个“点”去结交陌生人，比如通过蓝牙雷达找到附近的人，通过共同在哪个位置出现找到附近的人，通过对着麦克风吹气来发现陌生人，这样的小创意来发现“人”。这本质上其实是陌陌微信已经干完的事情，是一个工具，已经早就错过了这些风口了。当然也有一些垂直领域，也希望通过这样的点，依靠不需要运营的方式来实现用户的积累，这同样也是不可能的。

第二条路径，就是通过这些小的创意点，加上强大的运营来推动，那就有机会。比如nice就是一个图片加标签的形式，然后有着很强的运营，让用户看到优质的内容和小红人，而小红人们也被促进着继续发表内容，这样就可行了。但这本质上一定还是BBS，还是运营，本质不会有任何改变。

说几个“一针捅破天”的社交产品

唱吧：唱吧的陈华很有意思，也可能他是受“一针捅破天”理论的影响，每次演讲都说唱吧是因为把唱歌录声音这个“点”给做好了做透了，所以用户才留在上面。我承认，把声音变好听这个“点”相当重要，但有批判精神的人更应该反向思考。

难道真的就因为把这个“点”做好了就可以对抗竞争对手了吗？当然不是，最重要的依然还是运营，还是靠编辑挑选优质内容，刺激美女红人唱歌。我们反着想就很清楚，一个唱歌APP的效果再好，但是当她唱完之后只有3个人听，并且只有收到1个鲜花，而另一个唱歌APP的效果并不是特别好，但是当她唱完之后有30个人在听，收到10朵鲜花，那么这个用户会选谁自然是不言而喻的。

所以唱吧能够超越对手的除了技术外，最重要的还是运营功夫。任何创始人都可能会对自己的成功有归因谬误，也同样是因为这种中心主义的文化，我们很容易相信一个权威所说的话而缺少自己的独立思考，很多人也被“一针捅破天”的理论带到了坑里去。

美拍：美拍做的也很不错，据官方公布日活千万。之前也有人跟我说，看吧，这个就是把用户拍视频的功能做到了极致，切中了虚荣的底层需求，然后成功的。这又是“一针捅破天”逻辑在作怪了，美拍刚诞生就已经势能十足，各种明星都是直接就入住的，而运营编辑又不断的把明星内容前置，接着又把那些活跃草根号的内容前置，不断刺激，不断激活，这就导致了大量的用户停留与观看以及使用，甚至愿意成为红人。这和美拍切入的那个点确实有关系，但是试想如果美拍刚诞生没有这么多强势的可运营资源，单纯作为一个工具，又会有多少人用？至少现在这个日活千万级别是绝不可能的。

##########NextPage##########

Nice：Nice是一个在图片上贴标签写内容，然后再发布图片的APP。很多人又说这是一个极致的点，切入的实在是太好了，Nice就是靠着这个点做起来的。当然我想说的是，试想一下，如果打开nice，上面不是编辑通过运营挑选的优质内容，而是用户随便发的大量无聊图片，还会有多少人用？恐怕都逃之夭夭了吧。

综上：还是谈的变与不变，手机的便携性，使得文字、语音、图片、视频、地理位置能够组合出各种有创意的社交变化。但是不变的是任何社交产品离不开中心化，任何切入的创意的小点都只是起到一部分作用，这些小创意是在给某个社交社区提供一些文化调性上的支撑，起不到绝对的作用，最终一切还看运营实力。

那么社交到现在还有没有机会？

现在说到各位最关心的问题了，到底现在社交还有没有机会？那么先说不存在的机会。不存在的机会就是想通过一个“点”，建立一个基本不需要运营的社区，那就是不存在的机会。

其次，手机的特性导致了一定还会有很多创意的结合方式，但是这些创意与能否成功不是关键，这些创意只是在给运营制造一种文化氛围，而要想把社交做成功就看如何运营。如何把这个社区自顶向下的做好，让用户一进来就能看到优质的内容，让用户一进来就能感受到这里有活跃的红人用户，让这些进来的用户愿意为你的氛围留下，甚至愿意成为你的红人用户，这才是社交的核心本质，只要能把这种自顶向下的氛围做好，一切都不是问题。

此外，每个垂直领域都会有大量的中心化用户社群，一个平台越大，在上面的红人用户就越多，看一个平台能做多大，就看其笼络红人用户的能力。所以每一个垂直领域依然都有机会，只要创始人在运营方面的资源势能充足，绝对能够做好。

就像美拍的出现间接的让腾讯放弃已经坚持很久的微视一样，腾讯之前打造的微视的逻辑是通过与一些公司合作，购买内容，然后吸引用户。而美拍的逻辑则是，第一步和腾讯一样，先通过明星产出的内容先打开用户群体，接着更重要的是，美拍非常懂得去挖掘草根用户，让更多的草根用户与美拍共舞，通过不断培养更多红人的方式来完善平台，被培养的中心化的红人越多，这个平台也就也越吸引人，这是微视所欠缺的，或者说是没有做好的。

所以说到底，社交的本质一方面还是拼资源，一方面还是拼对人性的理解，如何让更多普通用户成为红人用户，产生更多优质内容，以及让更多用户留住。另外再说一下，小米做的miui论坛确实厉害，做到了真正的参与感，其建立了一个让中心红人用户不断增多的系统，中心化的红人多了，整个系统的权威就更大，这是一个非常巨大的良性循环。

结语：所以社交的本质还是社群，是不断的建立中心化的过程，中心化的人越多，这个社群的势能就越大，这也和传销的本质一样，但传销向恶。社交产品拼的就是一个用户氛围，任何想要靠一个“点”就想把社交做起来的想法都是妄念。通过一个“点”就能吸引海量用户的产品，一定是去中心化的工具产品，而这类产品不具备可运营性，就不是社交，如图。

另外，这篇文章也从顶层解释了营销和运营的规则。如果你要在一个平台上营销自己，那么就需要去与这个平台更多比你更加中心化的红人结交，最好是与管理者结交，让自己的观点不断露脸，拉动自己的中心化，持续输出内容，比如我在发这篇文章。其次如果你是一个管理者，是在平台做运营，就需要设计好的规则，拉动更多的红人出现，建立更多中心化体系。当然，这一切的前提还是基于高质量的内容，如图。

我们应该尽早跳出乱象，从文化层面看到社交本质，希望那些还在社交坑里的朋友们能尽早爬出来。

关注人文与科技，欢迎关注我的微信公众号：shouxifayanzhe

Jott：无需网络，借助蓝芽原理的聊天App在美国青少年中爆红

Sat, 13 Jun 2015 09:17:14 CST

在国内，熟人社交市场几乎被腾讯垄断了，陌生人社交有陌陌，除了各种重度垂直的社交领域，很多创业者都想切青少年社交。虽然这一块是QQ的地盘，但是机会依然有，小朋友总是生性好奇的，容易被流行引导。在美国，青少年都在手机上用什么？你或许听过Snapchat或YikYak，但有个新的聊天应用 Jott，也来自新创公司，靠着不需网络的聊天服务，逐渐拢获美国青少年的心。

Jott约在今年3月时，突破50万活跃用户，而其共同创办人Jared Allgood表示，平均每日也约有1万5千至2万名新用户加入，从今年4月开始，Jott就成功挤进iOS 社群App排行榜中前75名，至今维持水准成长中。

而Jott受到青少年青睐的原因很简单，就是不需要网络就能发信息。大部份中学生即使有智能手机，大部份却都没搭配网络流量方案，在学校时也大都无法用网络，即使有装置也不一定能与朋友传短信聊天。

Jott不需网络的背后原因，是靠低能源蓝牙或路由器来发短信（称为mesh network），只是传讯息的对方得在30公尺之内。这样简单的原理，却成了他们受欢迎的关键。

即使Facebook、Snapchat、Instagram都是社交网络的榜上龙头，但是青少年最常用的，还是发短信这样单一的功能。大约87%美国青少年每天都会发短信，反之使用频率第二名则是61%会使用Facebook。

除了不需网络外，Jott还有其他特色功能，来抓住青少年族群的使用习惯，例如对青少年而言，开口询问电话号码似乎不是件容易的事，因此Jott设定只要是同样社交网路（例如同学校、同个夏令营），就可以加彼此为联络人、开始聊天。

网站：http://jott.com/

猜您喜欢：
FireChat：无网络聊天APP爆红，这个方向值得关注	FastSociety ：手机APP提供免费的群组聊天和位置共享服务	Knewton网络培训公司	2011年美国100家最具创意的企业（领域3：媒体）	APP的未来
无觅

本文版权属于- 商业不靠谱 Bukop.com -转载请务必保留版权信息。
商业不靠谱（bukop.com）致力于汇聚全球新兴的商业模式与创新趋势，在全球范围内整合优秀商业创意和案例，并将这些好点子提供给具有企业家头脑的创业者，以及对创新和挖掘新商机有兴趣的朋友。

从0到100万下载APP应用市场优化怎么做

Sun, 28 Sep 2014 21:15:47 CST

如何提高应用的曝光度和排名从而获得更多下载对于运营推广人员或者开发者来说是一个非常重要的问题，一款应用在0预算的情况下你应该最先做什么，在各大应用商店(以下简称：应用市场)你的应用要怎么优化才能有好的排名，这篇文章将告诉你如何通过应用市场优化获取更多的下载量，并且通过一张图总结了所有可能影响下载的参数，据了解已经有应用在0预算的情况下通过优化做到100多万的下载量。

　　一张图告诉你如何做应用市场优化(下图)

　一、应用图标

经常上网购物，你会发现优质的商品图片往往点击率会比较高，应用图标(ICO)在各大应用市场的展现是同样的道理，一个有吸引力的应用图标会直接影响用户的点击和下载。所以在应用上传的时候就要考虑，在同一类目中你的应用图标是否有优势比如：“形象、清晰、直观”等，这很大程度决定了用户选择哪个应用。

　二、应用名称

有数据显示63%的下载量源于应用市场的搜索行为，所以应用名称的选择就很关键：“比如是否带品牌名、是否带热门搜索词(可以通过工具查阅搜索热度)、是否形象体现产品等”。如果品牌知名度高直接用品牌加产品相结合方式命名会起到更好的效果比如“百度地图、腾讯新闻、凤凰视频”，而如果品牌知名度不高则选择和自身产品相关的词来命名比如：“XX天气、XX音乐”会省去很多品牌宣传费用，因为这部分词“天气、音乐”热度极高，如果有好的排名，将带来大量免费下载。

　三、应用介绍

应用介绍在很多应用市场是不作为搜索排序的一部分(App store除外)，在App store应用简介如果有相关关键词会作为排序的一部分。无论如何应用简介一定要写好，至少写出5个产品的特点，甚至定期的活动都可以写进去吸引下载，也可以把微信和联系方式等写进去方面以后的商务合作，而很多应用在这方面却忽略了。

　四、应用类目

应用类目也叫应用标签，根据研究调查和综合数据统计发现，在很多关键词搜索中即使关键词和应用名称不一样但如果标签和关键词一样，你的应用也会出现在关键词搜索结果中，所以在标签设置的时候要综合自己的优势和类别合理的使用这些标签，由于各平台提供的标签数不一样，最好允许设置几个就全部设置，这个在很多下载量过千万的应用都没有做到位。

　五、应用评分

应用评分是应用质量的最直观表现，在各大应用市场都有很高的权重，而应用评分又和应用评论数和好评数密切相关，所以要提高应用评分最关键还是要提高应用的评论数量和质量。很多应用为了提高自己的评论数直接做活动(如：给好评截图可以获得相应积分等)或者通过各种技术手段引导用户去评论，特别是App Store和Google Play对评论给予了很高的权重。

另外也有不少应用市场提供了用户评论的回复功能这个要非常重视，因为一方面你可以带一些有引导性质的回复引导用户下载，另一方面你也可以通过回复查看用户遇到哪些问题是一个很好的产品信息反馈渠道。

　六、版本更新

一个月更新一个版本够么?从用户的角度足够，但从应用市场优化的角度不够。在各大应用市场都有一个最新更新列表，据观察在小米应用市场应用更新后排名明显上升，而过一段时间后排名就开始下降。

你的应用应该选择在一周的哪一天更新比较好呢?告诉你选择周四或者周五比较合适。如果是节假日那么选择放假前一两天比较合适，因为周末和节假日很少公司上班，你应用的更新时间会保留的比较长并且周末(节假日)大家碎片时间也比较多。

　七、应用认证

在国内的应用市场很多有提供“官方认证或优质认证”这两个认证对于应用排名来说都是非常重要，因为通过这两个认证的应用有优先排名，并且在应用图标或者名称旁边会有特殊标识，所以在应用上传的时候就应该提前准备好这些认证材料。

　八、总结说明

应用市场的优化绝对不是一个简单的事情，ASO优化甚至已经形成了产业链，目前来说应用市场优化是提高应用下载最直接的方式。各大应用市场的搜索排序不断变化，但无论如何做好每一个细节对排名和下载肯定会有很大的帮助，以上内容希望对运营和推广人员有所帮助。

source:腾讯

互联网从业者必备微信公众号：woshipm，如果你已经关注了，证明你已经很牛逼了。

优秀产品必经的 14 个拷问

Tue, 29 Jul 2014 15:26:11 CST

说什么： How to do a Product Critique？

谁来说： Julie @facebook

产品评判（Product Critique）是修炼产品直觉的必修课，

而评价一款产品，就是搞清楚用户对于产品的爱与恨。

这需要把握住 2 个核心原则：

读懂用户需求
把握用户对于事物的反应

下面以体验一款新 app 为例（即从应用商店下载 app，打开它，使用它...）

分3个阶段共用14组问题来阐述产品评判的思路：

使用之前

[1] 这款app是如何吸引到你的注意力的？

How did this app come to your attention?

是朋友推荐吗？
他为什么推荐给你？
还是你在一篇文章中看到了这个 app？
如果是，是什么促使你去找到这款 app 下载它？
它的图标或名字吸引了你吗？
你以前听说过它吗？
听说过几次，为什么当时没有下载而现在下载了呢？

[2] 在使用之前给这款app一句话评价，你会说什么？

What’s your one-line summary of what this app does at this stage?

对比使用前后的评价将会非常有趣。

[3] 你现在对它的感觉如何？

What’s the buzz so far?

你觉得它会流行吗？
它有用吗？
你下载这个 app 时看过评分、评论和描述吗？
你对一款新 app 的第一印象有助于让你更好地理解一款 app 的“价值主张“、市场营销以及产品背后的团队想要营造一种什么样的印象。

初次使用

现在打开这款 app 开始把玩它。尽量按照正常的使用时间来用它（可能是几分钟也可能是半小时），然后问你自己以下几个问题：

[1] 产品的开始界面或注册体验怎么样？

What’s the experience of getting started or signing up?

是很简单的按几个按钮还是有一堆复杂的验证步骤？

[2] 这款应用在最初怎样引导使用？

How does this app explain itself in the first minute?

它是否清晰地展现了如何使用？
引导界面友好吗？
你看介绍信息吗？
会不会因为介绍信息又长又无聊而略过它们？

[3] 这款app的易用性如何？

How easy to use was the app?

你能立刻明白怎么使用，还是得研究一下才行？
app 里有很多引导流程，还是整个感觉都很熟悉和简单？

[4] 使用这款app时整体感觉如何？

How did you feel while exploring the app?

是轻松愉悦还是因为找不到返回按钮而很沮丧？
这款 app 让你感到更智能和高效了吗？
有没有发现让你惊叹的小细节？

[5] 这款app符合你的预期吗？

Did the app deliver on your expectations?

想想你原来希望这款 app 做什么，实际使用中，它达到你的预期了吗？
如果是以内容为主的 app，其中的内容你感兴趣吗？
如果是工具型 app，那么它解决实际问题了吗？

[6] 你这个app上花费了多长时间？

How long did you spend using the app?

使用时间与用户兴趣直接相关，如果你花的时间很长，那么是什么原因呢？
大部分人对于产品的印象都是在头几分钟内形成的，回顾这个过程能够让你更好的理解一款 app 是如何创造价值，如何方便使用，如何让人感觉到开发者的用心。

再次使用

第一次使用 app 之后的几天甚至几周的时间也非常重要，能够让你看出产品的持久度和成长性。

[1] 你多久用一次这个app？什么时候用？是什么促使你打开它？

How often have you used the app? When do you tend to use it? What compels you to open it?

是因为通知推送？
还是因为周围的朋友都在使用和讨论它？
你越来越离不开这款 app 还是它成为你实现目标的障碍？
它能否成为你日常生活习惯的一部分？为什么?

[2] 这款app与其它类似app相比怎么样？

How does this app compare to other similar apps?

哪些地方做得更好，哪些地方不好？
你为什么愿意选择这款而不是另外一款 app？

[3] 其他人怎么看这款app？

What do other people think of this app?

看看人们在网上是如何评论它的，你身边的亲朋好友是如何使用它的？
别人的评价与你的看法吻合吗？
如果不一样是为什么呢？

[4] 基于你所了解的这些，你认为这款app在一年后会发展成什么样？

Based on all that you know, how successful do you think the app will be a year from now?

把你的真实想法记录下来，储存好对于日后的总结分析非常有用。

[5] 一段时间以后，看看你之前的预言是否正确

(And eventually, after enough time has passed), were you right in your prediction of how this app was going to do?

如果没有，为什么？
你的个人喜好与市场表现有什么不同？
你一定要理解这一点，这样在未来你才能合理的修正你的看法。

三大应用性能隐形杀手：谁Kill了你的App？

Mon, 28 Jul 2014 18:50:13 CST

对于移动开发者来讲，活跃用户流失=应用慢性死亡！当你的创意、用户体验和coding都无懈可击时，是谁在不知不觉中Kill了你的App？听云平台根据真实数据统计：“连接超时”、 “崩溃”和“CPU使用问题”正是Kill掉你的应用的三大隐形杀手！

头号隐形杀手：连接超时

根据听云平台统计，网络错误是App关闭的首要问题，而在移动应用中网络错误数据比例报错中最高的就是连接超时错误。想象一下当你花重金好不容易把你的App推广到用户手机上，而在用户初次尝试时发生连接超时无法正常使用，多数用户会选择再也不会打开你的应用第二次。

根据听云平台对可公开的样本数据分析：一个应用存在连接超时错误，该错误从上午9点开始报错比例突增到2%以上。

其中报错集中在接口域名下

具体报错连接是一个列表文件页面

在应用中的现象是提示网络不佳

该示例应用日活400万，月活4000万。听云平台分析，此问题将直接给开发者带来近10W个用户将永久不再使用。此问题如果持续一个月，近100W用户将永久不再使用这个App！小小的“连接超时”正在每天“偷走”开发者的用户，杀手本色尽显，“贵”为App头号杀手！

二号隐形杀手：崩溃

崩溃，是一种境界，教你也不会只能自己体会！App崩溃往往伴随着用户的“崩溃”！

根据听云平台对同一样本应用分析，发现该应用在7月1日崩溃比率从1‰左右上升到2‰ 。

听云分析：99%以上的崩溃都集中出在该应用的4.6.5版本，以此开发者可以判断原因是由于应用新版本上线所致。

同时听云平台还提供了崩溃当时调用的代码信息如下：

其中安卓4.2.2和4.1.2崩溃比例最高

其中小米1S手机崩溃比例最高

通过听云平台分析可以直接定位“崩溃”原因，并且根据系统版本和手机型号的崩溃原因进行分析和改进，揪出App的二号杀手。

三号隐形杀手：CPU使用问题

2014年7月武汉晨报报道：在广埠屯一家手机维修店了解到，最近武汉高温潮湿天气的来袭，让手机“中暑患者”有增多的趋势。“打了个电话，手机就滚烫滚烫的，刚开始也没怎么注意，现在手机发烫就干脆死机，这是咋了？”

据日本NHK网站2014年2月报道，去年全年，日本全国消费生活中心接到了520件左右的手机过热、手机死机等咨询案件，是前一年的5倍。

据半岛新闻2014年7月报道，司机小刘手机玩着玩着死机了，通着电话自动挂掉，由于频繁死机、速度变慢、温度升高甚至出现高温导致塑料材质的手机后盖出现融化的情况。

夏日来临，手机过热、手机突然死机又成了用户频繁投诉手机厂商的一大问题。

根据百度搜索数据，有275W条“手机过热死机”的搜索结果。但是请不要把用户的问题都归结为手机电池，听云平台分析：CPU超载是杀死App的第三大杀手。

据听云平台数据显示

当该应用在执行一个列表页程序时，CPU和内存使用率明显提升，对应的线程耗时时间明显增加。CPU频率设置过高时会导致过热,过热导致耗电更严重,CPU频率设置过低导致手机滞后,应用处理缓慢同样会导致耗电。更多时候，用户解决CPU超载问题只能关闭甚至卸载App。你的App就被Kill了！

囚禁杀手

如何囚禁“连接超时”、 “崩溃”和“CPU使用问题”乃至更多导致用户流失的杀手呢？

根据听云平台发布数据：69%开发者还处在裸奔状态！而作为中国最大应用性能管理服务商的基调网络日前所发布的听云平台，每日帮助开发者监控超过100亿次的真实用户请求，发现应用性能问题超过15万个，帮助应用留住因性能问题即将离开用户超过175万个，通过核心技术优势快速帮助开发者“囚禁”应用性能的“杀手”。想了解移动应用性能相关数据动态和报告，请登录听云平台永久免费版：www.tingyun.com

居民小区App的未来

Sat, 24 May 2014 19:04:20 CST

在 O2O 不断升温的移动互联网时代，各大互联网公司不断的跑马圈地，淘宝的淘点点，腾讯的微信，滴滴与快的打车，饿了么等等，O2O 的领域不断出现巨头的身影。而同时，连接小区业主、物业、以及周边商户的这类小区服务正如雨后春笋般冒出，O2O 深入到每户家庭中成为了诸多创业者的方向。

叮咚小区，小区无忧，小区问问，小区管家，小区助手，诸多的小区 App 不断冒了出来，在尚未出现巨头的小区服务领域，似乎仍是个蓝海。然而，5 月 17 日，上海叮咚小区宣布获得亿元的天使投资，将小区 App 大战推向了高潮。这让笔者不禁想到去年 10 月份获得 C 轮 6000 万美元融资的邻里私密社交应用 Nextdoor。Nextdoor 在美国可以说是发展的风风火火，从成立至今，共获得了近 1.5 亿美元的融资。

从成立开始，叮咚小区的产品思路就是仿照 Nextdoor 的方向，从小区社交切入，打造小区 O2O 生态圈。但是，获得了亿元天使投资的叮咚小区真的价值这么多吗？在国内，小区社交真的就是下一个 O2O 巨头产生的领域？

让我们先来看看叮咚小区是如何发展起来的，叮咚小区的推广手段有哪些？

首先，工作人员小区地推。从 14 年 1 月份上线之后，叮咚小区第一批的用户就是靠小区的地面推广，上海浦东张江的玉兰香苑、汤臣豪园是他们第一批推广的线下小区。笔者也就驻扎在张江，正好赶上叮咚小区第一批的推广，叮咚小区推广的方式很简单，小区的商业广场树立一个广告牌，下载叮咚小区，领 5 元红包。其次，地铁广告，这应该是大部分用户看到叮咚小区最直接的方式了，上海的地铁车厢门以及一些街区广告上，到处都是叮咚小区的广告，其在上海 1200 万每月的推广费用，足够让其哆啦 A 梦样式的 logo 有了足够的曝光率。后来，笔者发现 QQ 空间的推荐应用的位置也出现了叮咚小区的身影，小区生活便利站的口号不时出现在笔者的视线中。经过几个月的积累，这些推广的渠道也带来了官方所说的百万级的用户。

然而，小区社交是否会在亿元的天使投资下就这样盖棺定论？

首先，我们来看看什么是小区社交：小区社交是以居民小区为中心，基于同小区居民的人际关系，位于熟人社交（微信）与陌生人社交（陌陌）中间的一个社交领域。

尽管在国外有了成功的模式，但是小区社交在国内，从目前的状况来看，笔者并不认为其是一个强需求。

首先，不断流动的小区居民。在中国来说，大城市是大部分 App 发展的起源地，对于小区 App 更是如此。其实从推广上来看，叮咚小区选的第一步很不错，张江地区的居民基本以软件园的白领为主，人员密集，从事 IT 行业的居多，对新事物和互联网新东西的接受能力较强，再辅以 5 元钱红包的诱惑力，几万的下载量很轻松就可以达到，但其忽略了张江地区小区的居民流动性，作为长期潜伏在张江的笔者来说，张江地区居民的流动性可以说是非常快的，今天在这个小区，下个月可能就会搬去另外个小区。其实不止是在张江，北上广是中国人员流动性最大的城市，在上海的很多叮咚小区的目标小区中，外来租房用户仍然占着不少的份额，更不用提二三线城市小区的空房率了。以租房为主的居民属性并没有对小区有很大的归属感，他们更多关注的是个人的社交以及日常的生活服务，因此，对叮咚小区的使用兴趣必然大大降低。

其次，无序的小区管理。不是笔者贬低国内小区，除了小部分的高端小区以及部分成熟的居民社区之外，国内大部分的小区运营仍处于最低的标准，小区的物业管理者除了收个费，差个水表之类的活动能看到之外，也就剩下了门口嗑瓜子的保安了。连最基础的社区活动都没有，更别提什么居民监督小组和居民委员会了。Nextdoor 在美国可以发展起来主要受益于美国小区的成熟度，在 Nextdoor 上的主要需求亦是小区服务、商品推荐以及关于本地安全的信息。但在国内，单是本地安全的报警功能就是国内的 App 无法达成的。因此，国内小区管理的无序性根本无法支撑小区社交的开展。

最后，小区社交 App 用户群体的不稳定。对于项目的创始人来说，他想要面对的用户肯定是小区内长期稳定的居民群体，然而，他们是否想过，小区内最稳定的居民群体是哪些人？当然是上了年纪的大爷大妈。而这部分用户对于移动互联网、智能手机的接受程度又很低。而且，小区内的年轻人有了陌陌、微信、QQ 以及论坛，也就对小区的社交缺乏关注的兴趣。因此小区社交 App 就落入了一个尴尬的境地，年轻人不愿玩，老年人玩不了。

其实，说了这么多，小区 O2O 真的就不需要吗？答案当然是否定的，小区 O2O 是需要的，而且肯定会是未来一个较大的发展领域，只是，当前的中国小区的发展近况决定了小区社交肯定不是一个可以瞬间切入并爆发的点。

小区 O2O 的切入点有哪些？

第一步，从高端社区切入。相比于大部分小区管理的无序性，高端小区或者运营成熟度较高的小区，其居民的稳定性，以及较高的文化，可以使得小区 App 的推广更加数你。同时规范成熟的物业管理，常态化与多样化的小区居民活动，完善规范的小区商业，都可以给小区 O2O 带来足够多的商机。

第二步，从小区服务切入。其实在居民较为集中的小区周边，各项居民服务已经很完备了，餐馆、维修、商店等等都能找到很多家，但是其服务的过于分散，缺乏一个以小区为中心整合平台。饿了么、淘点点整合了餐饮，各种家政 App 整合了家政服务，唯独以小区为中心的垂直生活领域的服务整合尚没有出现较好平台。笔者曾和小区无忧的团队人员沟通过，小区无忧的整体产品方向就是从小区周边服务的整合开始，后续还准备针对小区的每户居民印制小区服务手册，其实，从这点来看，笔者是比较认可小区无忧的产品思路。以线下服务带动居民社区的活跃，再辅以社交的元素，一步步的走下去才是正道，盲目的烧钱给社交铺路，也许能获得一时的喧噪。但钱烧完了，究竟能沉淀下什么？

第三步，智能化小区的方向。如果可以与开发商或者小区物业达成合作，软硬件结合，在居民家中安置小区服务系统，门边放上一个触摸屏，居民可以在系统上完成点外卖、叫维修、报警、收听物业公告等活动，岂不是很方便。同时再辅以 App，做到人与房子合一，可以随时掌握小区与家中信息，及时找到物业或周边服务，这是一个多么美好的画面，不禁想想还有些小激动。当然，这个方向不时一般的小团队创业可以完成的。这一领域其实应该是各大开发商和物业公司发展的方向，龙湖地产在 2013 年建立的社区服务平台「生活帮」，以及万科同年上线一款基于社区生活的 App「新街坊」都是在朝这个方向发展。笔者可以大胆猜测，不久的将来，智能化的小区管理与服务系统必将会不断涌现。

俗话说，步子大了容易扯着蛋。叮咚小区亿元的天使投资是好事，同时又不是好事。移动互联网时代，每个人都在追求快，但没看清方向的快只会让自己死得更快。叮咚小区的创始人更多的应该考虑亿元天使的资金花完后能沉淀下什么，而不是盲目大跃进。

手绘移动端极致体验

Fri, 17 Jan 2014 09:58:40 CST

(Lennart Hennigs 著 Ellazou & Charrywang译 Crispinzhu校正查看原文转载请注明出处)

移动端用户体验设计正日趋成熟。衡量这一点的方法之一就是看工具。原型工具可以让我们创建线框图以及点击事件，比如Balsamiq、Axure以及Fireworks，帮助我们诠释目标用户体验。跨浏览器的框架工具如PhoneGap、Zurb Foundation以及jQuery Mobile可以帮助我们用互联网本地化语言来创建原型：HTML、CSS以及JavaScript。

为什么？举个草图的案例

与以往几乎没有时间来设计极致的体验来比，我们似乎处于一个相对更好的处境。然而，这些工具也伴随着隐藏成本：它们引导我们跳过了创造一个良好设计的产品必经的关键步骤——也就是花时间去理解我们所面对的问题。
这也就是为什么我会建议在打开你钟爱的工具之前，先手绘着理解问题并想出概念。
现在， 你可能想的是如下问题：
“我们的截止时间很紧迫，根本没有时间再去涂鸦。我们必须马上开始。”
“在XX工具里设计是目前为止比较快的方式，我必须很快能看到结果。”
“我们必须把结果给我们的客户或合作伙伴或同事看。我们不能给他们看手绘
的线稿。”
“不好意思，我真的不会画画。”

我不仅听别人几次这样反对，我对自己也这么说过。

定义问题和解决方案

手绘可以让我们一边探索问题一边定义解决方案。它可以结构化我们目前对问题的理解，同时帮助我们找到可能的解决方案。
当我们手绘出自己的想法时，新的主意也会萌生。 模糊和缺乏细节的草图会培育出新的思路。在这里，模糊是件好事，因为我们会自动尝试填补脑中的空白。这也正是草图富有“创造性“的原因：它捕捉到我们已经成型的想法，并迸发出新的火花。正如Bill Buxton在《Sketching User Experiences》中提到的：
“从草图上学习到的内容很大程度上是基于其表现的模糊性。也就是说，他们并不指定所有事情，而是鼓励创造者们不自觉的融入各种不同的解释。”

通过手绘不同的解决方案，我们不用立刻实现其中一种，就可以探索他们的可行性。这为我们提供了新的见解，也提出了新的问题。手绘本质上就是一个头脑风暴的锻炼。

草图的“成本”

把我们脑袋里的东西倒出来最快的方式就是拿起一只笔和一张纸迅速的画出来。在我们钟爱的原型工具里来做这件事情则需要花费太多的时间：我们需要先创建一个项目，使用合适的库，将一些小矩形放在画布上，画一些小箭头来连接这些矩形，把所有的元件都调整一下让它们看上去更好看一些——30分钟过去了。
如果我们不喜欢纸上画的东西，可以将它扔进垃圾桶然后重新开始。然而用原型工具的话，扔掉一些东西就比较困难了，因为我们花费了时间和努力去创建它——就算那个想法不是最好的，重新开始也更困难。反过来说，纸上手绘的内容则成本低廉，实现迅速。

捕捉和评估设想最快的方式就是将它勾画出来。

把草图作为沟通工具

不过俗话说，一图胜千言。草图可以让我们与合作者以及项目关注人们一块探讨对项目当前的理解。我们可以使用很多不同的表现方式去诠释项目不同的方面（下一个章节中我们会介绍最常用的一种方式）。在《餐巾纸的背后》一书中，Dan Roam提到：
“图片可以表示很复杂的概念，概括大量信息，并以一种我们容易看容易理解的方式呈现，它们在澄清和解决各种问题上都是有用的。”

我们的小伙伴可以直接指出我们想法上的鸿沟，共同讨论可能的解决方案和替代方案。他们可以很好的理解我们的草图，并且在想法的细节上给出一些反馈。 向其他人展示我们的想法也会让我们反思自己的想法。借此展示想法，我们会看到错误的地方以及找到更好的替代方案。

把草图作为合作工具

草图作为一种有力的工具可以让项目关注人们在设计过程中尽早参与进来。在定义的过程中，以下鸡生蛋的问题非常典型：项目关注人们在看到一些可视化的解决方案之前，是没法制定一套完整的需求的，但是我们设计师在没确定需求稳定完善之前，是不愿意开工去实施解决方案的——我们想要去避免不必要的反复修订，因为这会导致额外的工作。
摆脱这种困境的一种方法是在协作式工作坊里来手绘可能的解决方案，比如这一期设计工作室（参看Will Evans的文章“ Introduction to Design Studio Methodology“）。我们可以带领项目关注人们一步步的理解我们的概念（和其他备案），向他们解释他们的需求对设计的影响。
草图的 入门门槛也很低，非设计师也可以参与。（到底是否通过手绘的方式与项目关注人讨论，即取决于个人偏好，也存在许多争议。你需要自己做决定。）
由于草稿是粗略不完整的，给出反馈也就更加容易。一些人会隐忍不发，直到看到一个看上去完成度很好的页面，因为他们认为所有的工作必须要有一定的深入才行。高保真的视觉效果也会分散大家的注意力——大家会更倾向于讨论视觉效果或微妙细节，而不是聚焦在想法概念上。草图会让他们聚焦在核心概念上。
你唯一需要克服的就是不愿意将未经打磨的作品展示给他人的心理障碍。

草图不是绘画

一个常见的误区就是你的草图必须要画的很漂亮。但交互设计可不是上艺术课。 你的草图不需要看上去很漂亮；它们只需要表达出你的想法就可以。它们应该是引发讨论和催生想法的；它们并不是挂在墙上的艺术品。只要你会画方框，箭头，圆圈和简笔画，你就可以画草图。正如Joshua Brewer在“ Sketch, Sketch, Sketch”一文中提到：
“草图不是最终目标。最终目标是在手绘过程中你学到了什么。所以即使你不会手绘也不用担心。”

学习如何手绘不是本文的内容，但是可以从以下的宣讲、文章以及书目当中学习到一些基础：

“ The ‘Art’ of Sketching Interfaces”（PPT文档），作者Jason Mesut和Sam Smith
“ Sketching 101” （PPT文档），作者Jackson Fox
“ The Messy Art of UX Sketching”，作者Peiter Buick
《Sketching User Experiences: The Workbook》，作者Saul Greenberg，Sheelagh Carpendale，Nicolai Marquardt，Bill Buxton（Morgan Kaufman出版：2011）

如何手绘

现在，但愿我已经说服你认同手绘应该是你工作流程中的一部分了。让我们聊一聊在移动项目中手绘什么吧。

发散式手绘

一开始，你需要为你的移动应用或网站收集不同的创意。开始绘制出针对一个关键页面或其中一部分的各种版本。目标有两个：获取大量不同的想法，同时加以探索和评价。想法越多，后期的选择就越多。这个阶段通常被称为“发散式手绘”。
这个阶段的手绘有一种有效的多页模版的工具。它提供了一页以内绘制6个不同版本方案的空间，并且它留出了指引描述的空间。不同创意一起呈现，为后续的比较和讨论提供便捷。
有很多在线模版（我最常使用 Erik Loehfelm的模板）。选一个你喜欢的模板。

各种全局导航的变化方案线框稿

上面的截图展示了关于 一个App主菜单六个不同设计方案（顺带说一句，它生动地证明了我的草图并不漂亮）。我并不总能想出6个不同版本（我喜欢告诉自己我是一个追求结构的人），不过我会针对一个单页面努力创造至少3种变化方案。因为这是一场头脑风暴，并且你会在后续的讨论中需要多种选择的可能性。在这里数量即朋友。
如果你碰巧才思枯竭，浏览一些手机UI图册去激发新思路（例如 Inspired UI, Pttrns, Lovely UI 和 UI Parade）。它们演示了按主题或特性分组的解决方案（例如主菜单，聊天窗口）。汇集起你喜欢的草图，组合成你自己的创意。
养成对每张草图命名的习惯。这样更容易标注出方案之间的差别，并便于后续引用。我会增加说明和标注去解释草图以及它们后面贯穿的思路（比如优点、缺点、与其他方案之间的抉择、问题、新特性，等等）。打标签和登记日期同样是不错的习惯。

收敛式手绘

一旦你对一个界面绘制了多个版本的草稿时，就可以选择最佳解决方案了。不幸的是，单一的草图很难验证所有界面。大多数情况下，你需要糅合几个创意或创意中的不同方面形成优胜概念。为了达到这个目的，你需要通过绘制更详尽的草图来深入探究。利用空白区域做标注。 草草记下全部问题、新想法、要点或不明之处，以及留待讨论的事项。这些都将帮助他人更好的理解你的思路。这项工作通常被称为“收敛式手绘”。
更多关于发散式手绘和收敛式手绘的信息，请查看 Leah Buley在2010年失败者大会（FailCon大会）的演说：“ Good Design Faster”，和Brandon Shauer的文章“ Sketchboards: Discover Better + Faster UX Solutions”。

创建UI流程

在归结几个关键页面的创意后，下一步就要探索它们如何配合使用了。为此，创建一些UI流程（也就是一系列的关键页面）展示一个用户将如何通过你的解决方案完成一则任务。UI流程强调了使用什么界面元素（例如点击哪个按钮或使用何种手势），系统如何反馈（例如系统通过一个动画、转场、弹出框或新页面做出反馈）。它们同样展示关键界面的不同状态（例如，最初的空白然后填入内容）。
你可以视觉化呈现一个UI流程中的不同结果（例如搜索有结果页和搜索无结果页）。你的流程最好不再仅仅是单线。不同的分支流程将展示不同的结果。不过要尽量限制单个UI流程中分支的数量。每增加一个分支都会提升复杂度，让你的流程难以理解，也令它们很难被解释清楚。

UI流程视觉化呈现了用户如何从A到B的过程。

你不需要绘出所有的用例，选择重要且被使用最多的用例。帕累托原则是个很好的标准：20%的功能会在80%的时间里被使用到。
我通常从一则重要用例开始绘制并最终解决它。我会强调出各个界面之间的交互，通常用箭头连接彼此。我会解释每一步骤并标记重要页面。同样，我会宽泛地做上注释。
关于如何激发手机界面和UI流程绘制创意，请查看Gisele Muller的文章“ Inspiring UI Wireframe Sketches”； MOObileFrames 一个提供手机界面线框图的博客； Wireframes，Jakub Linowski的个人站点。你也可以将Jakub的 Interactive Sketching Notation（PDF文档）运用到你的UI流程中。

操作步骤

为了给你更多的上下文环境，并演示上文提及的三种方式之间的关系，现在提供一个典型手绘的步骤分解：

列出已有的信息和确立的目标
绘制第一组草图（例如一个关键界面的各种方案或一个初始UI流程）
自我复查草图
每个方案的优点和缺点是什么？
UI组件和数据是否保持一致？（就是说同一任务中是否使用了相同的组件）
数据展示方式是否相同？
交互选项是否明确？
征询他人的意见。从同事开始再到潜在用户。
他们的第一印象是什么？
他们最喜欢哪个？为什么？
最不喜欢哪个？为什么？
草图中哪些信息他们不清楚？
他们提了什么改进意见？为什么？
重审各个概念方案
是否可以合并各个概念方案的优点于一体？
草图能进一步清理吗？
步骤能进一步缩减吗？
依据最初的反馈再次复查
是否引入新的问题？
你可以从中得到什么启发？

你是否发现，这里有很多的“为什么”。这是因为 手绘是为了在提出解决方案的同时增进对问题的理解。在手绘后写下绘制过程中产生的的问题。它们会指引你走向正确的方向。

超越手绘

在创建关键页面和核心用例的草图后，你会希望在真实的手机上试验你的概念了。像 Pop和 Protosketch实现了导入草图的照片，将它们转变成原型。这种超快的低保真方法可以对交互方案找到一些感觉。这两款应用都允许你定义可点击热区和页面的切换，这令得交互原型更真实。
此外，可以选择导入页面到像Axure这类更高级的软件中生成原型。
无论你选择什么工具， 你的目标是在真实的手机上用很小的代价快速测试原型。

便携小贴士

手绘可以帮助你更好的理解问题并可视化潜在的解决方案。这是一种快速且省钱的头脑风暴方式，同时它也在锁定方案前测试很多的概念。手绘加速了概念创想和反复阶段，在方案变更较容易的阶段实现了早期问题反馈。
在你下次手绘环节中，请牢记以下原则。它们能帮助你保持正确：

偷懒
别尝试去再造一个轮子。手绘时利用现成的模版。
激发灵感
浏览设计范式库和手机UI图库，查看线框图示例。挑选你喜欢的，糅合你自己的想法，创造一些新方案。
适可而止
你的手绘要能传达你的想法。不要迷失在（不重要的）细节中。
帕累托怎么用？
你解决方案中只有小部分特性将被最频繁地使用。聚焦在它们上面。想清楚哪20%的方案会在80%的时间里被用到？
保持统一性
用已有的手绘标记或创建一种你自己的方式。这样是的你的手绘更可靠。同事能较好地理解你的风格，花更少的时间浏览完手绘并给予反馈。
详尽注释
手绘过程中，会涌现各种新命题、想法、问题。记下它们，否则，你就忘了。
开放心态
将你的手绘公之于众。把它们钉在墙上，并勤于向他人演示方案并获取反馈。
陷入怀疑时，继续手绘
当你不能确信某个方案时，重新开始衍化方案。列举出它们的利弊并从反馈中想清楚什么是最佳方案。

手绘愉快！

作者：腾讯mxd

微信号：woshipm，干货天天推荐，欢迎关注

IT瘾app推荐

案例拆解|T3出行用户激励体系

一、T3出行的现状及业务模式

二、T3出行的用户激励体系

1. 免费会员成长体系

2. 积分体系

3. 限时活动

三、从用户生命周期看T3出行的激励体系

四、一些思考

App深度链接与延迟深度链接

APP唤醒与场景还原

常见唤醒APP方式

URL Scheme

iOS URL Scheme

Android URL Scheme

URL Scheme的缺点

iOS Universal Links

Chrome Intent

Android App Link

深度链接 Deeplink

延迟深度链接(Deferred Deep Linking)

Deferred DeepLink的实现思路

第三方库

相关文章:

Android/iOS判断是否使用代理或VPN

Android判断是否使用代理IP

Android判断是否使用VPN

iOS判断是否使用代理IP

iOS判断是否使用VPN

相关文章:

一个 Hybrid SDK 设计与实现

Hybrid 的一个现状

Native 与前端分工

交互设计

账号信息设计

Hybrid 开发调试

Hybrid 交互设计

JS to Native

Api 交互

格式约定

常用交互 Api

跳转

Header 组件的设计

请求类

常用 NativeUI 组件

账号系统的设计

Hybrid 资源管理

增量更新

一些零散的解决方案

python使用深度神经网络实现识别暹罗与英短

欢迎来到后 ASO 时代

搜索改动还算小

榜单 Jobs 估计都不认识了

其他

总结

参考资料

App 繁荣时代已经过去，多数开发商面临增长困境

App设计者需要注意的21条禁忌

1. 不要在没有流程图之就前开始设计或者画线框图

2. 分工要明确不要忽略开发预算

3. 不要随意使用介绍动画

4. 别让用户空等

5、没有不可点击的效果

6、菜单层次太深

7、文字长度不加以限制

8、文字表意不明

9、交互流程分支太多

10、相关的选项离的很远

11、一次载入太多的数据

12、按钮可点击范围比看起来小

13、标签页跟内容没有从属关系

14、把所有的操作都暴露出来

15、没有空数据界面设计

16、用户引导的滥用

17、无加载中状态

18、未定义Back的逻辑

19、无横屏模式的设计

20. 不要忘记手势但不要滥用

21. 不要觉得每个用户有着跟你一样的 App 使用方式

22.怎么才21条？