IT瘾app推荐

5个运镜技巧，让你的旅拍Vlog更高级！_影视工业网-幕后英雄APP

Sat, 19 Apr 2025 08:36:05 CST

旅行的魅力在于

它让我们跳出熟悉的环境

去探索未知的世界

旅行的过程中

我们总想记录下每一次遇见的美好

但有时，拍出来的画面

也显得力不从心，始终少了些感觉

别担心，今天教你5个运镜技巧

让你的旅拍Vlog更有氛围

╱ 下摇运镜 ╱

开始拍摄时镜头要置于人物上方
从天空缓慢匀速向下摇镜头，引出人物

* 下摇运镜适合拍摄开场镜头，用来交代环境和人物所处的位置

╱ 侧跟运镜 ╱ 遮挡转场

摄影师在人物侧面，与人物同方向匀速移动
可以拍摄多个场景跟随，将画面剪接在一起，制作出背景多变的创意镜头

* 拍摄不同场景时保持人物在画面中的位置大致不变

遮挡转场

我们可以借助遮挡物作为拍摄开头或结尾，将视频剪接起来

* 这种方式让两个不同的场景可以很自然的过度，画面也更有连续性

╱ 前推运镜 ╱

摄影师匀速向前推镜头直到镜头越过人物

* 镜头展现出第一视角所看到的画面，这样拍出来的画面更有代入感

╱ 环绕运镜 ╱

静态环绕运镜

摄影师以匀速环绕人物拍摄

* 静态环绕运镜适合在光线比较柔和的时候进行拍摄，用来制造画面氛围感

动态环绕运镜

拍摄前比“ok”手势，开启 AI人脸追踪，这样就不用担心人物会出画
拍摄时模特与摄影师反方向转动，保持人物居中运镜

* 增加画面的速度感

╱ 后拉上摇运镜 ╱

摄影师上摇镜头的同时匀速向后移动

* 这种镜头会营造出一种远离感，适合用来拍摄结尾，让画面更有电影感

分享一个平时工作找需求找竞品的方法：通过产品使用的核心技术库 - 即刻App

Tue, 15 Oct 2024 10:40:49 CST

分享一个平时工作找需求找竞品的方法：通过产品使用的核心技术库，找使用这个库的 project showcase。

起源是公司内部最近出现了一个我和 leader 都觉得惊为天人的产品。但是因为是保密项目我们能获取到的信息不够，我们判断这种交互模式和 UI 体验是借鉴了某个海外产品，大概率不是我司的原创。但是因为这个产品是很垂类的 B 端场景，加上保密项目的原因内部获取不到什么技术方案和竞品调研。

灵机一动发现这个产品的核心技术库是 xy-flow（一种画布容器解决方案），于是便从 xy-flow 的官网找到了市面上使用 xy-flow 的 project showcase。

从 project showcase 中，我看到了太多太多以前从未想到、从未接触的垂类场景：

- JSON 与工作流打通的 JSONSea
- 数据监控与工作流画布结合的 Redata
- 客服与弹窗 rpa 工作流的 Botfront
- 与地理数据结合的物流系统 Geoplex
- 包括我们自己的竞争对手 retool 和 wix 的 workflow
- …

这些都在使用 xy-flow 构建工作流、画布容器。今天几分钟的时间，从这一个基础库我看到了许多从未接触过的业务场景，这些业务场景背后代表的是一定数量的用户群体以及潜在的同类型竞品。代表着某个行业、某个市场。

这种查找需求的方法之前 @哥飞飞哥也在社群和公众号分享过类似的，并且可操作性更强范围更广：通过产品的入口流量、出口流量挖掘需求，以及榜单、外链。具体的操作和知识可以去「哥飞」公众号上刷一遍学习一下。

习得了某个方法某个知识后，举一反三在生活工作场景中用出来、总结出来，那种感觉真的是不一样的。

总得来说，这种找需求的方法考察的是多角度多维地看待问题。直接看是现象，从上游看是解决方案，从下游看是业务场景。

reactflow.dev

随着打交道的人越来越多，人的形形色色，似乎都看过了。在我看来 - 即刻App

Tue, 15 Oct 2024 10:39:09 CST

随着打交道的人越来越多，人的形形色色，似乎都看过了。在我看来，绝大多数人都是不值得我们交往的，我们的人生里，真正值得去关注的人屈指可数。

以下是我对值得交往的人的一些看法：

1、先聊聊，什么样的人值得交往和重视。
一个很重要的评判标准是：能够让你越来越好的人。

这里有个定义，就是越来越好。什么叫做越来越好呢？就是能让你的认知/收入/价值/人脉等往上的人。
-这类人拥有丰富的经验和知识，愿意帮助你成长。
-他们会真诚地给出意见，指出你的问题，并提供改进的方法。
-但，这里面有一个非常重要的点两个点【你以为的好≠真正的好】【他人对你的坏，不一定就是坏】
-所以，这里有个非常关键的判断，对于我来说就是：客观真实地提出问题，并给出解决方案，而不是带有个人主观意识。

“指出你的问题，给予你解决方案”，坦白说，如若你的人生里面，有这样的人，一定一定一定要珍惜。

一个维度是，没有人有义务去帮你；另外一个维度是，没有人想要做“坏人”，大家维护面子上“好”更加容易。

比如，我每次和公司的投资人大哥聊天，他们总会说一些我不OK的地方，公司需要调整的地方等。

当一个人被说不OK的地方或者不好的地方，他心里面一定是不舒服的。只要是人，都很难避免这种难受感，人毕竟是情感性动物。

可，当他们说完了之后，我都会去复盘他们所说的，①是不是真实的，②是不是我改掉了它们，或者是我按照他们的做就会越来越好。

当然，能够让你越来越好的人，不一定就是你身边的人，还有可能是你的榜样，是你选择听的播客，是你选择看的电视剧，是你选择读的书籍等等。

总之，筛选权在你自己手里，可如何筛选的确是一件困难的事情。

2、什么样的人，是不值得交往的？
①消耗你，且没给你带来增长的人。
比如，我们的生意场合上有这样一类人，他们很擅长吃喝玩乐，隔三差五带你去KTV，去会所。

这样的人，看似带你去快乐，去逍遥，实际上是一种“消耗”，对是“消耗”，即使是对方结账也是。

消耗你的时间，你的精力，却没有任何成长和进步。

②本身价值观就有问题的人。
比如，我们的生意场合，也会遇到一些这样的人，在他们眼中“玩女人”很正常，“养小三小四”很正常，“出轨”很正常。。。。

这样的人，在我这里，就是直接pass。即使是生意场合上需要，也都会是“合同之交”，不会有任何进一步的关系。

③欺软怕硬的人。
欺软怕硬的这个词，重点会在这个“欺”字，这个欺字就证明这个人的价值观是不OK的。他们会对比如服务员、快递员等似乎比他弱小的人，呈现傲慢无礼的姿态。

这样的人，无论是合作伙伴，还是员工，都是非常容易观察出来，比如出去吃个饭，比如送个快递，都能观察出来。

一个人对待他人的态度可以反映出他的本性，细节反映一切。

④极度自私自我的人。
这类人就是站在自我的角度，不断去要求他人去满足他，但没有给对方报酬或者对等的价值。

简单来说，他们在消耗他人的时间，却不愿意给与对等的报酬，理所应当的认为他人应该回应他/帮忙他。

这样的人，在我们身边非常非常非常多。很多即使做到老板这个位置了，也改不了这个本性。

每个人的时间都是有价值的，我们要去消耗他人的时间的时候，一定要想想：
1）我给到的对应报酬是什么？
2）如若你实在给不了对应的价值，请你有一些礼节。

⑤把你当成“垃圾桶”的人。
有这样一类人，每次给你沟通，就把他身边的所有的负面的，不好的，全部倒给你。

这样的人，请尽可能快速地远离。

和上面说的很多一样，他们自我自私，且消耗他人而不自知。

⑥........

我们的人生，就是不断地筛选过程。大脑不断地有意念，有意念就有抉择。而我们在不断成长的过程中，会有不同的需求和欲望，这会影响我们选择与什么样的人相处。

在这个过程中，我们可能会失去一些人，但我们应该淡然看待这些变化。不是所有人都能和我们保持同频的成长。

“不断地越来越好”就是你筛选的重要原则。

仅个人观点。

jsBridge 以及 Web 和 APP 交互通信方式

Mon, 09 Oct 2023 16:21:55 CST

jsBridge 到底是什么？

jsBridge 是一种技术，主要用于解决 Web 前端和原生应用间的通信问题。这一技术在混合开发（Hybrid App Development）和一些原生应用内嵌 H5 页面的场景中被广泛应用。通过 jsBridge，开发者可以直接在 JavaScript 中调用原生代码，如获取设备信息、调用系统功能等，极大的提高了开发效率。

首先需要了解 WebView

WebView 是一个浏览器控件或者组件，它能够帮助开发者将网页或者 HTML 内容嵌入到原生应用中。

WebView 控件除了能加载指定的 URL 外，还可以对 URL 请求、JavaScript 的对话框、加载进度、页面交互进行强大的处理，之后会提到拦截请求、执行 js 脚本都依赖于此。

Android 中的 WebView：

Android 中的 WebView 是一个继承自 View 的控件，它可以加载并显示网页，同时也提供了一些方法供你与 JavaScript 交互。你可以使用 loadUrl(String url) 方法加载一个网页，使用 evaluateJavascript(String script, ValueCallback<String> resultCallback) 方法执行 JavaScript 代码。你还可以通过 addJavascriptInterface(Object object, String name) 方法向 JavaScript 环境中添加一个 Java 对象，使得 JavaScript 可以调用该对象的方法。

iOS 中的 WebView：

iOS 中提供了 UIWebView 和 WKWebView 两个用于展示网页的控件。 UIWebView 在 iOS 2.0 就被引入，但自 iOS 8.0 起，Apple 推荐使用 WKWebView 替代 UIWebView。 WKWebView 提供了 load(URLRequest) 和 loadHTMLString(String baseURL: URL?) 方法用于加载网页，通过 evaluateJavaScript(String completionHandler: ((Any?, Error?) -> Void)?) 方法执行 JavaScript 代码。同时，iOS 中的 WKWebView 通过 WKScriptMessageHandler 协议和 WKUserContentController 类来实现 Native 与 JavaScript 的交互。

了解 WebView 很重要，它才是连接原生和 Web 的桥梁。因为 Web 前端大多对原生开发不了解，如果一开始就去了解所谓的 jsBridge，反而会迷惑。

Web 和 Native 的交互

Web 和 Native 的交互分为 Native 调用 js 和 js 调用 Native。

Native -> js

原生调 js 的方式比较简单。JavaScript 作为解释性语言，最大的一个特性就是可以随时随地地通过解释器执行一段 js 代码，所以可以将拼接的 JavaScript 代码字符串，传入 js 解析器执行就可以，js 解析器在这里就是 WebView 组件。

所以 WebView 执行拼接的 JavaScript 字符串，从外部调用 JavaScript 方法，JavaScript 的方法必须在全局的 window 上。

Android

Android 4.4 之前只能用 loadUrl 来实现，效率低，无法获得返回结果，且调用的时候会刷新 WebView：

  webView.loadUrl("javascript:" + javaScriptString);

Android 4.4 之后提供了 evaluateJavascript 来执行 js 代码，效率高，获取返回值方便，调用时候不刷新 WebView：

  webView.evaluateJavascript(javaScriptString, new ValueCallback<String>() {
    @Override
    public void onReceiveValue(String value){
        xxx
    }
});

iOS

UIWebView 使用 stringByEvaluatingJavaScriptFromString：

  NSString *jsStr = @"执行的JS代码";
[webView stringByEvaluatingJavaScriptFromString:jsStr];

WKWebView 使用 evaluateJavaScript：

  [webView evaluateJavaScript:@"执行的JS代码" completionHandler:^(id _Nullable response, NSError * _Nullable error) {
  
}];

  func evaluateJavaScript(_ javaScriptString: String, completionHandler: ((Any?, Error?) -> Void)? = nil)
// javaScriptString 需要调用的 JS 代码
// completionHandler 执行后的回调

js -> Native

简单的说，主要是两类方法：拦截 URL，注入 API。

拦截 URL Schema

URL Schema 是类 URL 的一种请求格式，格式如下：

<protocol>://<host>/<path>?<qeury>#fragment

我们可以自定义 jsBridge 通信的 URL Schema，比如： jsbridge://showToast?text=hello

Native 加载 WebView 之后，Web 发送的所有请求都会经过 WebView 组件，所以 Native 可以重写 WebView里的方法，从来拦截 Web 发起的请求，我们对请求的格式进行判断：

如果符合我们自定义的 URL Schema，对 URL 进行解析，拿到相关操作，进而调用原生 Native 的方法
如果不符合我们自定义的 URL Schema，我们直接转发，请求真正的服务

Web 发送 URL 请求的方法有这么几种：

a 标签
location.href
使用 iframe.src
发送 ajax 请求

这些方法， a 标签需要用户操作， location.href 可能会引起页面的跳转丢失调用，发送 ajax 请求Android 没有相应的拦截方法，所以使用 iframe.src 是经常会使用的方案：

安卓提供了 shouldOverrideUrlLoading 方法拦截
UIWebView 使用 shouldStartLoadWithRequest，WKWebView 则使用 decidePolicyForNavigationAction

Android：

  public class CustomWebViewClient extends WebViewClient {
  @Override
  public boolean shouldOverrideUrlLoading(WebView view, String url) {
    ......
    // 场景一： 拦截请求、接收 scheme
    if (url.equals("xxx")) {

      // handle
      ...
      // callback
      view.loadUrl("javascript:setAllContent(" + json + ");")
      return true;
    }
    return super.shouldOverrideUrlLoading(url);
  }
}

iOS 的 WKWebview：

  - (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler{
    if ([navigationAction.request.URL.absoluteString hasPrefix:@"xxx"]) {
        [[UIApplication sharedApplication] openURL:navigationAction.request.URL];
    }
    decisionHandler(WKNavigationActionPolicyAllow);
}

这种方式有一定的缺陷：

使用 iframe.src 发送 URL SCHEME 会有 URL 长度的隐患。
创建请求，需要一定的耗时，比注入 API 的方式调用同样的功能，耗时会较长。

注入 API

注入 API 方式的主要原理是，通过 WebView 提供的接口，向 JavaScript 的 Context（window）中注入对象或者方法，让 JavaScript 调用时，直接执行相应的 Native 代码逻辑，达到 JavaScript 调用 Native 的目的。

iOS 的 UIWebView 提供了 JavaSciptCore：

  JSContext *context = [uiWebView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"];

context[@"postBridgeMessage"] = ^(NSArray<NSArray *> *calls) {
    // Native 逻辑
};

前端调用方式：

  window.postBridgeMessage(message);

iOS的 WKWebView 提供了 WKScriptMessageHandler：

  @interface WKWebVIewVC ()<WKScriptMessageHandler>

@implementation WKWebVIewVC

- (void)viewDidLoad {
    [super viewDidLoad];

    WKWebViewConfiguration* configuration = [[WKWebViewConfiguration alloc] init];
    configuration.userContentController = [[WKUserContentController alloc] init];
    WKUserContentController *userCC = configuration.userContentController;
    // 注入对象，前端调用其方法时，Native 可以捕获到
    [userCC addScriptMessageHandler:self name:@"nativeBridge"];

    WKWebView wkWebView = [[WKWebView alloc] initWithFrame:self.view.frame configuration:configuration];

    // TODO 显示 WebView
}

- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message {
    if ([message.name isEqualToString:@"nativeBridge"]) {
        NSLog(@"前端传递的数据 %@: ",message.body);
        // Native 逻辑
    }
}

前端调用方式：

  window.webkit.messageHandlers.nativeBridge.postMessage(message);

Android 提供了 addJavascriptInterface：

  public class JavaScriptInterface DemoActivity extends Activity {
private WebView Wv;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        Wv = (WebView)findViewById(R.id.webView);     
        final JavaScriptInterface myJavaScriptInterface = new JavaScriptInterface(this);     

        Wv.getSettings().setJavaScriptEnabled(true);
        Wv.addJavascriptInterface(myJavaScriptInterface, "nativeBridge");

        // TODO 显示 WebView

    }

    public class JavaScriptInterface {
         Context mContext;

         JavaScriptInterface(Context c) {
             mContext = c;
         }

         public void postMessage(String webMessage){    
             // Native 逻辑
         }
     }
}

前端调用方式：

  window.nativeBridge.postMessage(message);

在 4.2 之前，Android 注入 JavaScript 对象的接口是 addJavascriptInterface，但是这个接口有漏洞，可以被不法分子利用，危害用户的安全，因此在 4.2 中引入新的接口 @JavascriptInterface（上面代码中使用的）来替代这个接口，解决安全问题。所以 Android 注入对对象的方式是 有兼容性问题的。（4.2 之前很多方案都采用拦截 prompt 的方式来实现，因为篇幅有限，这里就不展开了。）

jsBridge 的实现（带回调的交互）

Native、Web 间可以交互，但站在一端而言还是一个单向通信的过程，比如站在 Web 的角度：Web 调用 Native 的方法，Native 直接进行相关操作但无法将结果返回给 Web，但实际使用中会经常需要将操作的结果返回，也就是 js 回调。

jsBridge 的接口主要功能有两个： 调用 Native（给 Native 发消息） 和 被 Native 调用（接收 Native 消息） 。因此，jsBridge 可以设计如下：

  window.JSBridge = {
    // 调用 Native
    invoke: function(msg) {
        // 判断环境，获取不同的 nativeBridge
        nativeBridge.postMessage(msg);
    },
    receiveMessage: function(msg) {
        // 处理 msg
    }
};

那么有回调的交互如何实现呢？

其实基于之前的单向通信就可以实现，我们在一端调用的时候在参数中加一个 callbackId 标记对应的回调，对端接收到调用请求后，进行实际操作，如果带有 callbackId，对端再进行一次调用，将结果、 callbackId 回传回来，这端根据 callbackId 匹配相应的回调，将结果传入执行就可以了。

可以看到实际上还是通过两次单项通信实现的。

  (function () {
    var id = 0,
        callbacks = {};

    window.JSBridge = {
        // 调用 Native
        invoke: function(bridgeName, callback, data) {
            // 判断环境，获取不同的 nativeBridge
            var thisId = id ++; // 获取唯一 id
            callbacks[thisId] = callback; // 存储 Callback
            window.nativeBridge.postMessage({
                bridgeName: bridgeName,
                data: data || {},
                callbackId: thisId // 传到 Native 端
            });
        },
        receiveMessage: function(msg) {
            var bridgeName = msg.bridgeName,
                data = msg.data || {},
                callbackId = msg.callbackId; // Native 将 callbackId 原封不动传回
            // 具体逻辑
            // bridgeName 和 callbackId 不会同时存在
            if (callbackId) {
                if (callbacks[callbackId]) { // 找到相应句柄
                    callbacks[callbackId](msg.data); // 执行调用
                }
            } elseif (bridgeName) {

            }
        }
    };
})();

最后用同样的方式加上 Native 调用的回调逻辑，同时对代码进行一些优化，就大概实现了一个功能比较完整的 jsBridge。其代码如下：

  (function () {
    var id = 0,
        callbacks = {},
        registerFuncs = {};

    window.JSBridge = {
        // 调用 Native
        invoke: function(bridgeName, callback, data) {
            // 判断环境，获取不同的 nativeBridge
            var thisId = id ++; // 获取唯一 id
            callbacks[thisId] = callback; // 存储 Callback
            nativeBridge.postMessage({
                bridgeName: bridgeName,
                data: data || {},
                callbackId: thisId // 传到 Native 端
            });
        },
        receiveMessage: function(msg) {
            var bridgeName = msg.bridgeName,
                data = msg.data || {},
                callbackId = msg.callbackId, // Native 将 callbackId 原封不动传回
                responstId = msg.responstId;
            // 具体逻辑
            // bridgeName 和 callbackId 不会同时存在
            if (callbackId) {
                if (callbacks[callbackId]) { // 找到相应句柄
                    callbacks[callbackId](msg.data); // 执行调用
                }
            } elseif (bridgeName) {
                if (registerFuncs[bridgeName]) { // 通过 bridgeName 找到句柄
                    var ret = {},
                        flag = false;
                    registerFuncs[bridgeName].forEach(function(callback) => {
                        callback(data, function(r) {
                            flag = true;
                            ret = Object.assign(ret, r);
                        });
                    });
                    if (flag) {
                        nativeBridge.postMessage({ // 回调 Native
                            responstId: responstId,
                            ret: ret
                        });
                    }
                }
            }
        },
        register: function(bridgeName, callback) {
            if (!registerFuncs[bridgeName])  {
                registerFuncs[bridgeName] = [];
            }
            registerFuncs[bridgeName].push(callback); // 存储回调
        }
    };
})();

参考

https://juejin.cn/post/6936814903021797389
https://juejin.cn/post/6844903585268891662
https://juejin.cn/post/6844904070881214471

前端工程师用Node.js + Appium实现APP自动化

Wed, 02 Aug 2023 12:39:51 CST

简介

最近在使用Appium做爬虫功能，网上全是python + Appium的教程，Appium也支持Node.js开发，作为前端工程师使用 Node.js + Appium实现了自动化爬虫功能。

零零散散折腾了小两天的时间，踩了一些小坑，把流程和坑点整理出来供大家参考，希望让大家少踩坑、快速实现功能。

原理介绍

我们先搞清楚几个概念，看Appium是如何实现自动操作设备的，结合图片从右往左看：

Device是设备，有安卓、IOS、Windows、Mac等不同类型的设备。
Appium是一个Web服务器，与设备连接，可以通过接口来操作设备，实现自动化，本身也是Node应用。
Driver是驱动程序，不同的设备需要不同的驱动程序去控制，驱动程序属于Appium架构中的一部分。
Client即调用Appium接口的客户端，支持不同语言调用，比如Java、Node等语言调用。

总结：用Java、Node.js作为客户端调用 Appium服务端接口，Appium通过驱动控制设备，实现自动化操作。

环境搭建

不再一一介绍每个依赖的安装步骤，网上搭建环境的文章很多，主要是如下两点功能：

安装Java、Android的SDK，确保 adb命令可用，用于连接手机。
安装Node.js，用于运行Appium 和 webdriver.io(Client Node.js)。

adb命令使用

adb 简介，可以通过数据线或WIFI实现电脑与手机的连接，手机需要打开开发者调试选项，连接成功后，可以通过adb命令操作手机、安装、调试应用。

查看设备列表：adb devices，如果成功连接手机，输入该命令后会展示设备列表。

安装APK：adb install + apk路径

查看当前打开的App包名与appActivity：

例如微信：com.tencent.mm 是包名，.ui.launcherUI 是 appActivity， 这些参数在后边开发自动化功能时使用。

Appium 服务启动

有两种方式启动服务，一种是安装命令行工具，通过命令行启动；第二种是安装 AppiumDesktop GUI软件启动，任选其一即可，作为前端工程师，首选命令行。

  // 安装命令行
$ npm i --location=global appium

// 安装驱动
$ appium driver install uiautomator2

// 启动服务
$ appium

坑点1 不同手机的ADB设置

Appium启动后，会在手机上自动安装3个App，这里有个坑，不同的手机系统开发者选型设置不同，可能会有不同的问题，亲测我的VIVO和OPPO机型，Vivo必须允许三个App为高耗电后台运行，OPPO开发者选项中需要需要开启禁止权限监控，否则无法自动安装App，其他同事出现了App总是重复安装的问题。

Vivo设置允许APP后台高耗电： https://blog.csdn.net/a10703060237/article/details/118895357
Oppo开发者选项设置： https://blog.csdn.net/HealerLX/article/details/122997161

小Tips：通过 Appium + 手机品牌去搜索问题，更高效。

页面元素定位工具

appium inspector官方的GUI界面定位工具，可以通过参数启动App，并将App的画面和页面结构展示出来，以微信为例：填入我们获取到的appPackage 和 appActivity。

坑点2 启动参数务必增加 appium:noReset为true

这里有一个坑需要注意，必须设置appium:noReset参数为true，不然每次启动会清空你的App历史数据，我的微信数据被清理了。

点击Start Session按钮就可以看到页面的截图、结构和元素的信息了。

自动化开发

如果通过adb连接手机，并通过 appium inspector 成功获取到界面元素，那么恭喜你已经完成了80%的进展，剩下的就是通过Node.js + webdriver.io 开发自动化脚本，App自动跑起来了。

开发前这里我们要掌握webdriver.io的几个基本用法：

连接设备
通过页面元素选择器实现元素的单选、多选。
获取元素属性、点击元素。
滑动页面
保存图片

webdriver.io 的选择器和jquery的语法很类似，看一个Demo相信你就掌握了。

  // 引入lib
const { remote } = require('webdriverio');


// 微信应用启动配置
const capabilities = {
  platformName: 'Android',
  'appium:automationName': 'UiAutomator2',
  'appium:deviceName': 'Android',
  'appium:appPackage': 'com.tencent.mm',  // 包名
  'appium:appActivity': '.ui.LauncherUI', // 启动页
  "appium:noReset": true, // 不复位数据
  "appium:unicodeKeyboard": false // 隐藏键盘
};


// Appium配置
const wdOpts = {
  hostname: process.env.APPIUM_HOST || 'localhost',
  port: parseInt(process.env.APPIUM_PORT, 10) || 4723,
  logLevel: 'info',
  capabilities,
};


// 入口
async function main() {

  // 设备实例
  const driver = await remote(wdOpts);

  try {

    // 通过Xpath获取元素
    // 单选  类名 + text
    const findBtn = await driver.$('//android.widget.TextView[@text="发现"]');
    // 单选  类名 + resource-id
    const myBtn = await driver.$('//android.widget.ImageView[@resource-id="com.tencent.mm:id/huj"]');
    // 多选 + 类名 + resource-id
    const commentList = await driver.$$('//android.widget.LinearLayout[@resource-id="com.tencent.mm:id/h1r"]');

    // 获取元素 text 属性
    const timeSel = await driver.$('//android.widget.ImageView[@resource-id="com.tencent.mm:id/huj"]');
    const time = await timeSel.getAttribute('text')

    // 点击元素
    await findBtn.click()


    // 向上滑动 开始坐标 + 滑动时间 + 结束坐标
    await driver.touchAction([
      {action: 'press', x: 379, y: 2098},
      {action: 'wait', ms: '2000'},
      {action: 'moveTo', x: 375, y: 606},
      'release'
    ]);

    // 暂停 1秒
    await driver.pause(1000);  

    // 保存图片
    const avatarSel = await item.$('//android.widget.ImageView[@resource-id="com.tencent.mm:id/a27"]');
    await avatarSel.saveScreenshot('./avatar.png');


  } finally {
    await driver.pause(1000);
    await driver.deleteSession();
  }
}

main().catch(console.error);

坑点3 滑动操作加时间

webdriver.io的文档中关于滑动操作，并没有提示必须加滑动时间，但实际开发中不加滑动时间，在App上会变成点击 + 滑动操作，经常会出现类似长按的操纵，所以务必加上wait的参数。

坑点4 键盘会被隐藏

unicodeKeyboard设置为false会将你的手机输入法关掉，重新启动输入法应用就可以了，还没研究清楚unicodeKeyboard参数的意义，大家实践后可以补充下。

效果展示

掌握选择器和操作语法后，前端工程师就能很快的实现自己的功能了，下边的截图是爬取我的微信视频号中的评论数据。

总结

我们再回顾下：

环境：安卓JavA、Android的SDK，安装Node.js 和 Appium命令行。
工具：adb连手机看参数、 Appium命令行启动服务、appium-inspector查看页面元素。
流程：使用Node+ webdriverio，实现操作设备。
语法：webdriverio 元素选择、模拟点击、滑动，获取元素属性 + 图片。

采坑：

不同手机的开发者选项设置。
启动参数务必加noReset。
滑动事件务必加wait参数。
键盘被隐藏，重新打开输入法即可。

最后，爬虫有风险，大家不要做违法违规的事， 我是前端工程师秦少卫，不到之处恳请斧正，欢迎大家点赞关注评论，我们一起成长。

Unity 引擎植入 App 渲染方案正式发布：可与原生 UI 无缝融合，丝滑交互，支持 iOS / 安卓

Wed, 17 Aug 2022 00:04:48 CST

IT之家 8 月 16 日消息，据 Unity 中国官方开发者平台消息，Unity 正式推出了“Unity 植入 App 渲染方案”，开发者可将 3D 内容渲染到 App 中的小窗口，用户可以进行点击、拖拽等交互。

据官方介绍，“Unity 植入 App 渲染方案”克服了此前民间试水 App 植入 Unity 的诸多困难，可与 App 原生 UI 无缝融合，官方演示了将 3D 内容直接嵌入电商平台的顶部轮播图 Banner 中。

▼ 图自“Unity 官方平台”微信公众号，下同

此外，“Unity 植入 App 渲染方案”可以让用户在 App 中与 3D 内容交互，比如查看鞋子的细节，和目前部分电商平台已经上线的功能类似。

该方案下，3D 内容还可以像游戏一样交互，下图是一个场景浏览的示例。

IT之家了解到，此前虚幻引擎和 Cocos-2dx 都有过嵌入 App 的使用，不过需要进行界面单独加载，Unity 的方案看起来确实要先进一些。

“Unity 植入 App 渲染方案”支持 iOS / 安卓两大 App 平台，预计我们会在不久后看到它的实际应用。

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。涉及内容较多，这里就先不做展开。后面会单独进行深入分析。

美国禁止绑定应用商店内购支付：苹果App Store世纪审判，Epic赢了

Sat, 11 Sep 2021 23:28:05 CST

9 月 10 日，美国加州地方法官 Judge Yvonne Gonzalez Rogers 签署了一项有关「Epic v. Apple」的永久禁令，宣告了这场诉讼战争告一段落。

禁令要求苹果在 App Store 中为任何软件卖家开放付款选项。简单来说，Epic Games 曾经想在《堡垒之夜》中添加内置支付链接，从而避免苹果 30% 抽成的愿望，现在可以实现了。

不可禁止开发者在应用程序和元数据按钮、外部链接或其他号召性用语中包含引导客户购买的行为，除了应用程序内购买和用户通过应用程序内的注册帐户自愿获取的联系方式。

简而言之，苹果必须允许 iOS 应用程序将用户引导到 Apple 提供的支付选项之外。该禁令计划在 90 天后生效，除非得到上级法院的命令。

受到禁令影响，苹果股价周五收盘大跌 3.31%，报 148.97 美元，为 5 月份以来最大跌幅，市值一日蒸发 846 亿美元，约合 5451 亿人民币。由于苹果市值巨大，纳斯达克指数也随之跳水。

法官：苹果没有垄断，但「反竞争」

在长达 185 页的完整判决书中，法官驳回了双方对案件中市场竞争的定义。「这里的相关市场是数字移动游戏交易，而不是一般的游戏，也不是苹果自己与 App Store 相关的内部操作系统。」

完整判决书：

https://s3.documentcloud.org/documents/21060631/apple-epic-judgement.pdf

根据该市场定义，「根据联邦或州反垄断法，法院无法判定苹果为垄断者。」法官表示：「尽管如此，根据加州的竞争法，判决确实表明苹果公司正在从事反竞争行为。」

苹果将这一裁决视为 App Store 模式的胜利：「今天法院确认了我们一直所知道的：App Store 没有违反反垄断法。」一位发言人表示。

「苹果在开展业务的每个领域都面临着激烈的竞争，我们相信客户和开发者选择我们是因为我们的产品和服务是世界上最好的。我们仍然致力于确保 App Store 是一个安全且值得信赖的市场。」

在另一份判决中，法院判定 Epic Games 在《堡垒之夜》App 中布置替代支付系统时违反了苹果的合同。因此 Epic 必须向苹果支付通过该系统收取的所有收入的 30%，总额约为 365 万美元，此外还有其他损失赔偿金。

这样的结果对 Epic 来说仍然不够完美，公司 CEO Tim Sweeney 在推特上表示：「今天的判决对开发商或消费者来说都不算是胜利。」

「Epic 正在为 10 亿消费者的应用内支付方式和应用商店之间的公平竞争而战。」或许，Epic 准备上诉，原因也不难想象：苹果既不会被迫允许用户旁载应用程序，也不会接受其他应用程序商店，更不会将其抽成降低至 30% 以下。

苹果官方则在判决出炉后表示：今天的判决宣告了我们一直以来认同的观点——苹果并未触犯反垄断法。正如法庭所说「成功并不意味着违法」，苹果在其发展的所有领域都面临着激烈的竞争，而消费者选择我们，是因为我们的服务是全球最佳水平。我们将继续坚持保证 App Store 作为一家安全可信的平台，支持开发者社区，支撑超过 210 万美国就业岗位，并对所有机构和个人一视同仁。

Epic 看上去大获全胜，但也可以说在其他方面都没赢。

Epic Games vs Apple，里程碑式的案件

对于游戏玩家来说，Epic 的名声往往是「为玩家谋福利」，但也有人认为这家公司是在为了博出位而不断制造噱头。除了风靡全球的《堡垒之夜》以外，他们自家的游戏平台也时不时向玩家派发免费的游戏，已经白送的游戏包括《GTA5》、《文明 6》、《无主之地》这种大作，最近一款被免费的是《仁王》。

多年来，苹果和 Epic Games 在商店交易系统上一直存在分歧，苹果将这 30% 的抽成视为关键的运营成本，而 Epic 将其视为垄断税。

2020 年 8 月，当 Epic 在《堡垒之夜》中安装了替代支付系统以规避 App Store 的交易费用时，这场斗争达到了顶峰。苹果的回应是从商店中删除了《堡垒之夜》，随后 Epic 对苹果发起了反垄断诉讼。

这是一场备受瞩目，漫长且残酷的法律拉锯战，事关 App Store 平台、游戏发行商和用户们的切身利益。除苹果之外，谷歌也被 Epic 告上了法庭，其理由是利用与手机制造商的暗箱操作，维持 Google Play 商店作为安卓应用的垄断来源。

「禁止第三方内购」机制即将崩塌？

8 月 31 日，韩国国会全体会议通过《电信业务法案》修正案，宣布在韩国的苹果、谷歌、三星等 App Store 被禁止强制软件开发商使用支付系统，实际上阻止了平台方对应用内购买活动收取佣金。

韩国是全球第一个立法禁止应用商店垄断的主要经济体，昨天美国法院对于 Epic Games v. Apple 案的判决中，法官同样站在了「反垄断」的一边，可见更多国家未来面对平台方采用同样的态度将是可以预见的趋势。

虽然在和苹果的诉讼案中 Epic 胜诉了，但这并不代表着热门吃鸡游戏《堡垒之夜》（Fortnite）就能重回 App Store。法官没有说要求苹果恢复该游戏，而且苹果和 Epic 都没有表示它将很快回来。Tim Sweeny 表示，除非苹果切实执行了游戏内购渠道开放，否则堡垒之夜不会重新上架。

最新裁决中最重要的一部分是禁令：苹果不能阻止其 iOS 平台上的开发者链接到 iOS 以外的支付方式。这可能使苹果的长期利润损失数十亿美元。

Epic 则赔掉了数百万美元，而且如果不是《堡垒之夜》被下架，Epic 之前两年靠这个游戏仅在 iOS 上就赚了 6.14 亿美元，这样看来，似乎两家公司都输掉了这场斗争，唯一获得好处的应该是第三方游戏开发商。

预计两家公司都会对该裁决的部分内容提出上诉。

参考内容：

https://www.reuters.com/legal/litigation/judge-epic-suit-says-apple-restrictions-anti-competitive-2021-09-10/

https://news.ycombinator.com/item?id=28482895

工信部将对 APP 违规调用通讯录和位置权限等加大惩处

Fri, 16 Jul 2021 15:19:15 CST

工信部信息通信管理局局长赵志国周五表示，将在常态化监管的基础上，适时针对重点问题、重点企业开展“回头看”，对反复出现违规调用通信录和用户地理位置权限等相关问题的企业，加大惩处力度，确保整改过的问题“不反弹、不反复”。“比如说调用通讯录、用户位置信息权限等，调用这些数据不是用户使用场景所必须，不符合信息收集最小必要原则，因此必须加大惩处力度。对于整改不到位、落实效果不好的，我们要在整治基础上纳入信用管理。”赵志国称。“数据是国家基础战略资源和重要的生产要素。”他强调。

【Weex】网易严选 App 感受 Weex 开发 · Issue #3 · zwwill/blog · GitHub

Mon, 31 May 2021 09:30:10 CST

自打出生的那一天起，Weex 就免不了被拿来同 React Native「一决高下」的命运。React Native 宣称「Learn Once, Write Anywhere」，而 Weex 宣称「Write Once, Run Everywhere」。在我看来，并没有谁更好，只有谁更合适。下面我将围绕 Weex 入门进行讲解。
（如果你尚不了解 React Native，并想简单入门，可以阅读【整理】React Native 快速入门笔记）

网易严选 App 感受 Weex 开发

什么都不说，先给你感受下 Weex 的效果。以下就是我使用 Weex，4*8h（不连续）做出来的 demo，其中还包括素材收集，踩坑总结等时间。

此处是 demo 源码：
https://github.com/zwwill/yanxuan-weex-demo

不得不说，使用 Weex 开发 app 对于我们纯前端人员来说，是件「很爽」的事情，只要你熟悉了他的语法，基本可以做到一周上手写 app。极其适合交互要求不高，时间紧迫，人手不足的同构开发需求。

但是，当然有但是，如果你想写出一个完美的 app，你就需要在性能优化上下很大的功夫，包括动画的优化，过场的优化，图片的优化，细节的打磨等等，再者，就是你需要掌握或者「能写」一些原生的代码，不然有些功能你是实现不了的，比如 status bar 的属性更改，开场动画的制作，内存的回收，webview 的监听等等。

下面我们具体讲讲入门知识

Write Once, Run Everywhere

Weex 提供了多端一致的技术方案。

首先，Weex 的开发和 web 开发体验可以说是几乎一样。包括语法设计和工程链路等。
其次，Weex 的组件、模块设计都是 iOS、Android、Web 的开发者共同讨论出来的，有一定的通用性和普遍性。
Weex 开发同一份代码，可以在不同的端上分别执行，避免了多端的重复研发成本。

在同构这条路上，Weex 比 React Native做得更彻底，他「几乎」做到了，「你来使用 vue 写一个webapp，我顺便给你编译成了 ios 和 android 的原生 app」

至于为什么要造这个轮子，官方给了以下说法

1、今天在技术社区有大量的 web 开发者，Weex 可以赋能更多的 web 开发者构建高性能和高体验的移动应用。
2、Web 开发本身具有非常强的高效率和灵活性，这和 Weex 想解决的移动端动态性问题不谋而合。
3、Web 标准和开发体验是很多顶尖而优秀的科技公司共同讨论和建设的结果，本身的设计和理念都有极高的品质保障
4、同时 Weex 也希望可以借此机会努力为标准贡献一点自己的微薄之力。
5、Web 是一种标准化的技术，标准本身就是一种力量，基于标准、尊重标准、贴近标准都意味着拥有更多的可能性。
6、Web 今天的生态和社区是非常繁荣的，有很多成熟的工具、库、工程体系、最佳实践可以使用、引入和借鉴。

在我看来，Weex 其实是 Alibaba 团队提高生产效率的产物，在淘宝这类要求多端统一迭代快速的部门，三端约定一种便于统一的规范，在加上时间的发酵，渐渐的就有了此类脚手架的雏形，同时在脸书 React Native 开源带来的极大轰动后，自己也坐不住了吧^_^

好了，闲话就说到这，下面就来让我们解剖一下WEEX的优劣良莠。

预科

入门 Weex 前需要了解以下知识，这样能帮助你更快的掌握
Node：《Node.js 教程》
Vue：《Vue.js官方教程》
ES6：《ECMAScript 6 入门》
再者就是 ios 和 android 开发语法的入门和编辑器的使用

环境

系统环境要求

IOS : MacOS, 黑苹果
Android : MacOS, Linux, Windows

配置环境

你可以参考官方文档安装必须的依赖环境 http://weex.apache.org/cn/guide/set-up-env.html，
也可以直接安装以下环境

node
npm
weex-toolkit
Xcode
安装 Xcode IDE 和 Xcode 的命令行工具（IOS 开发依赖）
Android Studio

下载必须的插件：
a) JDK1.8+
b) Show Package Details
c) Android SDK Build Tools
d) Android Support Repository

配置基础环境：
a) ANDROID_HOME （如运行是遇到问题可参考此文 http://www.jianshu.com/p/a77396301b22）
b) JAVA_HOME

Hello Weex

官方文档上的入门 Hello world 是 web 端的，紧接着介绍了如何「 集成 Weex 到已有应用」

但是，身为一个 web 前端开发者，如果你不懂原生语音的话，介绍这些并不能起到很好的引导作用，因为web前端开发者都有「 一统前端界」的野心（Web+Android+IOS），「寄人篱下」只能是暂时的。

快速创建并运行一个纯 Weex App 对于「纯」前端同学来说，才是有意思的事儿。
但：

为什么文档要这么设计也是跟Weex的定位有关的，读完下文后续你就慢慢懂了，后面我将做总结解释

如果你在官方教程里没有找到创建工程的教程，可以阅读此文《Weex 快速创建工程 Hello World》

Vue Native

Weex 在迭代的过程中选择了于 Vue 2.0 握手，因为该版本的 Vue 加入了 Virtual-DOM 和预编译器的设计，使得该框架在运行时能够脱离 HTML 和 CSS 解析，只依赖 JavaScript，如此，Vue 在和 Weex 合作后，便获得了使用 JS 预编译原生的组件 UI 的能力。

同 React Native 一样，有人也将 Weex 叫做 Vue Native。

如果你对 Vue 还不了解，可以先学习【预科】部分推荐的《Vue.js 官方教程》。

那么接下来我们讲讲，Vue 在 Weex 中的不同

Vue 在 Weex 中的不同

虽说 Weex 使用 Vue 语言写的，但毕竟是需要在不同平台间运行的，虽然大部分语法都有支持，但是依然有部分语法是不同的

语法差异

1、“html标签”

目前 Weex 支持了基本的容器 (div)、文本 (text)、图片 (image)、视频 (video) 等组件，注意是组件，而不是标签，虽然使用起来跟 html 标签很像，至于其他标签基本可以使用以上组件组合而成。

2、Weex 环境中没有 DOM

因为 Weex 解析 vue 得到的并不是 dom，而是原生布局树

3、支持有限的事件

并不支持 Web 中所有的事件类型，详情请参考《通用事件》

4、没有 BOM 但可以调用原生 API

在 Weex 中能够调用移动设备原生 API，使用方法是通过注册、调用模块来实现。其中有一些模块是 Weex 内置的，如 clipboard 、 navigator 、storage 等。
《clipboard 剪切板》
《navigator 导航控制》
《storage 本地存储》
为了保持框架的通用性，Weex 内置的原生模块有限，不过 Weex 提供了横向扩展的能力，可以扩展原生模块，具体的扩展方法请参考《iOS 扩展》和《Android 扩展》。

样式差异

Weex 中的样式是由原生渲染器解析的，出于性能和功能复杂度的考虑，Weex 对 CSS 的特性做了一些取舍
1、Weex 中只支持单个类名选择器，不支持关系选择器，也不支持属性选择器。
2、组件级别的作用域，为了保持 web 和 Native 的一致性，需要 <style scoped>写法
3、支持了基本的盒模型和 flexbox 布局，详情可参考 Weex 通用样式文档。但是需要注意的是，

不支持 display: none;可用 opacity: 0;代替，（opacity<=0.01时，元素可点透）
样式属性暂不支持简写（提高解析效率）
flex 布局需要注意 web 的兼容性
css 不支持 3D 变换

Weex 开发&调试

Vue 语法

举个栗子，以下是严选App Demo首页的简化代码

<template>
    <divclass="wrapper">
        <textclass="iconfont"></text>
        <home-header></home-header>
        <scrollerclass="main-list"offset-accuracy="300px">
            <refresher></refresher>
            <divclass="cell-button"@click="jumpWeb('https://m.you.163.com')">
                <yx-slider:imageList="YXBanners"></yx-slider>
            </div>
            <divclass="cell-button">
                <block-1:title="block1.title":items="block1.items"></block-1>
            </div>
        </scroller>
    </div>
</template><stylescoped>.iconfont{font-family:iconfont;  }.main-list{position:fixed;top:168px;bottom:90px;left:0;right:0;  }</style><script>varnavigator=weex.requireModule('navigator');importutilfrom'../../src/assets/util';importHeaderfrom'../components/Header.vue';importrefresherfrom'../components/refresh.vue';importYXSliderfrom'../components/YXSlider.vue';importBlock1from'../components/Block1.vue';exportdefault{components:{'home-header':Header,'refresher':refresher,'yx-slider':YXSlider,'block-1':Block1},data() {return{YXBanners:[{ title:'', src:'http://doc.zwwill.com/yanxuan/imgs/banner-1.jpg'},{ title:'', src:'http://doc.zwwill.com/yanxuan/imgs/banner-2.jpg'},{ title:'', src:'http://doc.zwwill.com/yanxuan/imgs/banner-3.jpg'}]}},methods:{jumpWeb(_url) {consturl=this.$getConfig().bundleUrl;navigator.push({url:util.setBundleUrl(url,'page/web.js?weburl='+_url) ,animated:"true"});}}}</script>

如果以上代码脱离工程单独出现，基本上是无法得知他是 Weex 工程。此处可切实感受到 Weex 的 web 开发体验

名存实亡的<标签/>

<template><div><textv-for="(v, i) in list"class="text">{{v}}</text><imagestyle=""src=""></image><videoclass="video":src="src"autoplaycontrols@start="onstart"@pause="onpause"@finish="onfinish"@fail="onfail"></video></div></template>

Weex 工程中常用的标签有 <div />， <text />， <image />， <video />（组件另算），由此四种标签基本可以满足绝大多数场景的需求，虽说此标签同 web 工程下的标签用法一致，但此处的标签已不再是我们前端口中常提的 html 标签，而且名存实亡的 Weex 标签，确切讲是 Weex 组件。

通过 weex-loader、vue-loader、weex-vue-render的解析最终转换输出的便是实际的组件，有此设计只是为了完成「 web开发体验」的目标。但是我们身为上层的开发人员要清楚自己每天「把玩」的到底是个什么「鬼」。

阉割版 CSS

其实用阉割版来形容 Weex 的 css 支持度并不合适，但如果从「web开发体验」的角度来衡量，那么这个形容词也是可以理解的。（此处对 Weex 寄有厚望^_^）

单位

Weex 中的所有 css 属性值的单位均为 px，也可省略不写，系统会默认为 px单位。

选择器

Weex 中只支持单个类名选择器，不支持关系选择器，也不支持属性选择器。

/* 支持单个类名选择器 */.one-class{font-size:36px;
}/* 不支持关系选择器 */.parent>.child{padding-top:10px;
}/* 不支持属性选择器，不支持 `v-cloak` 指令 */[v-cloak] {color:#FF6600;
}

这个只是对样式定义的限制，不影响样式类名的使用，在标签中可以添加多个样式类名，如：

          <template>
  <div class="one two three"><div>
</template>

盒模型

weex支持css基本的盒模型结构，但需要注意的是

box-sizing属性值默认为 border-box
margin， padding， border等属性暂不支持合并简写

FlexBox

Weex 中对 flexbox 布局支持度很高，但依然有部分属性并不支持，如 align-items:baseline;、 align-content:space-around;、 align-self:wrap_reverse;等。

具体 Weex 对 flexbox 的支持和布局算法，可通过此文进行了解由 FlexBox 算法强力驱动的 Weex 布局引擎，此处便不再赘述。

显隐性

在 Weex 的 ios 和 android 端，并不支持 display属性。

因此，不能使用 display:none;来控制元素的显隐性，所以 vue 语法中的 v-show条件渲染是不生效的。

我们可以使用 v-if代替，或者用 opacity:0;来模拟。

需要注意的是，ios和android端并不能使用 opacity:0;来完全模拟 visibility: hidden;，因为，当
opacity 的只小于等于 0.01 时，native 控件便会消失，占位空间还在，但用户无法进行交互操作，点击时会发生点透效果。

CSS 3

Weex 支持 css3 属性，虽然支持并不够，但相较 React Native 的「不能用」已经是强大很多了。

以下几种属性我们在开发前需要知道她的支持度

transform：目前只支持 2D 转换
transition：v0.16.0+ 的 SDK 版本支持css过度动画，可根据情况配合内建组件 animation实现动画交互
linear-gradient：目前只支持双色渐变色
font-family：Weex 目前只支持 ttf 和 woff 字体格式的自定义字体

第三方工具库

由于使用了增强版的 webpak 打包工具 weexpack，支持第三方框架也是件自然而然的事情。

常用的有 vuex、 vue-router等，可根据项目实际情况引入需要的第三方工具库

npm 包管理

npm 包管理是前端开发朋友们再熟悉不过的包管理方式了。这也是为什么 React Native 和 Weex 都选择这种管理方式的原因。

以下是本工程的 package.json 文件，这里就不做讲解了，不熟悉的朋友点这里-> NPM 使用介绍

          {
  "name": "yanxuan-weex",
  "version": "1.0.0",
  "description": "a weex project",
  "main": "index.js",
  "scripts": {
    "build": "webpack",
    "build_plugin": "webpack --config ./tools/webpack.config.plugin.js --color",
    "dev": "weex-builder src dist -w",
    "serve": "webpack-dev-server --config webpack.dev.js -p --open"
  },
  "keywords": ["weex"],
  "author": "zwwill",
  "license": "MIT",
  "dependencies": {
    "vue": "^2.4.2",
    "vue-router": "^2.7.0",
    "vuex": "^2.1.1",
    "vuex-router-sync": "^4.3.0",
    "weex-html5": "^0.4.1",
    "weex-vue-render": "^0.11.2"
  },
  "devDependencies": {
    "babel-core": "^6.21.0",
    "babel-loader": "^6.2.4",
    "babel-plugin-add-module-exports": "^0.2.1",
    "babel-plugin-transform-runtime": "^6.9.0",
    "babel-preset-es2015": "^6.9.0",
    "babel-runtime": "^6.9.2",
    "css-loader": "^0.26.1",
    "history": "^4.7.2",
    "quick-local-ip": "^1.0.7",
    "vue-loader": "^13.0.4",
    "vue-template-compiler": "^2.4.2",
    "webpack": "^2.7.0",
    "webpack-dev-server": "^2.4.2",
    "weex-builder": "^0.2.7",
    "weex-loader": "^0.4.5",
    "weex-router": "0.0.1"
  }
}

UI 尺寸适配

Weex 容器默认的显示宽度 (viewport) 是 750px，页面中的所有组件都会以 750px 作为满屏宽度。

这很像移动设备的逻辑像，比如 iPhone 6 的物理像素宽为 750，逻辑像素

Type	iPhone 3G	iPhone 4	iPhone 6	iPhone 6Plus
物理像素	320x480	640x960	750x1134	1080x1920
逻辑像素	320x480	320x480	375x667	414x736
像素比	@1x	@2x	@2x	@3x

类比在 Weex 中，如果所有的显示宽度都是用默认值 750，那么显示出来的实际像素信息为

Type	iPhone 3G	iPhone 4	iPhone 6	iPhone 6Plus
物理像素	320x480	640x960	750x1134	1080x1920
显示像素	750x1125	750x1125	750x1134	750x1333
像素比	@0.427x	@0.85x	@1x	@1.44x

所以我们在使用 Weex 做 UI 适配时就没有所谓的 @2x图和 @3x图，所有的尺寸都是Weex帮我们根据
750 作为基数宽做的缩放。

当然，Weex 提供了改变此显示宽度的 API， setViewport，通过此方法可以改变页面的显示宽度，可以实现每个页面根据自己的需求改变基数逻辑尺寸

因此对于一些固定的 icon，不建议使用普通的静态图片或者雪碧图，这里建议使用矢量的字体图片，有以下优点：

适量图不会变糊
使用方便，通过 css 的字号控制大小，不用适配机型和屏幕尺寸
引用 ttf 文件，体积小，且容易更新

本地调试

Weex 的调试方式有多种，如果说RN的调试模式是解放了原生开发的调试，那么 Weex 的调试方式可以说是赋予了 web 模式调试原生应用的能力。

方法一

此方法多用于解决 bug，检测控件的布局问题

          # 调试单个页面
$ weex debug your_weex.vue
# 调试整个工程
$weex debug your/path -e App.vue

执行调试命令后，会将指定的文件打包成 JSBundle，并启动一个 weex Devtool 服务（ http://localhost:8088可访问，如下图），同时将JSBundle 文件传递至该服务跟路径下的weex文件夹内（ http://localhost:8088/weex/App.js，实际是下图右边二维码的的内容）。

使用 Weex Playground App 扫下左二维码进入调试模，见下图

再次扫码右方二维码，点击【inspector】即可进入调试模式。

每一个控件都是相同的数据结构

          <view class="WXText" frame="{{0,0},{414,736}}" hidden="NO" alpha="1" opaque="YES"></view>

class：代表原声空间类型
frame：表示空间的坐标和大小
hidden：代表显隐性，css中visibility设置的值
alpha：不透明度，css中opacity设置的值
opaque：默认为YES，打开绘图系统性能优化的开关，即不去计算多透明块重合后的真正颜色，从而减小GPU的压力，weex中具体有没有地方可以设置这个开关暂时不清楚，有猎奇心的朋友可以研究下。

方法二

此方法多用于开发调试，试试观察结果

          $ weex your_weex.vue

如果出现 access 权限报错，使用管理员指令

          $ sudo weex your_weex.vue

此时本地同时启动一个watch的服务器用于检查代码变更，自动重新构建 JSBundle，视觉同步刷新。

上图看到的效果即为H5页面的效果，我们一般在整个单页编写完成后在使用 Weex Playground App 扫码查看真机效果，或者你也可以在编写的同时使用真机观察代码的运行效果，每次重新构建包到重绘的速度还是很快的。

但前提是你要保证，你的手机和电脑的连在同一个局域网下，并且使用IP访问。

Weex 的原理

虽然说，Weex 可以抹平三端开发的差异，但是知其然也应知其所以然使用起来才能游刃有余。

打包

熟悉 React Native 的人都知道， React Native 的发布实际上就是发布一个 JSBundle，Weex 也是这样，但不同的是，Weex 将工程进行分包，发布多个 JSBundle。因为 Weex 是单页独立开发的，每个页面都将通过 Weex 打包器将 vue/we 页面打包成一个单独的 JSBundle，这样的好处在于减少单个 bundle 包的大小，使其变的足够小巧轻量，提高增量更新的效率。

          # 仅打包
$ npm run build
# 打包+构建
$ weex build ios
# 打包+构建+安装执行
$ weex run ios

以上三种均会触发 Weex 对工程进行打包。
在我们执行了以上打包命令后，所有的工程文件将被单独打成一个独立的 JSBundle，如下：

打包后的 JSBundle 有两种格式

#由.vue文件打包出来的包格式（简写），使用vue2.0语法编写// { "framework": "Vue"}/******/(function(modules){......./******/})

#由.we文件打包出来的包格式（简写），使用weex语法编写// { "framework": "Weex" }/******/(function(modules){......./******/})

不同的头部是要告诉使用什么语法解析此JSBundle。

至此，我们准备「热更新的包」就已经准备完毕了，接下就是发包执行了。

发包

打包后的 JSBundle 一般发布到发包服务器上，客户端从服务器更新包后即可在下次启动执行新的版本，而无需重新下载 app，因为运行依赖的 WeexSDK 已经存在于客户端了，除非新包依赖于新的 SDK，这也是热更新的基本原理。

【WeexSDK】包括

【JS Framework】JSBundle 的执行环境

【JS-Native Bridge】中间件或者叫通讯桥梁，也叫【Weex Runtime】

【Native Render Engine】解析 js 端发出的指令做原生控件布局渲染

执行

Weex 的 iOS 和 Android 客户端的【JSFramework】中都会运行一个 JavaScript 引擎，来执行 JS bundle，同时向各端的渲染层发送规范化的指令，调度客户端的渲染和其它各种能力。iOS 下选择了 JavaScriptCore 内核，而在 Android 下选择了 UC 提供的 v8 内核（RN两端都是JavaScriptCore 内核）。

JSBundle 被 push 到客户端后就会在 JSFramework 中执行，最终输出三端可读性的 VNode 节点，数据结构简化如下：

          {
  tag: 'div',
  data: {
    staticStyle: { justifyContent: 'center' }
  },
  children: [{
    tag: 'text',
    data: {
      staticClass: 'txt'
    },
    context: {
      $options: {
        style: {
          freestyle: {
            textAlign: 'center',
            fontSize: 200
          }
        }
      }
    },
    children: [{
      tag: '',
      text: '文字'
    }]
  }]
}

有了统一的 VNode 节点，各端即可根据自己的方法解析渲染原生UI了，之前的所有操作都是一致的，包括文件格式、打包编译过程、模板指令、组件的生命周期、数据绑定等。

然而由于目标执行环境不同（浏览器和 Weex 容器），在渲染真实原生 UI 的时候调用的接口也不同。

此过程发生在【Weex SDK】的【Weex Runtime】中。

最总【Weex Runtime】发起渲染指令 callNative({...})有RenderEngine完成渲染

总结一下

Weex 文件分包打包成单个 JSBundle 文件
发布到发包服务器上，通过热更新 push 到用户的客户端，交由【Weex SDK】执行解析
SDK 中的【JS Framework】执行 Bundle 脚本生成 Virtual DOM
Virtual DOM 经由各端执行环境【Weex Runtime】解析翻译成执行指令
【Native RenderEngine】接收到指令后执行渲染操作，作出渲染出完整的界面

官方配图：

扩充配图：

Weex 的工作模式

1. 全页模式

目前支持单页使用或整个 App 使用 Weex 开发（还不完善，需要开发 Router 和生命周期管理）。

本文先行的严选 demo 便是使用第二种全屏模式，使用 Weex 开发整个 App，期间触碰到 Weex 的在此模式下诸多不足，如 StatusBar 控制、Tab 切换、开场动画自定义、3DTouch、 Widget 等等原生的特色功能没有现成的 API，需要我们自己扩展，甚至扩展不了。因此并不能完全“灭掉”原生。

所以，目前在阿里内部使用较多的是此模式中的单页模式，这也是为什么官方文档在介绍原理后就直接奔入 集成到原生应用的主题上去了。

2. Native Component 模式

把 Weex 当作一个 iOS/Android 组件来使用，类比 ImageView。这类需求遍布手淘主链路，如首页、主搜结果、交易组件化等，这类 Native 页面主体已经很稳定，但是局部动态化需求旺盛导致频繁发版，解决这类问题也是 Weex 的重点。

3. H5 Component 模式

在 H5 种使用 Weex，类比 WVC。一些较复杂或特殊的 H5 页面短期内无法完全转为 Weex 全页模式（或RN），比如互动类页面、一些复杂频道页等。这个痛点的解决办法是：在现有的H5页面上做微调，引入Native 解决长列表内存暴增、滚动不流畅、动画/手势体验差等问题。

另外，WVC 将会融入到 Weex 中，成为 Weex 的 H5 Components 模式。

严选 App Demo 实现过程中的感想

Vue-Router & Tab

由于 Weex 没有封装 Tab 的组件，因此笔者使用了很多方法来实现Tab切换的功能。

1、vue-router：router 思想方便管理，但是每次切换都是新的实例，没有tab模式
2、opacity、visablity：此处需要注意，Weex的渲染机制和web是有区别的，对夫层设置 opacity 或者visiablity隐藏是无法同时隐藏定位为 position:fixed;的子元素。
3、position、transform：改变 tab 层的位置，此方法在定位为 position:fixed;的子元素上依然无效。

image & iconfont

Weex 中所有的静态资源基本都是网络资源，包括图片、字体图片等，所以使用 iconfont 图标是再合适不过的了。

此 demo 中所有的 icon 均使用的iconfont。

此处强烈推荐一个站点 www.iconfont.cn。

在此平台你可以找到几乎所有你需要的 icon，你也可以上传自己的 icon 到自己创建的项目中。同时该系统还提供生成ttf、woff 资源，并且做了 cdn 加速和 gzip 压缩，是不是跟 Weex很配呢？

不过也有风险，就是，如果哪天阿里不在维护并回收该平台的资源了，你的 app 可能就会变成这样，全是方框，或者 padding 掉你 H5 的页面

当然，这种及情况出现的几率很小，如果你是一个大公司，你手上有更好的资源急速方案，那就自己保存吧。

webview

UIWebView是我们开发App常用的一个控件，不过Weex帮我们封装好的API明显时不够用的，目前只有 pagestart、 pagefinish、 error，并没有封装像RN那样的 onShouldStartLoadWithRequest拦截地址请求的API，在我看来，这有些不合理，并不清楚轮子的制造者是什么意图。

性能

性能是一个大课题，在此就不做展开了，只稍微提及一些我们开发需要注意的几点

性能影响点：UI更新>UI事件响应>后台运算
合理优化过场&动画，过场和 console 容易引起 app crash 需要注意
降低 js <-> native 的通信频率
优化list结构，降低重排重绘压力
把优先级低且耗时较长的工作推后处理

Weex 的现状

Weex 解决了的

我的发布我做主（热更新）

脚本语言天生自带“热更新”，Weex 针对 React Native 的热更新策略做了优化，将 WeexSDK 事先绑到了客户端上，并且对 JSBundle 进行分包增量更新，大大提高了热更新的效率。

但优点也是缺点，如果新包依赖于心的 SDK，此情况下，我们需要发布还有新 SDK 的 app 到应用市场，用户也须从市场更新此 app。不够随着 WeexSDK 版本的稳定后，相信此策略的优势就会凸显出来。

性能问题

Weex 是一种轻量级、可扩展、高性能框架。集成也很方便，可以直接在 HTML5 页面嵌入，也可嵌在原生UI中。由于和 React Native 一样，都会调用 Native 端的原生控件，所以在性能上比 Hybrid 高出一个层次。

统一三端

虽说这是一个大胆的实践，但对于大前端社区的统一有着推动作用，显然阿里在这一方面已经迈出了第一步。基本解决了三端同等需求导致资源浪费的痛点。

但后期可能会出现这种现象，开发一个三端的 App 会从原来的个人变成四个人，多出来的那一个人负责开发 Weex 单页。

意思就是，三端统一的不够彻底，但就目前的环境下，这一句是最优方案了，却是提高了开发效率。大前端将来将如何一统三国我们且行且观望吧。

做游戏

对于一些交互视觉统一且没有很大的性能需求的游戏，Weex 还是可以胜任的。

近期笔者将尝试发布一款纯Weex构建的益智小游戏，敬请期待。

朋友们可以用这个demo体验下 Weex 版扫雷游戏开发

Weex “暂时”放弃的

虽然说大一统事件百利的事，但并非无一害。

差异化

对于一些有差异化完美体验追求的项目就只能收敛或者放弃了。

独立的 bug 修复

对于三端同时上线，一端存在 bug 的情况，Weex 并不能保证做到牵一发而不动全身。

个性化功能

比如安卓的波纹按钮、3DTouch、 Widget、iWatch版本等，目前这些功能还是没有的，不知道以后 Weex
是否将其加入到官方文档中。

声明

以上均为个人见解，不代表官方。如有不当之处还望指正。

参考

[ 1 ] Weex官方文档- http://weex.apache.org/cn/references/
[ 2 ] 场景研读- Native 性能稳定性极致优化 - https://yq.aliyun.com/articles/69005
[ 3 ] 门柳- 详解 Weex JS Framework 的编译过程 - https://yq.aliyun.com/articles/59935?spm=5176.8067842.tagmain.66.1QA1fL
[ 4 ] 阿里百川- 深度揭秘阿里移动端高性能动态化方案Weex - https://segmentfault.com/a/1190000005031818
[ 5 ] 一缕殇流化隐半边冰霜- Weex 是如何在 iOS 客户端上跑起来的 - http://www.jianshu.com/p/41cde2c62b81

The text was updated successfully, but these errors were encountered:

几款移动跨平台App开发框架比较 - song-z - 博客园

Fri, 28 May 2021 20:17:22 CST

整理目前流行的跨平台WebApp开发技术的特点，仅供参考。

每个框架几乎都包含以下特性：

使用 HTML5 + CSS + JavaScript 开发
跨平台重用代码
丰富的UI库
提供访问设备原生API的 JavaScript API 包装器
解决原生开发中机型适配的难题
提供打包、部署的工具或服务
都需要学习自身封装的 JavaScript API

筛选框架的要求：

性能：运行速度快
UI：提供接近原生的UI体验
插件多，文档丰富，开发效率高，容易扩展和维护
满足业务需求

Cordova

Cordova 和 PhoneGap 的区别？
PhoneGap 是 Apache Cordova 的一个分发版，就像 Ubuntu 是基于 Linux 的一个发行版，其代码库也基于 Cordova，只是 PhoneGap 关联了 Adobe 的一些额外的商业工具或服务，例如 PhoneGap Build 和 Adobe Shadow，来帮助开发者简化开发。
此外，两者提供的CLI工具、项目结构有差异，如：
Cordova 把 config.html 放在项目目录下，而 PhoneGap 把它放在www 目录下。

优点：

开源免费，社区生态成熟，插件丰富
支持离线场景应用
开发工具选择空间大

缺点:

只提供基础访问设备的接口，需要自己搭配其他UI框架和JavaScript框架来搭配

UI框架

Framework7
MSUI| Github
Famous
为任意屏幕创建流畅、复杂的UI。
免费和开源的JavaScript渲染引擎。着名引擎的独特之处在于其JavaScript渲染引擎和3D物理引擎。
官网| Github| Hello World
使用 Famo.us 创建高性能移动 UI

参考资料

Cordova中文文档
 创建第一个App（英文）
利用 Cordova+Famous 创建高性能跨平台APP
使用 Cordova 和 Vue.js 创建移动应用

Ionic

官网地址： http://www.ionic.wang/（有案例）
Ionic = Cordova + AngularJS + 一套样式库。

技术要求

HTML + CSS + AngularJS

优点：

基于 Cordova
漂亮的界面，追求性能，专注原生，免费开源
Angular JS MVVM 开发理念，数据双向绑定
继承自 Cordova，可以使用 Cordova 的插件

缺点：

Angular JS 学习路线陡峭
Ionic 框架相比于原生的 Cordova 有所差异，Cordova 某些官方插件可能不适用于Ionic

AppCan

通过AppCan IDE集成开发系统、云端打包器等，快速开发出Android、iOS、WP平台上的移动应用。

有两种方式创建项目：IDE 和云端，并且IDE可以同步到云端。
免费用户有100M空间、50个应用的限制。

优点

提供一体化解决方案，方便环境搭建、开发、调试、发布
框架自带UI包，包含常用控件样式
框架对UI、动画渲染进行过优化，反应速度快
支持本地打包、云端打包
基于密钥的代码加密

缺点

不开源，无法修改、优化底层代码
分大众版和企业版，大众版免费，但功能有缺失，详细见附录
暂不支持自行开发控件/，无法调取android原生功能
框架自带功能过多，导致应用安装包偏大。
文档偏少
部分系统无法使用IDE进行调试
只能在服务器端发布，无法在本地发布
IOS发布，需要将证书上传至服务器

参考：
Phonegap VS AppCan

使用案例：
我爱我家App 等

附录：
企业版和大众版主要有以下几点区别：

开发环境：
企业版走独立的开发环境与打包环境，企业版配备macmini打包服务器，可以实现本地环境下创建项目，调试，打包；
大众版不管是创建项目还是打包都需要依托于官方的服务器，需要在联网的情况下进行，打包需要将源码上传到官方服务器进行打包；
版本控制：企业版独立控制引擎插件的版本；
大众版官方统一维护，官方换哪个版本开发者就需要使用哪个版本，没有选择；
协同开发：企业版可通过macmini后台分配开发者或者应用管理员帐号，可实现协同开发。
大众版不能满足协同开发
企业版有推送API接口
大众版没有
售后服务：企业版有独立的售后团队
大众版的入口是论坛

Dcloud

特点：
云编译必须联网获取AppId

优点：

国内厂商，中文文档
对HTML5的性能、工具、能力都做了深入扩展，提供 IDE 、云服务等帮助节省时间
MUI 更贴近国内App使用习惯，提供模块的详细例子，如登录，个人中心

缺点：

部分操作需要具备原生开发经验，如离线打包App
新产品仍然有bug，还需改进

学习路线：

APICloud

优点：

不懂原生开发，不懂后台语言就可完成APP

缺点：

更新速度快，版本不够稳定
面向不懂App开发人群，不适合程序员和科技公司，过度依赖会降低技术水平
涉嫌抄袭DCloud大量代码

React Native

能够在Javascript和React的基础上获得完全一致的开发体验，构建世界一流的原生APP。
仅需学习一次，编写任何平台。(Learn once, write anywhere)

缺点：

初次学习成本高
必须在不同平台下写两套代码，依赖暴露的接口

总结

经过一番对比，感觉 Cordova 和 DCloud 更适合本次项目。

原因：
Cordova

生态成熟，有更多可搭配工具使用，开源代码可自由定制；
前端框架： famous 或 Framework7

DCloud

国产中的开源，免费，性能不错
提供云服务帮助打包和部署、测试，降低一部分门槛，减少时间；
前端框架：MUI

其他框架不适合的原因：
APICloud

生态不好，名声不好，面向群体不适合；

AppCan

闭源，商业化产品，免费版限制太多；

Ionic

AngularJS 学习曲线陡峭，需要时间；

React Native

学习成本高

为什么别人家的APP，上报日志就这么省流量？

Mon, 11 Jan 2021 03:22:55 CST

为了统计 APP 内用户行为，或者需要收集某些产品数据，APP 往往需要进行日志上报，日志上报往往又非常费流量，大家的 APP 是怎么上报日志的呢？

画外音：用户流量的大头，是日志上报？

APP 可不可以不上报日志，只从服务器日志统计用户的行为和产品数据？
不行，有些用户行为不会与服务器进行交互，例如 “卡片切换”，服务器日志无法完成所有统计。

APP 一般如何上报日志？
常用方法有这么几种。

（1）使用类似于 Google Analytics 的第三方工具；

优点：无需开发

缺点：不能做个性化统计

（2）自己制订私有协议进行上报；

优点：节省流量

缺点：开发成本高

画外音：例如，TCP 二进制协议，可定制化，又省流量。

（3）使用 HTTP 协议，通过 GET 参数传递需要上报的数据。

如何通过 HTTP 协议进行上报？

可以在 Web-Server 下放置一个文件，APP 发起 HTTP 请求访问这个文件，通过 GET 参数传递数据，并通过分析 access 日志来得到想要的数据。

如何通过 GET 参数传递数据？

一般又有两种方式：

（1）约定格式法；

（2）KV 法。

什么是 “约定格式法”？

约定格式法：约定分隔符，约定占位符，约定每个字段的含义，例如：

daojia.com/up?[bj][201…

约定如下：

（1）被访问文件是 up；

（2）分隔符是 []；

（3）第一个字段 [bj] 代表城市，第二个字段代表日期，第三个字段代表时间，第四个字段代表用户 id，第五个字段代表行为。

该方法缺点是：扩展性较差，有时候某些字段没有值，也必须在相应的位置保留占位符，因为每个字段的含义都是事先约定好的，要想新增统计项，只能在 GET 后面新增 []。

什么是 “KV 法”？

KV 法：通过 GET 参数自解释的 KV 方式来上报数据。

上面的例子用 KV 法来上报，则上报形式为：

daojia.com/up?city=bj&…

该方法的优点是：扩展性好。

缺点是：上报数据量比较大，非常消耗流量。

为什么会这么消耗流量呢？

之所以消耗流量，主要有这样一些原因：

（1）无效流量多，HTTP 报文有很多无效数据；
（2）URL 冗余，每次都要上报 URL；
（3）KEY 冗余，每次都要上报 KEY；
（4）上报频度高，用户每次操作都要日志上报的话，上报量很大。

有没有节省流量的方法呢？

针对上述 1-4 点，常见的优化方案有这样一些。

痛点 1：HTTP 请求内无效数据多。

解决方案：手动构造 HTTP 请求，尽可能多的去除 HTTP 中的无效数据。

画外音：

如果使用第三方库构造 HTTP 请求，可能会带上你并不需要的 UA 数据。

自己构造，则可以只保留 GET /up HTTP/1.1 和 GET 传递的必须数据；

痛点 2：URL 冗余。

解决方案：使用尽可能短的域名来接收上报的日志。

画外音：例如，s.daojia.cn/a

痛点 3：KEY 冗余。

解决方案：使用尽可能短的 KEY 来标识数据，日志收集方一定要统一规范好 KEY。

画外音：例如，city=bj 可以优化为 c=bj

一个 BAD CASE，由于没有规范，曾经某个部门上报用户 ID，不同项目中重复埋点，上报了 4 次：

name=shenjian&user_id=123&uid=123&user_name=shenjian

而上述 name、user_id、uid、user_name 都属于重复上报。

痛点 4：上报频率高。

解决方案：先将数据保存到 APP 本地存储，再定时上报，这类优化对于 PV 类，SUM 类，AVG 类统计尤为有效。

例如，要统计登录按钮的点击次数，三次点击，传统统计可能需要上报三次：
daojia.com/up?date=201…
daojia.com/up?date=201…
daojia.com/up?date=201…

优化后，增加了一个参数，只需要上报一次：

daojia.com/up?date=201…

非实时上报，应该在什么时机进行日志上报呢？

如果进行合并上报，或者批量上报，数据的时效性会有一定的影响。

画外音：如果策略合理，数据误差会非常小。

为了优化，会在这样的一些时间点进行上报：
（1）特殊时间点上报：例如，APP 打开，关闭，后台转入活跃时；
（2）按时间批量上报：例如，每隔 10 分钟才上报一次；
（3）按数据量批量上报：例如，每收集 10 条记录才上报一次；

还有其他什么优化方案？
批量上报，数据压缩。

希望，文章的逻辑是清晰的。

架构师之路 - 分享通俗易懂的技术文章

调研：

贵司有埋点规范么？

不同项目出现过重复埋点么？

数据运营：如何搭建App的数据监控体系？

Sun, 24 May 2020 17:37:59 CST

精细化运营的核心是数据驱动增长，透过数据分析指引产品迭代和运营推广。因此，产品和运营需要掌握一定的数据运营能力，特别是需要搭建一套产品运营数据的监测体系来对日常运营效果进行复盘。本文介绍了搭建App数据监控体系的四大数据层次，与大家分享。

移动互联网进入到下半场，流量红利逐渐消失，互联网公司的竞争从增量用户的争夺转向存量用户的争夺。在这种环境下，精细化运营是每个互联网的必然选择。

区别于之前以采买流量为重点的运营模式，精细化运营的特点是针对产品和运营的每一个环节进行精心打磨，以最小的成本产出最大的价值，小到一个推广文案、大到一个业务流程，都要进行小心求证和持续优化，确保转化率达到最优解。

01 结果层

第一层是结果层，是指直接体现运营结果的数据，通常也是我们要定期向老板汇报的KPI数据。虽然不同行业的KPI会有所不同，比如电商产品会重点考核成交用户和成交额，但是归根结底都是围绕注册、活跃和付费转化3个核心，因此，我们的结果层数据一般包括：

KPI完成数：注册用户活跃用户付费用户
转化率：下载-注册转化率，注册-付费转化率，注册-活跃转化率
增长率：按日、周、月、季、年计算增长率
完成率：一般会将KPI分解到周、月、季和年，并定期计算完成率

02 运营层

第二层是运营层，是指反映运营问题的数据。运营方面，一般我们可以从以下3个方面进行分析：

1. 用户层面

可针对不同用户群体建立监控指标，常见的分群方法有按新老用户分群、按地区分群、按性别分群等，监控指标有留存率、转化率、活跃度等，比如新用户次日留存率、7日留存率和30日留存率；

根据用户分群进行数据监控的精髓在于，通过不同用户群的数据差异找到更精准的用户群体，以及针对不同用户群体找到差异化的营销策略。

2. 商品层面

针对不同品牌、不同sku建立监控指标，指标包含商品曝光、点击、加入购物车、下单、成交的数量、用户数和转化率，根据不同商品的对比和同一商品不同周期的对比可发现异常情况，从而找出商品定价、促销政策、排列规则或购物流程等方面的问题。

3. 渠道层面

针对不同推广渠道建立监控指标，比如按应用市场、按投放渠道。建立渠道的监控指标是为了监测渠道的推广效果，选择性价比最高的推广渠道。这里需要强调的是，渠道的效果监测一定要监测到付费用户的投入产出比，即在该渠道获取1个付费用户的成本是多少，这有这样才能判断渠道的性价比。

03 产品层

第三层是产品层，是指验证产品和反映产品问题的数据。针对产品的使用情况，我们可以重点监测以下3个方面的数据：

1. 新功能使用率

每次发布新版本后我们都应该观察新功能的使用情况，包括访问量、访问用户数、占全部访问用户数量的比率，平均停留时长、与其他功能访问时长的比较、用户转发该功能页面的数量/人数，以及和其他功能转发数据的对比，通过这些数据我们可以判断新功能的受欢迎程度，从而为下一次迭代做决策辅助。

2. 主要业务流程漏斗分析

不同的产品有不同的业务流程，我们要根据自身产品的业务流程建立转化漏斗，并定期观察漏斗转化率，及早发现异常情况。

最常见的业务流程转化漏斗有：

购买流程：首页-点击商品标题进入商品详情-点击购买按钮-提交订单-点击支付按钮-付款成功；
注册流程：首页-个人中心-点击注册-输入手机号码-获取验证码-输入验证码-提交-注册成功；
开户流程：首页-在线开户-输入手机号码-获取验证码-提交验证码-上传身份证照片-输入银行卡账号-提交

按上述方式将主要业务流程的每一个步骤列出，在每个节点进行埋点采集用户的访问和点击数据，即可计算每个环节的转化率。

通过长时间的数据监测即可发现数据异常，通过数据异常情况可反推可能在哪个环节出现问题，比如当点击购买按钮的用户数下降明显的时候有可能是商品的价格没有优势，这时候应对比竞品的价格策略。

3. 用户反馈数据

用户反馈数据也是运营需要统计和监测的运营数据，用户反馈数据与产品的崩溃日志相结合可反映产品线上的质量问题。

04 市场层

关注市场和竞品的数据一方面能使自己和公司管理层更客观的评价自身的运营情况，另一方面也能随时关注行业趋势帮助公司决策。一般可通过以下渠道收集行业数据：

竞品的财报：如果竞品已经上市，可以通过财报获取竞品的准确运营数据，通过炒股软件即可查询。

专业数据平台：易观、艾瑞有少数免费的行业报告，但是大部分需要付费；极光大数据有大量免费的行业数据，数据来源是装有极光sdk的APP产品，数据准确性参考度80%左右。

专业数据平台的不足之处是时效性不强，一般以季度和半年为时间周期发布，时效性不强。

百度和应用市场搜索热度：百度搜索热度和appstore的搜索热度可反映应用在前一天之前的用户搜索热度，搜索热度曲线约等于用户的增长曲线。

百度搜索热度大家应该比较熟悉，这里就不介绍，主要介绍一下Appstore搜索热度的查询方法：

登陆蝉大师、ASO100等ASO数据平台，输入关键词搜索会得出“搜索指数”的数据值，搜索指数就是这个关键词的搜索热度，指数越大热度越高。

boss直聘在Appstore的搜索热度曲线

需要注意的是，Appstore的搜索热度会受到ASO等运营手段的影响，因此要通过热度增长幅度、评论数有无爆发性增长等判断该时间段竞品是否由于ASO手段导致搜索热度大幅提升。

作者：Alien；公众号：运营记事本

本文由 @Alien 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议

百度APP-Android H5首屏优化实践

Sat, 17 Aug 2019 14:10:06 CST

一、背景

百度App自2016年上半年尝试Feed流业务形态，至2017年下半年，历经10个版本的迭代，基本完成了产品形态的初步探索。在整个Feed流形态的闭环中，新闻详情页（文中称为落地页）作为重要的组成部分，如果打开页面后，loading时间过长，会严重影响用户体验。因此我们针对落地页这种H5的首屏展现速度进行了长期优化，本文会详细阐述整个优化思路和技术细节

二、方法论

通过分析用户反馈，发现当时的落地页从点击到首屏展现平均需要3s的时间，每次用户兴致勃勃的想要浏览感兴趣的文章时，却因为过长的loading时间，而不耐烦的选择了back。为了提升用户体验，我们进行了以下工作：

通过用户反馈、QA测试等多种渠道，发现落地页首屏加载慢问题
定义首屏性能指标（首屏含图，以图片加载为准；首屏无图，以文字渲染结束为准）
NA、内核、H5三方针对自己加载H5的流程进行划分并埋点上报
统计侧根据三端上报的数据产出平均值、80分位值的性能报表
分析性能报表，找到不合理的耗时点，并进行优化
以AB实验方式，对比优化前后的性能报表数据，产出优化效果，同时评估用户体验等相关指标
按照长期优化的方式，不断分析定位性能瓶颈点并优化，以AB实验方式评估效果，最终达到我们的落地页秒开目标

三、Hybrid方案简述及性能瓶颈

（一）方案简述
优化之前，我们与业内大多数的App一样，在落地页的技术选型中，为了满足跨平台和动态性的要求，采用了Hybrid这种比较成熟的方案。Hybrid，顾名思义，即混合开发，也就是半原生半Web的方式。页面中的复杂交互功能采用端能力的方式，调用原生API来实现。成本低，灵活性较好，适合偏信息展示类的H5场景。
下面用一张图来表示百度App中Hybrid的实现机制和加载流程

（二）性能瓶颈
为了分析Hybrid方案首屏展现较慢的原因，找到具体的性能瓶颈，客户端和前端分别针对各自加载过程中的关键节点进行埋点统计，并借由性能监控平台日志进行展示，下图是截取的某一天全网用户的落地页首屏展现速度80分位数据

各阶段性能点可以按Hybrid加载流程进行划分，可以看到，从点击到首屏展现，大致需要2600ms，其中初始化NA组件需要350ms，Hybrid初始化需要170ms，前端H5执行JS获取正文并渲染需要1400ms，完成图片加载和渲染需要700ms的时间
我们具体分析下四个阶段的性能损耗主要发生在哪些地方：
1) 初始化NA组件
从点击到落地页框架初始化完成，主要工作为初始化WebView，尤其是第一次进入（WebView首次创建耗时均值为500ms）
2) Hybrid初始化
这个阶段的工作主要包含两部分，一个是根据调起协议中传入的相关参数，校验解压下发到本地的Hybrid模板，大致需要100ms的时间；此外，WebView.loadUrl执行后，会触发对Hybrid模板头部和Body的解析
3) 正文加载&渲染
执行到这个阶段，内核已经完成了对Hybrid模板头部和body的解析，此时需要加载解析页面所需的JS文件，并通过JS调用端能力发起对正文数据的请求，客户端从Server拿到数据后，用JsCallback的方式回传给前端，前端需要对客户端传来的JSON格式的正文数据进行解析，并构造DOM结构，进而触发内核的渲染流程；此过程中，涉及到对JS的请求，加载、解析、执行等一系列步骤，并且存在端能力调用、JSON解析、构造DOM等操作，较为耗时
4) 图片加载
第（3）步中，前端获取到的正文数据包含落地页的图片地址集，在完成正文的渲染后，需要前端再次执行图片请求的端能力，客户端这边接收到图片地址集后按顺序请求服务器，完成下载后，客户端会调用一次IO将文件写入缓存，同时将对应图片的本地地址回传给前端，最终通过内核再发起一次IO操作获取到图片数据流，进行渲染；总体来看，图片渲染的时间依赖前端的解析效率、端能力执行效率、下载速度、IO速度等因素
通过分析，延伸出对Hybrid方案的一些思考：

渲染为什么这么慢
图片请求能否提前
串行逻辑是否可以改为并行
WebView初始化时间是否还可以优化

四、百度App落地页优化方案

（一）CloudHybrid
基于之前对Hybrid性能的分析，我们内部孵化了一个叫做CloudHybrid的项目，用来解决落地页首屏展现慢的痛点；一句话来形容CloudHybrid方案，就是采用后端直出+预取+拦截的方式，简化页面渲染流程，提前化&并行化网络请求逻辑，进而提升H5首屏速度

1.后端直出-快速渲染首屏
a. 页面静态直出
对于Hybrid方案来说，端上预置和加载的html文件只是一个模板文件，内部包含一些简单的JS和CSS文件，端上加载HTML后，需要执行JS通过端能力从Server异步请求正文数据，得到数据后，还需要解析JSON，构造DOM，应用CSS样式等一系列耗时的步骤，最终才能由内核进行渲染上屏；为了提升首屏展示速度，可以利用后端渲染技术(smarty)对正文数据和前端代码进行整合，直出首屏内容，直出后的html文件包含首屏展现所需的内容和样式，内核可以直接渲染；首屏外的内容（包括相关推荐、广告等）可以在内核渲染完首屏后，执行JS，并利用preact进行异步渲染

百度APP直出方案：

对于客户端来说，从CDN中拉取到的html都是已经在server渲染好首屏的，这样的内容无需二次加工，展现速度可以大大提升，仅直出一点，手百Feed落地页的首屏性能数据就从2600ms优化到2000ms以内
b. 动态信息回填
为了保证首屏渲染结果的准确性，除了在server侧对正文内容和前端代码进行整合外，还需要一些影响页面渲染的客户端状态信息，例如首图地址、字体大小、夜间模式等
这里我们采用动态回填的方式，前端会在直出的html中定义一系列特殊字符，用来占位；客户端在loadUrl之前，会利用正则匹配的方式，查找这些占位字符，并按照协议映射成端信息；经过客户端回填处理后的html内容，已经具备了展现首屏的所有条件
c. 动画间渲染
先看下优化前后效果（上图：优化前；下图：优化后）：

正常来说，直出后的页面展现速度已经很快了；但在实际开发中，你可能会遇到即使自己的数据加载速度再快，仍然会出现Activity切换过程中无法渲染H5页面的问题（可以通过开发者模式放慢动画时间来验证），产生视觉上的白屏现象（如上面上图）
我们通过研究源码发现，系统处理view绘制的时候，有一个属性setDrawDuringWindowsAnimating，从命名可以看出来，这个属性是用来控制window做动画的过程中是否可以正常绘制，而恰好在Android 4.2到Android N之间，系统为了组件切换的流程性考虑，该字段为false，我们可以利用反射的方式去手动修改这个属性，改进后的效果见上面下图

  
/**
     * 让 activity transition 动画过程中可以正常渲染页面
     */
    private void setDrawDuringWindowsAnimating(View view) {
        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.M
                || Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
            // 1 android n以上  & android 4.1以下不存在此问题，无须处理
            return;
        }
        // 4.2不存在setDrawDuringWindowsAnimating，需要特殊处理
        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
            handleDispatchDoneAnimating(view);
            return;
        }
        try {
            // 4.3及以上，反射setDrawDuringWindowsAnimating来实现动画过程中渲染
            ViewParent rootParent = view.getRootView().getParent();
            Method method = rootParent.getClass()
                    .getDeclaredMethod("setDrawDuringWindowsAnimating", boolean.class);
            method.setAccessible(true);
            method.invoke(rootParent, true);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    /**
     * android4.2可以反射handleDispatchDoneAnimating来解决
     */
    private void handleDispatchDoneAnimating(View paramView) {
        try {
            ViewParent localViewParent = paramView.getRootView().getParent();
            Class localClass = localViewParent.getClass();
            Method localMethod = localClass.getDeclaredMethod("handleDispatchDoneAnimating");
            localMethod.setAccessible(true);
            localMethod.invoke(localViewParent);
        } catch (Exception localException) {
            localException.printStackTrace();
        }
    }

2.智能预取-提前化网络请求
经过直出的改造之后，为了更快的渲染首屏，减少过程中涉及到的网络请求耗时，我们可以按照一定的策略和时机，提前从CDN中请求部分落地页html，缓存到本地，这样当用户点击查看新闻时，只需从缓存中加载即可

手百预取服务架构图

目前手百预取服务支撑着图文、图集、视频、广告等多个业务方，根据业务场景的不同，触发时机可以自定义，也可以遵循我们默认的刷新、滑停、点击等时机，此外，我们会对预取内容进行优先级排序（根据资源类型、触发时机），会动态的根据当前手机状态信息进行并发控制和流量控制，在一些降级场景中，server还可以通过云控的方式来控制是否预取以及预取的数量
3.通用拦截-缓存共享、请求并行
在落地页中，除了文本外，图片也是重要的组成部分。直出解决了文字展现的速度问题，但图片的加载渲染速度仍不理想，尤其是首屏中带有图片的文章，其首图的渲染速度才是真正的首屏时间点
传统Hybrid方案，前端页面通过端能力调用NA图片下载能力来缓存和渲染图片，虽然实现了客户端和前端图片缓存的共享，但由于JS执行时机较晚，且多次端能力调用存在效率问题，导致图片渲染延后

初步改进方案：为了提升图片加载速度，减少JS调用耗时，改为纯H5请求图片，速度虽然有所提升，但是客户端和前端缓存无法共享，当点击图片调起NA图片查看器时，无法做到沉浸式效果，且仍需重复下载一次图片，造成流量浪费
终极方案：借由内核的shouldInterceptRequest回调，拦截落地页图片请求，由客户端调用NA图片下载框架进行下载，并以管道方式填充到内核的WebResourceResponse中

此方案在满足图片渲染速度的同时，解耦了客户端和前端代码，客户端充当server角色，对图片进行请求和缓存控制，保证前端和客户端可以共用图片缓存，改造后的方案，非首图展现流程，页面不卡顿，首屏80分位值缩短80ms~150ms
效果如下（上图：优化前Hybrid方案；下图：优化后通用拦截方案）：

4.整体方案流程

（二）新的优化尝试
1.WebView预创建
为了节省WebView的性能损耗，我们可以在合适时机提前创建好WebView，并存入缓存池，当页面需要显示内容时，直接从缓存池获取创建好的WebView，根据性能数据显示，WebView预创建可以提升首屏渲染时间200ms+

具体以Feed落地页为例，当用户进入手百并触发Feed吸顶操作后，我们会创建第一个WebView，当用户进入落地页后，会从缓存池中取出来渲染H5页面，为了不影响页面的加载速度，同时保证下次进入落地页缓存池中仍然有可用的WebView组件，我们会在每次页面加载完成（pageFinish）或者back退出落地页的时机，去触发预创建WebView的逻辑
由于WebView的初始化需要和context进行绑定，若想实现预创建的逻辑，需要保证context的一致性，常规做法我们考虑可以用fragment来实现承载H5页面的容器，这样context可以用外层的activity实例，但Fragment本身的切换流畅度存在一定问题，并且这样做限定了WebView预创建适用的场景。为此，我们找到了一种更加完美的替代方案，即MutableContextWrapper

Special version of ContextWrapper that allows the base context to be modified after it is initially set. Change the base context for this ContextWrapper. All calls will then be delegated to the base context. Unlike ContextWrapper, the base context can be changed even after one is already set.
简单来说，就是一种新的context包装类，允许外部修改它的baseContext，并且所有ContextWrapper调用的方法都会代理到baseContext来执行

下面是截取的一段预创建WebView的代码

  /**
     * 创建WebView实例
     * 用了applicationContext
     */
    @DebugTrace
    public void prepareNewWebView() {
        if (mCachedWebViewStack.size() < CACHED_WEBVIEW_MAX_NUM) {
            mCachedWebViewStack.push(new WebView(new MutableContextWrapper(getAppContext())));
        }
    }
    /**
     * 从缓存池中获取合适的WebView
     * 
     * @param context activity context
     * @return WebView
     */
    private WebView acquireWebViewInternal(Context context) {
        // 为空，直接返回新实例
        if (mCachedWebViewStack == null || mCachedWebViewStack.isEmpty()) {
            return new WebView(context);
        }
        WebView webView = mCachedWebViewStack.pop();
        // webView不为空，则开始使用预创建的WebView,并且替换Context
        MutableContextWrapper contextWrapper = (MutableContextWrapper) webView.getContext();
        contextWrapper.setBaseContext(context);
        return webView;
    }

2.NA组件懒加载
a. WebView初始化完成，立刻loadUrl，无需等待框架onCreate或者OnResume结束
b. WebView初始完成后到页面首屏绘制完成之间，尽量减少UI线程的其他操作，繁忙的UI线程会拖慢WebView.loadUrl的速度

具体到Feed落地页场景，由于我们的落地页包含两部分，WebView+NA评论组件，正常流程会在WebView初始化结束后，开始评论组件的初始化及评论数据的获取。由于此时评论的初始化仍处在onCreate的UI消息处理中，会严重延迟内核加载主文档的逻辑。考虑到用户进入落地页的时候，评论组件对用户来说并不可见，所以将评论组件的初始化延迟到页面的pageFinish时机或者firstScreenPaintFinished； 80分位性能提升60ms~100ms

3.内核优化
a. 内核渲染优化：
内核中主要分为三个线程（IOThread、MainThread、ParserThread），首先IOThread会从网络端或者本地获取html数据，并把数据交给MainThread（渲染线程，十分繁忙，用于JS执行，页面布局等），为了保证MainThread不被阻塞，需要额外起一个后台线程（ParserThread）用来做html的解析工作。ParserThread每解析到落地页html中带有特殊class标记的一个div标签或者P标签（图中的first、second）时，就会触发一次MainThread的layout工作，并把layout后得到的高度与屏幕高度进行对比，如果当前layout高度已经大于屏幕高度，我们认为首屏内容已经完成布局，可以触发渲染上屏逻辑，不必等到整篇html全部解析完成再上屏，提前了首屏的渲染时间； 80分位下，内核的渲染优化可以提升首屏速度100ms~200ms

b. 预加载JS：
预创建好WebView后，通过预加载JS（与内核约定好的JS内容，内核侧执行该JS时，只做初始化操作），触发WebView初始化逻辑，缩短后续加载url耗时； 80分位性能提升80ms左右

五、新的问题-流量和速度的平衡

频繁预取会带来流量的浪费：预取的命中率虽然达到了90%以上，但有效率仅有15%
解决思路：
&nbsp&nbsp1.压缩预取的包大小，减少下行流量
&nbsp&nbsp2.少预取或者不预取
（一）精简预取数据：
图文：优化直出html中内联的css、icon等数据，数据大小减少约40%
（二）后端智能预取：
1) 图文：通过对图文资源进行评分，来决定4G是否需要预取，多组AB试验最优效果劣化9.5ms
2)视频：为了平衡性能和流量，在性能劣化可接受的范围内（视频起播时间劣化100ms），针对视频部分采用流量高峰期不预取的策略，减少视频总流量约7%，整体带宽峰值下降3%
（三）AI智能预取
通用用户操作行为，对Feed预取进行AI预测，减少无效预取的数量。

六、总结&展望

（一）优化总结
在总结之前，先来看下整体优化的前后效果对比（上图：优化前；下图：优化后）：

可以看到，经过一系列的优化手段，落地页已经实现了秒开效果。回顾所做的事情，从分析用户反馈到定位性能瓶颈，再到各种优化尝试，发现所有类似的性能优化手段都可以从以下几点入手：

提前做：包括预创建WebView和预取数据
并行做：包括图片直出&拦截加载，框架初始化阶段开启异步线程准备数据等
轻量化：对于前端来说，要尽量减少页面大小，删减不必要的JS和CSS，不仅可以缩短网络请求时间，还能提升内核解析时间
简单化：对于简单的信息展示页面，对内容动态性要求不高的场景，可以考虑使用直出替代hybrid，展示内容直接可渲染，无需JS异步加载

（二）TODO

页面的更新机制，目前方案仅适用于偏静态页面，对于动态性要求较高的业务，需要提供页面更新机制，保证每次显示的正确性
开源之路：后续计划将我们总结下来的这套方案打包开源，前行之路必定坎坷，希望大家多多支持

12306崩了：App无法购票

Fri, 02 Aug 2019 20:35:10 CST

IT之家8月2日消息据不少网友反映，今天下午12306 App出现故障，无法完成购票，话题#12306崩了#也登上微博热搜榜。

据网友反映，登录、查票什么的还是正常的，但无法支付，也有网友称可以登录12306官网支付。

值得一提的是，今年6月19日，12306 App和12306网站网页端就曾出现了无法访问的问题。

来自中国国家铁路集团有限公司的统计显示，系统年售票量已超过31亿张，日售票能力达到1500万张，高峰时每秒售票量达700张，网页浏览量超过1500亿次/天。互联网售票占铁路售票总量的82.8%，12306已经成为世界上规模最大的实时票务交易系统。

这一次谷歌很强硬，App 再不支持，两个月后将拒绝上架

Sat, 08 Jun 2019 00:00:00 CST

一. 序

事情是这样的，前几天收到 Google Play 的通知邮件，这才想起来有几款在 Google Play 上架的 App，还没有支持 64 位 CPU 架构。

早在今年一月份，Google 就发布通知，在今年 8 月 1 日开始，上架的 App，除了提供 32 位的版本之外，还需要提供 64 位的版本。

这眼看着离强制升级窗口，只剩下最后两个月的时间，很多第三放来源的 so 支持库，如果没有提供 64 位的版本，还需要同步催促合作方更新。

那今天就来聊聊 Android APK 升级 64 位 CUP 架构的细节，看看你的应用是否需要支持 64 位 CPU 架构，如果要支持，需要做什么？

二. Android CPU 架构细节

2.1 这是强制规范

早在 2015 年 Google 发布 Android 5.0 版本时，就加入了 64 位处理器的支持，当时就提出了以 19 年 8 月为最后的更新支持期限，并在今年又重申了这个强制要求。

只要你的 App 存在国际版，需要上架 Google Play，这个规定都必须准守。

2.2 那些 APK 需要支持 64 位？

那假如你有一个国际化的 App 需要维护，在今年 8 月 1 日之后，更新 Google Play 时，就必须提供 64 位的版本。

那这里说的 64 位版本支持，到底是什么？

如果你的应用，完全是使用 Java 或者 Kotlin 编写代码，不包含任何原生（Native）的支持，那么就表示这个应用已经支持 64 位。

但是应用内使用了任何原生（Native）的支持（so 库），就需要针对这些 so 文件，针对不同的 CPU 架构提供不同的版本的 so 支持。

需要注意的是，有些时候，在我们自身的代码中，确实没有用到原生的支持，但是在 App 中使用的一些第三方库中却包含了。

此时最稳妥的方式，就是针对最终打包生成的 APK 文件进行分析，来判断是否需要提供 64 位架构的支持。

那 CPU 架构是什么？什么又是 ABIs？

在 Android 中，虽然 ARM 的 CPU 架构是主流，但是目前至少支持几类 CPU 架构，ARM 下的 ARMv5/ARMv7/ARMv8，x86 下的 x86/x86_64，以及很不常见的 MIPS 类架构。这里的每一种 CPU 类型对应了一种 API（Application Binary Interface），例如 armeabi-v7a 中的 "armeabi" 指的就是 ARM 这种类型的 ABI，后面的 “v7a” 指的是 ARMv7。

通常我们可以简单的理解：

这三个概念是相通的，通常在技术讨论中，说的是一个东西。

2.3 为什么是强制的？

谷歌之所以会有强制更新的要求，很大一方面原因是因为作为开发者，更新补全 ABIs 的动力并不足。

主要原因来自以下几个方面：

1. APK 体积增大

针对不同 CPU 架构提供对应的 so 库，当然是效率最高的做法。但是这种做法，最直接的影响，就是 APK 文件的增大，有些时候补全这些 so 支持，会导致整个 APK 体积有几 MB 到几十 MB 的增幅。

APK 体积优化，很多公司都将其算做是一个 API 指标，加入一个新特性，导致 APK 体积的增大，在很多时候都是不允许的，为此换技术方案都是常有的事。

从增长的角度来看，越小的 APK，用户下载的意愿就更大，转化率就越高。

但是随着现在流量越来越便宜，近期 iOS 已经将蜂窝数据下载限制从 150MB 放宽至 200MB，针对安装包的体积优化标准，也可以适当的放宽了。

2. 本身有一定的兼容性

应用市场中，很多 APP 其实都只有 armeabi 或者 armeabi-v7a 的支持，而市面上的设备，支持的并不是只有这两种 CPU 架构。

但是这并没有影响在这些设备上运行这些 App，这就是 CPU 架构的兼容性。

不同架构，并不意味着之间一定是不兼容的，在不同版本下，其实提供了两种 ABI 支持，分别是

主要 ABI：与系统本身使用的原生代码一样，最优方案。
辅助 ABI：支持的另一个 ABI 方案，兼容方案。

这种兼容策略就不在这里展开说了，最简单的就是 64 位的 arm64-v8a 在支持本身的 CPU 架构之外，还兼容支持 armeabi-v7a、armeabi；x86_64 同时也兼容支持 X86 和 armeabi。

你看，虽然添加 64 位的支持，可以有效的使用硬件的优势，提升性能，但大部分时候，采用兼容方案，是一种更简单的方式。

3. 没有对应架构的 so 文件

这个原因就比较尴尬了，我们 App 中使用到的原生代码，其实有两种。

一种是我们自己编写的，源码在手，想提供对应的支持，修改配置重新编译一下就解决了。

另一种来自第三方提供的，这种时候我们没有源码，无法做到重新编译，只能和第三方沟通，看能不能提供一个对应 CPU 架构的 so 库。这种情况就非常的不可控了。

例如比较常见的一个 WebView 的替换方案，腾讯 X5 内核，本身就不提供 X86 的库。

官方给的建议是使用 armeabi 或者 armeabi-v7a。

在前文有提到，ABIs 本身是有一些兼容规则的，但是这种兼容规则，是有条件的。

举个例子：64 位的 arm64-v8a 是可以向下兼容的，但是这有个前提，那就是如果你的项目中，有 armeabi-v7a 和 arm64-v8a 两个目录，就需要保证这两个目录下支持的 so 库文件保持一致。

在左边的情况下，如果 arm64-v8a 的手机用到 b.so 时，就会去 arm64-v8a 目录下找，当然是找不到 b.so 文件的，就会直接抛异常，而不会再去 armeabi-v7a 目录下继续寻找。

如果需要提供多套 ABIs 的支持，就需要保证所有 ABI 目录下，对应的 so 文件保持一致。

而在一些特殊的情况下，我们无法提供对应平台的 so 库，例如腾讯 X5 内核这种情况，就需要做个取舍了。

在没有 Google Play 的强制策略下，同时又因为各方考虑，大多数时候我们可能会舍弃其他 ABIs 的支持。但是现在既然强制执行了，腾讯 X5 内核就可能升级以提供 64 位的 so 库，毕竟一边是无法上架，另外一遍是一个 WebView 的内核，谁都知道怎么取舍。

三、支持 64 位架构

3.1 是否包含 64 位库？

介绍了 Android 下 CPU 架构的一些细节，接下来就要开始正题了，如何升级并支持 64 位架构。

从前文中应该了解到，支持对应的 ABIs，反映在项目中，就是存在对应 ABIs 架构的目录，并且目录中有完备的 so 库支持。

Google 并不要求我们支持所有的 64 位架构，但是对于已经支持的每种原生 32 位架构，就必须包含对应的 64 位架构。

例如：

对于 ARM 架构，有 armeabi-v7a（32位）就必须 arm64-v8a（64位）。
对于 x86 架构，有 x86（32位）就必须有 x86_64（64位）

这就要求我们有对应的目录，并且目录中包含对应的 so 文件。APK 中提供了完备的 ABIs 支持，运行的之后，会选取对应的最优支持进行加载和使用。

需要注意的是，有时候我们将 32 位的 so 复制到 64 位中，运行不会出现异常，但是这依然存在隐患。最好的办法是根据不同的架构，编译对应的 so 文件，原则上，我们的目标是确保应用可以在仅支持 64 位架构的环境中正常运行。

3.2 判断是否支持 64 位架构

前面也提到，我们的项目中，可能会引入一些第三方库，导致在不明确的情况下，引入了一些预期之外的 ABIs 库。

通常我们的做法是在 Gradle 中增加 abiFilters 过滤，来确保不会在打包输出的 APK 中存在预期之外的 ABIs 目录和 so 库。

  ndk {   
    //设置支持的SO库架构   
    abiFilters 'armeabi-v7a'    
}

那么我们拿最终打包输出的 APK 文件去分析，是最稳妥的办法。

分析的方法有两种：

1. AS 的 APK 分析器

在 Android Studio 中，从菜单依次选择 Build → Analyze APK…

选择需要分析的 APK 文件，查看其 lib 目录，是否存在预期的 ABIs 目录以及完备的 so 文件。

2. 使用 zipinfo 命令进行分析

得到待分析的 APK 文件，就可以通过 zipinfo + grep 命令，输出其内包含的 so 文件。

  > zipinfo -1 YOUR_APK_FILE.apk | grep \.so$   
    lib/armeabi-v7a/libmain.so   
    lib/armeabi-v7a/libmono.so   
    lib/armeabi-v7a/libunity.so   
    lib/arm64-v8a/libmain.so   
    lib/arm64-v8a/libmono.so   
    lib/arm64-v8a/libunity.so

依然是去看对应目录和 so 文件是否完备。

3.3 在 64 位设备上测试应用

支持 64 位架构是为了让我们利用 CPU 的特性，以提升性能，但是稳定依然是我们首先要保证的，所以在升级之后，就需要进行测试。

要测试 App，最简单的方式是使用 adb 命令安装该应用，可以配合 --abi参数，用以指示要将那些 so 库，安装到设备上，这样我们在这个设备上安装的 App，就会仅包含我们制定的库。

  # 成功安装 APK :   
> adb install --abi armeabi-v7a YOUR_APK_FILE.apk   
Success   
   
# 如果 APK 中不包含 64 位 so 文件:   
> adb install --abi arm64-v8a YOUR_APK_FILE.apk   
adb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]   
   
# 如果你的设备（手机）不支持 64 位架构   
> adb install --abi arm64-v8a YOUR_APK_FILE.apk   
ABI arm64-v8a not supported on this device

去年上市的手机，大部分都是 64 位架构的，找一款来测试即可。

3.4 分包处理

如果我们的应用只需要在国内分发，当前的策略对我们并不影响，保持原样就好了。但是如果存在国际版，需要上架 Google Play 就一定要重视此次升级。

在 Google Play 上传 APK，是可以根据 CPU 架构上传不同的 APK 的，也就是我们可以针对 32 位上传一个 APK，再上传一个 64 位的 APK。

此时就需要用到 Gradle 的打包技巧了，分别输出几个仅包含对应平台的 APK，以此完成 Google Play 的要求，分别上传 32 位的支持 APK 和 64 位的支持 APK，这样能够 APK 文件不至于增大很多。

  android {   
    ...    
    splits {   
        abi {   
            enable true   
            reset()   
            include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a' //select ABIs to build APKs for   
            universalApk true //generate an additional APK that contains all the ABIs   
        }   
    }   
    // map for the version code   
    project.ext.versionCodes = ['armeabi': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3, 'mips': 5, 'mips64': 6, 'x86': 8, 'x86_64': 9]   
   
    android.applicationVariants.all { variant ->   
        // assign different version code for each output   
        variant.outputs.each { output ->   
            output.versionCodeOverride =   
                    project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 + android.defaultConfig.versionCode   
        }   
    }   
 }

这里利用 Gradle 的 splite 配置，有兴趣可以直接查阅文档，就不展开讲了。

四. 小结时刻

在本文中，我们借此次 Google Play 的强制支持 64 位架构的事情，讲解了 Android 下 so 库的一些兼容问题。

如果你在 Google Play 上有应用需要更新，别忘了提前准备需要的 so 库，大多数原生支持的第三方库，在此之前其实都已经提供了对应的 64 位架构。我们只需要在最终日期之前，仔细的进行增加 so 文件，以达到适配的效果。

更新完成之后，别忘了测试，本文就到这里，你有什么更新的见解，欢迎在留言区讨论。

本文对你有帮助吗？ 留言、转发、点好看是最大的支持，谢谢！

reference：https://developer.android.com/distribute/best-practices/develop/64-bit

「联机圆桌」推荐我的知识星球，一年 50 个优质问题，上桌联机学习。

公众号后台回复成长『成长』，将会得到我准备的学习资料，也能回复『加群』，一起学习进步；你还能回复『提问』，向我发起提问。

关于手机App的Https抓包

Fri, 31 May 2019 16:14:34 CST

我喜欢用 Mitmproxy 来处理手机 App 抓包之类的工作，本来用它来抓 Https 包是很容易的一件事，只要设置好代理，浏览 mitm.it 按提示安装证书即可，可是当 Android 版本升级到 7 以后，此方法就失效了，为什么呢？因为新版 Android 缺省情况下只信任系统级证书，而不再信任用户级证书，问题详细描述可以参考：听说安卓微信 7.0 不能抓 https?

普通的解决方法有很多，比如说用低版本的 Android 手机，或者干脆换个苹果手机。不过那些治标不治本的方法并不是本文关注的重点，本文我们主要聊聊如何通过 root 来解决问题，但是 root 本身是有风险的，所以下面有请重量级嘉宾网易 MuMu 闪亮登场！它是一个有 root 权限的全功能 Android 模拟器。

mumu

网易 MuMu 使用起来很简单，不过你需要注意实际抓包的时候，你需要设置模拟器的网络连接走相应的代理，设置的方法是找到对应的网络连接「长按」即可：

网络连接

因为我是用 Mitmproxy 来抓包的，所以要安装的也是 Mitmproxy 的证书。下面看看如何把 Mitmproxy 证书安装到网易 MuMu 里，记得安装相关工具，以 Mac 操作系统为例：

shell> brew install mitmproxy
shell> brew install Caskroom/cask/android-platform-tools

安装好工具之后，别忘了启动网易 MuMu，然后通过 android-platform-tools 中的 adb 命令来连接它，只需要简单执行「adb shell」即可，如果遇到连不上的情况，可以参考文档。连接成功后，你可以在「/system/etc/security/cacerts/」目录看到现有的系统级证书：

证书

换句话说，我们只要把 Mitmproxy 证书安装到这里即可。不过这些证书的文件名都是啥意思，实际上他们就是证书文件的散列值，那 Mitmproxy 证书在哪？如何计算它的散列值？其实当我们安装好 Mitmproxy 的时候，相应的证书就已经保存在「~/.mitmproxy」目录里了，下面看看如何计算证书的散列值：

shell> openssl x509 \
    -subject_hash_old \
    -inform PEM \
    -in ~/.mitmproxy/mitmproxy-ca-cert.pem | head -1

c8750f0d

接下来我们把 Mitmproxy 证书推送到模拟器系统证书所在目录：

shell> adb push \
    ~/.mitmproxy/mitmproxy-ca-cert.pem \
    /system/etc/security/cacerts/c8750f0d.0

最后在模拟器「设置 / 安全 / 信任的凭据 / 系统」里就能看到 Mitmproxy 证书了：

系统证书

通过 root 安装系统证书可以解决大部分 Https 抓包问题，为什么是大部分？还有哪些特殊情况不能处理？答案是「 SSL Pinning」，它是为了应对中间人攻击而出现的一种技术，简单点说，就是证书被打包到 App 里，每次请求都会验证证书一致性。如此一来，虽然我们可以安装系统级证书，但是当 App 验证证书一致性的时候就失败了，如何突破此限制呢？答案很简单，你不是要验证一致性么，我统统返回 OK 不就行了！

为了达到 hack 的目的，我们需要安装 Xposed 和 JustTrustMe，其中 Xposed 是一个 hack 框架，JustTrustMe 是一个插件。安装过程并不复杂，唯一需要说明的是，在安装 Xposed 之前，最好在网易 MuMu 中关闭兼容模式，路径「设置 / 应用兼容性 / 兼容模式」。

Xposed

JustTrustMe

如果你认认真真从头看到尾，那么恭喜你，关于手机 App 的 Https 抓包，你已经是专家了，最后你摸着自己的良心扪心自问一下：是不是应该给作者一个大大的红包！

APP平台如何实现客户支付宝支付和微信支付将货款直接支付给商家，并实现平台抽佣？ - 知乎

Wed, 03 Apr 2019 09:44:39 CST

我理解题主指的APP平台不只是APP，还包括B2B的商城管理系统，以实现商家入驻对管理上架商品。
如果是这样，那么两种模式都可以支持。
最核心的问题是：B2B的商城管理系统是否支持商家配置自己的微信支付/支付宝的商户号、支付密钥等信息，商家是否愿意把支付密钥等私密信息配置到一个第三方平台（类似很多微信商城管理系统的做法）。

1、模式1
如果APP支持商家通过商城管理系统配置自己的商户号、支付密钥等信息，用户购买商品时候商城平台使用对应商户的商户号、支付密钥发起支付请求，微信支付/支付宝直接将资金结算给商家对公户，资金不过平台。
由于平台本身有订单信息，因此可以根据对应的订单信息计算出对应的佣金，与商户对账后，由商家把佣金通过企业网银、第三方支付代付等方式转账给平台。

2、模式2
此种模式比较典型，也是美团、饿了么之类的互联网电商平台的通用做法。
此种模式下，用户购买商品时，发起支付请求使用的商户号、支付密钥是平台的，微信支付/支付宝将资金结算给平台对公户，然后由平台按照结算周期将资金结算给商户。

题主后面的问题是结算款项代付问题。
代付的方式有很多，依赖于诸多因素，例如：
1、代付渠道：例如个人网银、超级网银、结算中心、央行大小额、银企直连等
2、本行/跨行
3、对公/对私
4、代付金额：大于5万，小于五万等等
5、时效性：实时、2小时、次日到账
6、单笔/批量
以上各种因素都会影响代付的成本，可以根据自己需要对比选择合适的方案。

作者：梁川

两种方式都是可行的。
第一种方式是平台不碰资金，由有清算拍照的公司第三方支付公司或者银行直接清算给商户，这种模式其实更合规。回到题主关于平台分润的问题，如果平台的资质和开发能力足够，平台可以成为微信的受理商，由平台也就是受理商向微信报商户，每个商户会拿到微信返回的发起交易的参数，商户的交易需要带着这些参数去请求，这样平台就可以拿到分润，但也要记录下每笔交易，做好交易对账的工作。如果平台的资质不够，或者不想承担这些开发工作，那么平台可以去找聚合支付公司，由他们牵线，把你们接入到类似广州兴业这样的银行，平台把商户报给银行，对接银行包装过的微信APP支付接口，银行一样会返回你支付参数，带着参数向微信发起交易就可以了，这种方式平台的工作量很少，甚至可以让商户用银行的系统查交易和对账，资金由消费者到微信到银行到商户。

第二种方式平台是要碰资金的，本质是二清，资金是消费者到微信到平台到商户。这种二清模式现在抓的严，但不是不能做。对平台自身的开发能力要求也高一些。

作者：Zark

手机 APP 应该选用哪个加密算法 - 兼吐槽 TEA

Wed, 27 Mar 2019 21:16:21 CST

标签： TEA 加密

很多 APP 产品都有通信加密的需求，一部分出于市场的要求，比如苹果对于“ATS”的强制性规定，一部分出于自身安全的考虑，比如对账号和密码的保护。这些需求大部分都可以用简单的 HTTP -> HTTPS 升级来搞定，而且几乎不用付出什么成本（除加解密的计算开支外），例如使用我之前文章介绍到的 Let's Encrypt 免费证书。

但还有一类特殊的需求，HTTPS 解决不了，也就是 防协议分析的需求。很多 APP 开发者应该知道，只要在手机里安装一个代理 CA 证书，就可以实现中间人攻击，通过代理软件抓到 HTTPS 包的明文内容。虽然这样的攻击很难在公开网络上进行，但对自己的手机进行抓包分析，作为 APP 和服务端通信的调试手段是被广泛使用的。

协议分析能做什么呢？可以猜想到一定的 APP 内部逻辑，可以对产品数据进行作弊攻击。举个例子：你的 APP 通过某个渠道进行推广，为了统计渠道安装、注册或者日活，你往往会在 APP 中埋一个点，当 APP 启动时，发送一些信息到服务器。如果这个协议被破解了，渠道商根本不需要真正进行推广，只需要构造一些假消息发送到你的服务器就行了。仅看数据你可能会以为这个渠道推广效果特别好，其实只是骗局而已。

这类情况下，就要求 对敏感协议内容进行额外的数据保护。最常用的做法，就是对协议内容进行一次额外的加密，为了性能，往往选用对称加密算法。那么问题来了，手机 APP 开发时，应该选用哪个加密算法？

关于这个选型， 国内互联网圈有个怪现状值得谈一下，那就是 TEA 算法。因为该算法在腾讯有着广泛的应用，因而被很多客户端开发人员推崇。典型推荐理由往往是：“TEA加密算法不但比较简单，而且有 很强的抗差分分析能力，加密 速度也比较快，还可以根据需求 设置加密轮数来增加加密强度”。 这是真的吗？算法安全性可以直接看维基百科上 TEA 算法的介绍，我的理解是不够安全。但其实大部分用户也不那么地在乎它的安全强度，那么性能呢？加密速度真的很快吗？

这就要从历史的角度去看了。作为曾经手撸过 “ DES 差分密码攻击” 代码的程序员，表示 TEA 算法的确足够简单。在 QQ 诞生的那个年代，TEA 在计算上的确有着不小的优势。但 QQ 已经 18 岁了啊同学们，18 年来中国发生了多大的变化，世界发生了多大的变化啊！

2008 年，Intel 就发布了 x86 的 AES 指令集扩展，近几年的服务器 CPU 应该都支持，不相信你
grep aes /proc/cpuinfo 就能看到；2011 年 ARM 也在 ARMv8 架构下直接提供了 AES 和 SHA-1/SHA-256 指令。这意味着什么？意味着 服务端和客户端在硬件上直接支持 AES，意味着原来 N 条汇编指令只需要一条 AES 指令就完成了。其实也意味着， 在绝大多数情况下 AES 才应该是你的首选。

口说无凭，咱们可以看一下测试数据，x86 服务器 CPU 测试可以直接看 Crypto++ 的 benchmark 。可以看到 AES/CTR (128-bit key) 与 TEA/CTR (128-bit key) 的加密速度比是：4499 MB/s 比 72 MB/s，62 倍的差异！这就是硬件实现的威力。

ARM 手机 CPU 加密算法的 Benchmark，我没有找到。但为了更有说服力， 我自己实现了两个测试 APP，一个 Android 版，一个 iOS 版。写技术文章多不容易啊，写博客之前先写三个晚上代码，泪目！！！代码在 https://github.com/solrex/cipher-speed ， Android 版可以直接在 Release 里扫码安装。

首先介绍一下目前的旗舰 CPU，骁龙 835 (MSM8998) 的表现，测试机型是小米 6：

# Speed Test of 10MB Data Enc/Decryption #
# AES: 
* [AES/CBC/PKCS5Padding] ENC: 1146.9 KB/ms
* [AES/CBC/PKCS5Padding] DEC: 692.4 KB/ms
* [AES/CBC/NoPadding] ENC: 1118.8 KB/ms
* [AES/CBC/NoPadding] DEC: 1343.5 KB/ms
* [AES/ECB/PKCS5Padding] ENC: 990.4 KB/ms
* [AES/ECB/PKCS5Padding] DEC: 703.2 KB/ms
* [AES/ECB/NoPadding] ENC: 973.4 KB/ms
* [AES/ECB/NoPadding] DEC: 988.9 KB/ms
* [AES/GCM/NOPADDING] ENC: 13.9 KB/ms
* [AES/GCM/NOPADDING] DEC: 14.7 KB/ms
# DES: 
* [DES/CBC/PKCS5Padding] ENC: 20.1 KB/ms
* [DES/CBC/PKCS5Padding] DEC: 20.7 KB/ms
* [DES/CBC/NoPadding] ENC: 21.3 KB/ms
* [DES/CBC/NoPadding] DEC: 21.6 KB/ms
* [DES/ECB/PKCS5Padding] ENC: 26.3 KB/ms
* [DES/ECB/PKCS5Padding] DEC: 26.2 KB/ms
* [DES/ECB/NoPadding] ENC: 25.9 KB/ms
* [DES/ECB/NoPadding] DEC: 26.8 KB/ms
# 3DES: 
* [DESede/CBC/PKCS5Padding] ENC: 23.6 KB/ms
* [DESede/CBC/PKCS5Padding] DEC: 23.2 KB/ms
* [DESede/CBC/NoPadding] ENC: 23.6 KB/ms
* [DESede/CBC/NoPadding] DEC: 23.5 KB/ms
* [DESede/ECB/PKCS5Padding] ENC: 8.5 KB/ms
* [DESede/ECB/PKCS5Padding] DEC: 8.5 KB/ms
* [DESede/ECB/NoPadding] ENC: 8.5 KB/ms
* [DESede/ECB/NoPadding] DEC: 8.6 KB/ms
# TEA: 
* [TEA] ENC: 16.0 KB/ms
* [TEA] DEC: 18.1 KB/ms

可以看到，TEA:AES=16:990，这是多少倍？我都懒得算了。然后是 2 年前的中低端 CPU，联发科 Helio P10 (MT6755)，测试机型是魅蓝 Note 3：

# Speed Test of 10MB Data Enc/Decryption #
# AES: 
* [AES/CBC/PKCS5Padding] ENC: 358.8 KB/ms
* [AES/CBC/PKCS5Padding] DEC: 267.9 KB/ms
* [AES/CBC/NoPadding] ENC: 438.8 KB/ms
* [AES/CBC/NoPadding] DEC: 515.0 KB/ms
* [AES/ECB/PKCS5Padding] ENC: 310.6 KB/ms
* [AES/ECB/PKCS5Padding] DEC: 222.1 KB/ms
* [AES/ECB/NoPadding] ENC: 312.4 KB/ms
* [AES/ECB/NoPadding] DEC: 319.5 KB/ms
* [AES/GCM/NOPADDING] ENC: 5.1 KB/ms
* [AES/GCM/NOPADDING] DEC: 5.7 KB/ms
# DES: 
* [DES/CBC/PKCS5Padding] ENC: 7.5 KB/ms
* [DES/CBC/PKCS5Padding] DEC: 7.7 KB/ms
* [DES/CBC/NoPadding] ENC: 7.7 KB/ms
* [DES/CBC/NoPadding] DEC: 7.8 KB/ms
* [DES/ECB/PKCS5Padding] ENC: 9.3 KB/ms
* [DES/ECB/PKCS5Padding] DEC: 9.2 KB/ms
* [DES/ECB/NoPadding] ENC: 9.3 KB/ms
* [DES/ECB/NoPadding] DEC: 9.5 KB/ms
# 3DES: 
* [DESede/CBC/PKCS5Padding] ENC: 12.5 KB/ms
* [DESede/CBC/PKCS5Padding] DEC: 12.3 KB/ms
* [DESede/CBC/NoPadding] ENC: 12.3 KB/ms
* [DESede/CBC/NoPadding] DEC: 12.5 KB/ms
* [DESede/ECB/PKCS5Padding] ENC: 3.1 KB/ms
* [DESede/ECB/PKCS5Padding] DEC: 3.1 KB/ms
* [DESede/ECB/NoPadding] ENC: 3.1 KB/ms
* [DESede/ECB/NoPadding] DEC: 3.1 KB/ms
# TEA: 
* [TEA] ENC: 6.2 KB/ms
* [TEA] DEC: 8.0 KB/ms

然后是 3 年前的旗舰 CPU，Apple A8，测试机型是 iPhone6。别问我为啥不用今年的苹果旗舰 CPU...

# Speed Test of 10MB Data Enc/Decryption #
# AES
* [AES/CBC/PKC7Padding] ENC: 76.0 KB/ms
* [AES/CBC/PKC7Padding] DEC: 111.3 KB/ms
* [AES/CBC/NoPadding] ENC: 138.2 KB/ms
* [AES/CBC/NoPadding] DEC: 450.7 KB/ms
* [AES/ECB/PKC7Padding] ENC: 305.6 KB/ms
* [AES/ECB/PKC7Padding] DEC: 735.9 KB/ms
* [AES/ECB/NoPadding] ENC: 330.0 KB/ms
* [AES/ECB/NoPadding] DEC: 673.6 KB/ms
# DES
* [DES/CBC/PKC7Padding] ENC: 23.1 KB/ms
* [DES/CBC/PKC7Padding] DEC: 24.5 KB/ms
* [DES/CBCPadding] ENC: 23.1 KB/ms
* [DES/CBCPadding] DEC: 22.8 KB/ms
* [DES/ECB/PKC7Padding] ENC: 19.4 KB/ms
* [DES/ECB/PKC7Padding] DEC: 20.8 KB/ms
* [DES/ECBPadding] ENC: 22.2 KB/ms
* [DES/ECBPadding] DEC: 22.2 KB/ms
# 3DES
* [3DES/CBC/PKC7Padding] ENC: 9.7 KB/ms
* [3DES/CBC/PKC7Padding] DEC: 9.8 KB/ms
* [3DES/CBC/NoPadding] ENC: 9.8 KB/ms
* [3DES/CBC/NoPadding] DEC: 9.8 KB/ms
* [3DES/ECB/PKC7Padding] ENC: 9.4 KB/ms
* [3DES/ECB/PKC7Padding] DEC: 9.1 KB/ms
* [3DES/ECB/NoPadding] ENC: 9.2 KB/ms
* [3DES/ECB/NoPadding] DEC: 9.4 KB/ms
# TEA
* [TEA] ENC: 10.9 KB/ms
* [TEA] DEC: 11.1 KB/ms

关于 Apple A8 的测试多说两句。我上面的 AES 性能，离 GeekBench 发布的 A8 AES Single Core 还有不少差距，不知道是不是测试方法差异导致。但总的来说，不影响结论，那就是 TEA 跟 AES 差距巨大。

看到这里，可能大部分人心里已经做出选择了。即使还没做出选择的读者，我想你也可以考虑看看我的代码实现是否存在问题。不过最后还是 回答一下开头提出的问题吧：

如果你使用平台语言来实现对称加密，也就是 Android 上用 Java，iOS 上用 OC 或者 Swift， AES 是不二选择。这样能充分利用硬件提供的能力，安全性+性能肯定是最优，不要再想其他选项了。
如果你使用 Native 语言来实现对称加密，在 Android 上使用 JNI 调用 C 编译的代码，的确不少人认为原生指令更难逆向。可能要在 ARM 架构上做个取舍，是取悦 v8 用户，还是取悦 v7 以下的用户，这可能影响到选型。不过我认为 AES 依然是一个好的选项，起码在服务器端，你肯定会节省成本。

您可能还对下面的文章感兴趣：

Burpsuite插件开发之RSA加解密 [2016-02-11 22:37:04]
文档安全加密系统的实现方式 [2016-02-06 11:19:22]
公钥私钥加密解密数字证书数字签名详解 [2014-04-21 12:44:29]
Perl 程序源码怎么加密 [2013-05-28 22:20:58]
网址加密(URL加密)（RC4、PHP、密钥长度可变） [2012-12-21 13:38:39]
跨越千年的RSA算法 [2012-12-16 23:46:00]
加密服务学习笔记 [2012-05-08 00:07:39]
Oracle Transparent Data Encryption - 透明数据加密 [2011-09-14 13:58:49]
在浏览器中加密Cookie [2011-06-02 23:44:09]
如何“加密”你的email地址 [2011-02-13 22:51:37]
Padding Oracle Attack实例分析 [2011-02-10 22:33:42]
加密你的shell [2010-11-14 21:05:30]
具有时效性的PHP字符串加密解密函数 [2010-05-22 13:04:30]
代理的加密部分 [2010-04-01 08:51:34]
使用bcompiler对PHP文件进行加密 [2010-03-26 14:21:55]
使用系统命令实现文件的压缩与加密 [2009-11-19 22:41:24]
可逆的加密方法(Mcrypt Encryption Functions) [2009-10-16 12:06:43]

用3天时间设计一款完整的APP作品

Wed, 06 Mar 2019 08:00:14 CST

很多人说看过很多设计道理却依然做不好设计，还不如直接看设计案例来的简单粗暴。今天为大家找到一篇实战好文，一个人，3天时间，打造一款APP全流程设计，学起来吧！几周前，我接到一个设计需求是为食品行业设计一套解决方案，甲方给出的时间是必须在3天内完成。乍一听，可能会觉得这几乎是不可能的，但是如果你熟悉“GV Design Sprint ” （译者注：GV Design Sprint就是一个专业的设计流程方案，想了解的朋友请见https://designsprintkit.withgoogle.com/introduction/overview），那么就会明白，这实际上是可以做到的。我发现这是一个非常好的机会，可以在这么短的时间内实践一套设计方法。在这篇文章中，我将逐一向大家分解我的设计过程和每天的设计进展。

项目背景

Common Food是一个使用社区支持农业(CSA)出售水果蔬菜的农场。人们需要在年初提前预定农场一年的收成，然后在生长季节里，社区成员每周都会收到一箱食品。（译者注：CSA的运作过程通常由认同相同理念的社区支持者（个人或单位）采用共同购买的模式，预先支付一笔费用给当地的小农户预约一季或一年的收成，农民收成后，再根据实际产出的多寡分配给会员，如此达到结合社区力量支持在地农民采用有机农耕的积极意义。——百度百科）

设计挑战

设计一款应用，帮助普通农场每周能向会员们卖出更多的农副产品。帮助他们个性化的推荐食品方案，以满足会员们不同的知识水平，兴趣和饮食限制。

第一天：资料收集

研究方法

研究阶段往往会占用一些时间，所以尽可能的利用手头现有信息是节省时间的好办法。市场环境二手资料，竞争对手，用户调研或者直接去App Store中收集用户评论，我需要尽早了解清楚用户的思维模式。

用户调研

Common Food 公司会在每个季度对会员们进行回访，以便能更好的了解他们的喜好，以下是今年的一些反馈：

“我喜欢烹饪和做罐头。我可以多买一些西红柿吗？” “大头菜我不喜欢吃，我把它都扔掉了，不过生菜确实很好吃。” “我儿子对花椰菜过敏，所以我们从不吃花椰菜。另外我喜欢吃蒜蓉，但不知道怎么做。” “我希望我能有更多的大头菜，然后用来做泡菜。” “ 我觉得我们应该需要更多的CSAs，继续扩大农场的规模。我现在看到了很多转基因的怪物农作物，希望有渠道能及时发布最新消息。” “我们能不能弄到更多的甜菜？” “我从来没听过白菜，它看起来很漂亮，但是我不知道怎么做这道菜。”

一份来自Field Agent的最新报告发现，不管是在计划内还是计划外购物的网购者来说，农产品都是一个很受欢迎的类别。65%的受访消费者表示，他们购买的是新鲜农产品，与冷冻乳制品并列第一。31%的人说他们一时冲动买了新鲜水果和蔬菜，超过了零食（23%）和糖果（14%）。然而，39%的网购者并不会在网上购买新鲜农产品，因为他们更喜欢去菜市场。

市场调研

市场研究公司Mintel发现，尽管消费者越来越多的转向网上购物，但只有十分之一的美国人会通过电商购买新鲜的农产品，肉类，家禽和鱼类。该研究建议，为了打消消费者的顾虑，提高销售额，零售商应该多提倡节约成本，并提供更全面的产品信息，以建立信任，提升价值吸引力。研究表明，亚马逊的“购物车和收藏”等功能对于忙碌的消费者来说也是一个很有吸引力的点，特别是女性（48%）比男性（37%）更有可能在线购买，做好功能体验很重要。

头脑风暴

脑暴出的问题 1、我们如何收集用户需求数据来减少浪费和分配食品？ 2、我们如何通过季节性食物和促销活动来增加销售业绩？ 3、我们如何帮助会员根据他们的饮食偏好发掘额外的食物需求？

用户画像

用户调查的结果提供了足够的信息来创建用户画像。我选择创建与年龄和性别都无关的角色，以便能够将更加聚焦在如何平等的实现用户目标上。

用户画像

竞品分析

当我准备进入草图阶段时，我将会研究在相关行业或竞争对手那里类似的问题和解决方案，以确定最佳方案。 盒子大小和内容分类 FarmBox Direct和Farm Fresh to you两款产品分别提供不同的盒子大小和产品选项。（译者注：为什么会定义盒子大小，这是因为他们每周会发放给会员的食品是以盒子来计量的。） 自定义盒子装的食品种类 FarmFresh to You让你定制你的盒子，添加或删除农产品和设置数量。但你必须充会员才能定制它，与此同时，你也可以为排除项创建项目列表。

FarmFresh to You

真实的食品照片 Farmstead 允许添加任意数量的购物清单，你可以添加，删除和浏览，都没问题之后再来结账。Farmstead提供真实新鲜的产品照片，不像其他竞争对手使用库存的照片。

方案思考

我的解决方案是设计一个APP，从会员那里收集数据，比如家庭规模、饮食偏好等等，让会员们可以轻松定制季节性食谱。利用人工智能了解会员的饮食习惯，提供食谱，饮食建议和运营一些有针对性的促销活动，取得双方共赢。这些数据可以帮助我们从会员那里得到反馈，然后就可以知道他们在哪个季节可能会重新订购哪种类型的产品或组合，以及他们实际上最喜欢什么产品。

第二天：草图和设计

我喜欢在自己感觉“明白了”之后开始画草图，我会把自己的想法都画出来，然后再把自己觉得不好的想法剔除掉，保留自己觉得最好的效果。我会通过绘制用户旅程地图来定义用户任务和目标。

用户旅程地图

解决了用户角色，竞品分析和草图方案，接下来，我就开始为注册了这些服务的会员们设计流程。一旦他们通过APP首次下单，我们的数据库中就有了用户的日程安排、发货和账单信息。一旦确认了这些流程信息，我就准备开始画线框图。 线框图 线框图是APP的骨架，这让我在开始做视觉设计之前，能够专注于关键功能、元素和交互。我选择了高保真线框图，这样我只需要在一些色彩，配图，和图标上进一步思考视觉呈现。 风格板 在画好线框图之后，我会找相同行业内的APP视觉做一个风格板来作为设计参考。 配色方案 我选择了鲜红色作为主色。鲜艳的颜色会让人胃口大开，红色也会引发购物欲望（促销、清仓、热闹等氛围）。 字体选择 图标设计 当说到图标和节省时间这个话题时，我不建议把它们都画出来。尽管我很喜欢自己画图标，但是这次时间上并不允许。我推荐一些图标库，比如Material Design icons（https://material.io/tools/icons/），或者我这个应用用到的一个图标库The Noun Project（https://thenounproject.com/#）。在利用这些图标库时，请注意购买版权，如果不想付费，也必须注明图标来源，定稿后有时间再来重新画。 Logo设计 我期望这个APP能有一个清晰易懂的名字，同时也希望能有一个与名字非常匹配的Logo。在思考了很多名字之后，我觉得“FameCrate(农场条板箱)”这个名字非常的适合，通过不断迭代，优化，最终得到了下面这个Logo。 视觉设计 我喜欢尝试不同的风格和设计变化，我对第一稿不满意，因为缺乏整体上的一致性，然后不断优化，直到最终全局页面都能做到统一协调并符合自己的设计预期为止。

第三天：交互原型

到了第三天，我完成了最后的视觉设计，便开始做可交互原型。我等到这个阶段才开始做这事，主要是因为如果在线框阶段就开始做原型的话，尽管它们是高保真的（我经常这么做），但会花很多时间在交互界面上。对于这个项目，我在设计完成后再来添加交互动作，其实是为了节省时间。 最终设计 自动动画 我会用Adobe XD的自动动画（https://helpx.adobe.com/xd/help/create-prototypes-using-auto-animate.html）功能来做原型设计，这是节省交互动画制作时间的好办法，而不是在After Effects上花费几个小时来做这种效果。下一步 可用性测试 找一些真实用户来做这项测试。我个人最喜欢用Maze.Design（https://maze.design/）这款工具来记录测试结果，它易于使用，并能提供有关原型的全面数据分析。 不断迭代 通过可用性测试的一些结论，在设计上进行迭代，改进用户流程。总结在有限的时间内，你绝对不能让自己分心，必须专注于这个项目并管理好自己的时间。我会给自己进行计时，并在每一个步骤上给自己设定时间限制。我试着让APP用起来尽可能的简单，从草图和用户旅程地图就要开始思考，最后这一切才能水到渠成。感悟永远相信你的直觉，不要害怕设计修改。如果你把我的线框图和最终的设计效果图进行比较，会发现我做了很多的选择来改进最终的设计。另外，也可以使用你自己熟悉的软件，或者你自己知道的更快速的方法，而不要太花费时间来确定是不是跟我完全一样。原文：https://uxdesign.cc/ux-ui-case-study-designing-a-food-app-in-3-days-1e2856680205 作者：Paola Ascanio 译者：彩云Sky(微信号:caiyunyisheji) 本文翻译已获得作者的正式授权

(ノ◕‿◕)ノ*:･ﾟ✧ 查看最受欢迎 301 个设计网站 *:･ﾟ✧ヽ(◕‿◕ヽ)

UI设计QQ群 ¦ RSS订阅 ¦ 新浪微博 ¦ 本文链接 ¦ 添加评论

霸榜世界第一的在线教育App，靠什么增长到3亿用户？ - 增长黑盒 - 增长黑客专用工具箱 - 增长黑客社区

Sun, 24 Feb 2019 08:22:16 CST

Alan@增长黑盒最近和国内不少知识付费公司都聊了一遍，发现国内的知识付费市场还是相当野蛮的。除了争相模仿和同质化的竞争，还有一个更核心的问题：

目前，绝大部分知识付费公司的核心指标是销售量和销售额，这就导致公司必然是 销售和营销导向型的。这也导致大家更注重对课程的包装，而不是质量，变相地使得 完课率和复购要画个问号。赚钱的秘密武器自然是 收割用户的焦虑，而这种行为也容易被人联想为割韭菜、收智商税。

只有少数公司将 完课率和课程效果作为核心指标，而这样做的问题在于服务和运营成本会变重，卖课的数量反倒不一定能多起来。最终导致认真打磨课程的公司可能卖不过那些营销做的好的公司，成功实现 劣币驱逐良币，最终使得知识付费行业的 市场变得混乱。

不过，目前来说头部公司还是那些用心做产品的，例如国内英语类的知识付费产品—— 薄荷阅读。他们就属于深耕英语教育行业，又专心 打磨用户体验和 产品内容的那种，所以自然也成了大家竞相模仿的对象。

知识付费到底还有什么玩法？我们不妨放眼全球，来看看国外教育类App下载排行榜榜首之作—— Duolingo （多邻国）。

这是一款 神奇的语言学习APP：没有卖过 付费广告，仅通过 游戏化的设计和 口碑传播，七年时间在全球做到3亿用户，2500万月活，并在去年估值超过7亿美金。多邻国的用户还包括很多大咖，例如比尔盖茨和扎克伯格。

如果只是这样也就一般神奇，更神奇的是： 这家公司的口号是学语言永远免费，不收用户一分钱 ！

于是，我决定和团队的小伙伴Rhino@增长黑盒深入研究一下这款APP，搞清楚两个问题：

1.“知识免费”靠什么商业模式赚钱？2.实现从0到3亿的增长，其核心策略是什么？

价值观和商业模式探索之路

2009年——从知识付费到知识免费

神奇的公司必然有神奇的创始人，多邻国创始人 Luis von Ahn是 卡内基梅隆大学计算机教授，曾经做过一个验证码公司reCAPTCHA后来卖给了Google。

reCAPTCHA这个系统，使得验证码不仅可以验证用户是否为真人，同时这些人填写的验证码还能帮助机器识别难以辨别的文字。最终，大家的众包劳动，会把一些老旧而经典的书籍给数字化，正所谓 一箭双雕。

卖掉公司后，Luis开始寻找新的市场，而他看中的是 外语学习的“知识付费”领域。

在2009年，美国市场上混的风生水起的外语学习软件是 Rosetta Stone。他们于2009年上市，公司年 营收超过2.09亿美元。

但Luis并不满意这样的模式，这里有 两个原因：

一方面，他意识到这样的商业模式 想象的空间小， 市场有限，一眼就 望得到头（毕竟之前一箭双雕，要求有点高）。
更重要的是，这样简单粗暴地卖语言学习课并不是他的目标，他想做更加 普惠的语言教育。这也是他的联合创始人 Severin Hacker（并且也是他的学生，名字里自带黑客）一直以来想要做的事情。

他们会这样想，也是源于 他们两个人自身的“痛点”：

Luis来自 危地马拉，位于加勒比海沿岸，他们那里有很多人想要去美国学习和工作。但是对于动辄上千美金的外语学习资料来讲，这实在是许多人一辈子也不可企及的梦想。而Severin来自瑞士，一个有 4种官方语言的国家，在他成长过程中有一段 很困难的语言学习期。

所以他们不想把自己圈在知识付费软件的条条框框里，而是决定通过“知识免费” 切入更广阔的增量市场。

可以说这是个 超越时代的想法。不过，从这些年的谷歌趋势可以看出来，多邻国确实是比Rosetta Stone 更具成长性。

2011年——宣布永远免费的外语学习产品

“We believe true equality is when spending more can’t buy you a better education.”

永远免费，成为了Luis在创办多邻国的时候立下了一个flag。竞争对手还在销售昂贵学习软件的 红海里拼得你死我活，Luis开始把脚步迈向了 “知识付费”的进阶版“知识免费”。

这大概和当年 360开始免费杀毒有异曲同工之妙，在付费软件你死我活的时候，免费就是最好的获客手段，然后再想办法开发出 “二级火箭”的商业模式来挣钱。

2009年Luis把reCAPTCHA卖了，正在寻找新的项目；而付费英语软件Rosetta Stone刚好在 同年上市， 生意如日中天。Luis留意到教育行业的火热，但又不认可这种昂贵付费学习软件的商业模式，就开始自己捣鼓产品。2011年，终于有了 多邻国Beta版本可用于测试，而 如何冷启动一个产品？还是 最小化可执行产品，这又是一个难点。

这里要给创业老手Luis点个赞，他深知PR的玩法，尤其是如何发布一款 全球性的、 免费的语言学习工具。对于这么有 前瞻性和话题性的产品， TED演讲是一个值得一试的渠道。

于是Luis以一个创业者的身份登上了TED演讲，上来先阐述了自己之前一箭双雕的reCAPTCHA项目。之后，他顺着reCAPTCHA的逻辑，讲了自己想要做的新项目，这个社区有可能成为 免费学习英语的网站。不仅如此，你在 学习一门外语的同时，还在 翻译全球的网页内容。

在那个线上软件和线下纸质书都很贵的时代， 免费学习加 全球协作 翻译这个概念引起了轰动的效果。

该视频当时在网络上就被观看100万次（七年后累计达到300万），这个零成本的 “冷启动”最终筛选到了 10万种子用户，并且有 多达50万人在排队（waiting list），效果可以说是完美。

2013年——模仿reCAPTCHA，开始众包翻译

既然承诺了用户“免费”，那就必然要想办法嵌套一个 二级火箭的商业模式来挣钱，有过reCAPTCHA众包经验的Luis早已准备尝试 “众包翻译“这个模式。

体验过多邻国的朋友应该比较容易理解，多邻国的基本学习逻辑就是 “母语和目标语言互译”，通过单词、句子和图片的翻译达到 练习和强化记忆的目的，从而掌握一门语言。

它一开始会让你 翻译一些简单的单词和句；到了 学习的高阶，它会将CNN（美国CCTV）上的新闻报道拆分成小章节交给用户翻译，通过 多个用户对同一素材的翻译得到 精准的翻译结果，再整合成一整篇卖给媒体。

这种 “众包”的模式不仅不会伤害到用户体验，反而让用户感知多邻国的语料素材丰富且拥有相当高的时效性。而多邻国自己，把翻译内容“众包”出去，降低了 翻译的人力成本，让价格有很大的竞争力。

一般的翻译公司给的价格是 6-10美分一个词，而多邻国可以 压到4美分，且由于 用户数量大，产量可以保证 平均每天600篇，这才让CNN和Buzzfeed（美国今日头条）都来和它合作。

于是，这个模式成功地跑了起来。

2014年初——开始做外语培训的认证

虽然翻译业务可以让公司有一定的营收，但整个公司并 没有停止探索新的商业模式。更重要的是，他们已经 暗自决定缩小翻译业务的规模了，具体原因后面会介绍。

那有什么新的盈利方向可以参考呢？大家可以想一下 传统教育行业是如何 为结果负责的。

那就是先不管你学没学到， 最终来一场考试，通过了就给你 发证书，而且证书认可范围越广越好。

一份独立的调查显示，多邻国的 英语测试结果跟 托福分数有很强的联系。此外，全球有 8亿人希望获得一个英语水平验证以有更好的工作机会，但是标准的英语能力测试，如托福、雅思对于普通人来讲太贵，并且还要负担去考试中心的差旅费。

独立调查报告链接：

https://s3.amazonaws.com/duolingo-certifications-data/CorrelationStudy.pdf

基于这些内部和外部的调研，多邻国上线了测试中心，只需要 托福考试的10%价格—— 20刀就能在家里考试（现在已经涨价到49刀了），通过了考试即获得英语学历证明。

可是，一个 App开出的认证资格，别人认吗?

不要忘了，Luis可是卡内基梅隆大学计算机教授，又是被Google收购过的创业者。 有愿景，有实力， 有过硬的产品和用户口碑。你没有看错，这个认证资格从一

开始就联合了大公司、高等学府和机构。

Uber、哈佛继续教育学院、哥伦比亚政府等纷纷站出来给它站台，测试既有 权威性，还顺便拓展了一下 “职场人士学外语”这个细分市场。

2015年初——砍掉众包翻译业务，拒绝销售导向

根据Techcrunch（世界最大的科技媒体之一）报道，多邻国在15年初又获得Google领投的 D轮融资，此时他们已经有 一亿用户了！

在这篇融资采访稿中，让大家没想到的是，Duolingo的发言人透露其实他们一年多以前就 已经没有再去扩大 翻译业务，只留下了CNN一家合作伙伴。

他们认为如果全力去做翻译业务，会需要更多的人员去把控翻译质量，并雇佣更多销售。这样的商业模式 有悖于 做普惠教育的初衷，且极有可能伤害 用户体验。

2015年——做B端的外语教学工具

所以，多邻国又开始探索 新的增长方式和 盈利模式。

在和企业、学校、机构打交道的过程中，Luis又看到了 和B端合作的巨大潜力。

当 D轮融资后多邻国把团队从30人扩大到了50人，终于可以腾出手来去开发一个呼声很高的功能 —— Duolingo教育版。

很多教育机构、企业、政府都曾经向多邻国提过需求，说希望 发布一个供机构使用的Duolingo版本，方便老师 统一管理学生的学习进度。

多邻国据此开发了一个新的版本 Duolingo for Schools，帮助老师建立错误答案看板以及学生学习进度表。

这本是个挣钱的机会，但是Luis最终还是坚持了 “免费教育”的初衷，最终决定对老师和学生端 完全免费。

这个尝试虽然没有给多邻国带来任何收入，但是给多邻国带来了别的收获—— 爆发式用户增长。因为 良好的体验、 免费的价格、 长期用户使用习惯的培养，多邻国一下子打入学生个人市场，在广大的学生群体中间流行起来。

同时也在企业用户中流行起来，类似Slack（国外企业版qq群）的增长方式 —— 与机构合作， 通过机构层面切进用户使用场景，培养用户习惯。

几个月后，教师端用户数 从0增长到10万；与此同时，在16年年初，多邻国的用户 规模突破1.5亿。

2017年——上线App内购和广告

经历过这么多商业模式的探索，多邻国一直在坚持自己的承诺—— 不向用户收费。

不仅如此，之前App内也没 有任何道具内购和广告。

只不过，在团队扩招后， 考试认证和翻译那点营收似乎不够看了。17年4月的一篇报道中(https://www.makeuseof.com/tag/duolingo-plus-easier-learn-new-language/)，CEO Luis说公司已经有 多达150人，每天需要花费约 4.2万美金，于是他们选择了App变现的一些常规方式：

免费版App中 加入了广告，用户可以选择观看获得 额外奖励
同时上线了 付费版（Duolingo Plus），每月9.99美金订阅可以 取消广告，并且可以 离线学习所有内容
加入了 游戏化道具的内购，生命值、宝石等等，可以帮助你 加快学习进度

App内的广告还是比较克制的，比如在课程结束后，会出现广告页面，有两个“按钮”可以选择：“观看加倍你的生命值”和“不看，谢谢”。

广告一般是一个20s的手游推广，右上角有倒计时告知你 广告进度，左下角还可以关掉声音。

虽然用户多少 会有些抱怨，但是绝大部分用户还是 表示可以接受的，他们的iOS App Store评分还是有4.7分之多。

那么，“知识免费”究竟 能赚多少钱呢？Luis在最近的采访透露，多邻国2018年的营收估计会达到3000万到4000万美元，公司有望在明年实现盈利，希望在最近2-3年内上市。

以留存为核心的增长策略

从12年上线到18年8月9号，多邻国用户突破了 3个亿，虽然营收没有做的那么漂亮，但是一直保持着 很高的用户增长效率，而且关键是 没有烧钱买量。那么，多邻国是如何用具体的技巧和策略来推动增长呢？

多邻国拥有 一支顶尖的增长团队，几乎所有内容都经历过AB测试并且在不断优化。

多邻国的 增长总监Gina Gotthilf曾在Growthhackers.com（世界最大的增长黑客社区）举行过一次问答活动 – 就连“增长黑客之父”肖恩·埃利斯都借机说明自己是多邻国的 “上瘾”用户，并向她请教：多邻国究竟是如何做增长的？

Gina坦言，他们的 增长策略就是：

将留存和完课率的重要性放在首位

采用游戏化的产品设计

数据驱动，用A/B测试等实验来增长各种指标

教育应该是以“结果”为导向，产品关心的指标应该是 “留存”、“完课率”或“复购”等一系列持续使用的行为，所以在多邻国的 增长策略里留存才是是核心。

但是，学习 是反人性的，让人长期 坚持并掌握一门语言，难度是 超乎想象的。全球都在研究的，也是被认为最有效的留存手段就是 Gamification（游戏化），多邻国的 增长团队甚至参考了消消乐和愤怒的小鸟这些 游戏的原素，让用户爱上学习，上瘾学习。

多邻国将 产品游戏化放到了仅次于 产品免费的战略地位上，甚至在官网清晰的展现了自己这种理念：

比如，众多游戏化设计中， 每日连续学习（Day Streak）是多邻国最重要的一个 用户留存的手段，围绕它有很多玩法。用户每天完成10分钟的打卡训练，获得升级条（Streak）作为凭证；升级条作为连续的系统，如果间断一天不练习，前面的升级条也会失效，而且还会失去“特别奖励”。

为了让用户坚持每日学习，团队 煞费苦心做出了这些 有趣的产品功能。但用户究竟买不买账？这些功能真的能提高用户留存吗？

在增长总监Gina的带领下，多邻国贯彻了 增长黑客最经典的策略： 高频实验– 针对产品的各个模块循环进行 “试错 – 分析 – 改进”，从而达到不断优化用户体验、推动留存提高的目的。

多邻国做实验的速度究竟有多快？在一次采访中，Gina表示，增长团队大 概每天会做5-8个增长实验。而在Gina的带动下，整个公司都产生了一种 热衷实验的习惯 – 在增长团队之外，其它部门也会主动去做各种实验，全公司加起来甚至能达到每天80次！

Gina坦言在多邻国，他们几乎 测试每个细节，只要能上线AB测试的，不多啰嗦，直接上线测试、观测结果、作出决策。

下面，我们就来看 三个提升留存的有效策略，以及它们背后的 实验细节：

1. 善用推送信息。用户万一真的一狠心“前功尽弃”，就真的不会再回来了。所以Gina的增长团队决定给 用户适当的提醒，让用户成功地回归。

比如他们在一个法语课程的推送文案中，他们做了一组 善恶分明的测试：

善良版：嗨！友情提示，亲爱的你应该练习法语了！

刻薄版：喂傻x，为什么不治好你的懒癌，去练习那该死的法语呢？

但是这两种推送效果都不理想，收到“善良版”的用户数量在一周后开始明显下降，而收到“刻薄版”的用户数量在一天后明显下滑。

所以团队想出了一个方法，就是把文风保持在“ 善良”和“刻薄”之间，于是就有了这条充满 “丧文化“的推送——

“反正给你发提醒也没用，再不来学我们就停止给你推送了。”

这招还是挺奏效的，用户数量维持了 三周才开始出现明显下滑，不少用户被这条“傲娇”的自残式推送吓到了，赶紧拿起手机学习。但这个 “被动积极”的方式毕竟用力过猛，像“狼来了”的故事讲多了就不吓人了，所以“有效”也“有毒”，基本上用过几次就没什么用了。

2. 周末保护盾牌。多邻国从数据洞察到一个有趣的现象，周一到周五大家都是精神饱满地学语言，但一到了周末， DAU平均下降9%，并且有一部分人在周末搁置任务之后永远地流失了。这时他们提出了一个 “周末保护盾牌”的实验想法。

用户可以并且只能在周五买到“盾牌”，盾牌可保护用户在 周末不上线的时候“每日连续学习”（day streaks）状态不会丢失。这个盾牌的效果就是它把7天的留存率提高了2.1%、14天提高了4%。

3. 徽章制度

徽章是 游戏化很常见的一环，团队自然也做了大量测试。

一开始，他们试图在用户注册的时候就送徽章，但这个数据结果 差得令人影响深刻，日活无变化，14天留存无变化，其它数据也都没有变化，于是团队就把这徽章设计这部分 搁置了一年。

但在这一年中他们参考了 大量其它打卡类app和游戏化设计，比如国外的大众点评“FourSquare”，感觉这个“徽章”项目还有的做，在一年之后的一次增长会议上，团队提出了 70多条优化建议，决定 再优化一次。

相比于上一次只测试一个徽章在一个场景的使用，这一次团队引入了 多个徽章，并且 分为不同等级，安排在 App不同场景测试。比如在这些不同场景可以获得徽章：

鼓励完成学习任务

邀请朋友

在App内体验更多产品功能和经验

但不同行为都有一个导向——让用户在app内留存久一点。

实验结果竟然与 原来有惊人的不同，徽章刚上线不久，日活上升了2.4%；用户开课率提高了4.1%；完课率提高了4.5%。另外，上线徽章还有预料之外的收获：

虚拟商城购买率增加了13%

加好友的行为增加了116%

他们复盘一年前的实验，发现当时 疏忽了以下几点：

使用场景不对，用户在刚进来注册好的时候发徽章没有成就感

徽章数量太少，徽章的背后是收集的逻辑，单个的徽章对留存作用不大

人们喜欢与朋友攀比徽章

看到这里，相信大家都会有个疑问：Gina提到的三个策略，都在强调 留存环节。那多年来， 新用户究竟是从哪来的呢？毕竟冷启动只有几十万用户，后期几乎也没有营销预算，为何会有源源不断的人来使用这个App？

为了弄清楚这个问题，我首先画出了多邻国的用户增长曲线：可以看出，它的病毒 系数k值约等于1，曲线平稳上升， 而不是几何级数式爆发。根据我的经验，这意味着多邻国一直保持着有效且长期的“裂变 ”，用户增长的驱动力来自留存的老用户持续带来新用户 – 不靠各种花哨的拉新活动，而是靠产品本身的自传播。这样一来，不仅获客成本极低，用户还非常精准，从而实现了正向循环。

因此，多邻国的 留存策略确实是 增长的基础。而 合理的自传播设计，却是另一个重要的增长要素。Gina并没有提到这点，所以我简单调查了一下，发现多邻国的自传播机制还是 归结于游戏化。

多邻国设计自传播的理论基础是：“轻量化”的小游戏可以帮助增强社区内“人与人-点对点”的联系，他们常常可以通过大社区的人际关系网络来加速小社区的成长。有人曾对多邻国的 facebook传播网络进行过 可视化分析，如下图所示，是很明显的 “由小到大”：

举个例子，在多邻国内玩小游戏，你不仅可以邀请现有的好友来玩，还可以从更大的通讯列表（比Facebook 通讯录）中邀请朋友，召唤玩伴。就像小游戏里常常鼓励分享，并邀请你的微信好友加入，即从 大的流量平台里导流。

除了小游戏，多邻国还把推荐内嵌到 其它功能里面，比如前文提到的 “徽章”。用户只要邀请 朋友加入多邻国，就可以获得徽章一枚，比起起早贪黑背单词，这种动动手指就能得奖的方式岂不更好？

用大社区带动小社区、呼朋引伴、分享趣味，其实跟我们现在的教育类产品付费是同样的逻辑。只在自己 封闭的生态中实现用户增长是不行的，要打通与 更大社区间的联系，从那里稳定引流。

正如我们上次做的增长实验复盘《微信裂变一定要刷屏才好吗》，增长不一定要刷屏才好， 把K值稳定在1左右，有助于触达到 更精准的用户、 注重服务和品牌口碑。

最后，我们可以总结：多邻国增长 策略的核心是 留存+自传播的强效配合，是K=1的“长期裂变”。同时又将游戏化的各种增长的技巧应用到这两个环节，以测试循环来不断优化。微小的改变能对用户增长带来强力的拉升作用，比如：

优化打卡文案使学习学习效果更明显，提高了1%的DAU；
推迟强制注册页面提高了20%的DAU；
优化推送文案使用户平均留存时间增加了3周；
上线徽章功能提高了2%的DAU，双周留存提高了2%，App内购收入增加了5%；
引入打卡对赌功能，14天日活提高了5%，App内购增加了600%！

我们增长黑盒做了一张图进行简单的总结：

多邻国的产品一直保持着 “小步快跑”的 迭代速度，在每一个微小的改变中 打磨产品，在 关键节点上 提高转化漏斗效率，才有了当前3亿规模的用户体量。

“知识免费”的启示

多邻国 从10万用户涨到2亿，7年估值7亿美金，坚持不收用户一分钱，旨在向全世界想学语言的人 提供免费的线上教育。在这种情况下，它一直在 优化用户体验、打磨产品，变现就是个 顺水人情。那么，对于国内的在线教育、知识付费来说，能够从多邻国身上得到什么启发？

1.价值驱动，以用户为中心

B2B的翻译业务既轻松，又有一定营收，多邻国 却放弃去扩大它，而是 回归到为用户创造价值。教育不能以销售为导向，而是要为用户提供 实实在在的服务，赚快钱的想法永远要放在 第二位。

我用一个大家比较熟悉的案例来类比一下：不久之前，罗振宇曾经谈到，自己曾想过给得到 App做一个付费会员制– 只要 一次性付一年的钱，就可以 全平台听课了！这一方面是部分用户的建议，另一方面，会员制非常赚钱 – 有罗振宇自身的背书，售价可以卖的很高。但是，罗胖最后 放弃了这个想法，他说：

以to B业务为导向，就必然会让公司重心 向销售倾斜，团队自然 不再有热情去打磨产品。而多邻国的愿景是为全世界提供免费的、高质量的语言教育，用户的体验才是真正的核心和驱动力。

2.长远来看，留存>获客

短期来看，很多 知识付费贩卖的是焦虑。这就导致，获客环节声势浩大，但完 课率和留存率十分惨淡。如果用户在后续学习过程中没有获得足够好的体验，这只能是 一锤子买卖– 再有新课，很可能他们就不会来购买了。

我们经常看到的 裂变分销，确实是有效的获客手段。但我们需要 深刻思考：自己是否有能力在下游承载这么多用户？课程质量是否经过了验证？售后服务是否能跟得上？

过度追求拉新规模、只看重裂变系数K，这是 “收智商税”的典型表现。 K值过高的 最大缺陷，就是带来 大量不精准用户，严重影响留存。一时冲动的消费，虽然能化解焦虑，却不能真正创造价值。我个人认为，真正健康的模式是通过 低频的拉新活动，吸引精准的目标用户，然后依靠超高的留存以及合理的分享机制，让产品实现自发传播，从而能在长期内将 K值稳定到1左右。“老带新”的前提是不论新老用户，都对产品价值产生了认可。

我观察发现，大家都很熟悉用户获取的指标监测，比如K值、裂变层级等等，但很容易忽略留存的关键指标： 用户满意度和NPS。各位回想一下，在课程结束后，普遍会给你一个二维码，让你加客服、加群，或者推荐其它课程，却并没有问你对课程是否满意，愿不愿意推荐给朋友等等。课后的调查问卷，还是非常有必要的 – 根据用户洞察，我们才能对产品做到心里有数。

3.从小处着手，逐渐积累优势

很多人十分看重 爆发式增长：课程一定要裂变出几万人才算成功。但很多时候，这是几乎是不可能的。我们必须从 细节入手，慢慢改进产品，才能真正让用户满意。 A/B测试和数据驱动，就是最强大的武器。

多邻国是 高度实验导向，数据驱动的。通过微小的改变，持续不断的优化，多邻国一点点地积累起 增长和留存。这些微小的改变可能在当下看来是个不 值一提的提升，但是每天提升的那百分之几，成就了他们7年增长2000倍。

“高频实验”的策略已经被硅谷众多增长团队验证过，不论是facebook这种巨头，还是airbnb这些独角兽，每天都用惊人的速度在做测试。

回归到知 识付费领域，除了产品本身，其实 最容易入手测试的地方就是 裂变海报。大家是否还记得今年鉴锋团队操盘的“网易微课”？看起来似乎是一夜之间就刷屏了，但实际上他们预先对4种不同的海报进行了测试，最后挑选了裂变层级最高，也就是传播潜力最大的那张（第一张）。

4.快速的商业转型

在硅谷流行的精益创业理论中，有个概念叫做 pivot（本意：中心点、支点、枢轴） – 这里是商业模式的转型。创业公司一定要拥有及时 “掉头”的能力。

做一个大胆的设想，如果当时多邻国一直 守着B2B业务的模式不放手，那结果会怎样？

他们可能会建立 企业级销售团队， 攫取用户价值来保证翻译数量？反正不可能打磨出现在这款有趣又有用的产品的。

在商业模式探索上兼具 灵活性和实验性，让他们能够在关键时刻不拘泥于自己的成就，做出重大的变革，推动公司向前。

一个好产品，有灵魂才能生长！

参考资料：

How Duolingo Built a $700 Million Company Without Charging Users

http://firstround.com/review/the-tenets-of-a-b-testing-from-duolingos-master-growth-hacker/

Gina Gotthilf on growing Duolingo to 200 million users

https://mashable.com/2017/11/23/ceo-duolingo-notifications/#oWgYuEaRPgq5

https://medium.com/@jensenloke/duolingo-a-user-retention-case-study-7ebabf6c8853

多邻国下一个阶段的商业模式是怎样的？我们拭目以待。有兴趣探讨的朋友可以加入我们知识星球，圈子还有增长黑客大佬坐镇、增长和营销的策略和思路分享、国内国外最新的案例研讨！每满500人，圈子会涨价100块，知识不等人，还是先扫为敬了。

另外，对文章参考资料有兴趣，或者对知识付费、在线教育行业的朋友也可以加我的个人号哦，聊增长，不失联～

“三英战吕布”，看我如何抓出那些流氓APP

Sat, 09 Feb 2019 09:00:08 CST

“三英战吕布”，看我如何抓出那些流氓APP

在今年互联网凛冬来临的时候，整个圈子却火了一把，互联网众诸侯（头条、王欣、罗永浩）组成“复仇者联盟”纷纷做起了IM，并在同一天发布新产品，不过企鹅帝国深知“星星之火，可以燎原”，三个产品刚问世，企鹅帝国就以“迅雷不及掩耳之势”，凭借强大产品矩阵将其在各个渠道封杀，撕逼大战正式开始。吃瓜群众一边是感叹腾讯的胸襟，一边是评论新IM的产品体验，突然之间我又看到了一篇自媒体叫“今日”无隐私，“头条”在监控？，突然来了灵感，何不调查一下整个互联网究竟是谁家的APP在监控这大众的隐私。

众多的APP一会申请用户通讯录权限，一会又要申请读取通话记录权限等等，这些申请的权限往往和实现相关功能或获取相关数据有关，究竟我们常用的APP需要申请了多少权限？哪家的APP申请的权限更多？小编我准备对此做一下调查，让大家真正的了解谁才是恶人。

一、开土动工，调研四大派系

江湖传言互联网一直存在BAT（百度、腾讯、阿里）、TMD（头条、美团、滴滴）派系，那么就在TOP1000的APP排行榜单上全部下载这个几个派系的产品，发现其实美团、滴滴派系产品相对四大家族百度、腾讯、阿里、头条较少，那我调研的对象就直接对准四大家族吧，毕竟他们基本代表了中国互联网的发展水平。

腾讯派系：微信、QQ、应用宝、腾讯WiFi管家、手机管家等；

阿里派系：手机淘宝、天猫、UC头条、优酷、支付宝等；

百度派系：百度钱包、百度文库、手机百度、百度网盘、百度地图等；

头条派系：今日头条、抖音、西瓜视频、火山小视频、懂车帝、Faceu激萌、悟空问答等。

二、没有最多，只有更多

在各个APP的AndroidManifest.xml中将申请的权限都提取出来做统计，因为发现自定义的权限实在太多了，所以这里仅过滤了Android原生的权限，然后各取前七名然后做一个排行。

从申请android权限个数来看，腾讯系的APP 应用宝、腾讯WiFi管家、手机管家等均排在前列，申请的android权限数量达到了60~70个权限，而头条系的APP android权限申请数量普遍比较少，今日头条、火山小视频等几乎只有腾讯系前三甲的一半。市面上一些APP往往会申请很多与APP本身功能无关的权限，从而获取更多用户信息或数据，从上图权限申请的情况来看：腾讯还是那么“拔尖”，头条相对其他家，可谓是圈中清流、业界良心。

我将数据做了分类，将一些涉及用户信息(通讯录、短信、通话记录等)的权限标记为敏感权限，做了一个比较直观雷达图，结果似乎出乎意料却又在意料之中。

三、流氓的背后是用户信息的裸奔

App申请了这么多权限但是真的是功能需要吗？于是我搞了一个简单的代码扫描，粗略的扫了一下一些相关的API调用。

1. 获取通讯录联系人

“获取通讯录联系人”相关功能。通过代码扫描发现，将近一半的APP，比如微信、手机管家、腾讯WiFi管家、钱盾、钉钉、菜鸟裹裹、百度地图、百度贴吧等均有获取用户通讯录的行为，以下是通过反编译手机管家APP，发现的代码中读取通讯录相关的代码。

微信、钉钉获取通讯录联系人我们可以理解，手机管家、腾讯WiFi管家、百度地图等需要这个干嘛呢？其实都是利益使然，手机APP调取用户部分隐私信息成为常态现象，通过收集该部分信息也有利于应用为用户提供更好的服务体验。但部分企业的APP对用户权限调取存在疑似越界现象，该种行为对用户隐私造成侵犯，网络隐私不应该成为企业牟利工具。

2. Root提权功能

获取隐私什么的大家估计都快习惯了，所以我想到了一个更加刺激的东西，就是root！为此，我写了一个小程序，就是循环判断是否有进程获取了root权限，然后找了一些朋友，把这东西放到他们手机里边做监控。root权限大家使用的还是比较少的，不会把APP做的跟病毒似的。

最后监控到的APP有：Kingroot、净化大师、腾讯手机管家、Baidu 输入法、百度刷机存在该功能。

root提权是非常有风险的APP行为，一旦提权成功以后，该APP可以进行很多风险操作，如获取其他应用的数据，篡改系统文件，修改系统。

让我比较费解（其实也正常，继承了百度一贯的作风，毕竟我记得三年前百度系应用还留过后门）的是Baidu输入法，居然也会root？而测试的头条系相关的抖音、火山、今日头条等均未有发现有提权相关行为，还是上面的那句话，头条在业界算是良心派系。

四、监管刻不容缓

国家监管部门对于市场上各个APP的权限申请也一直在做各种各样的监管，其目标就是使得APP不要过多地申请与本身功能无关的权限，从而更好地保护用户隐私和用户敏感数据。

2017年颁布实施的《网络安全法》也明确指出“网络产品、服务具有收集用户信息功能的，其提供者应当向用户明示并取得同意；涉及用户个人信息的，还应当遵守本法和有关法律、行政法规关于个人信息保护的规定”，国家也不断的加强监控，但是作为这些巨头互联网在APP开发和发布上也应该严格控制权限的申请，遵守国家规定，用户在使用的时候也应该谨慎授权。

*本文作者：TopSec123，转载请注明来自FreeBuf.COM

7款让自己偷偷成长的App，送给爱学习的你

Tue, 15 Jan 2019 00:00:00 CST

1：BOOK

BOOK是一款集合高质量图书，期刊杂志，报纸的高质量阅读软件，并且这款软件还支持听书功能，软件的书籍全部免费，软件的书籍也是十分丰富；仅支持安卓版本。

它书籍种类丰富，分类功能十分强大，它还支持强大的搜索功能；一款软件可以代替大多数书籍阅读软件。

2：中国大学MOOC

中国大学MOOC是由网易与教育部爱课程网携手推出的在线教育平台，汇集中国顶尖高校的MOOC(课程；它支持安卓和苹果版本。

它免费提供985高校的顶尖课程，其中包括：计算机，经济管理，心理学，外语，文学历史，艺术设计，工学，理学，医药卫生，哲学，法学，教育教学等等各种不同学科的视频教程。

它还提供考研辅导，支持全新的教学模式，让你拥有全新的学习体验。

3：我要自学网

我要自学网是一个老牌学习软件；它支持安卓和苹果版本，还支持网页版本。

它支持电脑办公，会计课程，室内设计，平面设计，室外设计，机械设计，工业自动化，网页设计，程序开发，影视动画等等视频教程，是一个可以全面提升自己的学习网站。

4：藏书馆

藏书馆是一款高质量的公益网络图书馆，软件的整体界面和阅读体验都是十分不错；是一款质量很高的阅读软件。

它非常好用的免费阅读软件，里面的图书全部免费借阅，向书友借的书15天后会自动归还给对方；软件上面提供了藏书已达五十多万册之多，数量和种类都是十分丰富。

5：鹅说

鹅说是一款将知识卡片化的冷知识软件，是一款小众的有温度的冷知识和百科普及应用；它支持安卓和苹果版本。

它将知识卡片化，点击卡片，卡片会自动翻转，然后带给你的是具体的知识，并且同时关联相关的关键词，让你阅读这个卡片的同时有可能学习到更多领域的知识；这款软件整体界面也是十分清新简洁，一款不仅可以给你带来知识，也可以给你带来不错的阅读体验的小众软件。

6：默沙东诊疗手册

默沙东诊疗手册提供各种医学主题，各种症状的原因，评估，治疗方法，各种紧急情况的的治疗方法，它还以动画和视频的形式让你了解各种医学知识，它还提供各种医学资源；它支持安卓和苹果版本。

7：下厨房

下厨房是一款教你做菜的手机软件；它支持安卓和苹果版本。

它提供各种不同的菜式：家常菜，下饭菜，肉类，早餐，蔬菜，汤粥主食等等，它对不同的食材提供不同的做法，对不同的场景提供不同的做法，并且每一个做法都会以图片和文字结合的形式一步一步地教你如何制作，包括用料和具体做法。

可以说，有了这款软件，不会做菜的你也可以轻松制作出不错的菜。

Flutter Go：Flutter 开发者帮助 App

Sun, 13 Jan 2019 00:00:00 CST

Flutter Go

帮助开发者快速上手 Flutter 内部测试中，1.0 正式版将于 2月 20日发布。

Release安装包下载地址

android下载地址:

iphone下载地址: 暂无

背景

Flutter 是什么?

2018年6月21日Google发布Flutter首个release预览版,作为Google 大力推出的一种全新的响应式，跨平台，高性能的移动开发框架。Flutter是一个跨平台的移动UI框架，旨在帮助开发者使用一套代码开发高性能、高保真的Android和iOS应用。

flutter优点主要包括：

跨平台
开源
Hot Reload、响应式框架、及其丰富的控件以及开发工具
灵活的界面设计以及控件组合
借助可以移植的GPU加速的渲染引擎以及高性能ARM代码运行时已达到高质量的用户体验

Flutter Go 的由来

Flutter学习资料太少，对于英文不好的同学相对来说比较困难
官网文档示例不够健全，不够直观
各个 widget 的用法各异，属性纷繁，要运行一个 widget 的 demo 往往要到处翻阅各种资料

Flutter Go 的优势

详解常用widget多达 130+个
配套 Demo 详解 widget 常规用法
集中整合 widget 案例，一个 APP 搞定所有常用 widget 的用法
持续迭代 ‘追新’ 官方版本

app 预览

Core Team

@minghe

@ryan730

@Nealyang

@hanxu317317

@DeckeDeng

融合通信MaaP会取代APP吗？

Sat, 29 Dec 2018 14:55:13 CST

RCS (Rich Communication Suite, 融合通信)的出现和不断发展，带来了融合文本、图片、音频和视频等的多种消息形态。为使RCS消息给用户带来更加丰富的体验，也为了给行业服务带来更大的便捷，2017年代表全球移动通信领域的行业组织——全球移动通信系统协会GSMA在RCS Universal Profile 2.3中引入了一个全新的标准MaaP（Messaging as a Platform，消息即平台）。MaaP的出现可以让RCS为用户带来全新的消息服务体验，同时也标志着RCS不仅仅是一个融合的富媒体消息业务，更将是一个全新的行业能力平台。

MaaP是什么？

MaaP是RCS Universal Profile最新规范中的核心功能，旨在将短信升级为RCS消息，并将RCS的高级消息传送功能与标准接口整合于Chatbot（聊天机器人）和Plug in（插件）中，能够以无应用程序模式，使用户在消息窗口内就可进行搜索、交互、支付等一站式业务体验。值得注意的是，目前全球有包括76家运营商、OEM终端厂商、操作系统厂商等承诺支持GSMA的UP标准，未来将覆盖全球47亿用户。

MaaP通过接入Chatbot、物联网及其他技术体系和平台，以快应用、快捷支付、统一认证、图文、视频、流量红包等丰富多样的RCS开放消息形态升级RCS消息服务，打造更优用户体验、更具商业价值的RCS消息服务平台，同时也在人与人工智能、与物联网之间创建了更轻、更便捷的连接通道。MaaP的引入不仅为RCS提供了全新的思路和模式，还为运营商进一步创新发展其消息服务提供了的重要机会，并将在未来基于IP消息的服务中起到核心作用。

（基于MaaP技术下的RCS消息——流量红包示意图）

Maap颠覆人机交互模式

其实我们可以把MaaP看做一个Chatbot Store，它的核心是聊天机器人（Chatbot），Chatbot 是一种可以代替APP的全新人机交互模式，它结合AI人工智能，可以根据聊天场景为用户提供智能的个性化服务，升级用户消息体验。同时，MaaP利用Chatbot平台聚合商户，通过RCS消息通道满足商户与客户的交流。

在“RCS+Chatbot+Platform”的方式下，MaaP让我们不需要在手机上安装繁多的APP，就可享受到各行各业的服务，节省时间的同时也节省了手机有限的存储空间；对于商户而言，无需拓展APP的安装量，也不需要强求用户关注商户的公众号，就可以使消息直接触达所有用户。某种意义上来说，Chatbot是一种成本更低、集成程度更高的服务模式，当我们在无应用程序模式下通过 Chatbot获取服务时，我们所使用的手机操作系统也就变得不那么重要了。

MaaP为行业服务提供新思路

接入到MaaP平台的Chatbot让我们可以更快更便捷地获取服务。当我们遇到困难，希望向客服人员寻求帮助的时候，无需拨打客服电话，收听冗长的提示语，只要在手机上通过Chatbot发一个消息就可以获得回复，提高了用户与商户彼此之间的沟通效率。Chatbot就像是我们的虚拟管家，为我们提供天气查询、购物、医疗、订餐、打的、机票查询预订等全方位的服务；并通过记录我们的习惯、了解我们的品味，进而推送更个性化的服务，让我们省去输入搜索等操作。

MaaP平台的A2P消息拥有广阔的发展空间，基于RCS消息的聊天机器人具有广泛的应用场景，随着人工智能的不断发展，未来可应用在银行、航空公司、铁路部门、餐馆、地面交通等众多行业及部门。

MaaP革新应用生态链

随着5G时代的来临，商业消息拥有巨大的市场前景，众多通讯公司及互联网巨头，如三星与AT&T等企业已经率先发展MaaP产品，成为了国际市场的潮流风向标。据悉，在国内中国移动研究院也正与中移互联网公司一起基于MaaP国际标准和中国移动企业标准，共同研发出了全新的A2P消息平台型产品。

未来，MaaP将以Chatbot代替APP为我们提供智能交互服务，我们在Chatbot聊天场景中即可快速得到回复，享受到一站式服务。而基于手机终端原生信息界面，支持快应用、移动认证、图文、视频等丰富多样的开放消息形态及功能的MaaP，也完全实现了与OTT消息能力一致。此外，MaaP还可通过接入物联网，利用RCS消息将人与各类智能硬件进行连接，成为物联网与互联网便捷的大连接入口。通过改变人机交互方式、升级用户消息体验，我们可以期待在不久的将来，MaaP将革新应用的生态链，并为商业消息和通信行业的发展带来新机遇。

Debugging .NET Core app from a command line on Linux - Dots and Brackets: Code Blog

Wed, 19 Dec 2018 09:15:45 CST

Million years ago, way before the ice age, I was preparing small C++ project for “Unix Programming” university course and at some point had to debug it via command line. That was mind blowing. And surprisingly productive. Apparently, when nothing stands in the way, especially UI, debugging can become incredibly focused.

Since .NET Framework got his cross platform twin brother .NET Core, I was looking forward to repeat the trick and debug .NET Core app on Ubuntu via command line. Few days ago it finally happened and even though it wasn’t a smooth ride, that was quite an interesting experience. So, let’s have look.

Setup

We’ll need Ubuntu, .NET Core SDK, lldbdebugger and a sample app. Late April, 2018 was the month of updates, so now we have shiny new Ubuntu 18.04and . NET Core SDK 2.1 RC1, which finally got its libsosplugin.socompiled against lldb-3.9, so v3.6we had to use for previous .NETs finally can rest in peace. As for demo project, any .NET Core hello-world wannabe with local variables and call stacks will do.

The tools

I’ll install all of that in a VM and here’s Vagrantfile with its provision.shfile to do so:

Vagrantfile

Ruby

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/bionic64"

  config.vm.provider "virtualbox" do |v|
    v.memory = 1024
  end

  config.vm.provision "shell", path: "provision.sh"
end

Vagrant.configure("2")do|config|

config.vm.box="ubuntu/bionic64"

config.vm.provider"virtualbox"do|v|

v.memory=1024

end

config.vm.provision"shell",path:"provision.sh"

end

provision.sh

Shell

#!/bin/bash

function install_lldb39 {
	echo "deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.9 main" | tee /etc/apt/sources.list.d/llvm.list
	wget -O - http://llvm.org/apt/llvm-snapshot.gpg.key | apt-key add -
	apt-get update -y
	apt-get install -y lldb-3.9
}

function install_ms_package_source {
	wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg
	mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
	wget -q https://packages.microsoft.com/config/ubuntu/18.04/prod.list 
	mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
}

function install_netsdk21rc1 {
	install_ms_package_source

	apt-get install -y apt-transport-https
	apt-get update -y
	apt-get install -y dotnet-sdk-2.1.300-rc1-008673
}

function main {
	install_netsdk21rc1
	install_lldb39
}

main

#!/bin/bash

functioninstall_lldb39{

echo"deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty-3.9 main"|tee/etc/apt/sources.list.d/llvm.list

wget-O-http://llvm.org/apt/llvm-snapshot.gpg.key|apt-keyadd-

apt-getupdate-y

apt-getinstall-ylldb-3.9

}

functioninstall_ms_package_source{

wget-qO-https://packages.microsoft.com/keys/microsoft.asc|gpg--dearmor>microsoft.asc.gpg

mvmicrosoft.asc.gpg/etc/apt/trusted.gpg.d/

wget-qhttps://packages.microsoft.com/config/ubuntu/18.04/prod.list

mvprod.list/etc/apt/sources.list.d/microsoft-prod.list

}

functioninstall_netsdk21rc1{

install_ms_package_source

apt-getinstall-yapt-transport-https

apt-getupdate-y

apt-getinstall-ydotnet-sdk-2.1.300-rc1-008673

}

functionmain{

install_netsdk21rc1

install_lldb39

}

main

The project

It’s very simple. Let’s have a function that returns a number of ticks passed since last measurement. It’s absolutely useless except for the fact that it will have local variables and some arguments to examine later.

Program.cs

using System;

namespace console
{
  class Program
  {
    static void Main(string[] args)
    {
      while (true)
      {
        var lastTick = DateTime.Now.Ticks;
        System.Threading.Thread.Sleep(2000);
        var ticksElapsed = GetTicksElapsed(lastTick);
      }
    }

    static long GetTicksElapsed(long lastTicks)
    {
      var currentTicks = DateTime.Now.Ticks;
      var delta = lastTicks - currentTicks;
      return delta;
    }
  }
}

usingSystem;

namespaceconsole

{

classProgram

{

staticvoidMain(string[]args)

{

while(true)

{

varlastTick=DateTime.Now.Ticks;

System.Threading.Thread.Sleep(2000);

varticksElapsed=GetTicksElapsed(lastTick);

}

staticlongGetTicksElapsed(longlastTicks)

{

varcurrentTicks=DateTime.Now.Ticks;

vardelta=lastTicks-currentTicks;

returndelta;

}

Attaching debugger

OK, so let’s start the whole thing and try to connect debugger to it:

provision.sh

Shell

dotnet build
# ...
dotnet bin/Debug/netcoreapp2.1/console.dll &
# [1] 6124

dotnetbuild

# ...

dotnetbin/Debug/netcoreapp2.1/console.dll&

# [1] 6124

The program is producing no output and running in a background thread, so knowing the process id ( 6124) I can start lldb, load SOS plugin and connect to dotnet process:

Attach debugger

Shell

find /usr -name libsosplugin.so # find SOS plugin
# /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.0-rc1/libsosplugin.so
sudo lldb-3.9                   # start LLDB
(lldb) plugin load /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.0-rc1/libsosplugin.so
(lldb) process attach -p 6124
# Process 6124 stopped
# * thread #1: tid = 6124, 0x00007fef21a92ed9 libpthread.so.0`__pthread_cond_timedwait + 649, name = 'dotnet', stop reason = signal SIGSTOP
# ...

find/usr-namelibsosplugin.so# find SOS plugin

# /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.0-rc1/libsosplugin.so

sudolldb-3.9 # start LLDB

(lldb)pluginload/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.0-rc1/libsosplugin.so

(lldb)processattach-p6124

# Process 6124 stopped

# * thread #1: tid = 6124, 0x00007fef21a92ed9 libpthread.so.0`__pthread_cond_timedwait + 649, name = 'dotnet', stop reason = signal SIGSTOP

# ...

Nothing difficult. We can make sure that SOS has kicked in by examining e.g. managed threads before moving on to setting up an actual breakpoint:

View managed threads

Shell

(lldb) clrthreads
# ThreadCount:      2
# UnstartedThread:  0
# BackgroundThread: 1
# PendingThread:    0
# DeadThread:       0
# Hosted Runtime:   no
#                                                                                                         Lock  
#   ID OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception
#    1    1 17ec 00000000022884A0  2020020 Preemptive  00007FEE8002DE50:00007FEE8002FB30 000000000226F620 0     Ukn 
#    7    2 17f2 00000000022AB0D0    21220 Preemptive  0000000000000000:0000000000000000 000000000226F620 0     Ukn (Finalizer)

(lldb)clrthreads

# ThreadCount: 2

# UnstartedThread: 0

# BackgroundThread: 1

# PendingThread: 0

# DeadThread: 0

# Hosted Runtime: no

# Lock

# ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception

# 1 1 17ec 00000000022884A0 2020020 Preemptive 00007FEE8002DE50:00007FEE8002FB30 000000000226F620 0 Ukn

# 7 2 17f2 00000000022AB0D0 21220 Preemptive 0000000000000000:0000000000000000 000000000226F620 0 Ukn (Finalizer)

Setting up a breakpoint

For that we can use bpmd command introduced by SOS plugin. The only parameter it needs is a method name or its descriptor address, so in order to set up a breakpoint in a method called GetTicksElapsed, which is a member of Program class inside of console.dllassembly, here’s what I’d do:

Add a breakpoint

Shell

(lldb) bpmd console.dll Program.GetTicksElapsed
MethodDesc = 00007FEEA63F57E8
Setting breakpoint: breakpoint set --address 0x00007FEEA7061777 [console.Program.GetTicksElapsed(Int64)]
Adding pending breakpoints...

(lldb)bpmdconsole.dllProgram.GetTicksElapsed

MethodDesc=00007FEEA63F57E8

Settingbreakpoint:breakpointset--address0x00007FEEA7061777[console.Program.GetTicksElapsed(Int64)]

Addingpendingbreakpoints...

As a side note, sometimes it might be actually easier to add a breakpoint by method descriptor address instead. Those are all over the place – in call stacks, instruction pointers, in class method tables. For instance, this is the call stack of currently selected thread:

Call stack

Shell

(lldb) clrstack
# OS Thread Id: 0x17ec (1)
#         Child SP               IP Call Site
# 00007FFE0D679AA8 00007fef21a92ed9 [HelperMethodFrame: 00007ffe0d679aa8] System.Threading.Thread.SleepInternal(Int32)
# 00007FFE0D679BF0 00007FEEA7165ABB System.Threading.Thread.Sleep(Int32)
# 00007FFE0D679C00 00007FEEA70616FC console.Program.Main(System.String[]) [/home/vagrant/console/Program.cs @ 12]
# 00007FFE0D679F10 00007fef2023de1f [GCFrame: 00007ffe0d679f10] 
# 00007FFE0D67A310 00007fef2023de1f [GCFrame: 00007ffe0d67a310]

(lldb)clrstack

# OS Thread Id: 0x17ec (1)

# Child SP IP Call Site

# 00007FFE0D679AA8 00007fef21a92ed9 [HelperMethodFrame: 00007ffe0d679aa8] System.Threading.Thread.SleepInternal(Int32)

# 00007FFE0D679BF0 00007FEEA7165ABB System.Threading.Thread.Sleep(Int32)

# 00007FFE0D679C00 00007FEEA70616FC console.Program.Main(System.String[]) [/home/vagrant/console/Program.cs @ 12]

# 00007FFE0D679F10 00007fef2023de1f [GCFrame: 00007ffe0d679f10]

# 00007FFE0D67A310 00007fef2023de1f [GCFrame: 00007ffe0d67a310]

And this how setting up a breakpoint in Main method might look like:

Set a breakpoint by method descriptor

Shell

(lldb) ip2md 00007FEEA70616FC
# MethodDesc:   00007feea63f57d8
# Method Name:          console.Program.Main(System.String[])
# Class:                00007feea7131088
# MethodTable:          00007feea63f5800
# mdToken:              0000000006000001
# Module:               00007feea63f43e0
# IsJitted:             yes
# Current CodeAddr:     00007feea7061690
# Code Version History:
#   CodeAddr:           00007feea7061690  (Non-Tiered)
#   NativeCodeVersion:  0000000000000000
# Source file:  /home/vagrant/console/Program.cs @ 12
(lldb) bpmd -md 00007feea63f57d8
# MethodDesc = 00007FEEA63F57D8
# Setting breakpoint: breakpoint set --address 0x00007FEEA7061690 [console.Program.Main(System.String[])]

(lldb)ip2md00007FEEA70616FC

# MethodDesc: 00007feea63f57d8

# Method Name: console.Program.Main(System.String[])

# Class: 00007feea7131088

# MethodTable: 00007feea63f5800

# mdToken: 0000000006000001

# Module: 00007feea63f43e0

# IsJitted: yes

# Current CodeAddr: 00007feea7061690

# Code Version History:

# CodeAddr: 00007feea7061690 (Non-Tiered)

# NativeCodeVersion: 0000000000000000

# Source file: /home/vagrant/console/Program.cs @ 12

(lldb)bpmd-md00007feea63f57d8

# MethodDesc = 00007FEEA63F57D8

# Setting breakpoint: breakpoint set --address 0x00007FEEA7061690 [console.Program.Main(System.String[])]

Easy peasy. Now, let’s resume the program with program continue command and see how it almost immediately stops at GetLastTicks:

Breakpoint hit

Shell

(lldb) process continue
# Process 6124 resuming
(lldb) Process 6124 stopped
# * thread #1: tid = 6124, 0x00007feea7061777, name = 'dotnet', stop reason = breakpoint 1.1
#     frame #0: 0x00007feea7061777
# ...

(lldb)processcontinue

# Process 6124 resuming

(lldb)Process6124stopped

# * thread #1: tid = 6124, 0x00007feea7061777, name = 'dotnet', stop reason = breakpoint 1.1

# frame #0: 0x00007feea7061777

# ...

Good. Now it’s time to look around.

Examining call stacks

clrstack (or sos ClrStack) does exactly that:

View call stack

Shell

(lldb) clrstack
# OS Thread Id: 0x17ec (1)
#         Child SP               IP Call Site
# 00007FFE0D679BB0 00007FEEA7061777 console.Program.GetTicksElapsed(Int64) [/home/vagrant/console/Program.cs @ 18]
# 00007FFE0D679C00 00007FEEA7061706 console.Program.Main(System.String[]) [/home/vagrant/console/Program.cs @ 13]
# ...

(lldb)clrstack

# OS Thread Id: 0x17ec (1)

# Child SP IP Call Site

# 00007FFE0D679BB0 00007FEEA7061777 console.Program.GetTicksElapsed(Int64) [/home/vagrant/console/Program.cs @ 18]

# 00007FFE0D679C00 00007FEEA7061706 console.Program.Main(System.String[]) [/home/vagrant/console/Program.cs @ 13]

# ...

The output is pretty straightforward. Even line numbers and file names are there. But clrstack can do more than that. For instance, it also has -p parameter, which will include function arguments into the output, and that’s something really, really useful:

View stack arguments

Shell

(lldb) clrstack -p
# OS Thread Id: 0x17ec (1)
#         Child SP               IP Call Site
# 00007FFE0D679BB0 00007FEEA7061777 console.Program.GetTicksElapsed(Int64) [/home/vagrant/console/Program.cs @ 18]
#     PARAMETERS:
#         lastTicks (0x00007FFE0D679BE0) = 0x08d5bacfae88e0b3
# 
# 00007FFE0D679C00 00007FEEA7061706 console.Program.Main(System.String[]) [/home/vagrant/console/Program.cs @ 13]
#     PARAMETERS:
#         args (0x00007FFE0D679C40) = 0x00007fee8001e5c0
# ...

(lldb)clrstack-p

# OS Thread Id: 0x17ec (1)

# Child SP IP Call Site

# 00007FFE0D679BB0 00007FEEA7061777 console.Program.GetTicksElapsed(Int64) [/home/vagrant/console/Program.cs @ 18]

# PARAMETERS:

# lastTicks (0x00007FFE0D679BE0) = 0x08d5bacfae88e0b3

# 00007FFE0D679C00 00007FEEA7061706 console.Program.Main(System.String[]) [/home/vagrant/console/Program.cs @ 13]

# PARAMETERS:

# args (0x00007FFE0D679C40) = 0x00007fee8001e5c0

# ...

Let’s examine what we’ve got. lastTicks value is 0x8d5bacfae88e0b3, which is 636620323491995827 in decimal, which indeed corresponds to current UTC date:

As for args argument, most likely that’s program’s command line arguments and this is something easy to confirm:

Examine args

Shell

(lldb) dumpobj 0x00007fee8001e5c0
# Name:        System.String[]
# MethodTable: 00007feea6e26308
# EEClass:     00007feea65c64a8
# Size:        24(0x18) bytes
# Array:       Rank 1, Number of elements 0, Type CLASS
# Fields:
# None

(lldb)dumpobj0x00007fee8001e5c0

# Name: System.String[]

# MethodTable: 00007feea6e26308

# EEClass: 00007feea65c64a8

# Size: 24(0x18) bytes

# Array: Rank 1, Number of elements 0, Type CLASS

# Fields:

# None

Yup, that’s empty array of strings allright.

Examining local variables

Bad news here. clrstack -i is the command to see local variables and their values. However, in lldb-3.9 and libsosplugin.so, which comes with .NET Core 2.1 RC1, this command immediately causes segmentation fault and crash of lldbprocess. Haven’t checked it in earlier versions, but here it happens 100% of the time.

Stepping in/over/out

Unlike with WinDBG, it doesn’t look like there are SOS commands for stepping in, out or over the next statement or function. However, there’re still native commands, which will step over assembly instructions, but it’s better than nothing. Especially when we can call clrstackand check where in managed realm we currently are:

Step over

Shell

(lldb) next
(lldb) Process 6124 stopped
# * thread #1: tid = 6124, 0x00007feea7061778, name = 'dotnet', stop reason = instruction step into
#     frame #0: 0x00007feea7061778
# ->  0x7feea7061778: callq  0x7feea6af3cd0
#     0x7feea706177d: movq   %rax, -0x38(%rbp)
#     0x7feea7061781: movq   -0x38(%rbp), %rdi

(lldb)next

(lldb)Process6124stopped

# * thread #1: tid = 6124, 0x00007feea7061778, name = 'dotnet', stop reason = instruction step into

# frame #0: 0x00007feea7061778

# -> 0x7feea7061778: callq 0x7feea6af3cd0

# 0x7feea706177d: movq %rax, -0x38(%rbp)

# 0x7feea7061781: movq -0x38(%rbp), %rdi

callq, if I’m not mistaken, is the instruction to execute procedure at given address, so step will probably jump us somewhere:

Step into

Shell

(lldb) step  
(lldb) Process 6124 stopped
# * thread #1: tid = 6124, 0x00007feea6af3cd0, name = 'dotnet', stop reason = instruction step into
#     frame #0: 0x00007feea6af3cd0
# ->  0x7feea6af3cd0: pushq  %rbp
# ...
(lldb) clrstack
# OS Thread Id: 0x17ec (1)
#         Child SP               IP Call Site
# 00007FFE0D679BA8 00007FEEA6AF3CD0 System.DateTime.get_Now()
# 00007FFE0D679BB0 00007FEEA706177D console.Program.GetTicksElapsed(Int64) [/home/vagrant/console/Program.cs @ 19]

(lldb)step

(lldb)Process6124stopped

# * thread #1: tid = 6124, 0x00007feea6af3cd0, name = 'dotnet', stop reason = instruction step into

# frame #0: 0x00007feea6af3cd0

# -> 0x7feea6af3cd0: pushq %rbp

# ...

(lldb)clrstack

# OS Thread Id: 0x17ec (1)

# Child SP IP Call Site

# 00007FFE0D679BA8 00007FEEA6AF3CD0 System.DateTime.get_Now()

# 00007FFE0D679BB0 00007FEEA706177D console.Program.GetTicksElapsed(Int64) [/home/vagrant/console/Program.cs @ 19]

Yup, we’re in DateTime.Now‘s getter now. I actually could test where callq leads without stepping into the method itself. Checking callq‘s argument would tell the same story:

Dump IP

Shell

(lldb) ip2md 0x7feea6af3cd0
# MethodDesc:   00007feea66448c0
# Method Name:          System.DateTime.get_Now()
# ...

(lldb)ip2md0x7feea6af3cd0

# MethodDesc: 00007feea66448c0

# Method Name: System.DateTime.get_Now()

# ...

Stepping out from current procedure could’ve been easy, if it didn’t jump 2 levels up instead of one every other time I used it. Maybe it has something to do with the fact that real call stack is actually a mixture of managed and unmanaged entries, whereas clrstackcommand shows only managed ones ( -f argument would show all of them). Then, I couldn’t find an alias for step-out command and had to use its full form instead: thread step-out.

Conclusion

So this is how debugging a .NET Core app from a command line on Linux feels like. It’s surprisingly hard to find any documentation for it, so probably I missed a command or to. Faulting clrstack -i also doesn’t make the debugging easier. But still it’s really cool to be able to add a breakpoint, see how execution goes and examine call stack parameters – all from a command line, on any machine and for any project. It’s also surprising to see how thin the layer between a managed code and assembly language is. If I was able to convert callq instruction argument to managed method description, maybe I’ll be able to convert CPU register values to managed objects as well. Who knows.

史上最全最详细的APP运营推广策划方案

Wed, 24 Oct 2018 13:35:45 CST

一款成功的应用，开发APP只是第一步，比前者更重要的是APP运营，APP就像是一个需要不断包装和投入的“明星”，需要不断制造“话题”来吸引用户，靠一版版的优化升级和足够的内容、活动来支撑，否则很快就会泯灭于人们的视野中，因此，比APP开发更难的是后续的运营和推广。

目前市场上，大家都没有非常清晰的APP推广渠道和方式，目前，大家都在摸索的阶段，除了常规的安卓和苹果市场以外，其余的推广渠道和方式各公司因为资源的不同而不同，在此，马海祥特意为大家整理了最全最详细的APP运营推广策划方案。

一、竞品分析

APP分析方法和分析任何一款产品时做的竞品分析是一样的，这里把之前总结过的一些竞品分析的内容整理了下，内容比较适合新人，分享给大家。

1、选择竞品，做好定位

一般来说，竞品分析选择两个产品最好，最多三个，那么我们该如何获取竞品呢？

A、百度搜索类似产品关键词，假设你的产品是一款三国主题的卡牌游戏，你可以输入主要关键词“三国 ”,一般排在自然排名前面，百度竞价推广前面的产品都是竞品。

B、各大移动应用市场上用关键词查找，如应用市场，应用宝，豌豆荚等。

C、行业网站上查找最新信息。

D、咨询类网站如艾瑞、DCCI、Alexa等是相对靠谱渠道。

还有其他的方法，如通过参加行业展会，同行交流等渠道获取竞争对手信息，这里不一一介绍了。

2、竞品分析，得出结论

选择恰当的分析方法来分析，根据分析得出结论，一般来说，比较全面的竞品分析要从用户，市场趋势，功能设计，运营推广策略等方面来展开，这里我们把它细化成以下几个维度：

（1）、市场趋势、业界现状。

（2）、竞争对手的企业愿景、产品定位及发展策略。

（3）、目标用户。

（4）、市场数据。

（5）、核心功能。

（6）、交互设计。

（7）、产品优缺点。

（8）、运营及推广策略。

（9）、总结&行动点。

对于移动互联网部门市场推广总监来讲，可以只关心市场部分，功能及设计这块可以忽略，如从1,2,3,4,7,8这几部分对竞品进行分析，重点关注市场数据及运营推广策略。

这里拿一款移动旅游APP来说，运营数据可从下载量、用户数、留存率、转化率、活跃用户数、活跃时长等来进行竞品分析。

运营及推广策略可从竞品的渠道管理来分析，如应用市场投放，移动论坛，市场活动，软文投放，社交化媒体表现等（具体可查看马海祥博客《 APP营销推广的渠道、策略和方法技巧》的相关介绍）。

3、根据结论，得出建议

通过对上述竞品分析，可以大致得出一个比较有市场商业价值的结论，然后跟结论制定一个合理的APP运营推广方案。

二、产品定位

将产品定位单独一个篇幅来讨论可见其重要性，清晰的产品定位，目标用户群定位是运营推广的基石，目标用户群分析的越透彻，越清晰，对于后期产品推广起关键性助推作用。

1、产品定位

一句话清晰描述你的产品，用什么样的产品满足用户或者用户市场，比如：

陌陌：一款基于地理位置的移动社交工具。

QQ空间：一个异步信息分享和交流的平台，是QQ即时通讯工具的补充。

91运营网：分享互联网产品，电子商务运营干货。

酷social：关注移动社交发展趋势，探讨移动社交商业价值。

2、产品核心目标

产品目标往往表现为解决目标用户市场一个什么问题，这个问题分析的越透彻，产品核心目标越准确。

如：360安全卫士解决用户使用电脑的安全问题；微信为用户提供流畅语音沟通的移动应用。

3、目标用户定位

一般按照年龄段，收入，学历，地区几个维度来定位目标用户群体。

4、目标用户特征

常用用户特征：年龄，性别，出生日期，收入，职业，居住地，兴趣爱好，性格特征等。

用户技能：熟练电脑办公，外语能力强。

与产品相关特征：

a、电子商务类：购物习惯，年度消费预算等。

b、交友类：是否单身，择偶标准。

c、游戏类：是否喜欢3D游戏，是否有同类型游戏经验。

5、用户角色卡片

根据目标用户群体围绕目标用户特征建立用户角色卡片。

6、用户使用场景

用户使用场景是指将目标用户群投放到实际的使用场景中。

还是以上APP为例，张三每天来到了万达商场某体育用品店，看到了科比二代球鞋售价1400元，顿时心动想入手，他用比价APP进行二维码扫描发现京东售价800，淘宝售价810，APP主动提示建议在京东购买，张三迅速浏览了商品的高清图片和产品说明，因为店家可以包邮，所以张三放弃了在线下购买。

三、推广方案

移动互联网行业，创业公司市场则适合多面出击，把能够想到的各种途径方式都去尝试，用最小的投入把品牌效果最大化（具体可查看马海祥博客《企业该如何通过APP营销树立品牌》的相关介绍）。

在想到的100种方法里，不断测试出一种最有效的方法，剔除掉其中99个，集中火力把手里的资源集中在一个可能爆发的点上，不断放大，不断分析，等待爆发。最终吸引更多的注册用户，提高自己的市场份额。

1、渠道推广

APP运营都离不开推广，要学会从运营中找的问题，总结良好经验，做优质渠道，改良产品，对于渠道推广，有以下几点可供大家参考：

（1）、线上渠道

A、基础上线：各大下载市场、应用商店、大平台、下载站的覆盖Android版本发布渠道，因为在马海祥看来，推广的第一步是要上线，这是最基础的，无需砸钱，只需最大范围的覆盖。

下载市场：安卓、机锋、安智、应用汇、91、木蚂蚁、N多、优亿、安机、飞流等。

应用商店：geogle商店、HTC商城、历趣、十字猫、开奇、爱米、我查查、魅族商店、联想开发者社区、oppo应用商店等。

大平台：MM社区、沃商店、天翼空间、华为智汇云、腾讯应用中心等。

客户端：豌豆荚手机精灵、91手机助手、360软件管家等。

wap站：泡椒、天网、乐讯、宜搜等。

web下载站：天空、华军、非凡、绿软等。

iOS版本发布渠道：AppStore、91助手、pp助手、网易应用中心、同步推、快用苹果助手、itools、限时免费大全。

B、运营商渠道推广：中国移动，中国电信，中国联通

用户基数较大，可以将产品预装到运营商商店，借力于第三方没有的能力，如果是好的产品，还可以得到其补助和扶植。

市场部门要有专门的渠道专员负责与运营商沟通合作，出方案进行项目跟踪。

C、第三方商店：上述A类都属于第三方商店

由于进入早，用户积累多，第三方商店成为了很多APP流量入口，全国有近百家第三方应用商店，渠道专员要准备大量素材，测试等与应用市场对接。各应用市场规则不一，如何与应用市场负责人沟通，积累经验与技巧至关重要。

资金充足的情况下，可以投放一些广告位及推荐等。

D、手机厂商商店

大厂家都在自己品牌的手机里预装商店，如联想乐商店，HTC市场，oppo nearme，魅族市场，moto智件园等，渠道部门需要较多运营专员来跟手机厂商商店接触（具体可查看马海祥博客《关于App推广运营的8条隐藏技巧》的相关介绍）。

E、积分墙推广

“积分墙”是在一个应用内展示各种积分任务（下载安装推荐的优质应用、注册、填表等），以供用户完成任务获得积分的页面，用户在嵌入积分墙的应用内完成任务，该应用的开发者就能得到相应的收入。

积分墙起量快，效果显而易见，大部分是采用CPA形式，价格1-3元不等。但以活跃用户等综合成本考量，成本偏高，用户留存率低。

业内公司有tapjoy，微云，有米，万普等。

积分墙适合大型有资金，需要尽快发展用户的团队。

F、刷榜推广

这种推广乃非正规手段，但是在国内非常的受欢迎，毕竟绝大部分苹果手机用户都会实用APP Store去下载APP，如果你的APP直接都在前几名的位置，当然可以快速获得用户的关注，同时获得较高的真实下载量。

不过，刷榜的价格是比较高的，国内榜top25名的价格在每天1万元左右，top5的价格每天需要两万多。由于这种推广成本比较高，所以一般会配合新闻炒作一起搞，这样容易快速的出名（具体可查看马海祥博客《详解APP应用分发平台的榜单推荐和搜索排名规则》的相关介绍）。

G、社交平台推广

目前主流的智能手机社交平台，潜在用户明确，能很快的推广产品，这类推广基本采用合作分成方式，合作方法多样，业内公司有微云，九城，腾讯，新浪等。

如2010年6月非诚勿扰的交友软件，在微云社交平台上自传播自推广，上线第一个月用户达到32万。

H、广告平台

起量快，效果显而易见，但成本较高，以目前主流平台为例，CPC价格在0.3-0.8元，CPA在1.5元-3元之间。

不利于创业融资前的团队推广使用。

业内公司有admob，多盟，微云，有米，亿动等。

I、换量

对于换量，马海祥了解到的主要有两种方式：

①、应用内互相推荐

这种方式可以充分利用流量，增加曝光度和下载量，量级不大，但曝光度不错，有内置推荐位的应用可以相互进行换量，但这需要以一定的用户量作为基础。

②、买量换量

如果自身无法给某一应用带量或者量很小，可以找网盟跑量，以换取应用商店优质的资源位或者折算成钱进行推广，这种方式也是比较实用的方式，包括应用宝、小米等在内的商店都可以换量，通过某些代理，还能跟360等进行换量，可能会比直接在360做CPT有更好的效果，商店：CP一般以2:1的方式进行换量。

（2）、线下渠道

A、手机厂商预装

出厂就存在，用户转化率高，最直接发展用户的一种方式（具体可查看马海祥博客《如何利用线下预装推广使APP立刻拥有千万用户》的相关介绍）。

用户起量周期长，从提交测试包测试-过测试-试产-量产-销售到用户手中需要3-5个月时间。

推广成本：应用类产品预装量付费价格在0.5-1元不等，CPA方式价格在1.5-4元不等。游戏类产品，采取免费预装，后续分成模式，CPA价格在2-3元之间。

业内公司：华为，中兴，酷派，TCL，波导，OPPO，魅族，海信等。

操作难点：品牌众多，人员层级多，产品项目多，需要有专业的团队进行针对性的推荐与维护关系。

B、水货刷机

起量快，基本上2-4天就可以看到刷机用户，数量大，基本上一天可以刷几万台。

重刷现象严重，基本上一部手机从总批到渠道到店面会被刷3-5次，推广成本剧增，用户质量差，不好监控。

基本上刷机单一软件CPA在1-2元，包机一部机器价格在5-10元之间。

业内公司：XDA,酷乐，乐酷，刷机精灵。

C、行货店面

用户质量高，粘度高，用户付费转化率高，见用户速度快。

店面多，店员培训复杂，需要完善的考核及奖励机制。

基本上CPA价格在1.5-3元之间，预装价格在0.5-1元之间。

业内公司：乐语，中复，天音，中邮，苏宁等。

案例：2010底微云与国内知名连锁手机卖场进行合作试点，将合作的光盘放到店面进行打包销售给用户，8万套光盘激活用户达到了一半。

2、新媒体推广

接下来，马海祥就重点来说一下App推广方式中的新媒体推广，具体包括以下几个方面：

（1）、内容策划

内容策划前需做好受众定位，分析得出核心用户特征。

坚持原创内容的产出，在内容更新上保持一天三条左右有趣的内容。

抓住当周或当天的热点跟进。

创意，还是创意，让你的产品讲故事，拟人化（具体可查看马海祥博客《 8个奇葩且好玩的国外APP应用案例》的相关介绍）。

（2）、品牌基础推广

百科类推广：在百度百科，360百科建立品牌词条。

问答类推广：在百度知道，搜搜问答，新浪爱问，知乎等网站建立问答。

（3）、论坛，贴吧推广

机锋、安卓、安智……，在手机相关网站的底端都可以看到很多的行业内论坛。

马海祥建议推广者以官方贴、用户贴两种方式发帖推广，同时可联系论坛管理员做一些活动推广。

发完贴后，应当定期维护好自己的帖子，及时回答用户提出的问题，搜集用户反馈的信息，以便下个版本更新改进。

第一阵容：机锋论坛、安卓论坛、安智论坛。

第二阵容：魔趣网、安卓论坛、魅族论坛。

第三阵容：风暴论坛、木蚂蚁论坛、DOSPY论坛。

（4）、微博推广

内容：将产品拟人化，讲故事，定位微博特性，坚持原创内容的产出，在微博上抓住当周或当天的热点跟进，保持一定的持续创新力，这里可以参考同行业运营比较成功的微博大号，借鉴他们的经验。

互动：关注业内相关微博账号，保持互动，提高品牌曝光率。

活动：必要时候可以策划活动，微博转发等。

（5）、微信推广

微信公众号的运营推广需要一定时间沉淀，这里可以参考几步曲：

内容定位：结合产品做内容聚合推荐，内容不一定要多，但是一定要精并且符合微信号的定位。

种子用户积累：初期可以给定个KPI指标，500个粉丝一个门槛，种子用户可以通过同事好友，合作伙伴推荐，微博引流，官网引流等。

小号积累：开通微信小号，每天导入目标客户群。

小号导大号：通过小号的粉丝积累推荐微信公众号，将粉丝导入到微信公众号。

微信互推：当粉丝量达到一定预期后，可以加入一些微信互推群（关于微信推广经验分享，这里不再展开讨论了，具体可查看马海祥博客《微信公众号该如何做营销推广》的相关介绍，也可以加入我的微信公众号mahaixiangboke交流）。

（6）、PR传播

PR不是硬广告，学会在对的途径讲一个动人的故事是非常重要的，互联网时代人人都是传播源，无论微博Kol、微信公众号、媒体网站的专栏或各大社交网站，我得去研究如何利用这些平台来讲述一个好的品牌的故事，反之，这些平台也会是用户对品牌产生UGC的最好渠道。

在初创公司，作为PR需要把公司每一个阶段的方向都了解透彻，然后学会向市场、投资人、用户传递一个有力的声音，这个声音并不是生硬的广而告之，而是抛出一个话题让大家对你的故事所感兴趣，并带动大家如何把兴趣引到你的产品上来，最好形成行业的热议话题。

以下有几个策略：

①、用日常稿件保持稳定的曝光

我们会定期做一张传播规划表，每个月要根据公司和产品的变化来决定该向外界传递什么声音，恰当的表达和持续的内容产出会让公司的曝光度及行业的关注度逐渐提高。

②、维护好已有的媒体资源，积极扩展新资源

对于自己原来熟识的记者和媒体，我仍会保持续的沟通和交流，告诉他们，我们的团队在做怎么样的一件事，深信只有反复的沟通，才会把故事的闪光点打磨得抓住人心，而作为PR也更能及时嗅到媒体关注的兴趣点，为下一次的报道梳理做好充分准备。

在创业公司对PR的经费并不是非常充足的情况下，我们需要仔细去分析，在什么样的发展阶段和进度，需要利用的什么样的途径和资源去支撑公司的发声和观点，所以我们对自己的要求是每周都有计划的去拓展一些新的媒体资源，这样能为之后做事件输出时能有合适的渠道的进行支撑。

③、选择的渠道决定了传播的效果

说什么故事，用哪种方式呈现传播效果会最佳，这对于渠道的选择就显得尤为重要，比如对于公司创始人的一些采访，我们可能更倾向于行业及财经相关的权重高的纸媒，有利于大面积的带动传播。

对于产品的发声，我们更倾向于科技类的新媒体，在行业内能引起更快速的关注力，而对于事件话题性的新闻，我们更青睐于选择大型门户类网站。

对于自媒体这领域，实力参差不齐，选择有中立观点和实力派的自媒体发声，不失为好的选择，但是成本对创业公司来说，并不是性价比最高的。而对于电视媒体，选择对和你潜在用户相吻合的节目，是一个能快速让产品呈爆发式增长的途径。

最后，要记得做好对营销传播效果的评估，这些可能包括人群的覆盖率、点击量、阅读量，点赞量等。每一次的数据，都会告诉你下一次的内容应该怎样做得更赞。

而PR作为连接内外的桥梁，最好也要藏身于用户中间，在深度沟通中突出品牌的个性。

（7）、事件营销

事件营销绝对是个体力活和脑力活，这需要整个团队保持敏锐的市场嗅觉，此外还需要有强大的执行力，配合一定的媒体资源，事件才得以在最快的速度推出去。

事件营销的前提必须是团队成员需要每天接触大量新鲜的资讯，把这些信息整合，也需要养成随时记录下一些闪现的灵感创意并和成员们及时分享碰撞。

对于能贴上产品的创意点结合点，我们会马上进行头脑风暴，对事件的始终进行推理，若确定方案可行，那么马上做出与之匹配的传播计划，开始做项目预算并一边准备好渠道资源。

（8）、数据分析

每周花一些时间去认真分析每一条微博、微信、每一个渠道背后的数据，你一定会发现传播度高的内容背后的契合点和关联性，这样非常有利于自己官方微博、微信内容质量的提升，运营起来也更接地气（具体可查看马海祥博客《 App运营必须关注的5个数据指标》的相关介绍）。

3、线下推广

利用宣传经费印制纸质宣传单和各种海报，做宣传。

（1）、介绍海报：在人流量多且可免费宣传的地方张贴海报宣传。

（2）、宣传单：与合作商家商议，将宣传单曝光于商家跟用户接触的地方。

（3）、地推卡传单：制作精美传单，在办公区域相对集中的地方、商场发布传单。

四、推广预算

根据以上推广方案对各渠道做预算配比，与老板敲定最后的第一期投放预算。

五、制定目标

对于一款APP，马海祥觉得由两方面决定关注指标：

1、产品运营阶段

A、种子期：主要目的在于收集用户行为数据，与产品设计时的用户模型做对比，有目的性调优。

主要关注数据有：页面路径转化，按钮点击，启动次数，启动时间段，停留时长等。

这个阶段数据量不求大，但求真实，用户来源的话，可以先做免费渠道，如果能有一些首发资源更好了。

B、推广期：主要目的在于扩大影响，吸收用户。

主要关注数据有：新增，活跃，留存以及渠道数据。

在这个阶段如果能够配合各种资源多管齐下，用户量能有爆发是最好的了（具体可查看马海祥博客《 APP常用的推广方法》的相关介绍）。

C、营收期：主要目的在于通过各种活动运营、增值服务创造营收。

主要关注的找数据有：付费用户数、付费金额、付费路径转化、ARPU等。

2、产品类型

如工具类，启动次数很重要；社区类，活跃用户和UGC很重要；游戏，在线人数和arpu值是关键；移动电商主要关注成交转化率，包括订单转化率和金额转化率，根据APP产品类型及所处运营阶段，制定APP数据指标考核表，如下图显示：

这里有一张整理过的图来说明一下吧，很早以前在网上收集的一些数据指标，感觉比较实用，制作方案的时候可以参考。

六、关于APP数据指标分析

APP的数据指标体系主要分为五个维度，包括用户规模与质量、参与度分析、渠道分析、功能分析以用户属性分析。用户规模和质量是APP分析最重要的维度，其指标也是相对其他维度最多，产品负责人要重点关注这个维度的指标。

1、留存用户和留存率

留存用户和留存率通常反映了不同时期获得的用户流失的情况，分析这个结果往往是为了找到用户流失的具体原因。

APP获得一定用户以后，刚开始用户会比较多，随着时间的推移会不断有用户流失，留存率随时间推移逐步下降，一般在3-5个月后达到稳定。其中阅读资讯、社交沟通、系统工具是留存率最高的三类应用，在4个月以后的留存率稳定在10%左右。

留存率提高了，才会有更多的用户留下来，真正使用APP的用户才会越来越多（具体可查看马海祥博客《如何计算并提高APP用户留存率》的相关介绍）。

次日留存：因为都是新用户，所以结合产品的新手引导设计和新用户转化路径来分析用户的流失原因，通过不断的修改和调整来降低用户流失，提升次日留存率，通常这个数字如果达到了40%就表示产品非常优秀了。

周留存：在这个时间段里，用户通常会经历一个完整的使用和体验周期，如果在这个阶段用户能够留下来，就有可能成为忠诚度较高的用户。

月留存：通常移动APP的迭代周期为2-4周一个版本，所以月留存是能够反映出一个版本的用户留存情况，一个版本的更新，总是会或多或少的影响用户的体验，所以通过比较月留存率能够判断出每个版本更新是否对用户有影响。

渠道留存：因为渠道来源不一，用户质量也会有差别，所以有必要针对渠道用户进行留存率分析，而且排除用户差别的因素以后，再去比较次日，周留存，可以更准确的判断产品上的问题。

2、活跃用户

用户每天既会不断新增，也会不断流失，如果单独只看每日活跃用户数，是很难发现问题的本质的，所以通常会结合活跃率和整个APP的生命周期来看。

活跃率是指活跃用户/总用户，通过这个比值可以了解你的用户的整体活跃度，但随着时间周期的加长，用户活跃率总是在逐渐下降的，所以经过一个长生命周期（3个月或半年）的沉淀，用户的活跃率还能稳定保持到5%-10%，则是一个非常好的用户活跃的表现，当然也不能完全套用，得视产品特点来看。

七、团队架构

这个篇幅简单介绍移动互联网运营推广团队的组织架构及成员工作职责，具有一定的普遍性，总体概括来说，这个市场运营部门架构大概是：一个带头的，一个做渠道和流量，一个玩社交媒体的，一个天马星空写文案的，再辅助一些打杂的。

1、市场运营总监

工作职责:

（1）、负责公司开发的移动互联网产品的内容整体规划和运营策略的制定及执行。

（2）、负责制定每季度、月运营计划。

（3）、整理各产品运营渠道数据报表，并定期收集分析同类竞品情报。完成活动的策划执行，并做好跟踪记录。

（4）、构建和完善App推广和分销渠道，促进App的下载和使用（具体可查看马海祥博客《史上最全的APP推广模式及方法技巧》的相关介绍）。

（5）、网络媒体、网站联盟、博客、论坛、社区营销、SNS等各种互联网营销渠道的拓展和维护。

（6）、负责和移动互联网领域各传播媒体有效沟通，调动各种资源，促进公司互联网产品和相关渠道及媒体的联合推广，以提高公司产品的市场知名度。

（7）、负责通过微博，微信等网络推广方式，开展公司自有产品的运营和推广活动，收集相关营销成功案例并进行分析。

（8）、负责制作内容及话题，能够结合热点事件开展推广活动，及时监控和处理产品运营活动过程中的各类正负面事件。

（9）、跟踪运营推广效果，分析数据并反馈，分享推广经验；挖掘和分析目标用户使用习惯、情感及体验感受，即时掌握新闻热点。

（10）、策划、组织、评估和优化推广计划。

（11）、分析App运营数据，根据分析结果不断优化运营方案。

岗位点评：从工作职责要点来说，市场总监应该是负责内容规划，运营策略及计划制定，渠道构建和监督，新媒体推广实施跟踪，APP运营数据分析,团队建设和管理。

2、文案策划

工作职责：

（1）、清晰项目目标，快速了解客户需求，并密切与相关协同部门合作，提供快速、精准、精彩的案头支持。

（2）、负责宣传推广文案及宣传资料文案的撰写。

（3）、负责创意内容撰写，为线上活动、广告传播、线上公关稿件撰写相关文案内容。

（4）、沉淀创意产出和内容撰写的经验，形成知识管理，供其他项目借鉴。

岗位点评：文案策划岗位是文字输出岗位，需要文字功底好，有创意，对热点有嗅觉，最好在事件营销传播方面有成功案例。

3、渠道经理(BD拓展）

工作职责：

（1）、深入研究公司产品与所属行业，制定适应公司发展战略的拓展计划。

（2）、根据公司业务发展需求，寻找、挖掘有利于公司的合作资源。

（3）、负责商务拓展及合作，与其他客户端及推广渠道（各大市场）建立良好的业务合作关系。

（4）、对推广数据进行分析，有针对性的调整推广策略，提高下载量、安装量及活跃度等（具体可查看马海祥博客《盘点那些不为人知的App推广技巧》的相关介绍）。

（5）、辅助APP产品的运营和推广，整体规划和专题策划。

岗位点评：渠道经理顾名思义就是拓展各互联网流量渠道，一切有助于APP流量提升的渠道合作都属于工作范畴，渠道经理的工作职责就是制定渠道拓展计划，带领BD专员拓展各市场，分析数据，完成运营总监制定的流量指标。

4、新媒体推广经理

工作职责：

（1）、有互联网信仰，最好是重度使用者，制定新媒体推广计划，执行力强。

（2）、熟悉新媒体，对微博、微信如数家珍，熟悉大号，运营过微博草根号、微信公众号更好！

（3）、有判断力，对热点事件能分析，知道如何借势，有自嘲精神，可以黑人兼适度自黑。

（4）、有战斗经验，没混过论坛没耍过微博刷过微信的就算了，不管明骚闷骚，永不放弃！

岗位点评：这个岗位要求“离了手机就不能活并且认为它比性更重要”那种，能配合文案玩转各社交媒体渠道，在事件营销及热点引爆有嗅觉和实操经验。

八、绩效考核

每个公司绩效考核指标不同，对于移动互联网公司市场部门来说，各个岗位指标也不尽相同，这里只罗列出有共性的一些考核点。

1、市场运营总监

这个岗位背负团队整体KPI指标，如APP运营数据指标，销售指标等，如何将团队指标有效分解到每周，每天、每个人，这是市场运营总监每天都要思考问题。

2、文案策划

A、文案撰写能力：写作功底深厚，表达能力强、思维逻辑清晰、具有独特敏捷的创意思维。

B、创意能力：能根据公司品牌定位, 完成有创意的文案策划，为产品销售及运营推广带来很大飞跃。

C、对接能力：与渠道部门，设计部门，推广部门，客户等沟通协调及分配工作能力。

D、工作态度：纪律性，团队协作意识，工作责任感。

根据这几个考核指标做分数配比，适当提高AB两项指标分数。

3、渠道经理

渠道考核指标直接跟APP运营数据挂钩，这个数据指标可参考上篇中app运营目标中数据。

那么在APP运营推广过程中哪些数据指标，可以更好的指导我们工作呢？比如：下载量、每日新增用户数、留存率、活跃用户数、平均用户收益(ARPU）、使用时间、活跃时长是很多公司作为数据指标的一个考核，也是改进优化工作的一个依据。

当然，产品阶段的不同，我们关注的数据指标肯定不同。例如APP初期，我们更加关注下载量和用户数。之后，我们又会比较关注活跃用户、留存率、转化率等等的数据，所以运营阶段的不同，我们所关注数据的侧重点也会有所不同。

4、新媒体推广经理

新媒体推广由于渠道不同考核指标也不同，微博、微信、豆瓣、知乎、其他软文推广渠道等，运营总监可以根据渠道设立不同考核指标，这里以微博和微信为案例：

（1）、微博考核指标

微博营销涉及的数据大致有微博信息数、粉丝数、关注数、转发数、回复数、平均转发数、平均评论数。

微博信息数：每日发布的微博数量，10条/天。

平均转发数：每条信息的转发数之和/信息总数量，一般计算日平均转发数或月平均转发数，平均回复数原理类似。平均转发数（评论数）与粉丝总数和微博内容质量相关，粉丝总数越高，微博内容越符合用户需求，转发数和评论数就会越高，所以这个数据可以反应粉丝总数、内容和粉丝质量的好坏，粉丝基数越大，理论上转发会提高，内容越契合用户，或者粉丝中你的目标人群越多，这个数据都会上升。

以A公司品牌微博为例，4月1日只有1.4万左右，5月结束有2.6万！

从这个表中可以看到4、5月的增长情况，两个月的粉丝增量差不多，微博信息数量5月增加36%，但是转发总数增长近100%倍，评论增长了64%，搜索结果数也是增加了。应该说针对4月的微博内容分析之后，5月份作了一些调整，更加注重用户需求，所以在总量增加的同时微博的平均转发数和回复数都上升了，可以说明该微博5月份比4月份是有进步的，而且搜索结果数直接增加曝光率，说明了营销效果。

总结：平均转发数和评论数可以衡量自身微博运营状态好坏；搜索结果数可以作为品牌传播的考核；只有综合所有数据来看才可以指导微博营销。

（2）、微信考核指标

文章考核指标：送达率、图文阅读率、原文页阅读率、转发率、收藏率。

订阅粉丝量，有三个指标：新关注数、取消关注数以及净增关注数。

刚开微信的企业，我们可以用1个月的时间，设定目标完成500个用户的订阅，接下来的每个月，逐步增长。每天订阅粉丝超过20个，1月就是600个。

用户互动量：该用户在微信上和你的互动，我指的是有意义的互动，比如马海祥博客(微信号mahaixiangboke)，当你添加微信时，自动回复写的是：输入1获取移动互联网干货，输入2获取电子商务运营干货，输入3获取产品策划干货，这其实就是很好的一个规则。

用户转化量：该用户最后通过你的规则输入相关词后，我们的跟进情况，以及成交情况。

九、团队管理

这个篇幅侧重于团队运营管理，不只是针对移动互联网，同样适合互联网公司团队管理，以马海祥个人经验分享来说，互联网团队运营管理应重点关注三方面：执行力，目标管理，团队凝聚力。

1、执行力

关于执行力的案例，腾讯是很多互联网公司学习榜样，马化腾凌晨4点发出邮件，运营团队下午就能给出实现计划。

很多创业型互联网小公司发展速度快，因为执行力强，当公司发展到一定规模后，变态的层层审批机制阻碍了项目的实施。马海祥原来在一家传统企业转型互联网的公司呆过，深有体会，一个很简单的推广页面，本来当天就可以决策通过，还要经过总监--副总--老板几个层级审核，一周过去了，才通过，结果好好的项目被时间给拖死了。

所以，在大的公司，马海祥还是比较推崇项目负责制，扁平化管理。

2、目标管理

运营总监从拿到KPI那天起，脑海里都是数据化管理，从年目标，季度目标，月目标，周目标层层分解，一个没有数据量化目标的运营团队会跟无头苍蝇一样乱窜，运营总监团队管理过程其实就是一个目标管理流程。

3、凝聚力

保持一个高效、快乐、有活力的工作环境，让整个运营团队保持凝聚力，是每个运营总监职责所在，团队成员频繁跳槽，稳定性差将不利于项目的进展，所以如何保持项目核心成员稳定性至关重要。

马海祥博客点评：

企业APP营销推广需注意运营方案的策划，随着移动互联网领域的白热化，平板电脑和智能手机已经占了大半的PC市场，APP的第三方应用程序变得格外重要，而开发出的APP软件，想在电子市场营销，必须要有一套完善的APP运营方案才行，不然就会得不偿失。

本文为马海祥博客原创文章，如想转载，请注明原文网址摘自于http://www.mahaixiang.cn/App/1499.html，注明出处；否则，禁止转载；谢谢配合！

一份完整App运营推广计划方案 - 简书

Wed, 24 Oct 2018 10:46:53 CST

一、App运营推广概念

引用百度百科的概念：对运营过程的计划、组织、实施和控制，是与产品生产和服务创造密切相关的各项管理工作的总称。从另一个角度来讲，运营管理也可以指为对生产和提供公司主要的产品和服务的系统进行设计、运行、评价和改进的管理工作。细细思考下，其实，APP运营推广无非是产品想盈利模式，而运营去实践盈利模式。

任何运营都围绕“用户”展开，包括“吸引用户”和“留住用户”，说白了就是：让用户过来，并留下。

运营的三个阶段：吸引用户、把用户留住、让用户掏钱。

运营三大核心目标：扩大用户群、寻找合适的盈利模式以增加收入、提高用户活跃度。

我们把运营的分工和种类进行细分，运营可以分为：

1.基础运营：维护产品正常运作的最日常最普通的工作。

2.用户运营：负责用户的维护，扩大用户数量提升用户活跃度。对于部分核心用户的沟通和运营，有利于通过他们进行活动的预热推广，也可从他们那得到第一手的调研数据和用户反馈。

3.内容运营：对产品的内容进行指导、推荐、整合和推广。给活动运营等其他同事提供素材等。

4.活动运营：针对需求和目标策划活动，通过数据分析来监控活动效果适当调整活动，从而达到提升KPI，实现对产品的推广运营作用。

5.渠道运营：通过商务合作、产品合作、渠道合作等方式，对产品进行推广输出。通过市场活动、媒介推广、社会化媒体营销等方式对产品进行推广传播。

二、App产品运营推广要做哪些事情？

前期的准备工作：

1.保证产品能正常运行。

2.明确产品定位和目标。

3.选择合适的推广渠道和方式，协调内外部的资源并制定详细的计划。

4.确定团队分工并执行。

上线初期的工作：

1.保障产品的正常使用

2.根据运营状况，阶段性的跳转优化产品

3.上线初期的推广策略（请见 CP干货：如何选择推广渠道与推广的技巧）

后期的日常工作：

1.产品的更新

2.内容运营

3.活动策划

4.用户运营

5.数据分析

6.意见反馈

如何为你的App定制合适的推广渠道和方式？

第一考虑：产品定位第二考虑：目标群体习惯和属性第三考虑：公司资源

三、运营推广过程中需要重点关注哪些数据指标

在APP运营推广过程中哪些数据指标可以更好的指导我们工作呢？下载量、用户数、留存率、转化率、活跃用户数、活跃时长、付费率是很多公司作为数据指标的一个考核，也是改进优化工作的一个依据。

当然，产品阶段的不同，我们关注的数据指标肯定不同。例如APP初期，我们更加关注下载量和用户数。之后，我们又会比较关注活跃用户、留存率、转化率等等的数据。所以，运营阶段的不同，我们所关注数据的侧重点也会有所不同。

目前，市场上的APP数据统计分析工具比较多，比较出名的有：友盟、百度统计、谷歌统计、talkingdata等

一个App从开始运营到结束，要做的事情：

1.APP运营阶段

2.APP定位

2.1 定义APP所属关键词

2.2 组织对会员（厂家企业）有价值的内容或是服务

2.3APP会员（厂家）卖点

3.APP启动(2014年10月-2014年11月)

3.1人员配制

3.2收集潜在会员、厂家资料

3.3进行线下的推广营销

3.4 APP编辑的工作

4.团队建设（1-2个月）

5. App推广（从产品正式版开始，大规模推广从A轮融资开始）

5.1行业APP广告交换

5.3产品关建词竞价排名

5.4行业网站广告直投

5.5软文宣传

5.6长尾关键词优化

5.7效果分析，经验总结

5.8流量分析

6.APP盈利（A轮到B轮要开始考虑盈利）

6.1 通知组织活动来搞人气

6.2 通过会员费或是增值服务

6.3 展会服务、广告代理

6.4 B2B

6.5 APP广告

7. 执行计划表

8. 软文推广说明

8.1 软文推广的作用

8.2 软文写作参考标准

一）、标题

二）、主题

三）、内容

9. 论坛推广说明

9.1 何为论坛推广

9.2 论坛推广的效用

9.3论坛营销推广四步

10.网络广告说明

10.1 网络广告概述

10.2 网络广告媒体选择策略

10.3 媒体选择范围

10.4 广告形式确定策略

11. EDM营销推广说明

11.1 邮件营销的优势分析

11.2 APP邮件的注意事项

12.APP收费标准

总则：结合自身优势资源，一切以吸引行业相关企业作为行网会员为目的。

APP运营阶段

APP定位->APP启动–>APP宣传->APP建设 ->APP赢利

APP定位

1 定义APP所属关键词

跟行业相关，跟产品相关的，写出10个以上（例如：上游产业、下游产业等），长尾关键词跟以后编辑文章以及做SEO优化、ASO优化、线上广告推广有密切关系，同时需要考虑主营业务、APP内容、以及受众、和搜索量。关键是尽可能多的写出多一些，到时可以做一些筛选。

2 组织对会员（厂家企业）有价值的内容或是服务

选出方向和卖点：每一个APP都有主要的运营方向和定位。前期不建议定太多的方向和服务，以防以后精力受限做不好等于不做。所以建议前期先择一到二个服务方去做，内容的话如果有精力和资源可以都放一些，如果没有精力的话也是选突破一到二个方向。前期也可以做一些了解，那些目标会员或是客户希望得到哪些资料和内容，针对性去做这样会好一点。

3 APP会员（厂家）卖点

这是核心问题，把之前的事情做完了，就需要把特产行业了解一下，把那些优势和卖点形成书面资料或是广告资料或是电话脚本。这样子就可以去做下一步的事情了。

APP启动

1.人员配制

（一名编辑）编辑要求：经常上APP，会使用Office，会对HTML进行排版编辑，有一定的互联网经验，有一定的文笔。

编辑：主要负责APP内容维护及线上推广工作；

2.收集潜在会员、厂家资料

收集行业相关的企业（配套行业、行业、）等资料：

1.（客户资料，包括但不限于邮箱、电话、传真、具体地位）

2.通过线下关系收集

3.通过阿里巴巴企业库

4.通过搜索引擎

5.收集邮件是有专门的，可以让它不断在网上找，然后收集起来。

6.通过腾讯qq空间，微信，微博，客户端等超大流量社交网站进行资料采集。

3.进行线下的推广营销

前期主要是吸引厂家加盟，这时需要列出所以针对厂家加盟的卖点，然后进行会员广告的销售！最好是写出电话营销脚本或是宣传单页。

a)先将有一定关系的厂家或是经销商拉进来，然后通过客服人员进行线上或是线下营销将大量相关厂家拉进来。因为厂家是免费加盟的，可以尽可能多的拉一些，对于重点厂家可以赠送一些门户广告位。

b)主要是吸引会员加盟，前期可以是免费的，主要将一些网站会员的卖点价值提高一下，对潜在客户进行宣传，方式可以有：电话、传真，Email,纸制宣传单信件手段来做，同时统计一下每一种宣传效果，选出一种最有效的宣专方式，然后就可以大量以这种方式去操作，给客服人员每日做出量化考核。评估工作效率。

4.APP编辑的工作

1)围绕APP关键词收集相关，或是从线下渠道收集资料发布在行业网站上，要注意突出关键词以及产品。

2)互联网一直是以内容为王，如何吸引用户还是以优秀的内容为主，所以尽可能的能发布一些实用的，有价值的行业文章。保持更新，每天每个栏目都能得到新发布的文章。

3)关键词优化，尽可在内文能突出关键词，做好锚点

团队建设

在原有基本上添加一名客服和项目经理；

分工明确，责权落实

人员考评，尽可能的科学，公平，合理

根据业务需要增配人员，工作量加大时需要及时补充人员

提升相关人员的专业知识，业务能力，人员素质

有长远的人员规划以及激励方案

APP推广

1.行业网站广告交换

当APP有一定的流量时，可以找一些相同规模的同行APP交换广告，即在你的APP上做对方的广告，在对方APP上做你的广告。这样可以不用花钱即可得到一定的广告效果。

2.产品关建词竞价排名（SEM）

你可以有效控制预算来做广告。

3.行业APP广告直投

找出一些有流量，有影响力的相关行业网或是相关网站，在他们网站上直接投放广告。

4.软文宣传

让专业写手为APP一到三篇专业软文，同时发布到专业到APP上。

5.长尾关键词优化（网站SEO）

根据APP的定位列出尽可能多的长尾关键词，这些关键词必须跟APP的方向、产品或是服务相关，相结合，然后我们可以针对这些关键词做一些SEO优化。

通过关系网直接或是间接宣传行业门户

群发、定阅、报纸等手段

专业杂志报刊广告

6.效果分析，经验总结

对活动效果进行跟踪，统计做出一些数据分析，总归一些经验。

对活动的宣传效果进行分析统计（主要依靠流量统计）

对于参与厂家进行回访了解情况

对于不足之外需要讨论如查改进

7.流量分析

流量分析可以让你知道你的客户从哪里来，关心什么内容等，对APP运营是一个很好的数据参考。我们主要可以分析以下数据：

a.每天的关注数据，它代表着来你APP的独立用户和点击量，关注数据可以理解成为每个用户到APP的翻看量，而翻看量越大，说明APP的吸引力越大，也就是粘性强。如果这个值小于4那就要注意内容建设了。

b.来路流量：可以看看客户从哪些平台点过来，哪些平台的链接比较有效果。这里同时也经常被用做广告效果分析，看一看投放哪种广告的效果比较好一些。对于些来没有什么来流的广告，就可以考虑撤消了。

c.搜索引擎：可以看看对哪些搜索引擎的优化效果好。

d.关键词：看看用户关心什么，以及哪些关键词优化做得好。

e.查看/浏览页面：看看用户看得最多的页面是哪个？这里是不是可以挖掘些有用的价值。因为有些页面流量是有时效性的，当时间过了，流量也降下去了，可以让你抓住在流量高的时候抓住商机。

f.入口页，这些页面经常是被直链或是优化做得比较理想的页面，可以学习或是在这些入口页面上做一些营销上的事情。

g.根据流量数据，我们可以对推广方式以及APP内容做一定的调整。

等APP的人气和知名度上来以后，我们可以偿试提供一些收费服务。

8.信息流广告

一是社交信息流，社交信息流包括腾讯广点通；在腾讯的QQ空间和微信里展现的一些广告，但微信公众号文章底部的不算信息流。你在QQ空间里面看到的广告就是信息流广告，QQ空间里面信息流展现的位置和友好度都是很好的，所以说广告好不好看广告展现的方式。还有新浪粉丝通，在新浪微博里面和QQ空间是类似的。陌陌也推出了自己的信息平台陌陌信息流。还有比较传统的天涯，可能有很多90后不知道天涯，在传统PC时代天涯基本上有一段时间就是社交的代名词，相当于现在的微博微信，而天涯的群体年龄基本上在30岁-50岁之间。

二是新闻信息流里，有腾讯智慧推，新浪扶翼、今日头条、UC，UC给人印象比较深的是浏览器，经过最近改版之后已经变成了一个浏览器+新闻头条的产品。UC在移动端的用户量相当大，前4个是目前在市场上量比较大的。

网站盈利

APP的赢利有多种方式方法，但是需要找到适合自己的那一种，当APP人气上去以后，其实APP的赢利是水到渠成之事。下面有几个方面可以去考虑。

1 通知组织活动来搞人气

活动本身就是可以赢利的项目，如果操作得好，活动可以成为APP的一道招牌菜，在全国各地全面开花，光是这些，估计都可以赚不少钱。而且可以将APP分支不断延伸，公司影响力不断提升。而且这样一来，APP人气就可以有效得到提升。

2 通过会员费或是增值服务

会员本身也是赚钱的项目，只要能提供会员们感兴趣的内容或是服务，让他们在其中可以获利，那么从他们那里收取少部份的服务费是非常容易，当会员数据成长到一定程序，赢利变得很自然而稳定的事情了。以后我们还可以想出一些个性化的增值服务来进一步提升APP赢利能力

3 展会服务、广告代理

由于APP自已的活动举办的好，可以光以这个项目为线下企业组织各种活动，或是展会，或是以APP名义在做展位和宣传，相信可以帮助到线下成员企业。同时广告代理也是可以操作的，在前期在一些专业性网站或是媒体投放广告，积累一定的操作经验以后，以网站名义可以帮助线下会员企业做一些广告宣传的项目。

4 B2B

直接通过APP卖产品，不管是卖谁的，赚钱方式是直接的，关键是APP需要有一定的人气和知名度。

5 APP广告

APP如果能达到一定的知名度和公信力，APP广告应该是最容易操作的一个赢利项目了。这时候，应该对APP广告位进行一些规化，排版。对每一个广告位的广告效果进行一些测试，然后定出每一个广告的报价。广告位在空余的时候尽可能做一些自己的广告或是公益性的广告，不要让它空着。但是仍然需要做出一个广告报价页面，以及说明那些广告位是可以投放的说明。前期广告位可以以赠送、配送等方式先放上去，后来可以先以低价方式做一些尝试，如果APP人气上来了，知度度上来了，APP上的广告更多是一种知名度，实力，形象的宣传了，这时候价格就可以提上来了。

软文推广说明

软文营销推广是中小企业现阶段赖以发展和对外推广的最优选择，通过软文推广能够带动企业销量的快速增长。通过软文营销推广创建的是企业品牌价值，这样带来的客户比一般推广方式更有黏性，如果你的产品或服务很好，通过客户的口碑传播还会带来更多销量。

A. 软文推广的作用

软文推广是硬广告的有效补充

软文是以引导性的思想传达，润物无声地将产品信息灌输到消费者的头脑中。以目标受众容易接受的方式切入消费者内心，并在消费者经常密集的地方进行软文教育，打动消费者，最终促进消费行为的一种“软”营销。软文营销的成本远低于硬性广告，但综合效果与性价比却远高于硬性广告。进行企业宣传和推广时，如果软文推广与硬广形成有效互补，往往能够起到更好的宣传效果。王老吉、必胜客等便是非常好的例证。

软文推广在抢占消费者心理方面独具优势

软文是抢占消费者心理的最佳途径。原因是，软文形成之前必定是经过不断分析、调研、研究消费者的需求特征，根据需求提炼产品或者服务的核心价值和卖点，寻求切入点，将产品、服务信息更巧妙地植入文章中，这样的软文才能更好的发挥销售优势，带动消费者的消费行为。

创口碑，树品牌

在互联网时代，口碑的作用越来越明显。当人们对铺天盖地的APP广告熟视无睹，审美疲劳时，通过口碑传播在一定程度上会降低消费者对漫天广告的不适感。好的软文不仅吸引消费者浏览和阅读，甚至可以在不知不觉中广泛传播，从而形成巨大的口碑效应。随着数字技术和网络传播的演进，网络中的邮件、聊天室、论坛、网站、博客等一方面加快了口碑传播的速度，另一方面消费者有目的地搜索，有很强的针对性，既避免了不可预期的时效障碍，又使口碑传播有了质的飞跃。

软文能带动群体效应，便于打开市场

如果APP用户在一个地方看到企业的相关报道，在不知不觉很多地方都看到同样的相关报道，包括服务、产品、企业文化、市场流行等各方面的报道。众口铄金，消费者想不相信都很难，自然留下了深刻印象，这样就形成了群体效应，在积累大量消费群体同时，也打开了销售的大市场。

B. 软文写作参考标准

一）、标题

软文的标题要紧贴主题，突出核心内容和表达意图，要具体不要抽象，要简洁不要繁杂。以下总结了几种比较引人注目的标题形式：

1、热门关键词式标题

用热门关键词造势的软文标题，直接点明文章内容的中心。例如:“阿里巴巴集团宣布将口碑网资产注入淘宝网”、“全新百度统计系统福尔摩斯正式推出”等等。

2、数字式标题

在标题里加入一些匪夷所思的数字容易引起别人的注意。例如:“100篇2014年最流行的软文模板”,“揭密你为何不能网络赚钱的10大原因”等等。

3、经验分享式标题

别人的成功经验很容易引起人们的关注和学习。一般以如何、怎么样、浅淡、揭密、秘决、经验、忠告、某某方法技巧等开头或结尾的文章。例如:“教你如何选择价廉物美的****产品”。

4、借用名人、名站效应

例如“奥巴马访华衣着有技巧” 行业精英、政要富商、体育明星、网络热门人物都是人们炒作的重要对象。

5、提问式标题

通过提出问题来引起关注，从而使消费者发生兴趣，启发他们思考，产生共鸣，留下印象。例如：“京东为何越亏越不怕？”

二）、主题

写文章一定要有中心，要有主题。选好切入点，把需要宣传的网站、产品、服务、企业形象等信息嵌入到文章内容中。一个好的切入点才能让整篇软文看起来浑然一体，把软性广告做到极致，宣传效果才会出来。

三）、内容

逻辑性强

文章内容条理清晰、一目了然，紧扣标题进行表述。层级要分明，段落要清晰，重点要突出。文章正文要从不同方面反映主题，可以采取添写小标题的方式，分段叙述，这样才能使文章有条有理，脉络清晰。

真实性

软文最忌漫无目的的混乱编写。有号召力的软文，语气措词必须礼貌，既要使人感到亲切，又要迎合消费者的心理。口气平和的广告往往易于被消费者接受。

不要硬性植入广告

软文最好的方式是把宣传的意思自然融入到文章中，硬性植入网址和链接只会让消费者更反感。插入文章里的链接，一定要选择一个过渡的句子进行协调，不要太直白地插入网站链接。

论坛推广说明

1、何为论坛推广

论坛推广就是企业利用论坛这种网络交流的行网，通过文字、图片、视频等方式发布企业产品和服务的信息，从而让目标客户更深刻地了解企业的产品和服务。最终达到宣传企业品牌、加深市场认知度的网络营销活动。

成功的论坛推广如同核裂变的源泉,数以亿计的网民在论坛上自由发表个人观点、看法，而民众言论组成的浪潮通过网络往往可以产生类似病毒传播、甚至山洪涌泄的效果，因此论坛被认为是 “营销新媒体”，具有极强的低投入高产出的营销优势。

2 论坛推广的效用

l用论坛推广的是商品，它能引导销售。在论坛推广的时候要根据商品的特性选择论坛进行推广，这样目标群体就会精准很多，也就会提高销售量；

l如果帖子够吸引人，能快速给网站带来较大的流量和访问量；

l论坛互动性强,通过论坛传播,可提高企业曝光率，提高网民对产品和企业的认知度；

l论坛都是按照主题分类,产品与用户定位明确,因而在相对应论坛开展推广可提高营销效率与转化率。

3.论坛营销推广四步

第一步：客户分析

怎样不露痕迹地抓住手机用户的心是论坛营销的关键所在。企业在进行论坛推广之前,首先要进行目标客户分析，要研究客户属性,了解目标客户经常去哪些论坛、对哪些主题比较感兴趣。企业只有从客户的角度出发进行主题策划和论坛选择,通过论坛跟客户互动才能有的放矢。

第二步：提炼传播点

卖点不等于有效传播点,产品的优势或卖点不一定可以通过论坛很好地传递。例如某款笔记本的卖点是外形时尚,但如果仅将“外形时尚”作为传播话题组织论坛软文,恐怕不会有多少关注。有效传播点其实就是论坛的噱头，有噱头的帖子被搜索引擎收录以后点击量会非常大。凡是标题中带有 “现场”、“震惊”、“最牛”、“惊爆”等词的帖子,会首先吸引网友的眼球,而 “草根”、“原创( YC)”、“实录”都是他们最喜欢的一类帖子。

第三步：创造话题

针对目前社会或APP流行热门的话题，在论坛组织专题讨论，并组织人力、物力进行文章的整理和发布，形成某个热门话题的关键讨论地，那么搜索引擎有可能会认为你的网页很有价值，搜索排位自然也会靠前了。

一、以生活为题材,如生活奇闻逸事、亲情关系；

二、以明星、关键人物为题材,切入点可大可小；

三、以新闻和社会热点为题材。如房价波动、金融危机、企业过冬等皆可,也可利用新产品试用或礼品赠送等方式激励APP用户参与。

第四步：选择阵地

在选择论坛的时候，应该关注该论坛的人气和流量，也就是论坛的权重，比如天涯论坛，百度贴吧都是很不错的发帖站点。不同的论坛各有其特点,需要了解其规则和营销底线。权盈根据客户网站的特点和推广需求,选择推广的精准目标论坛和板块。具体资源列表参见“附五：论坛行网列表”。

网络广告

1.网络广告概述

网络广告就是利用网站上的广告横幅、文本链接、多媒体的方法，在互联网刊登或发布广告，通过网络传递到互联网用户的一种广告运作方式。网络广告以其价格便宜、统计准确、互动交流、跨越时空、图形生动等特点，正以迅雷不及掩耳之势，渗透到现代生活的各个方面，展示出魅力无穷的网上商机。

目前网络广告的市场正在以惊人的速度增长，网络广告发挥的效用越来越重要，已成为继传统四大媒体（电视、广播、报纸、杂志）之后的第五大媒体。

2.网络广告媒体选择策略

所谓网络广告媒体选择就是对你所要发布信息站点的确定，甚至包括具体页面位置的确定。不同的站点有不同的受众对象，所以媒体的选择对网络广告的最终效果影响很大。

广告媒体选择策略：

Ø具有较高的目标受众比例；

Ø具有较高的品牌知名度，形成品牌互补；

Ø广告表现可承载性；

Ø广告效果的可监控性；

3. 媒体选择范围

a、综合门户网站的相关频道，利用综合性网站的大流量优势，在短时间内提高品牌知名度和产品知晓度；

b、社区网站，利用这些颇受社区人员欢迎SNS网站的受众集中特征，辅以高频次的广告播放，极有针对性的向精确目标受众传递广告信息，有效地提高了广告到达率；

c、各大论坛，这是网民发表自己意见的主要行网，在社区上很容易形成对某个产品或企业评论的较强“声音”，从而对消费者的消费选择产生导向作用。

4. 广告形式确定策略

网络广告具体形式有新闻组式广告、条幅广告、游戏式广告、背景品牌式广告、交流式广告、弹出式广告、旗帜广告等。网络广告形式多种多样，每一种形式都有其各自的特点和长处，因此选择恰当的广告形式对吸引网络浏览者、提高浏览率，树立企业及产品形象、建立声誉，促使潜在顾客购买起着重要作用。

l根据广告目标选择网络广告的形式。如果企业的广告目标是品牌推广，可以选用旗帜广告、按钮广告等形式；如果企业广告目标是树立企业形象和产品声誉，要选用微型网站广告和主页型广告；如果企业广告目标是商品促销，选择游动式广告。

l根据广告对象选择网络广告形式。如果广告对象是以年青人为主，可选用互动性较强的游戏互动式广告；如果是企业的忠诚客户，则选用制作屏幕保护程序广告或墙纸广告。

l根据广告费用预算选择网络广告形式。如果预算充裕，可选用丰富媒体广告，预算紧张，选用文字链接式广告。

l根据竞争对手情况选择网络广形式。通常竞争对手采用什么形式的网络广告，企业也应采用相应形式的广告，并且最好还要有所创新，这样才富有新意和吸引力。

EDM营销推广说明

一、邮件营销的优势分析

最近几年是邮件营销（EDM）市场爆发的序曲阶段，邮箱普及和EDM的自身优势，成为EDM市场被看好的主要原因。来自第三方调查机构的数据显示，个人邮箱数在2010年达到5亿，而全球企业邮箱数也达到5.7亿。范围广、成本低、效率高、精准度高，这些优势使得邮件营销成为网络营销手段中最常用、最实用的方法。

邮件群发可以在短时间内把您的产品信息投放到海量的客户邮件地址内。让您的企业品牌名扬中外，让您订单倍增且零成本、高效率，使企业在竞争激烈的市场中占尽先机！

1、 Email营销的成本优势

Email营销最重要的特点就在于成本低廉而效果显著。

2、Email营销可获得连续推销的机会

Email营销可以让企业与客户保持常效联系，公司一旦有新产品，就可以通过邮件的方式进行宣传。而且邮件具有直效针对性，针对不同消费群体，发送不同的营销收件，针对性强，效果也就更佳！这比任何一种方式都简单和划算。如果用户是因为某个关键词来到你的网站，有可能浏览几下就走了，并且不会再来，也不会记得你网址是什么，这样就白白损失了一个潜在的用户。如果用户来到你的网站，你通过一些礼品券或者书之类的礼物送给他，前提是让他注册邮件，那么他会很愿意。

3、建立稳定的客户关系

与一般的产品（或服务）促销手段不同，Email营销在实现促销职能的同时，能够明显促进与顾客的关系。以常用的刊物为例，有研究表明，网站上提供的刊物比网站本身的营销效果更好，这其中的重要原因在于刊物和用户之间不仅仅是单向的信息传递，同时也在网站和用户之间建立起一个互相交流的渠道。通过刊物直接将信息发送到用户的邮箱中，会产生用户和网站长期互动的关系。

4、满足用户个性化需求

Email营销可以为用户提供个性化的服务信息，用户可以根据自己的兴趣预先选择有用的信息，当不需要这些信息时，还可以随时退出，不再继续接收。因此，在Email营销中，用户拥有主动的选择权，正是因为用户自己选择的信息与自己的兴趣和需要相关，因而对接收到的信息关注程度更高，这是Email营销获得较好效果的基本原因。正是因为这些优点，Email不仅成为重要的网络营销手段，有助于品牌推广和促进销售，同时也成为维持和改善顾客关系、开展顾客服务的重要工具。

5、有针对性的目标客户群

邮件营销的客户一般都是较精准的部分人群，他们来到你的网站一般都是和这个行业有直接或者间接关系。再者，能填写邮件地址并允许企业发送邮件的人一般都较关心该行业的产品走势或新闻动态。他们是潜在消费者，我们要做的只是选择合适的时机把合适的信息传递给他们就可以了。这类客户一旦成功购买第一次，往往就会成为你的忠实用户，并且他还会去影响身边的人，免费为你宣传。

综上所述，邮件营销以其成本低、投递速度快、精准性、个性化易操作等优势成为最有效的营销手段之一。在经济低迷、市场预算紧张的当下，邮件营销对许多企业就更加有吸引力了，而企业邮箱也自然成了企业和现有客户沟通最常用的渠道之一。

二、网站邮件的注意事项

A、邮件主题

1、邮件主题中要体现出邮件内容的精华、品牌或者产品信息；

2、邮件主题中要包含丰富的关键词；

3、一般说来，邮件主题保持在8-20个汉字范围内是比较合适的。

B、邮件内容

1、将公司logo固定在同一位置，可以是Email顶部的显眼处（但不要太大，占据整个屏幕）；

2、尽量使用统一字体；

3、简洁明了，重点突出，注意不要强加给客户太多文本信息；

4、巧用图片作为内容补充。在选择图片时，要挑选那些简单、易于理解，并且与正文内容有直接关联的图片；

5、邮件信息内容要有针对性，是客户关心和感兴趣的内容。

App盈利模式

1、广告费：首页广告（2-3万/年）、频道广告（1-2万/年）、标王广告（10000/年）、内页广告（5000/年以内）等（成熟平台：几万/天，刚开始几百一天/位）

2、会员费：高级VIP会员（2000元/年）、VIP会员（1580元/年）、采购通会员（580元/年）普通会员（免费）（阿里巴巴会员收费情况，诚信通：1688元/年、3688元/年，国际几万到几十万不等其他平台几千到几万不等）

3、竞价搜索：按关键词搜索时，竞价点击付费；排第一位付多少，排第二位多少等（如：百度、谷歌等）

4、关键词连接：关键词直达会员商铺或会员网站服务

5、名家访谈：对知名企业、企业家进行宣传报道（几千到几万不等）

6、贸易：行业网站是以第三方身份出现的，平台上所有的供求信息第一个知道的就是本企业；可以为本企业带来客户。

7、授牌费：针对手机门户网站的会员，单独授牌；提高会员的荣誉感。

8、后期杂志：杂志广告费、文章报道费等

9、吸纳风投：会员达到一定数量，可找风险投资商入驻。

10、上市或整体转让（套现走人）

App Store Top 1000 关键词分析

Mon, 08 Oct 2018 09:20:21 CST

做这个分析的主要目的是分析用户的搜索习惯及用户的需求方向，寻找可能的机会。以下分析是7月初进行的，数据比较老，供参考。

在Top 1000的关键词中，82% 是品牌词，足见品牌（口碑）对应App的下载量还是非常的重要。而另外18%的非品牌词也展现了一些打造品牌的机会（用户在该品类下还没有产生思维定势，新的App还存在一定的机会），以下为另外18%的非品牌关键词：

VPN

有需求存在，涉及到相关的法律政策，很难有较好的发展。

排名	关键字	热度	榜首应用	热度搜索结果数
13	vpn	9849	VPN-极速高效稳定的VPN网络加速神器	1149
358	vpn翻墙软件免费	7557	VPN – 无限流量，高速网络vpn	42
596	vpn免费版	7050	VPN-极速高效稳定的VPN网络加速神器	1166
688	极速vpn	6926	VPN-极速高效稳定的VPN网络加速神器	1167

理财

理财的需求没有被很好的满足，这个行业鱼龙混杂，随着P2P的不断爆雷，其他方向的理财或许是一个方向，目前这个行业存在较大的机会。

排名	关键字	热度	榜首应用	热度搜索结果数
31	理财	9450	京东金融-新人领888元大礼包	1410
66	期货	8903	期货直播吧-香港全球期货投资理财专家	1741
181	理财平台	8088	金碗理财-高收益短期理财投资平台	1601
251	理财软件	7849	有理树理财—短期投资理财的手机理财软件	1530
270	投资	7785	立信投资-银行存管对接中	1555
314	外汇	7666	外汇牌价-全球行情分析软件	1693
642	理财工具	6991	八条鱼理财-懒人投资理财神器	1626
536	短期理财	7146	正经事理财-短期投资理财银行存管	1508
578	金融	7083	聪明钱包-简单的金融投资理财软件	1685
613	理财产品	7028	有理树理财—短期投资理财的手机理财软件	1507
626	外汇交易	7010	金道外汇投资-全球期货现货交易平台	1691
673	投资理财	6952	铜掌柜理财-高收益合规p2p金融投资理财平台	1533
676	股票	6948	股市	1631
762	理财管家	6843	帝象理财	1586
872	贵金属	6714	原油交易宝-原油贵金属期货投资平台	1705
932	期货交易	6639	期货交易-全球期货资讯专业平台	1573
940	外汇投资	6634	金道外汇投资-全球期货现货交易平台	1691
986	活期理财	6587	花生米富-银行存管,理财更安全	1360

贷款

与理财相对，有的人钱多，有的人钱少，小额贷款存在一定量的需求，此类风险较大，贷款的核心是尽可能多贷，所以会出现用户尽可能的下载更多的app，进行拆东墙补西墙的操作等，慎。

排名	关键字	热度	榜首应用	热度搜索结果数
41	贷款	9220	贷款钱包-30分钟到账的贷款app	1634
102	借钱	8543	马上借钱-分期贷款现金借钱借款平台	1597
232	闪电借款	7896	闪电借款领先版-小额现金借款	1709
345	贷款平台	7591	贷款钱包-借钱快现金贷款平台	1665
346	现金贷	7587	现金贷-小额分期借钱贷款平台	1713
398	贷款app	7448	闪贷钱包—小额分期贷款的现金贷款APP	1650
423	借款	7388	借款王-身份证就能手机借款的app	1700
515	小额贷款	7184	小额贷款-分期贷款急借钱平台	1717
805	现金贷款	6778	现金借款-手机极速借款app	1727
813	贷	6772	任性贷-有信用即刻下3000-10万的贷款借钱、网贷分期APP	1709
840	借款平台	6752	秒借款-30000元2小时到账的闪电借款平台	1706
897	借贷	6685	借贷宝 – 手机打借条, 体面有保障	1676
938	小额借款	6635	小额借款-极速借钱小额借款贷款软件	1723
973	借钱软件	6597	轻松借-小额分期贷款借钱借贷软件	1657

记账

钱不够花的引导出来的还有一个需求是：记账。记账属于工具类的产品，难点在获利。

排名	关键字	热度	榜首应用	热度搜索结果数
656	账本	6972	鲨鱼记账-3秒钟快速记账手机助手	765
756	记账软件	6851	鲨鱼记账-3秒钟快速记账手机助手	1694

彩票

没钱的状况下，还会考虑一夜暴富，买彩票也存在一定的需求，由于相关法律法规，想要开展互联网彩票非常的困难。

排名	关键字	热度	榜首应用	热度搜索结果数
46	六合彩	9113	重庆时时彩-六合彩资料大全好运彩票出品	780
152	彩票	8236	网易彩票-双色球体彩竞彩预测投注开奖	801
503	六合宝典	7203	奖多多彩票-新人注册送108元	765
793	快三	6795	天天中彩票	1028
827	福利彩票	6761	福利彩票-高低频彩票开奖平台	616
228	抓娃娃	7920	抓娃娃机游戏-天天都想玩的在线抓娃娃	913

游戏

游戏类的关键词会出现较多的品类词，可能原因是用户想要寻找新的游戏导致的，目前也可以看到益智类的游戏品类词较多。

排名	关键字	热度	榜首应用	热度搜索结果数
196	游戏	8016	密室逃脱：逃出神秘宫殿	1644
301	游戏大全	7694	神庙酷跑 – 跑步游戏大全	1575
460	手游	7302	龙骑世界-国民级热血PK手游	1536
987	单机	6587	斗地主单机斗地主单机版全民棋牌比赛	1409
34	吃鸡	9359	绝地求生:刺激战场	1678
123	吃鸡游戏	8377	绝地求生:刺激战场	1422
167	修仙	8142	焚仙-逍遥侠侣修仙手游	1463
799	仙侠	6787	全民寻仙-大型3D国民修仙热恋手游	1485
937	足球	6635	足球大师黄金一代	1248
832	赛车	6756	狂野飙车8：极速凌云	1147
905	炫舞	6673	QQ炫舞	1845
147	百家乐	8247	百家讲坛大全-手机电子书免费书城(得到一个有声小说阅读器管家)	690
279	牛牛	7762	金爵棋牌-真人棋牌游戏	900
327	麻将	7638	腾讯欢乐麻将全集	1159
494	欢乐炸金花	7220	炸金花 – 全民炸金花天天欢乐炸金花	826
766	棋牌	6836	金爵棋牌-真人棋牌游戏	967
877	五子棋	6710	腾讯欢乐五子棋	1415
830	象棋	6758	中国象棋—楚汉争霸，策略小游戏	1664
974	卡牌游戏	6595	三国·军师-全自由实时策略卡牌手游	1442
944	数独	6630	数独—经典数字趣味谜题桌游	1686
149	弹球	8245	物理弹球	1685
239	消消乐	7878	开心消消乐®	1702
394	钢琴	7460	完美钢琴 – 智能键盘, 海量曲谱, 远程连线	1887
447	塔防	7325	塔防三国志 – TD塔防类卡牌手游	1645
764	塔防游戏	6837	塔防三国志 – TD塔防类卡牌手游	1676
454	捕鱼游戏	7313	熊猫捕鱼-捕鱼高手的街机捕鱼游戏	1031
618	跳一跳	7016	欢乐跳跳跳	487
509	拼图	7190	简拼-文艺范视频拼图·美图P图神器	1935
748	拼图软件	6858	海报拼图软件-照片组合器	1872
545	儿童游戏	7140	2-6岁宝宝爱数学-家庭育儿益智启蒙教育必备的免费儿童游戏	1961
964	连连看	6602	宠物连连看经典版-最新免费益智爱消除单机小游戏	1843

系统工具

工具类的需求可能原因是原生类的工具不能很好的满足需求或功能不够强大。核心是产品要在功能点上有亮点。

排名	关键字	热度	榜首应用	热度搜索结果数
50	浏览器	9051	QQ浏览器 – 用腾讯王卡全网免流	1518
333	浏览器IPHONE版	7625	浏览器iPhone版-安全版	1537
201	天气	8001	天气	1749
362	天气预报	7552	天气预报	808
706	天气预报苹果版	6907	天气 – 精准预报实时天气变化	808
238	万年历	7879	万年历-值得信赖的日历黄历查询工具	914
886	万年历黄历	6694	万年历-值得信赖的日历黄历查询工具	908
292	日历	7732	日历	1857
258	计算器	7815	计算器	1855
865	计算机	6724	计算器 – 默认计算器	1870
269	翻译	7792	有道翻译官-出国旅游英语日语翻译必备旅行APP	1790
531	翻译软件	7153	有道翻译官-出国旅游英语日语翻译必备旅行APP	1216
548	录音	7134	专业录音—移动录音专家。	1292
912	变声器	6662	Voice Changer – 变声神器声音特效器	172
737	网络电话	6876	微微电话-通话最好的网络电话	1440
639	指南针	6993	指南针	1297
498	备忘录	7215	备忘录	990
570	输入法	7096	百度输入法-语音输入法	1181
550	音乐播放器	7133	酷狗音乐-《无限歌谣季》官方音乐APP	1289
501	K歌	7206	全民K歌 – K歌短视频互动平台	1370
816	视频播放器	6768	爱奇艺万能播放器 – 观看本地视频神器	1363
845	播放器	6745	播放器OPlayer Lite – 视频播放器	1352
564	空调遥控器苹果版	7116	遥控大师	68
858	空调万能遥控	6728	遥控精灵-手机万能遥控器	147
412	邮箱	7413	邮件	938
115	壁纸	8422	壁纸：高清手机主题桌面动态墙纸	1529
448	动态壁纸	7323	我的动态壁纸	427
767	壁纸大全	6836	壁纸大全 : 百万超高清壁纸库	977
483	铃声	7238	铃声多多-手机铃声大全	1351
530	手机铃声	7153	铃声多多-手机铃声大全	582
854	苹果手机铃声	6735	铃声多多-手机铃声大全	531
213	相机	7961	B612咔叽 – 全球自拍达人的新圣地	1720
462	p图	7297	P图神器-图片编辑拼图修图制作软件	1765
637	证件照	6994	智能证件照-自带美颜拍摄最美证件照	272
796	ps	6789	Adobe Photoshop Express	1807
953	美颜	6615	BeautyCam美颜相机	1612
958	拍照	6611	B612咔叽 – 全球自拍达人的新圣地	1810
264	视频编辑	7801	爱剪辑手机版 – 专业视频剪辑编辑制作	1391
481	视频剪辑	7243	视频剪辑 – 影片裁剪,视频编辑制作	636
665	同步助手	6961	QQ同步助手-手机通讯录安全备份管家	1356
820	电池医生	6766	电池医生-专业电池状态管理	576
908	wifi	6668	WiFi钥匙-安全上网管家	1587

微信分身

工作微信和生活微信分开是很多人存在需求，特别是微商类的。

排名	关键字	热度	榜首应用	热度搜索结果数
119	微信分身版苹果版免费	8405	商信 – 微商达人必备助手	102
302	微信分身版苹果版	7691	商信 – 微商达人必备助手	110
875	微信分身	6711	商信 – 微商达人必备助手	927

小说、视频、新闻

用户闲的时间还是比较多，小说、资讯等还是存在一些发展空间。

排名	关键字	热度	榜首应用	热度搜索结果数
56	免费小说	8958	小说大全 – 小说阅读器大全	1587
70	小说	8861	QQ阅读-拥有海量热门小说、漫画的电子书阅读器	1460
351	免费小说阅读器	7571	小说大全 – 小说阅读器大全	1571
552	看书神器	7132	小说阅读器 – 畅读小说阅读大全	1520
978	小说大全	6592	热门小说大全—小说阅读器之最新电子书小说	1480
591	阅读	7063	小说阅读器 – 畅读小说阅读大全	1611
660	听书	6966	喜马拉雅FM「听书社区」电台有声小说相声评书	1612
339	漫画	7606	快看漫画-高清正版漫画流畅看	1497
800	电子书	6786	QQ阅读-拥有海量热门小说、漫画的电子书阅读器	1637
929	收音机	6642	FM收音机-轻松收听全国广播电台	594
399	视频	7445	视频	1620
603	NBA	7040	NBA LIVE-EA出品 5v5真操控篮球手游	1647
290	直播	7737	腾讯视频-创造101全网独播	1345
502	电视直播	7204	天天看电视直播	1091
728	韩剧	6888	韩剧TV-追剧女生大本营	1557
160	音乐	8195	音乐	1798
241	影视大全	7876	今日影视大全-电影电视剧视频播放器	741
120	新闻	8402	一点资讯-热门新闻头条资讯和娱乐视频	1797
245	头条	7859	今日头条 – 你关心的，才是头条	1693
353	资讯	7569	一点资讯-热门新闻头条资讯和娱乐视频	1722
522	头条新闻	7166	今日头条 – 你关心的，才是头条	1606

交友

原始需求还是非常的旺盛啊

排名	关键字	热度	榜首应用	热度搜索结果数
211	约炮	7970	约单-有你想要的服务	1312
906	同城约炮	6669	成人之美 – 成人交友社区	807
275	交友	7769	他趣 – 成人交友情趣体验社	1359
422	闲聊	7392	闲聊-兴趣部落	1365

购物返利

此部分有一定的发展机会，也容易赚钱，可以好好的发展。

排名	关键字	热度	榜首应用	热度搜索结果数
869	购物	6719	大众点评-会生活的人在大众点评	1609
926	全球购	6644	全球购-全球正品海淘代购特卖商城	1366
231	返利app	7897	返利-专注网购省钱的APP	1599
326	淘宝优惠券	7640	省钱达人-领淘宝优惠券的省钱APP	825
439	返利	7348	返利-专注网购省钱的APP	1587
341	二手车	7602	瓜子二手车直卖网-二手车卖车买车交易平台	1899

生活服务

主要是O2O型的服务，比较适合大型的公司进行发展。

排名	关键字	热度	榜首应用	热度搜索结果数
458	租房	7305	蚂蚁租房 – 掌上租房必备	1489
466	酒店	7283	艺龙旅行-订酒店机票旅游攻略	1879
584	租车	7072	神州租车-万辆新车自由行	1934
587	共享汽车	7065	GoFun出行-首汽共享汽车	320
823	旅游	6765	驴妈妈旅游-订景点门票,选机票酒店	1715
801	外卖	6785	美团外卖-外卖订餐,送啥都快	1739
975	装修	6595	好好住 – 你的家居装修指南	1739
495	兼职	7220	兼客兼职-年轻人兼职找工作必备	1653
526	招聘	7159	Boss直聘-招聘求职找工作神器	1889
790	找工作	6798	Boss直聘-招聘求职找工作神器	1793
475	英语	7264	懒人英语—每日英语听力趣配音秀（基础音标学习雅思扇贝口语）	1837
590	运动软件	7064	Keep – 自由运动场	1847
488	违章查询	7230	车轮(车轮查违章)2018全国违章代缴助手	1423
862	公交车实时查询	6726	车来了-精准的实时掌上公交地铁	103
615	菜谱	7023	菜谱大全-小白学做菜做饭必备烹饪助手	1774
863	汽车	6726	汽车之家-2.2亿家人都在用的汽车App	1726
427	大姨妈	7377	大姨妈月经期助手-女性生理备孕健康工具社区	1118
774	发现精彩	6830	信用卡办卡 – 中国的银行手机银行信用卡快速申请攻略	111

The post App Store Top 1000 关键词分析 appeared first on 标点符.

No related posts.

Android dlib人脸识别 dlib-android-app: Android app to demo dlib-android(https://github.com/tzutalin/dlib-android). Use the prebuilt shared-lib built from dlib-android

Sun, 30 Sep 2018 13:46:34 CST

dlib-android-app

See http://dlib.netfor the main project documentation.

See dlib-androidfor JNI lib. Refer to dlib-android/jni/jnilib_ex

Grap the source

$ git clone https://github.com/tzutalin/dlib-android-app.git

Features

Support HOG detector
HOG Face detection
Facial Landmark/Expression

Demo

Build

Android app

Open Android studio to build
Use command line to build (Optional)

On Windows platforms, type this command:

$ gradlew.bat assembleDebug

On Mac OS and Linux platforms, type these commands:

    $ ./gradlew assembleDebug

or

$ make ; make install

Update shared lib (Optional)

You can build shared library from dlib-android

Copy the shared library to ./dlib/src/main/jniLibs/

Try directly

Download and install the apk

$ adb install demo/app-debug.apk

Otherwise, import the library to your build.gradle

    repositories {
    maven {
        url 'https://dl.bintray.com/tzutalin/maven'
    }
}

dependencies {
    implementation 'com.tzutalin.dlib-android-app:dlib:1.0.4'
}

Sample code

Facial landmark detection

FaceDetfaceDet=newFaceDet(Constants.getFaceShapeModelPath());Bitmapbitmap=BitmapFactory.decodeFile("Image Path");List<VisionDetRet>results=faceDet.detect(bitmap);for(finalVisionDetRetret:results) {Stringlabel=ret.getLabel();intrectLeft=ret.getLeft();intrectTop=ret.getTop();intrectRight=ret.getRight();intrectBottom=ret.getBottom();//Get 68 landmark pointsArrayList<Point>landmarks=ret.getFaceLandmarks();for(Pointpoint:landmarks) {intpointX=point.x;intpointY=point.y;
    }
}

Pedestrian detection

PedestrianpedestrianDet=newPedestrianDet();List<VisionDetRet>personList=pedestrianDet.detect(imgPath);

IT瘾app推荐

5个运镜技巧，让你的旅拍Vlog更高级！_影视工业网-幕后英雄APP

分享一个平时工作找需求找竞品的方法：通过产品使用的核心技术库 - 即刻App

随着打交道的人越来越多，人的形形色色，似乎都看过了。在我看来 - 即刻App

jsBridge 以及 Web 和 APP 交互通信方式

jsBridge 到底是什么？

首先需要了解 WebView

Web 和 Native 的交互

Native -> js

Android

iOS

js -> Native

拦截 URL Schema

注入 API

jsBridge 的实现（带回调的交互）

参考

前端工程师用Node.js + Appium实现APP自动化

简介

原理介绍

环境搭建

adb命令使用

Appium 服务启动

页面元素定位工具

自动化开发

效果展示

总结

相关链接：

Unity 引擎植入 App 渲染方案正式发布：可与原生 UI 无缝融合，丝滑交互，支持 iOS / 安卓

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的实现思路

第三方库

相关文章:

美国禁止绑定应用商店内购支付：苹果App Store世纪审判，Epic赢了

工信部将对 APP 违规调用通讯录和位置权限等加大惩处

【Weex】网易严选 App 感受 Weex 开发 · Issue #3 · zwwill/blog · GitHub

网易严选 App 感受 Weex 开发

Write Once, Run Everywhere

预科

环境

系统环境要求

配置环境

Hello Weex

Vue Native

Vue 在 Weex 中的不同

语法差异

1、“html标签”

2、Weex 环境中没有 DOM

3、支持有限的事件

4、没有 BOM 但可以调用原生 API

样式差异

Weex 开发&调试

Vue 语法

名存实亡的<标签/>

阉割版 CSS

单位

选择器

盒模型

FlexBox

显隐性

CSS 3

第三方工具库

npm 包管理

UI 尺寸适配

本地调试

方法一

方法二

Weex 的原理

打包

发包