IT瘾通信推荐

中国联通推进混改，启动运营组织体系改革，走互联网化转型之路丨钛快讯

Fri, 06 Mar 2020 23:35:00 CST

钛媒体3月6日消息，近日，中国联通在深化改革方面又有“大动作”，集团公司党组坚持疫情防控与改革发展“两手抓”，在2月下旬党组召开“应对疫情转危为机、蓄势提能转型发展”专题研讨会的基础上，3月3日公司党组审议通过了《大市场统筹运营组织体系改革方案》，相关改革随之全面启动。

中国联通运营组织体系改革的主要内容是，通过改革建立大市场统筹下的总部、省分、地市及区县四级新型运营体系，按照“统筹”、“产品”、“运营”三大板块，整合市场线资源。

第一， 在总部层面，建立以 “1 部 2 中心 ” 为核心的运营组织体系。 “1部 ”，即将市场部作为大市场体系的规划者和资源协调者，负责市场前后端的统筹协调组织。“2中心”，即建立大市场统筹下的“产品中心”、“渠道运营中心”。
第二， 在省公司层面，实现 “ 管 ” 、 “ 办 ” 分离。市场营销部负责规则与策略制定、统筹资源等，可设置独立的产品、运营板块；地市公司设营销部，负责客户运营与末梢支撑；区县以末梢生产组织为载体，负责落地执行。
第三， 在改革节奏上，实行分阶段推进。由于大市场统筹对现有组织的承载能力、团队的支撑能力、人员的专业能力都提出了新要求，公司将根据现实情况分为两个阶段有序推进。 第一阶段，重点补全大市场统筹职能，迅速提高公众市场产品能力，推进线上线下一体化，打造大统筹全运营的公众市场体系； 第二阶段，通过对产品、能力的进一步统筹整合，未来待集约共享、赋能渠道条件成熟后，建立“市场部+公众BG”市场与运营解耦模式。
第四，在改革的力度上，通过线上线下一体化进一步强化电商在发展中的作用。毫无疑问，从这次改革的最本质内容来看，电商的作用不仅不会削弱，而且会进一步增强。过去，电商可能作为公司的一个部门而单独存在，或者代表一类产品，或者代表一类渠道。这次改革后，全公司上下都将进一步按照互联网化的方式运作，推进整体性的数字化转型，实现线上线下的一体化融合。

中国联通实施大市场统筹下的运营组织体系改革，是纵深推进混合所有制改革的再突破，是互联网化运营转型的再推进，是中国联通“聚焦创新合作”战略和“五新”联通建设的再深化。这次改革意义主要体现在以下三点：

首先，这次改革是中国联通纵深推进混合所有制改革的实际行动。中国联通作为央企混改的先行者，在“混”的任务完成后，“改”的探索始终没有停歇。这次改革，也是希望在企业治理模式、治理结构与治理能力的现代化等方面进一步有所突破。
其次，这次改革是中国联通全面落实 “ 去机关化、去行政化、去层级化 ” 的实际行动。按照中央企业“总部机关化”问题专项整改工作部署，中国联通正在全面梳理总部和各级本部功能定位，优化职能、机构、岗位设置，建立更加符合公司化、市场化的组织运营体系。政企BG改革、大市场统筹改革都是落实这一部署的具体体现。
第三，这次改革是中国联通顺应防控新冠肺炎疫情助力全社会数字化转型变革、打造数字化服务能力的实际行动。当前，电信业正处于新旧动能转换的关键时期。过去以成本驱动的发展模式难以为继，传统业务增长缺乏动力。从行业外来看，加快5G建设发展、防控新冠肺炎疫情带来的数字化转型大潮风起云涌，线上线下一体化、集约化的消费与运营模式成为必然选择。面对新形势、新任务，需要加快推进公司运营模式转变，强化市场和资源的统筹与协同，提高市场前端组织变革的适应性，打造“体验领先、高效运营、良性增长”的数字化服务能力。

这次运营组织体系改革前，公司有关方面做了大量调查研究工作，归纳总结出目前在运营组织体系的定位、运营、支撑三个层面存在的诸多突出问题。 这次运营组织体系改革，重点要解决 “ 三个痛点问题 ” 、化解 “ 三对突出矛盾 ” 、加快 “ 三个转型 ” 。

一是解决 “ 三个痛点问题 ” ，具体来讲，就是通过运营组织体系的调整优化，重点解决“统筹不足”、“产品竞争力不足”、“线上线下割裂”这三个痛点问题；二是 化解“三对突出矛盾” ，具体来讲就是化解“增量与存量”、“营销与交付”、“销售与服务”这三对突出矛盾，加强产品与渠道触点间的协同，实现效率的提升；三是 加快“三个转型 ” ，通过上述努力，最终本次改革将以客户为中心，加快产品、渠道、创新三个转型，在转型需求的牵引下，厘清总部管控方式和功能定位、明确统筹内容、强化能力建设以支撑大市场统筹体系建设，有序推进大市场统筹运营体系和组织体系改革工作，建立“匹配转型、责权清晰、协作高效”的组织体系。

中国联通运营组织体系改革的主要目标是，聚焦客户价值经营、品牌塑造与传播、产品创新、全渠道运营、中台、大数据、生态合作、金融等8大能力建设，形成差异化优势。中国联通运营组织体系改革后新组建的“1部2中心”，其职责定位分别发生了新的变化。大市场统筹组织体系下的市场部，未来其主要职责是负责集团营销模式的建立，并尽快转型成为公司运营发展中的 “ 新六者 ” ：

一是在战略上，要做大市场体系的 规划者；二是在协同上，要做大市场资源的 协调者；三是在执行和变革上，要做领先营销模式的 打造者；四是在担当上，要做互联网化运营的 驱动者；五是在品牌上，要做智慧品牌的 创造者；六是在合作上，要做生态合作的 构建者。 大市场组织体系下的产品中心，将整合市场、电子商务相关业务，负责产品的统筹管理研发，落实产品全生命周期管理，加快推动产品转型。 大市场组织体系下的渠道运营中心，将整合实体渠道、电子商务相关业务，负责产品在各类触点的销售，以实现增量与存量、销售与服务、营销与交付、产品与触点之间的高效运营协同。

当前，新冠疫情的发生，使得“治理体系数字化，社会管理云大物化，企业经营互联网化，用户消费线上化”的趋势更加明显，中国联通将坚定不移地走互联网化转型之路。

（本文首发钛媒体）

更多精彩内容，关注钛媒体微信号（ID：taimeiti），或者下载钛媒体App

vue父子组件通信高级用法

Tue, 27 Aug 2019 10:52:02 CST

vue项目的一大亮点就是组件化。使用组件可以极大地提高项目中代码的复用率，减少代码量。但是使用组件最大的难点就是父子组件之间的通信。

子通信父

父组件

  <template>
  <div class="parent">
    我是父组件
    <!--父组件监听子组件触发的say方法，调用自己的parentSay方法-->
    <!--通过:msg将父组件的数据传递给子组件-->
    <children :msg="msg" @say="parentSay"></children>
  </div>
</template>

<script>
import Children from './children.vue'
export default {
  data () {
    return {
      msg: 'hello, children'
    }
  },
  methods: {
      // 参数就是子组件传递出来的数据
      parentSay(msg){
          console.log(msg) // hello, parent
      }
  },

  // 引入子组件
  components:{
      children: Children
  }
}
</script>

子组件

  <template>
  <div class="hello">
    <div class="children" @click="say">
      我是子组件
      <div>
        父组件对我说：{{msg}}
      </div>
    </div>

  </div>
</template>

<script>

  export default {
      //父组件通过props属性传递进来的数据
      props: {
          msg: {
              type: String,
              default: () => {
                  return ''
              }
          }
      },
      data () {
        return {
            childrenSay: 'hello, parent'
        }
      },

      methods: {
          // 子组件通过emit方法触发父组件中定义好的函数，从而将子组件中的数据传递给父组件
          say(){
              this.$emit('say' , this.childrenSay);
          }
      }
  }
</script>

子组件使用$emit方法调用父组件的方法，达到子通信父的目的。

父通信子

父组件

   <!--Html-->
<template>
   <!--父组件触发click方法-->
  <div class="parent" @click="say">
    我是父组件
    <!--通过ref标记子组件-->
    <children ref="child"></children>
  </div>
</template>

<script>
import Children from './children.vue'
export default {
  data () {
    return {
        msg: "hello,my son"
    }
  },
  methods: {
      // 通过$refs调用子组件的parentSay方法
      say(){
         this.$refs.child.parentSay(this.msg);
      }
  },

  // 引入子组件
  components:{
      children: Children
  }
}
</script>

子组件

  <template>
  <div class="hello">
    <div class="children" >
      我是子组件
      <div>
        父组件对我说：{{msg}}
      </div>
    </div>

  </div>
</template>

<script>

  export default {
      data () {
        return {
            msg: ''
        }
      },

      methods: {
          // 父组件调用的JavaScript方法parentSay
          parentSay(msg){
              this.msg = msg;
          }
      }
  }
</script>

父组件通过 $refs调用子组件的方法。
以上就是父子组件通信的方式，父子组件传递数据直接用props，或者使用 $emit和 $refs依靠事件来传递数据。

父子组件通信提升篇

上文中，子通信父是在 子中触发点击事件然后调用父组件的方法，父通信子是在 父中触发点击事件调用子组件的方法。但是实际情况中可能存在 子通信父时子组件不允许有点击事件而事件在父中或者 父通信子时点击事件在子组件中。

子通信父时击事件在父组件

这种情况其实很常见，例如提交一个表单时表单的内容为子组件，而保存按钮在父组件上。此时点击保存按钮想要获取子组件表单的值。这种情况下已经不单单是子通信父和父通信子了，需要将两者结合在一起使用才能完成整个通信过程。

实现的思路是在父组件中点击事件时，先通过父子通信调用子组件的方法，然后在子组件中的该方法里使用子父通信调用父组件的另一个方法并将信息传递回来。以下是代码演示：

父组件

  <template>
  <div class="parent" @click="getData">
    我是父组件
    <!--父组件监听子组件触发的transData方法，调用自己的transData方法-->
    <!--通过ref标记子组件-->
    <children ref="child" @transData="transData"></children>
  </div>
</template>

<script>
import Children from './children.vue'
export default {
  data () {
    return {
      msg: 'hello, children'
    }
  },
  methods: {
      getData(){
          // 调用子组件的getData方法
          this.$refs.child.getData();
      },
      // 参数就是子组件传递出来的数据
      transData(msg){
          console.log(msg) // hello, parent
      }
  },

  // 引入子组件
  components:{
      children: Children
  }
}
</script>

子组件

  <template>
  <div class="hello">
    <div class="children" >
      我是子组件
      <div>
        子组件的数据：{{childrenSay}}
      </div>
    </div>

  </div>
</template>

<script>

  export default {
      data () {
        return {
            childrenSay: 'hello, parent'
        }
      },
      methods: {
          // 子组件通过emit方法触发父组件中定义好的函数，从而将子组件中的数据传递给父组件
          getData() {
              this.$emit('transData' , this.childrenSay);
          }
      }
  }
</script>

另一种情况思路也和这个一样，基础就在与父通信子和子通信父的灵活运用。
转评赞就是最大的鼓励

2018上半年中国三大运营商数据对比移动宽带用户数逼近电信

Sat, 11 Aug 2018 20:28:52 CST

昨日，中国移动发布2018年中期业绩，上半年营运收入达到3918亿元，同比增长2.9%；净利润达到656亿元，同比增长4.7%。与靓丽业绩同步呈现的是，中国移动在固网家宽市场上的高歌猛进。在今年上半年，中国移动宽带用户已经实现净增2238.6万户，其中家庭宽带客户净增1880万。

为此，中国移动将今年宽带用户发展目标从2100万户调高至3000万户，这也意味着中国移动今年的宽带用户数量有望超过1.4亿户。业内人士指出，按照此增速，中国移动在今年下半年将铁定超越中国电信，成为家宽市场上的领头羊，进而实现“双冠王”。

增速碾压

今年上半年，中国移动宽带用户增长数量仍旧保持着快速增长的势头。据今年三大运营商披露的1-6月运营数据显示，中国移动1-6月宽带用户净增数分别为407.6万、308.1万、407.6万、317.8万、335万、462.5万。

中国电信1-6月宽带用户净增数分别为103万、98万户、175万、100万、99万、134万；中国联通1-6月宽带用户净增数分别为50.1万、43.3万、58.4万、25.3万、30.9万、29.7万。

截至6月底，中国移动、中国电信、中国联通累计宽带用户数量分别为1.35073亿户、1.4062亿户、7891.6万户。按照上半年平均增速，预计下个月，中国移动宽带用户数量将与中国电信用户数持平，成为宽带市场并列第一。在今年第四季度，中国移动将大概率超越中国电信，成为市场“一哥”。

健康成长

可能有很多人认为，中国移动在家庭宽带市场上的增长，都是“赠送”来的，但实际情况并非如此。

据中国移动2018年中期业绩数据显示，上半年，家庭宽带收入达到210亿元，同比增加49.1%，成为中国移动的重要增收来源；上半年家庭宽带综合ARPU达到34.8元，增长7.3%。

也就是说，在用户保持高速增长的同时，中国移动宽带收入、宽带用户ARPU也保持着持续增长。

据中国移动总裁李跃介绍，在上半年，中国移动持续推进用户向中高速宽带升级，100兆以上带宽收入占比达到42.5%，较2017年底提升了20.5个百分点。同时，中国移动还积极构建融合的家庭生态，大力拓展智能家庭网端等智能产品，为家庭业务持续增长奠定了坚实的基础。目前，中国移动魔百和客户规模突破7915万，比上年底净增2190万，渗透率达到61.7%。

除此之外，作为运营商家宽市场竞争的重要抓手，中国移动在今年6月份成功拿到了广电总局的IPTV传输牌照，扫清了政策障碍，真正实现了与电信、联通的同台竞技。

自中国通信网

Android 进程间通信

Fri, 23 Feb 2018 21:58:37 CST

什么鬼！单例居然失效了，一个地方设置值，另个地方居然取不到，这怎么可能？没道理啊！排查半天，发现这两就不在一个进程里，才恍然大悟……

什么是进程

按照操作系统中的描述：进程一般指一个执行单元，在 PC 和移动设备上指一个程序或者一个应用。

为什么要使用多进程

我们都知道，系统为 APP 每个进程分配的内存是有限的，如果想获取更多内存分配，可以使用多进程，将一些看不见的服务、比较独立而又相当占用内存的功能运行在另外一个进程当中。

目录结构预览

先放出最终实践后的目录结构，有个大概印象，后面一一介绍。

如何使用多进程

AndroidManifest.xml 清单文件中注册 Activity、Service 等四大组件时，指定 android:process 属性即可开启多进程，如：

  <activity
    android:name=".Process1Activity"
    android:process=":process1" />
<activity
    android:name=".Process2Activity"
    android:process="com.wuxiaolong.androidprocesssample.process2" />

说明：

1、 com.wuxiaolong.androidprocesssample，主进程，默认的是应用包名；

2、 android:process=":process1"，“：”开头，是简写，完整进程名包名 + :process1；

3、 android:process="com.wuxiaolong.androidprocesssample.process2"，以小写字母开头的，属于全局进程，其他应用可以通过 ShareUID 进行数据共享；

4、进程命名跟包名的命名规范一样。

进程弊端

Application 多次创建

我们自定义一个 Application 类， onCreate 方法进行打印 Log.d("wxl", "AndroidApplication onCreate"); ，然后启动 Process1Activity:

  com.wuxiaolong.androidprocesssample D/wxl: AndroidApplication onCreate
com.wuxiaolong.androidprocesssample:process1 D/wxl: AndroidApplication onCreate

看到确实被创建两次，原因见： android:process 的坑，你懂吗？多数情况下，我们都会在工程中自定义一个 Application 类，做一些全局性的初始化工作，因为我们要区分出来，让其在主进程进行初始化，网上解决方案：

  @Override
public void onCreate() {
    super.onCreate();
    String processName = AndroidUtil.getProcessName();
    if (getPackageName().equals(processName)) {
        //初始化操作
        Log.d("wxl", "AndroidApplication onCreate=" + processName);
    }
}

AndroidUtil：

  public static String getProcessName() {
    try {
        File file = new File("/proc/" + android.os.Process.myPid() + "/" + "cmdline");
        BufferedReader mBufferedReader = new BufferedReader(new FileReader(file));
        String processName = mBufferedReader.readLine().trim();
        mBufferedReader.close();
        return processName;
    } catch (Exception e) {
        e.printStackTrace();
        return null;
    }
}

静态成员和单例模式失效

创建一个类 SingletonUtil：

  public class SingletonUtil {
    private static SingletonUtil singletonUtil;
    private String userId = "0";

    public static SingletonUtil getInstance() {
        if (singletonUtil == null) {
            singletonUtil = new SingletonUtil();
        }
        return singletonUtil;
    }

    public String getUserId() {
        return userId;
    }

    public void setUserId(String userId) {
        this.userId = userId;
    }
}

在 MainActivity 进行设置：

  SingletonUtil.getInstance().setUserId("007");

Process1Activity 取值，打印：

  Log.d("wxl", "userId=" + SingletonUtil.getInstance().getUserId());

发现打印 userId=0，单例模式失效了，因为这两个进程不在同一内存了，自然无法共享。

进程间通信

文件共享

既然内存不能共享，是不是可以找个共同地方，是的，可以把要共享的数据保存 SD 卡，实现共享。首先将 SingletonUtil 实现 Serializable 序列化，将对象存入 SD 卡，然后需要用的地方，反序列化，从 SD 卡取出对象，完整代码如下：

SingletonUtil

  public class SingletonUtil implements Serializable{
    public static String ROOT_FILE_DIR = Environment.getExternalStorageDirectory() + File.separator + "User" + File.separator;
    public static String USER_STATE_FILE_NAME_DIR = "UserState";
    private static SingletonUtil singletonUtil;
    private String userId = "0";

    public static SingletonUtil getInstance() {
        if (singletonUtil == null) {
            singletonUtil = new SingletonUtil();
        }
        return singletonUtil;
    }

    public String getUserId() {
        return userId;
    }

    public void setUserId(String userId) {
        this.userId = userId;
    }
}

序列化和反序列化

  public class AndroidUtil {
    public static boolean createOrExistsDir(final File file) {
        // 如果存在，是目录则返回true，是文件则返回false，不存在则返回是否创建成功
        return file != null && (file.exists() ? file.isDirectory() : file.mkdirs());
    }

    /**
     * 删除目录
     *
     * @param dir 目录
     * @return {@code true}: 删除成功<br>{@code false}: 删除失败
     */
    public static boolean deleteDir(final File dir) {
        if (dir == null) return false;
        // 目录不存在返回true
        if (!dir.exists()) return true;
        // 不是目录返回false
        if (!dir.isDirectory()) return false;
        // 现在文件存在且是文件夹
        File[] files = dir.listFiles();
        if (files != null && files.length != 0) {
            for (File file : files) {
                if (file.isFile()) {
                    if (!file.delete()) return false;
                } else if (file.isDirectory()) {
                    if (!deleteDir(file)) return false;
                }
            }
        }
        return dir.delete();
    }

    /**
     * 序列化，对象存入SD卡
     *
     * @param obj          存储对象
     * @param destFileDir  SD卡目标路径
     * @param destFileName SD卡文件名
     */
    public static void writeObjectToSDCard(Object obj, String destFileDir, String destFileName) {

        createOrExistsDir(new File(destFileDir));
        deleteDir(new File(destFileDir + destFileName));
        FileOutputStream fileOutputStream = null;
        ObjectOutputStream objectOutputStream = null;
        try {
            fileOutputStream = new FileOutputStream(new File(destFileDir, destFileName));
            objectOutputStream = new ObjectOutputStream(fileOutputStream);
            objectOutputStream.writeObject(obj);

        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            try {
                if (objectOutputStream != null) {
                    objectOutputStream.close();
                    objectOutputStream = null;
                }
                if (fileOutputStream != null) {
                    fileOutputStream.close();
                    fileOutputStream = null;
                }
            } catch (IOException e) {
                e.printStackTrace();
            }

        }

    }

    /**
     * 反序列化，从SD卡取出对象
     *
     * @param destFileDir  SD卡目标路径
     * @param destFileName SD卡文件名
     */
    public static Object readObjectFromSDCard(String destFileDir, String destFileName) {
        FileInputStream fileInputStream = null;

        Object object = null;
        ObjectInputStream objectInputStream = null;

        try {
            fileInputStream = new FileInputStream(new File(destFileDir, destFileName));
            objectInputStream = new ObjectInputStream(fileInputStream);
            object = objectInputStream.readObject();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            try {
                if (objectInputStream != null) {
                    objectInputStream.close();
                    objectInputStream = null;
                }
                if (fileInputStream != null) {
                    fileInputStream.close();
                    fileInputStream = null;
                }
            } catch (IOException e) {
                e.printStackTrace();
            }

        }
        return object;

    }
}

需要权限：

  <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

MainActivity 序列写入

  SingletonUtil singletonUtil = SingletonUtil.getInstance();
singletonUtil.setUserId("007");
AndroidUtil.writeObjectToSDCard(singletonUtil, SingletonUtil.ROOT_FILE_DIR, SingletonUtil.USER_STATE_FILE_NAME_DIR);

Process1Activity 反序列化取值

  Object object = AndroidUtil.readObjectFromSDCard(SingletonUtil.ROOT_FILE_DIR, SingletonUtil.USER_STATE_FILE_NAME_DIR);
if (object != null) {
    SingletonUtil singletonUtil = (SingletonUtil) object;
    Log.d("wxl", "userId=" + singletonUtil.getUserId());//打印：userId=007
}

AIDL

AIDL，Android 接口定义语言，定义客户端与服务端进程间通信，服务端有处理多线程时，才有必要使用 AIDL，不然可以使用 Messenger ，后文介绍。

单个应用，多个进程

服务端

AIDL 传递数据有基本类型 int，long，boolean，float，double，也支持 String，CharSequence，List，Map，传递对象需要实现 Parcelable 接口，这时需要指定 in（客户端数据对象流向服务端）、out （数据对象由服务端流向客户端）。

1、Userbean.java

  public class UserBean implements Parcelable {
    private int userId;
    private String userName;

    public int getUserId() {
        return userId;
    }

    public void setUserId(int userId) {
        this.userId = userId;
    }

    public String getUserName() {
        return userName;
    }

    public void setUserName(String userName) {
        this.userName = userName;
    }

    public UserBean() {

    }

    private UserBean(Parcel in) {
        userId = in.readInt();
        userName = in.readString();
    }

    /**
     * @return 0 或 1 ，1 含有文件描述符
     */
    @Override
    public int describeContents() {
        return 0;
    }

    /**
     * 系列化
     *
     * @param dest  当前对象
     * @param flags 0 或 1，1 代表当前对象需要作为返回值，不能立即释放资源
     */
    @Override
    public void writeToParcel(Parcel dest, int flags) {
        dest.writeInt(userId);
        dest.writeString(userName);
    }

    /**
     * 反序列化
     */
    public static final Creator<UserBean> CREATOR = new Creator<UserBean>() {
        @Override
        public UserBean createFromParcel(Parcel in) {
            return new UserBean(in);
        }

        @Override
        public UserBean[] newArray(int size) {
            return new UserBean[size];
        }
    };

}

2、UserBean.aidl

Userbean.java 同包下创建对应的 UserBean.aidl 文件，与 aidl 调用和交互。

  // UserBean.aidl
package com.wuxiaolong.androidprocesssample;

parcelable UserBean;

3、IUserManager.aidl

  // IUserManager.aidl
package com.wuxiaolong.androidprocesssample;

// Declare any non-default types here with import statements
//手动导入
import com.wuxiaolong.androidprocesssample.UserBean;

interface IUserManager {

    //基本数据类型：int，long，boolean，float，double，String
    void hello(String aString);

    //非基本数据类型，传递对象
    void getUser(in UserBean userBean);//in 客户端->服务端


}

4、服务类

新建 AIDLService 继承 Service，并且实现 onBind() 方法返回一个你实现生成的 Stub 类，把它暴露给客户端。Stub 定义了一些辅助的方法，最显著的就是 asInterface()，它是用来接收一个 IBinder，并且返回一个 Stub 接口的实例。

  public class AIDLService extends Service {

    private Binder binder = new IUserManager.Stub() {

        @Override
        public void getUser(UserBean userBean) throws RemoteException {
            Log.d("wxl", userBean.getUserId() + "," + userBean.getUserName() + " from AIDL Service");
        }

        @Override
        public void hello(String aString) throws RemoteException {
            Log.d("wxl", aString + " from AIDL Service");
        }
    };

    @Nullable
    @Override
    public IBinder onBind(Intent intent) {
        return binder;
    }

    @Override
    public void onCreate() {
        super.onCreate();
    }
}

AndroidManifest 注册：

  <service
    android:name=".AIDLService"
    android:process=":aidlRemote" />

以上创建完毕，build clean 下，会自动生成 aidl 对应的 java 类供客户端调用。

客户端

1、app/build.gradle

需要指定 aidl 路径：

  android {
    //……
    sourceSets {
        main {
            java.srcDirs = ['src/main/java', 'src/main/aidl']
        }
    }
}

2、启动服务，建立联系

  public class MainActivity extends AppCompatActivity {

    private ServiceConnection aidlServiceConnection = new ServiceConnection() {
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            IUserManager remoteService = IUserManager.Stub.asInterface(service);
            UserBean userBean = new UserBean();
            userBean.setUserId(1);
            userBean.setUserName("WuXiaolong");
            try {
                remoteService.getUser(userBean);
                remoteService.hello("Hello");
            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {

        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Intent intent = new Intent(this, AIDLService.class);
        bindService(intent, aidlServiceConnection, Context.BIND_AUTO_CREATE);
    }

    @Override
    protected void onDestroy() {
        unbindService(aidlServiceConnection);
        super.onDestroy();
    }
}

打印：

  com.wuxiaolong.androidprocesssample:aidlRemote D/wxl: 1,WuXiaolong from AIDL Service
com.wuxiaolong.androidprocesssample:aidlRemote D/wxl: Hello from AIDL Service

多个应用，多进程

和上面基本差不多，把服务端和客户端分别创建的两个项目，可以互相通信，注意点：

1、服务端创建好的 aidl 文件，带包拷贝到客户端项目中；

2、客户端启动服务是隐式启动，Android 5.0 中对 service 隐式启动有限制，必须通过设置 action 和 package，代码如下：

AndroidManifest 注册：

  <service android:name=".AIDLService">
    <intent-filter>
        <action android:name="android.intent.action.AIDLService" />
    </intent-filter>

启动服务：

  Intent intent = new Intent();
intent.setAction("android.intent.action.AIDLService");
intent.setPackage("com.wuxiaolong.aidlservice");
bindService(intent, serviceConnection, Context.BIND_AUTO_CREATE);

使用 Messenger

Messenger 可以在不同的进程传递 Message 对象，而我们可以在 Message 对象中放入我们所需要的数据，这样就能实现进程间通信了。Messenger 底层实现是 AIDL，对 AIDL 做了封装，不需要处理多线程，实现步骤也分为服务端和客户端，代码如下：

服务端

MessengerService：

  public class MessengerService extends Service {

    private final Messenger messenger = new Messenger(new MessengerHandler());


    private static class MessengerHandler extends Handler {
        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
                case MainActivity.MSG_FROM_CLIENT:
                    //2、服务端接送消息
                    Log.d("wxl", "msg=" + msg.getData().getString("msg"));

                    //4、服务端回复消息给客户端
                    Messenger serviceMessenger = msg.replyTo;
                    Message replyMessage = Message.obtain(null, MSG_FROM_SERVICE);
                    Bundle bundle = new Bundle();
                    bundle.putString("msg", "Hello from service.");
                    replyMessage.setData(bundle);
                    try {
                        serviceMessenger.send(replyMessage);
                    } catch (RemoteException e) {
                        e.printStackTrace();
                    }
                    break;
            }
            super.handleMessage(msg);
        }
    }

    @Nullable
    @Override
    public IBinder onBind(Intent intent) {
        return messenger.getBinder();
    }
}

AndroidManafest.xml 注册：

  <service
    android:name=".MessengerService"
    android:process=":messengerRemote" />

客户端

MainActivity

  public class MainActivity extends AppCompatActivity {
    public static final int MSG_FROM_CLIENT = 1000;
    public static final int MSG_FROM_SERVICE = 1001;
    private Messenger clientMessenger;
    private ServiceConnection messengerServiceConnection = new ServiceConnection() {
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            //1、发送消息给服务端
            clientMessenger = new Messenger(service);
            Message message = Message.obtain(null, MSG_FROM_CLIENT);
            Bundle bundle = new Bundle();
            bundle.putString("msg", "Hello from client.");
            message.setData(bundle);
            //3、这句是服务端回复客户端使用
            message.replyTo = getReplyMessenger;
            try {
                clientMessenger.send(message);
            } catch (RemoteException e) {
                e.printStackTrace();
            }
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {

        }
    };

    private final Messenger getReplyMessenger = new Messenger(new MessengerHandler());

    private static class MessengerHandler extends Handler {
        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
                case MainActivity.MSG_FROM_SERVICE:
                    //5、服务端回复消息给客户端，客户端接送消息
                    Log.d("wxl", "msg=" + msg.getData().getString("msg"));
                    break;
            }
            super.handleMessage(msg);
        }
    }


    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
 
        // Messenger 进行通信
        Intent intent = new Intent(this, MessengerService.class);
        bindService(intent, messengerServiceConnection, Context.BIND_AUTO_CREATE);

    }

    @Override
    protected void onDestroy() {
        unbindService(messengerServiceConnection);
        super.onDestroy();
    }

}

打印信息：

  com.wuxiaolong.androidprocesssample:remote D/wxl: msg=Hello from client.
com.wuxiaolong.androidprocesssample D/wxl: msg=Hello from service.

最后

《Android开发艺术探索》一书关于 Android 进程间通信这块，还有 ContentProvider、Socket 方式，由于篇幅所限，这里不一一介绍了，有兴趣可以自行查看。如果需要这次 Sample 的源码，可在我的公众号「吴小龙同学」回复：「AndroidProcessSample」获取。

参考

《Android开发艺术探索》
Android 中的多进程，你值得了解的一些知识
 Android使用AIDL实现跨进程通讯（IPC）

Adrian Stephens：预测2017 年移动通讯行业趋势分析

Mon, 02 Jan 2017 13:12:47 CST

本文作者是 IEEE 802.11 无线局域网工作组主席 Adrian Stephens，在即将迈入全新的 2017 年之际，他对未来移动通讯行业进行了一些预测，包括 Wi-Fi 网络的发展对未来 5G、物联网等领域里所产生的影响和应用前景。

对于业内人士来说，预测行业趋势总是一件值得去做的事情，因为你可以据此判断自己是否足够了解所处的行业。事实上，作为人类，我们并不太擅长预测未来，不过一旦我们预测对了，则会非常享受这种“意外的幸福”。

在过去的 25 年时间里，当涉及到 IEEE 802.11 相关的技术——嗯，没错，其实就是 Wi-Fi，其实已经非常成熟了。不过我们似乎都低估了市场的能力，因为很多创新用例都是过去无法预见的。换句话说，作为IEEE 802.11 无线局域网工作组里的一名技术人员兼主席，也许明年我依然会回到幕后努力工作，但是我希望通过这次预测给未来市场带来一些理性因素。而且，几乎可以肯定的是，在 2017 年到 2020 年之间，“物联网”和新兴的“5G”技术将会迅速增长。

从短期来看

IEEE 802.11ad 标准是基于 60GHz 未授权频谱运行的，并且支持室内覆盖千兆位速度的高网络数据吞吐量。相比于 2012 年，这种能力也许能够满足一些行业的应用需求，但随着商业竞争力的不断增强，以及受到用户必须为链接两端付费的约束，IEEE 802.11ad 很可能无法避免被淘汰的宿命。与之相匹配的是，该标准的用例也会发生改变，过去它可能被用于连接一个扩展网络基座，现在则会用于连接外围设备；过去它适用于便捷的无线家庭办公环境，现在则会应用在数据中心建立无线网络通讯网络，企业也无需花费成本购买铜制或光纤电缆来铺设有线网络了。那么，IEEE 802.11ad 什么时候能够实现大规模商业化应用呢？其实，这个问题我也无法预测答案。

在 2016 年，IEEE 标准协会回到了基本的 IEEE 802.11-2016 标准上，并推出了 IEEE Std 802.11ac 和 IEEE Std 802.11ad。与此同时，这些标准也有机会去支持更精准、吞吐量更高、并且基于室内定位的应用，或许它们在 2017 年能够“引起轰动”，因为目前网络定位的精准度大约在五米左右，而未来则可能精准到三米范围之内。相应地，一些基于地理定位功能的服务供应商应该会对这种技术青睐有加。

在此，我可以介绍两个已知的用例。一个用例可以应用在大型购物中心，你可以识别、追踪购物者的位置，然后通过定位及时推送一些优惠券。如果整合一些数据分析功能，商家还可以了解到某个特定购物者的消费喜好和兴趣，不过，由于这种分析涉及到个人数据隐私等问题，能否被实际应用还需要得到政策制定者的审查批准。另一个用例则是所谓的“地理围栏”，用一个虚拟的栅栏围出一个虚拟地理边界。当你进入到某个保密领域里之后，设备就无法再访问一些机密内容了。显然，对于一些公共或私人部门会议的时候，“地理围栏”可以有效限制移动设备分享数据，提升数据安全性。

IEEE P802.11az 则正在酝酿之中，它可以进一步优化定位精准度，在 60Ghz 未授权频谱下能够准确到几厘米的范围。在电信行业内经常谈到所谓“最后一公里”连接，现在我们又在谈论“最后一米”连接，说不定未来我们谈论的会是“最后一厘米”连接了。虽然现在我还不清楚如此精准的“最后一厘米”连接具体用例会在哪里，但请放心，它肯定会发生的。

物联网时代已经来了

相信很多雷锋网的读者已经体验过物联网应用了，比如你可以通过自己手上的移动设备能够与家中的智能恒温器进行通讯，此外还可以远程控制家中的能耗管理设备，比如电热器和空调等。这其实就是目前物联网技术的表现形式，不过未来在 IEEE 802.11 LAN 的支持下，物联网设备可能会发挥更多能力。未来“物联设备”如何彼此通讯、又如何与互联网交流呢？

随着市场上投放的物联网产品和服务越来越多，网络连接的价值也开始增长。根据梅特卡夫定律，网络的有用性（价值）随着用户数量的平方数增加而增加。换句话说，某种网络，比如电话的价值会随着使用用户数量的增加而增加，而在物联网行业里，当使用物联网技术的人越多，这种技术的自身价值也会得到大幅提升。一些与 IEEE 802.11 相关的、设备对设备或设备对互联网应用将会“浮出水面”，比如用于节能的供电协调设备和系统，以及智能建筑、智能城市和智能电网。

其他影响物联网的 Wi-Fi 技术标准还包括 IEEE 802.11ah-2016，明年可能会出现一些相关产品。它提供了更广的网络覆盖范围，而且能耗也较低，此外利用低于 1 GHz 未授权开放频段，能够很好地适应连接物联网应用里的多个传感器设备。

另一个重要发展，是我们所谓的 IEEE P802.11ba “无线电唤醒”能力，目前该标准也正在酝酿之中，不过再明年推出的可能性不大。很快，物联网内的“物”将可以使用两个无线电同时确保低延迟和高能效。一个无线电将会高效“唤醒”一台设备，或是“物”和其他无线电连接，而且一旦触发了唤醒，就能确保处理低延迟数据通讯。

5G：真正的游戏颠覆者

5G 网络代表了多样化的网络需求，比如机器对机器通讯、高移动设备、高吞吐量、高可靠性和低延迟，等等，这些不同的需求也导致没有一个独立的系统能够完全满足。4G 网络依靠的是单一芯片组，因此 802.11 将在某些特定领域内补充、并支持 5G 网络，比如让未授权频谱得到更高效的使用。举个例子，IEEE P802.11ax 涵盖了一系列能力，包括高效率频谱、大于 10 千兆比特每秒的吞吐量，等等。但是，想要最终实现商业化应用可能还需要等待几年时间。

那么，消费者会如何看待 5G 网络呢？预计在 2020 年的冬季夏季奥运会上，很多厂商会展示 5G 网络的实际应用，所以我们需要抓紧时间来尽快实现这一革命性的飞跃了！

总结

2017 年，我们可能会看到市场出现更多全新的无线 Wi-Fi 功能，而且到 2020 年，更多后续新功能也会逐渐推出。当然，我们也惊讶于 IEEE 802.11 的“变形”能力已经超出了过去的预测。实际上，我们也都知道任何新技术的市场应用都依赖于多种因素，所以如果你相信了我的预测，那么就请“后果自负”哦！

VIA： crwireless

来自：雷锋网

您可能也喜欢的文章：
IDC：2015年计算机科技行业趋势预测	2016年ICT产业趋势预测	Forrester：2013年移动行业十大趋势	2014年移动信息化八大趋势预测	2015年五大IT趋势预测
无觅

Web应用中实时消息技术总结

Sun, 25 Oct 2015 15:21:43 CST

在互联网应用中，很多时候我们需要在客户端和服务端之间进行实时的消息交互，比如下面这些常见的应用场景：

SNS网站用户互动消息通知(weibo/twitter)
门户网站实时滚动新闻(突发事件)、文字直播(体育赛事)
在线聊天室(在线客服)
实时数据展示（实时股价，实时商品价，服务器实时监控等）

接下来就来看看web开发中常见的实时消息的实现技术方案，每种方案都各有优缺点，在不同的应用场景下有不同的选择

普通的http

客户端从服务器端请求网页
服务器作出相应的反应
服务器返回相应到客户端

AJAX Polling

客户端使用普通的http方式向服务器端请求网页
客户端执行网页中的JavaScript轮询脚本，定期循环的向服务器发送请求（例如每5秒发送一次请求），获取信息
服务器对每次请求作出响应，并返回相应信息，就像正常的http请求一样

客户端定时请求服务器来询问是否有新的消息产生，这种情况下客户端每次请求都要建立一次http连接，服务器都要产生一个响应信息。

优点：实现简单，使用方便，开发成本很低，适合刚起步的小型应用或是其它方案的备用方案。
缺点：消息有延迟，网络通信消耗大（特别是移动网络下），服务器容易产生峰值请求。
实现：浏览器里用js定时请求，或是移动设备上 native app里定时发http请求。
实例：适于小型应用。

AJAX Long-Polling

客户端使用普通的http方式向服务器端请求网页
客户端执行网页中的JavaScript脚本，向服务器发送数据、请求信息
服务器并不是立即就对客户端的请求作出响应，而是等待有效的更新
当信息是有效的更新时，服务器才会把数据推送给客户端
当客户端接收到服务器的通知时，立即会发送一个新的请求，进入到下一次的轮询

跟上面的polling模式相比：

优点：消息到达客户端更及时；减少了http请求不停地创建、关闭成的不必要浪费。在无消息的情况下不会频繁的请求。Long-polling支持大多数当前的浏览器。
缺点：服务端需要保持大量连接，http连接的维护开销较大；每次产生消息后都需要重新创建连接。
实现：客户端只要简单的发送请求，等待响应即可。服务器端需要做两方面的工作：一是保持大量的连接(Non-Blocking I/O)；二是读取后台的消息更新（异步定时轮询或由事件触发）。是一个近实时的异步方式。
兼容性：
实例：WebQQ、Hi网页版、Facebook IM。

基于流的模式(http streaming)

在这种情况下，客户端与服务器端保持一个持久的连接，服务器端有新消息产生时通过这个持久连接不断地返回给客户端。这种模式与上面的long polling差不多，差别就是只需要创建一次连接就可以了。另外，要注意http header中需要设置Connection: keep-alive和Transfer-Encoding: chunked这两个属性。跟上面longpolling模式相比：

优点：消息可以实时到达客户端；客户端与服务端之间只需要建立一次连接。
缺点：服务器端也要维持大量连接，开销很大。
实现：客户端一般有两种方式：一是隐藏iframe的src指向服务器端url，不断地进行dom渲染；二是使用ajax里的XMLHttpRequest对象来实现。对于服务端来说，和 long polling一，要保持大量连接和处理后台的消息更新。

HTML5 Server Sent Events (SSE) / EventSource:

客户端使用普通的http方式向服务器端请求网页
客户端执行网页中的JavaScript脚本，与服务器之间建立了一个连接
当服务器端有有效的更新时，会发送一个事件到客户端
- 服务器到客户端数据的实时推送，大多数内容是你需要的
- 你需要一台可以做Event Loop的服务器
- 不允许跨域的连接
- 默认延时3秒，但是可以调整。
- 除非Server-Sent Events不必在每一次响应发出后都关闭连接。
- 支持Chrome9+、Firefox6+、Opera11+、Safari5+

如果你觉得这些还不够，想要了解更多，可以参考下面的文件和手册

HTML5 Websockets

客户端使用普通的http方式向服务器端请求网页
客户端执行网页中的JavaScript脚本，与服务器之间建立了一个连接
服务器和客户端之间，可以双向的发送有效数据到对方
- 服务器可以实时的发送数据到客户端，同时客户端也可以实时的发送数据到服务器
- 你需要一台可以做Event Loop的服务器
- 使用 WebSockets 允许跨域的建立连接
- 它同样支持第三方的websocket主机服务器，例如Pusher或者其它。这样你只需要关心客户端的实现，降低了开发难度。

WebSocket是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术，浏览器和服务器只需要要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相送。

优点：实时通讯，双向交互，节省服务器资源和带宽。真正的实时。
缺点：浏览器支持不足。
实现：客户端需要html5来实现，服务器端一般的web服务器都有支持。

目前WebSocket协议仍在开发中，目前Chrome和Safri浏览器默认支持WebSocket，而Firefox和Opera出于安全考虑，默认关闭了WebSocket，IE则不支持（包括9），目前WebSocket协议最新的为“76号草案”。有兴趣可以看以下资料 http://dev.w3.org/html5/websockets/

如果你觉得这些还不够，想要了解更多，可以参考下面的文件和手册

Flash Socket

在页面中内嵌入一个使用了Socket类的 Flash 程序JavaScript通过调用此Flash程序提供的Socket接口与服务器端的Socket接口进行通信，JavaScript在收到服务器端传送的信息后控制页面的显示。

优点：实现真正的即时通信，而不是伪即时。
缺点：客户端必须安装Flash插件；非HTTP协议，无法自动穿越防火墙。
实例：网络互动游戏。

WebRTC

WebRTC是一种点对点类型的传输方式，它支持多种传输协议，如：UDP、TCP甚至是抽象层的协议。设计它时同时考虑到了允许使用可靠和不可靠的两种方式传输数据。这种技术一般应用在传输数据量较大的内容，比如音、视频等流媒体的传输。

参考资料： https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API

Comet

Comet是一种用于web的推送技术，能使服务器实时地将更新的信息传送到客户端，而无须客户端发出请求，目前有两种实现方式，长轮询和iframe流。

Event Loop是一个程序结构，用于等待和发送消息和事件。
长轮询是在打开一条连接以后保持，等待服务器推送来数据再关闭的方式。
iframe流方式是在页面中插入一个隐藏的iframe，利用其src属性在服务器和客户端之间创建一条长链接，服务器向iframe传输数据（通常是HTML，内有负责插入信息的javascript），来实时更新页面。iframe流方式的优点是浏览器兼容好，Google公司在一些产品中使用了iframe流，如Google Talk。

如果你想了解更多，可以参考维基百科或者IBM

优点：消息即时到达，不发无用请求。
缺点：服务器维护一个长连接会增加开销。
实例：Gmail聊天

参考链接： http://stackoverflow.com/questions/11077857/what-are-long-polling-websockets-server-sent-events-sse-and-comet

在我们实际的应用中，各种方案应该怎么选择？

polling轮询机制很简单，使用方便，都是http短连接，在应用架构上跟普通接口api一致，非常适合小型应用和刚起步的应用，可以节省很多开发成本。

当用户量上升到一定程度后（比如日活跃百万级），产品做得越来越受欢迎了，我们对消息到达的及时性也就有更高的要求了，而且这种轮询机制对服务器压力也是一种考验，这时候我们就可以考虑long polling或http streaming的方式了，这两种方式其实在服务端实现上差不多，主要是保持大量长连接和异步（或事件触发）获取消息。

在保持连接方面，在java的nio出现后，为我们提供了便利，主流的应用服务器像tomcat和jetty都有支持，但是，工作在jvm上的服务器保持大量socket连接时gc是个很严重的问题。可以借助nginx的push模块来实现保持连接以及消息实时推送。

支持long polling模式的模块: https://pushmodule.slact.net/
支持streaming模式的模块： http://wiki.nginx.org/HttpPushStreamModule

这两个模块工作在nginx上，可以维持大量的http连接，实现了pub/sub协议来支持消息发送，基本流程是下图这的，发送者(publisher)把消息推送到nginx服务器上，然后push模块负责把消息发送给订阅者(client)：借助nginx的这个push模块，我们可以省去大量的工作，应用程序只需要关注业务逻辑（也就是publisher做的事），简化了应用架构，同时nginx的高性能也有不错的表现。

当我们的产品发展到千万级的日活跃时，我们可能就要考虑更好的方案了，比如上面的提到的WebSocket，但是为浏览器兼容的问题，这个方案并不是主流的解决方案。一般这种情况下，我们就要考虑基于tcp的socket长连接模式了，通过某种消息推送协议（xmpp/mqtt/自定议协议等）来实现客户端和服务器端的实时交互。

其他相关资料： http://socket.io/

招行向左平安向右：互联网金融做app这事靠谱吗？

Fri, 13 Feb 2015 14:25:27 CST

微信变得越来越讲“规则”：2月4日起，微信关闭了支付宝钱包、虾米音乐、网易云音乐甚至叫车应用Uber的微信分享信息，如果你点击这些APP分享到微信里的链接，会出现无法打开的提示。微信关闭它们似乎“理由充分”：支付宝钱包进行红包营销，网易云音乐与QQ音乐之间有版权纠纷等等，不一而足。

姑且不讨论微信这么经营自己的生态是不是合理，反正只要在微信这个中国最大的移动熟人关系社交网络平台里开发应用或进行营销推广，就必须遵循它制定的“规则”。微信表示自己正在“连接一切”，但第三方在微信平台上能做的事却有着极为严格的限制：比如订阅号一天只能发送有限次数的群发消息，服务号的服务信息推送也要遵循微信的相关规定，商业信息分享更不能过火，否则就有被判定“营销”的危险……

当然也会有一些例外：比如滴滴打车的红包分享在微信里就从来不会被限制，但前提是你知道腾讯是滴滴打车的股东之一。还比如招商银行的“服务号”比其它的“服务号”总能多一些数据接口与推广权限，前提是你要知道招商银行是微信扶植的“样板服务号”——招行花了一笔千万级人民币的预算由微信开发了一整套服务号的完整解决方案，微信自然不可能让它吃亏。

所以，招商银行是个例外，但对其它大型互联网金融服务提供商来说，把业务全部押注在微信上其实并不是一个好主意。

而来自微信的限制主要有两个方面。其一是微信平台的限制。诸如像平安集团这样涵盖了保险、银行和金融三大业务门类数十个服务的大型公众平台来说，最初他们把旗下业务都搬上了微信，然而由于微信的限制，服务却难以优化——比如推送的数量，API接口的类型，以及单个公司注册公众账号的数量也有规定。其二，微信的产品属性和生态注定了大型服务无法在这个平台上持续成长和繁荣。微信的用户人群大多是互相之间“认识”的熟人关系，而且由于展示空间有限和微信官方对用户体验的要求，一些在其它APP中顺理成章的行为放到微信上其实并不合时宜。比如用户恐怕并不习惯与一个客户经理互加微信好友。而这样一来，不少大型服务提供商想要增加用户粘性，进行信息互通的难度也增大了。

所以你可以看到，像招商银行等商业银行和滴滴打车等互联网服务，都把微信当做服务的提供平台之一，手里的其它服务，比如原生APP开发并没停下。因为在那里，他们没有微信的规则束缚，可发挥的空间更大。

2013年，平安也做过类似尝试，规划了“平安天下通”。它的产品思路仿照微信，建立一个金融类的垂直社交应用。微信的客观限制从一方面促成了这个产品的产生，另一方面又使其拥有了不同于其它的产品规划和升级路径：从企业内部的办公协同工具，到客户和客户经理之间的交流工具，再到如今成为了一个泛金融类的移动社交服务APP。

而对于平安天下通来说，离开了微信，平安旗下的业务也能在其原生APP中更自由地整合。从功能上说，平安天下通可以让用户管理自己的信用卡、寿险产险等产品，还加入了“问理财”等讨论社区，用户可以在这里直接与理财专家互通有无，除此之外用户还可以在平安天下通的朋友圈里分享理财和金融的相关信息。也就是说，通过以兴趣和功能为维度构建的用户关系不仅增加了用户粘性，也便于了信息沟通。

其实，平安集团可以算是比较早进驻微信公众平台的一批传统商业机构，旗下负责集团互联网业务的平安科技也早在2011年底到2012年初就开始了互联网服务的开发。平安旗下的子服务在移动端的拓展也选择了原生APP和微信公众平台并进的方案：一方面用户关注微信平台上平安公众号后，绑定自己的信用卡、车险、寿险等账户，可以实现简单的信息查询和账户操作，并且收到平安相应的推广消息和服务信息；另一方面，由平安科技自己开发的原生APP可以为用户提供更深入和完整的服务。

2014年作为互联网金融爆发之年，平安集团董事长马明哲也曾公开表示过，平安做互联网的一个重要战略是“社交金融”。“数据安全”这事，还是得靠自己，这是一个系统工程。

利用微信做O2O，商家需要哪些能力？

Sat, 31 May 2014 09:45:53 CST

【品途导读】微信推出小店功能，通过微信做O2O，商家需要哪些能力？商家要拥有1.微信营销2.微信服务3.微信技术。综合以上三点，大品牌商借用微信营销做O2O，其实是一项综合技能，并不是单纯依靠某个点就能突破的。

微信服务号昨天推出了小店功能，业界一片哗然，腾讯在和京东合作以后，但仍旧没有放弃C2C业务方向的拓展，基哥暂时不去评论这一做法是否足够高明，从个人的实践角度来看， 微信和O2O去结合，会比做C2C 或者B2C更好玩；接下来我想和大家分享下，通过微信做O2O，商家需要哪些能力？

我们先来看下微信公众平台的现状虽然业界都强调说， 微信是强关系，但这种强关系只是建立在个人和个人之间，也是C2C之间是强关系。然而对微信公众平台和个人微信用户这两者之见而言，反而是弱关系，大家都有明显的注意到，无论是自媒体，还是品牌微信公众账号的文章打开率在逐渐降低，很多信息抵达不到用户的打开界面，有点像大V和普通微博用户之间的关系，甚至比这种关系还糟糕，毕竟现在玩微博的人不多，留在微博上的用户，他们反而能有一个更加清净的信息流环境，去看他们所关注的内容；基哥一直认为， 内容并不能作为微信营销的核心，用户只愿意去花费时间关注他们需要的内容，原创内容虽然不是很难，但有趣，有料，有种的内容很难创造，往往是一篇好的内容推出以后，盗版的满天飞，微信内容的过载，导致微信号的打开率越来越低

目前大部分用户都被集中在了一些娱乐，干货类的微信账号上，商家的品牌账号更加的没有多少人光顾，在这种情况下，商家的微信公众账号，慢慢被个人微信用户遗弃；腾讯面对品牌号打开率低，做了哪些拯救手段？如果是照这样的趋势发展下去，商家做微信公众账号真的很难有出路，但腾讯做了一件有趣的事，就是开放了广告平台，即我之前文章里提到的广点通广告，我在【 为什么广点通刚上线，我就看衰】（关注微信号yingxiao00544，即可查看）的一文里提到，虽然我个人并不是太看好广点通，但对于此刻商家微信公众账号，的确是一根救命草；

广点通通过强曝光的形式，能够在一定程度上解决品牌微信公众账号没有人气的问题，把广大的微信公众平台运营商家，从持续推出经典的内容中解脱出来，虽然优质的内容能够形成出乎意料的传播，但这种优质的内容可遇不可求，并不是每个商家，每次推送都能推出经典的内容，大多数的商家在创意面前，是平庸的，但他们又需要借助微信这样一个平台来发展新的业务，所以广点通成为这部分商家的救命草；对于小的商家来说，也许一个月能够打造出那么一次经典的内容，即可获取不菲的流量，然后来慢慢转化，但对于一些稍微具有规模的商家而言，这种靠大自然恩赐的流量，并不能满足他们的需求；他们虽然也在乎资金的投入，但他们更在乎的是人力和精力的投入，他们不会为了一个产出能小的平台，去花费太多的心思，但大家都看好微信营销，所以他们在这块的人力和精力投入会很大，急需广点通这样，通过钱就能解决问题的渠道，来保持他们每天流量的稳定；商家玩好微信公众平台营销，需要哪些能力？

文章开头也提到了，基哥个人更看好通过微信去做O2O，所以接下来想重点讲下，通过微信做O2O需要哪些能力

接下来我将从三点来分解利用微信公众账号做O2O的关键词第一个词： 微信营销前面也提到了，微信公众账号和个人用户之间的关系，其实是弱关系，所以在引导个人用户关注微信公众账号的时候，这个临界点一定要是弱关系的点，才能获得用户的关注，即不要刻意去强调营销产品，而是去告诉用户这个个号能够给用户帮到什么，他所需要付出的仅仅只是一个点击关注而已是，比如某个培训学校的微信公众账号，是致力于O2O培训的，如果他去投放广点通，那他的广告语这样说会更能吸引用户，100篇O2O实操干货免费分享；如果他强调，O2O培训现在打5折，用户的关注量就会低很多；

从做O2O的角度来说，尽可能的去圈住有这方面意向的客户是关键点，即在前端不要去承载太多的营销功能， 让更多的流量进入到你的CRM系统，是O2O营销的关键；有人会说，拉那么多无效流量进来有什么用？这就是O2O的巧妙之处，O2O营销的巧妙在于，借用免费模式，占据用户更多的心智和时间，然后再把形成”粉丝“的用户导入线下，变现成现金。所以，微信公众账号的营销，是去推广微信公众账号本身能提供的服务，而不是这个微信公众账号的运营商能够提供的服务；

第二个词： 微信服务前面也提到了，单纯的内容并不能形成核心竞争力，所以内容只是吸引用户关注该微信公众账号的点，并不会因为这个账号发了很多文章，就能把这种用户变成付费用户，还需要和用户进行深度的沟通，这是一种人工服务；但光靠人工提供一些暧昧性的语言，是做不了真正的营销的；还需要一个能够和用户进一步加强关系的点，这个点我称为微信服务；

继续拿O2O培训举例，用户关注微信公众账号以后，他们的心态基本是坐等博主群发干货，这时候他们的状态是一种订阅状态；微信的互动人员，主动和用户去发起互动，先去解决他当前遇到的一些问题，建立相互之间的基础信任感；这是通过人工，帮用户去解决一些基础问题，这是第一种微信服务；

通过交流挖掘用户的需求点以后，再借用微信公众平台的API接口，智能去推送给用户相关的精准信息，这是第二种微信服务。

给用户推荐提供一些，比如免费的在线听课名额，或者企业诊断服务，提供部分干货材料等，进一步强化用户和微信公众账号之间的粘性，这是第三种服务，也是最为深入的一种服务，经过这三轮服务，用户和微信公众账号之间的信任度可以到达一个更高的深度；

第三个词： 微信技术通过付费的引流手段，微信公众账号的关注量会非常大，因此微信服务工作也会很大，这时候就需要借助微信技术，去承担一些重复性高的工作；比如用户关注以后的开场白，比如用户经常问到的常规性问题，比如上一段提到的智能推送文章等等，这些都需要通过微信技术去解决；

除了利用技术手段去解决一些重复性的工作以外，微信技术还需要承担一项更为重要的责任，借用微信公众号的二次开发能力，去策划一些刚性产品；前面也提到了，微信内容并不能作为微信公众账号的核心竞争力，所以提供给用户刚性的产品功能，也是让用户保持粘性的重要手段；

我们拿有道云笔记的微信公众账号来举例；用户在微信上看到某篇文章觉得不错，除了可以转发到朋友圈，收藏以为，同样可以保存到有道云笔记里（手机里下载了云笔记APP后，自动附带这样的保存功能），云笔记的公众账号这时候会提醒你，你所保存的信息，自动生成了图文消息，存放在云笔记的微信公众账号里；当用户需要去看自己精选内容时，通过云笔记的公众账号即可查看，这个自动转换成图文消息的功能，成了云笔记保持用户粘性的功能。具备基础的粘性以后，用户才会有机会去关注云笔记公众账号提供的其他功能；

综合以上三点来说， 大品牌商借用微信营销做O2O，其实是一项综合技能的活，并不是单纯依靠某个点就能突破的。微信公众账号发展至今，用户数早已经不再是200万，可能是300万，400万；众多的个人或者品牌也早已投入到微信营销的大军里，除了极少的个人或者品牌，通过微信获得盈利，大多数的投入方还处于苦苦支撑的状态；

微信就不要再立“微信不是营销工具”的牌坊了，按照微信目前的架构划分，以及最近的动作，和营销工具已经没有什么区别了。

如何把微信营销的门槛，降低到通过“努力+真诚”的经商门槛，是腾讯微信需要考虑的问题；毕竟大众都能够操作的营销渠道，才能成为真正的营销渠道；而并不是像前期的微博，单纯的依靠内容取胜，导致了很多的个人和品牌商死在了内容的门槛下；

品途网专栏作者：谌基平

责编：Chris

虚拟运营商是什么？它对你有什么影响？

Wed, 01 Jan 2014 08:00:23 CST

前几天，工信部正式授予十一家企业虚拟运营商牌照，它们分别是：天音通信、浙江连连科技、乐语、华翔联信、京东、北纬通信、万网志成、迪信通、分享在线网络技术、话机世界数码连锁集团、巴士在线控股有限公司（而之前被广泛看好的苏宁和国美并没有出现在第一批名单当中）。

虚拟运营商是一个人人都能听懂，但多数人却并不了解的名词，那么它的尘埃落定究竟对于市场和普通用户来说，有什么意义呢？本文将就用户最为关心的几点进行一番探讨：

什么是虚拟运营商？

虚拟运营商其实更应该被称作“虚拟网络运营商”，虚拟运营商不同于增值服务商的最大区别是，它以自己的品牌面向最终用户提供服务，拥有自己的计费系统、客服号、营销和管理体系。

以最受用户臆想的腾讯为例。如果腾讯获得了虚拟运营商牌照的话，那么用户在使用QQ和微信等业务时，将不再需要像从前那样计较运营商套餐资费，而是完全由腾讯主导资费定价，更进一步而言，腾讯可以推出独立的手机卡，提供基础语音与短信等业务——简而言之，虽然你用的还是移动或联通的网络，但实际上你已经是腾讯的客户了。

影响力有限

但是这并不代表腾讯有机会可以组建自己的物理网络，无论腾讯推出多受用户欢迎服务，它本质仍旧受着传统运营商网络提供的钳制，腾讯需要向基础运营商缴纳基础网络租赁费用，这种关系顺序决定了虚拟运营商几乎不可能对基础运营商形成威胁，况且在更大的程度上，这也意味着基础运营商对民营企业和互联网公司话语权和影响力的增加。甚至如果早些开放虚拟运营商的话，那么微信能否撼动传统运营商、或者腾讯还能否这么有底气的正面与运营商对峙，都很难说。

但是，腾讯就目前而言还不具备获得虚拟运营商牌照的资格，因为作为港资上市公司的腾讯，并不符合虚拟运营商“中资民营企业”的条件，同样受到限制的还有百度等一众业界大拿，不过在具备把通信行业竞争提升到更高层次的能力的当下，即便没有这个政策，传统运营商也势必会一同抵制腾讯等企业的介入。

虚拟运营商靠什么盈利？

从现阶段来看，虚拟运营商主要的盈利方式就是增值服务的售卖，因为转卖通信业务盈利能力十分有限，目前运营商按7折左右价格将短信、流量资费“批发”给虚拟运营商，短信结算价格是7分钱/条，流量是120元/G，语音资费是0.1元/分钟。这与现行运营商资费大致相同。如果虚拟运营商玩不转，不仅辛苦钱赚不到，还可能会倒贴钱。

所以另辟蹊径就显得十分有必要了，以苏宁为例，可以通过与移动互联网和云商结合，细分用户后推出多元化的业务和个性化套餐，甚至未来还可以在手机卡中添加自家的地产和银行等服务，使整体营销更精准，消费体验更完善。

突破垄断？

虚拟牌照的发放意味着民营资本终于能够合法参与一直处于垄断下的电信行业间的竞争，不仅有助于激发行业活力，还可以繁荣通信市场和刺激电信改革，具有里程碑式的意义。

同时，它的意义并不仅限于电信行业，这也是民营资本争取市场公平地位的极大进步，民营企业获得虚拟运营商牌照属于“非公36条”破冰的一部分，是“允许非公有资本进入垄断行业和领域”、“鼓励民间资本以参股方式进入基础电信运营市场”、“支持民间资本开展增值电信业务”条款的具体践行，

但是这并不意味着通信行业的垄断就此会被打破，因为在政策的倾斜下，传统运营商虽然放下了姿态展开合作，但这也是在高度优势的基础上才做出的选择。而目前中国移动也并未递交或公布合作伙伴的成分，就显示了一直占据行业大头的移动对这项政策并不足够热衷和需要，而相比较之下单薄和弱小的联通电信则明显更有干劲一些，这也说明了虚拟运营商影响力的“虚拟”。

值得玩味的是，中国移动曾经推出的Jego服务，本身也属于虚拟运营商的体系，是开放还是竞争，移动显然有它自己的考量。

能给消费者带来实惠吗？

虽然很多人寄希望于虚拟运营商的介入能有效降低电信资费，但就目前看来，这并不现实。

需要纠正的一个概念是，虽然传统运营商的高资费饱受消费者诟病，但抱怨的用户主体更多瞄准归咎的是电信行业的垄断性质。虚拟运营商并不能实质性的破除垄断，根据协议又不能打价格战，即便瞄准收益较低、更注重性价比的学生和年轻人市场，其优势也几乎隐形，因为几乎全国每一所高校都有运营商长期驻扎，这是直接与学校领导和业绩挂钩的，虚拟运营商要想下凡到普通市场上来，短时间内也很不现实。

总结

虽然虚拟运营商在国外也并不景气（约占行业比重7%——10%），但仍然有很多成功的案例供我们参考，最典型的就是维珍航空和Skype。不过我国推行虚拟运营商的时间已经太晚，很多机会已经缩小或者失去了，就好比那些挂名在电信运营商旗下的地方宽带服务商一样，所提供的基础服务并不能产生竞争力，反而会推动更多的消费者选择正牌运营商。电信行业是个非常讲究务实的行业，而就目前来看，虚拟运营商的美好前景相比起发牌的意义而言，还太过遥远和微不足道。

（若无特别注明，雷锋网文章皆为原创，转载请注明出处)
原文链接: http://www.leiphone.com/virtual-carrier.html

招行信用卡：指尖上的银行

Mon, 14 Oct 2013 06:00:04 CST

通过微信，凭借信用卡起家的招行开始了“扼腕断臂”的去卡化自我革命，但这也给予招行更大的生存和发展空间。

4484万，这是招商银行信用卡的发卡量。如果按部就班地发展，招商银行信用卡中心的工作很可能会和大多数银行的信用卡中心一样，极力推进信用卡的发卡量。但是，这家最早在中国发行信用卡的银行，却提出了要“消灭信用卡”，这究竟是怎么一回事？

“与其被别人革命，不如自我革命。消灭信用卡成为了招行信用卡的共识。”在接受《商业价值》采访时，招商银行信用卡中心副总经理刘鹏如是表示。

在刘鹏看来，互联网特别是移动互联网与金融的结合，迫使招行信用卡不得不重新审视新技术对于信用卡业务甚至银行业务带来的冲击。

移动互联网的快速崛起，借助智能手机等移动终端，银行业开始有了越来越大的创新空间，手机银行、手机钱包等应用逐渐普及开来，这无疑对信用卡业务造成了影响。易观智库的数据显示，2013年第2季度，中国手机银行总客户注册数达到3.8888亿户，同比增长87.3%；手机银行累计交易额达到22155.6亿元，同比增长80.6%。

“移动互联网技术正在将信用卡功能所附着的载体，从传统的实体卡片转移到手机等移动终端。所以信用卡的功能在加强，但是信用卡的实体作用却在减弱。我们要消灭的恰恰是实体信用卡。”刘鹏表示，“招行不能再走传统的扩大发卡量的路子，而要审时度势的去卡化，拥抱互联网成为最好的选择。招行信用卡要进行的是自我革命，最终将手机变成‘指尖上的银行’。”

互联网的基因

将银行业务与新技术快速融合创新，一直是招行的基因。新技术不断变化，招行总能抢先一步推出新的产品和服务。尤其是在互联网技术应用方面，招行一直不断探索新的产品和服务，依托“水泥+鼠标+拇指”移动互联网时代业务发展模式，招行在中国第一次推出了移动金融生活门户概念，提出 “移动金融生活一站式开放平台”，并推出了全终端模式和SIM 卡模式的手机钱包。2012年，招行零售电子渠道综合柜面替代率达90.66%，网上企业银行交易结算替代率达88.47%。

“互联网技术在不断的影响和改变招行信用卡发展，这也是招行信用卡保持领先的重要原因。”刘鹏解释说，“尤其是到了移动互联网时代，招行信用卡面临的变革更加剧烈。”

招行一系列眼花缭乱的动作，目的非常明显，就是要在移动互联网时代占据主动。2010年，招行信用卡联合中国联通发布招行iPhone版手机银行服务以及“掌上生活”移动终端应用；2012年，招商银行推出中国首张微博信用卡，并与HTC合作，推出搭载内置招商银行“手机钱包”应用的3款智能手机；2013年1月，招行信用卡和腾讯QQ合作，推出智能客户服务。

招行的这一系列动作，带来的直接效果就是让招行在移动互联网时代得以继续占据主动。仅2013年上半年，招行信用卡移动客户端“掌上生活”就获得了近280万次的下载量，绑定用户近133万。其PV（用户点击）量在300万次/天，每天活跃用户超过13万人次。而智能客服平台“微信客服”的表现则更加惊人，截至8月底，其绑定用户已突破200万，其中70%的用户选择了信用卡绑定，成为微信客服的实际使用者。仅在6月初，“微信客服”的日交互量就超过20万次。

在与移动互联网结合的过程中，招行信用卡对微信平台尤为看重。之所以如此看重微信，一方面微信的使用群体大部分是年轻人，这与招行的目标群体非常类似，满足了年轻人的需求，同时也拓展了招行的新渠道；另一方面则更为重要，利用招行信用卡的微信平台，这有助于招行以服务升级为核心的二次转型。

事实上，银行赖以发展的资源渐次为关系、风险、产品与服务。中国银行业经历了简单比拼规模、获取上市红利、扩展表外业务等历史阶段后，已经开始并将加速步入以服务为主要资源的新阶段。“以服务为主线深入推进招行的二次转型，这是招行转型的必由之路。”招商银行行长田惠宇曾表示。

“招行信用卡一直将微信平台定义为服务平台，而非营销平台。”刘鹏表示，“利用微信来改善招行的服务，增加个性化的服务才是招行信用卡微信平台的核心。”

围绕服务，招行信用卡在不断地进行升级。由最初的只涉及业务宣传咨询及账户余额查询等功能，逐步增加了LBS、语音等功能，并升级到微信银行，其功能不仅可实现借记卡账户查询、转账汇款等卡类业务，还可实现招行网点查询、贷款申请、办卡申请等多种便捷服务。未来还将引入资金融通等方面的业务。

这并不像看起来这么简单，要知道，每个客户服务的个性化和后台服务的标准化之间总是存在一个巨大的鸿沟，而跨越这个鸿沟，招行信用卡则是仰仗其多年在IT技术和互联网方面的积累不断地优化后台的服务。今年4月，招行微信银行的服务项目为79项，而5月服务项目已经拓展为94项，占总服务项目的85%。“服务就是最好的营销，互联网基因是招行信用卡做好服务的基石。”刘鹏表示。

自我革命

今年以来，招行在移动互联网方面动作不断，先是与中移动等合作涉足移动支付，4月推出小企业专属网银平台U-BANK8，7月将推行数月的微信客服升级为中国首家“微信银行”等。

这固然有着成本的考虑，比如招行每年需要发送上亿条短信，每条按照几分钱来算，这是一笔不小的开支；再如最简单的纸质账单，招行曾有1000多万的纸质账单，一封账单的成本是1.6元，每个月仅是寄送账单的成本就要1600万元。

“信用卡已经是非常成熟的行业，降低成本就是增加盈利。”刘鹏表示，“更重要的是招行信用卡要找到适合未来发展趋势的模式。”

对招行信用卡来说，移动互联网金融大概可以分为远程支付和近场支付两种情况，目前主流的移动支付方式包括：一是银行、通信运营商、央行和银联主推的NFC模式；一是互联网公司主推的二维码识别远程支付；还有一种是通过短信号进行输入的模式。

在众多银行纷纷加入微信平台大军之际，招行信用卡将微信平台定位于服务平台，希望为客户提供金融、购物娱乐等各种服务集于一身。可以看到最新的招行微信服务平台，不仅增加了LBS（基于地理位置的服务）和语音功能，而且还将柜台的很多业务搬到微信平台上，比如生活缴费、转账还款等。据《商业价值》了解，如今招行微客服平台的日交互量多达20万次（单个用户多次回复计一次），提供的自助服务已经可以满足持卡人70%以上的需求，自助查询回复命中率高达98%。

显然，借助微信服务平台，招行信用卡中心已经构筑了从“水泥+鼠标”向“水泥+鼠标+拇指”模式转变的路径。“未来将进一步加强本地化生活服务等体系，将微信服务平台打造成为O2O平台。”刘鹏表示。

电信新改革及互联网业机会

Sat, 12 Jan 2013 16:14:51 CST

近日，关于腾讯将获得第一张虚拟运营商牌照的传闻在业界传的沸沸扬扬，随着1月8日《移动通信转售业务试点方案》(征求意见稿)的公布，各种猜测才尘埃落定。该方案的出台，标志着电信业向着开放，向着市场化又迈进了一步。当然电信业的格局，绝非一纸文件文件可以撬动的，从三网融合的缓慢进程来看，还是“意见稿”的方案，到上升到立法再到全面推进还有很多路要走。专栏作者，评论员信海光对该事件发表了自己的观点，以下是他的原文：

如果腾讯借由通信转售从运营商获取一个号段，并将之分配给每个微信用户，开通移动网络即时通话业务，是不是说它可能立刻成为中国最大的电信运营商？

这次改革，会因为巨头的抵制或阳奉阴违而最终流于形式吗？

1月8日，工信部向社会公布“《移动通信转售业务试点方案》(征求意见稿)”，方案显示，封闭多年的移动通信转售业务即将启动，试点期初定2年。这意味着，中国电信业一次重大的变革很可能即将拉开帷幕。

所谓“移动通信转售业务”，是指从拥有移动网络的基础电信业务经营者购买移动通信服务，重新包装成自有品牌并销售给最终用户的移动通信服务，也就是说，垄断企业巨头之外的公司，未来有可能可以借由移动通信转售业务成为“虚拟运营商”，参与电信市场竞争。

试点方案必将对电信业产生长远影响，但它亦有行业外的深刻背景。根据该方案规定，申请经营移动通信转售业务的企业，申请者必须是依法设立的中资民营公司。这很明白的显示， 此次试点是民营经济界期盼已久的“非公36条”破冰的一部分， 是“允许非公有资本进入垄断行业和领域”条款的践行， 试点实行后，民营资本将有望进入电信行业最核心领域。

很期待，类似的试点方案，也在其他垄断领域尽快推出。

尽管核心资源还掌握在垄断巨头手中，但一旦试点方案真正落实，更具市场活力的民营资本进入后，必将会对三大运营商造成有力冲击。比如，成为“虚拟运营商”的民营企业可能拥有自己的号段，发放自有品牌的电信服务，它们轻装简从，高效快捷，在与拥有百万员工电信巨头的贴身竞争中未必就落了下风。而臃肿的巨头们则很可能会被价格战打掉部分利润。

更高效、冗员更少的民营电信企业拥有更大的降价空间，这对消费者当然是好消息，传说中的“免费电话”说不定很快就会出现。而期待已久的携号转网，是否也会因为转售试点向全国施行呢？中国版google voice是否也会出现？

方便攫取超额利润的三寡头垄断局面被打破，对此， 电信巨头们一定不会束手就擒。因此， 至少在短期内转售试点多半会充满坎坷。而《试点方案》也提出了一些保障条款，如强制要求运营商必须和2家以上的转售企业合作、转售的业务接入质量不得低于自营业务、要分配连续号码或者整个号段资源给转售企业、批发价格水平应该低于当地公众市场上同类业务的最优惠价格水平、不得排他等。

事实上，不管巨头们是否情愿，电信业的开放已是大势所趋，在国外也一样--目前全球移动虚拟运营商已达1100多家。 与其在未来被时代潮流摧残，不如及早调整出开放、包容的心态， 在市场竞争中实现脱胎换骨。

最好的双赢结果是蛋糕被做大，更具活力的民营企业可以通过推出不危及老运营商根本的创新业务为其创造增量利润。

移动通信转售业务试点对中国的互联网业，尤其是移动互联网业也将产生重大影响，这不止是意味着阿里巴巴、百度、腾讯等大的互联网公司可以借机申请牌照成为虚拟运营商，还意味着相关企业在移动领域对未来有了更多的把握,对创新有了很多的勇气及空间。以腾讯为例，其移动QQ和微信曾不止一次被运营商评价为“已开始威胁运营商传统电信业务”，随时都可能面临运营商的制裁，但如果腾讯成为虚拟运营商，则不但把命门掌握在自己手中，还有可能为微信赋予即时通话功能，成为中国版google voice，乃至成为拥有2亿用户的超级运营商。当然，也正是因为这种巨大威胁存在，使腾讯很难成为第一批转售业务伙伴。但无论如何，对其他次一级的互联网企业，仍意味着新的机会。

从这个角度讲，移动通信转售业务还有鼓励移动互联网企业创新的重要作用。

文/信海光本文最早发布于新浪微博

日本NTT Docomo计划将LTE网络提速至112.5Mbps

Mon, 25 Feb 2013 20:31:58 CST

对于身在天朝，都还没完全用上3G技术的手机用户来说，是否已经认为帝国主义国家4G LTE网络在速度上足够快了呢？日本人会告诉你：追求速度永无止尽。日本最大的无线网络运营商NTT Docomo的CEO加藤熏在MWC的主题演讲中说，未来公司计划向用户提供112.5Mbps速率的无线数据网络，并且这一高速数据连接服务很快就会到来。

作为对比，在我们看来已经算高速的Verizon和AT&T尚且在网络状况良好的情况下都只提供20Mbps的速度，而且实际情况是还会由于种种问题而出现低速率的问题，更不用提中国移动联通和电信的良好服务。

加藤熏说，LTE网络是NTT Docomo为用户提供所有网络服务的关键所在，这些服务叫做“smart life（智能生活）”。NTT Docomo计划将用户资源真正掌握在自己手里，通过提供多样化的服务，从信用卡支付到医疗服务，在网络层面上提供Android和iOS系统本身所不具备的内容。

NTT Docomo是最早一批部署4G LTE网络的运营商之一，加藤熏表示现在公司有至少1000万LTE网络用户，预计到2015财年，这个数字会增加到4100万，收益也会提升至110亿美元。

有意思的加密通信

Sat, 17 May 2014 17:11:44 CST

互联网就是个公开演讲的广场。意思是任何人说任何话，其实别人都是能听见的。这个认为是互联网的天性了，那么在这个前提下如果我和我一个朋友说点机密的事情，同时不想让别人偷听到，这个就成了一个有点挑战性的技术问题，也就是今天我们要讨论的加密通信。

对称加密

几千年来，我们人类都在用一种“对称性加密“的形式来进行秘密信息的传递，”对称“指的是加密用一个密码，那解密是用的还是这个密码。但是“对称性加密”为啥不能用在互联网上的加密通信中呢？说说这个过程，我有一个文件，用一定的加密方式来进行加密（比如用一些文件压缩程序），然后可以把加密后的这个包，传递给我的朋友，到目前为止一切都好。但是接下来的问题是，我朋友如何才能解密我给他的文件呢，显然我必须安全的把我加密时输入的密码安全的传递给他，这样才能完成这个加密通信过程。所以这就有了一个鸡和蛋的问题。最终我可能就不得不借助互联网以外的工具，例如打电话，来把密码给我朋友了。所以，对称性加密是不适合用于互联网上的加密通信的。

非对称加密的原理

那我们就可以想一下，是不是有一种“非对称加密”的方法能解决鸡和蛋的问题呢？恭喜你，答对了！非对称加密用一句话来描述就是，加密是用一个密码 key，而解密则会用另外一个密码 key。安装好相应地程序之后，任何人都可以在自己的计算机上来生产这一对密码。其中用于加密的这个叫公钥，是可以公开给别人的，所以叫”密码“这个不严密，还是英文好，就叫 key。另外一个是绝对自己要保密好的，叫”私钥“，这个是用来解密的，真的是”密码“。

这两个 key 是一对，意思是他们在数学角度是有着联系的，但是如果想要从公钥计算出私钥也是不可能的。加密通信的过程是这样的，收信人，比如说我，先生成这一对 key，然后我想跟我的朋友秘密通话，那我就把我的公钥传给他，这个反正有人得到也没关系。我朋友拿到公钥之后，就把他想要跟我说的话进行加密，然后把加密后的信息通过互联网传给我，整个互联网上，即使有其他人得到了这些加密数据也没用，因为只有我拥有跟那个公钥配对的这个私钥，所以也就只有我，才可以解密这个信息。

非对称加密的类比和应用

我们再来打个比方。我家门口有个信箱，那么凡是知道我家地址的人就可以给我发信了，所以我家的地址就相当于公钥，但是由于只有我自己有信箱的钥匙，所以也只有我能看到信。那这个信箱的钥匙当然就相当于私钥了。

打另一个比方。我和朋友要秘密的通信。首先朋友寄给我一把她的打开的锁，这样我把信放到一个盒子里，锁上，给她寄过去。拿到盒子之后，朋友拿出自己的钥匙就可以打开箱子了。反过来，如果我想从她那里得到回信，那我就给她寄我的锁就行了。这种通信方式的好处是，任何一把锁的钥匙都没有邮寄过。

最后说实际的一个应用。我在北京，如果我有一台服务器在美国，那么我如何让信息从我的服务器上安全的传递到我这里呢？首先，我先生成一对 key，然后我就把公钥传到我的服务器上。这样，我的服务器就可以把信息加密，然后传递给我了，听起来可能比较麻烦，但是实际中有 ssh 这样的程序帮忙，其实加密和解密过程都是自动完成的。下面是生产秘钥的具体操作过程：

$> ssh-keygen

Generating public/private rsa key pair.

$> ls .ssh/

id_rsa id_rsa.pub

好，加密通信就说这么多，以后有机会我们会谈一个相关的话题：数字签名。

参考资料：

http://en.wikipedia.org/wiki/Public-key_cryptography

http://blog.agupieware.com/2014/05/online-learning-bachelors-level.html

有意思的加密通信，首发于极客范 - GeekFan.net。

4G国际标准正式公布 TD-LTE-Advanced入选

Fri, 20 Jan 2012 09:51:06 CST

日内瓦时间2012年1月18日下午17时，在2012年无线电通信全会全体会议上，LTE-Advanced和WirelessMAN- Advanced（802.16m）技术规范通过审议，正式被确立为IMT-Advanced（俗称“4G”）国际标准，我国主导制定的TD-LTE- Advanced同时成为IMT-Advanced国际标准，标志着我国在移动通信标准制定领域再次走到了世界前列，为TD-LTE产业的后续发展及国际化提供了重要基础。

TD-LTE-Advanced是我国自主知识产权3G标准TD-SCDMA的发展和演进技术。我国第三代移动通信系统TD-SCDMA历经 10余年的磨砺，于2009年正式商用，产业规模不断壮大，形成了覆盖系统、终端、芯片、仪表等各环节完整的产业链。2010年9月，为适应TD- SCDMA演进技术TD-LTE发展及产业发展的需要，我国加快了TD-LTE产业研发进程，工业和信息化部率先规划2570MHz～2620MHz(共 50MHz)频段用于TDD方式的IMT系统，在良好实施TD-LTE技术试验的基础上，于2011年初在广州、上海、杭州、南京、深圳、厦门六城市进行了TD-LTE规模技术试验；2011年底在北京启动了TD-LTE规模技术试验演示网建设。与此同时，随着国内规模技术试验的顺利进展，国际电信运营企业和制造企业纷纷看好TD-LTE发展前景，目前，日本、沙特阿拉伯、巴西、波兰、印度、美国等国家的运营商已经开始或计划商用、预商用TD-LTE网络。

顶一下

RSSリーダーで読むために変換しています

まるごとRSS

从Mobile World Congress看未来智能机五大趋势

Wed, 29 Feb 2012 17:25:02 CST

世界移动通信大会无疑是全球最具影响力的移动通信展览会，每年业界大佬都将自己的精品展示，MWC可以说是移动行业的风向标，那么今年，在智能手机领域，你看到了什么趋势？

1) 四核处理器

如果你想成为2012高端Android智能机的竞争者，那么四核是必备。上周LG发布了Optimus 4X HD；周日HTC也展示了One X；周一，中兴展示了Era，所有设备都搭载Nvidia的Tegra 3处理器。华为也开发了自己的四核处理器K3V2，用于其Ascend D Quad及Ascend D Quad XL手机中。

LG称：使用四核手机，计算机具有更强的密集型人物处理能力，不过，不是所有任务都需要这么强的处理能力，有的需要低一些的处理能力以延长电池寿命，比如Tegra 3就用于简单任务，比如接打电话，收发邮件，听音乐等。

2)高清的大屏

除了拥有四核处理器，高清的大屏也必须有，比如LG Optimus 4X HD及HTC的One X，两者都4.7寸，分辨率为1280×720。

3)NFC

利用NFC来实现移动支付已成为一个热点，在MWC上，宏碁，化为，LG，诺基亚，Orange，三星以及中兴都展示了具有NFC功能的手机。更多这种手机的出现将会推动NFC技术的的发展，美国高德纳咨询公司研究员Sandy Shen说，其实NFC的最大障碍是改变用户习惯，花费时间比开发基础设施或设备更长。

4)LTE

和NFC一样，LTE智能手机也开始普及。一些新产品，从中兴的N910到PF200，从LG的Optimus Vu到Optimus LTE Tag，都使用LTE网络。LG的目标就是在2012年拥有各式各样的的LTE智能机。

但LTE并不适用于所有智能机，因为对处理器能力有要求，比如搭载Nvidia Tegra3 四核处理器的手机就不能使用LTE网络，不过Nvidia已宣布，将与芯片制造商GCT Semiconductor and Renesas Mobile合作，解决这个问题。

在美国，LTE已成必然趋势，欧洲次之。LG称，公司在今年将会向欧洲用户销售LTE智能机。

5)价格实惠

虽然奢侈智能机赚足了眼球，但在低端消费者（比如那些无法使用四核处理器及4.7寸屏幕的消费者）的获取方面，竞争也很激烈。诺基亚发布了Lumia 610，价格254美金，将于今年第二季度面市，竞争者包括中兴的Orbit，对于想要购买便宜Windows Phone的消费者来说，也是个不错的选择。

大会上，英特尔也想凑凑热闹，发布了1GHz的Z2000处理器，第一款搭载此处理器的手机将会于2013年面市，价格150美金。

Via IW

DNSPod国内版全新亮相:前端使用Backbone技术

Mon, 16 Jan 2012 08:20:13 CST

国内最大第三方DNS解析服务商DNSPod国内新版于2012年元旦正式上线公测。前端大胆使用Backbone.js框架，旨在为用户提供优质客户体验。
DNSPod此次改版前端使用了Backbone.js，Seajs以及Mustache等先进技术。其中Backbone的使用最为大胆，它是结合jQuery来构建复杂的 Web 前端交互应用。

最大的优点在于客户端共用一套API，整个架构整洁优雅，容易维护。但是对于很多网站来说，若非不得已，不轻易为之，可谓“小站难驾驭，大站轻易不敢用”。

DNSPod此次改版不仅从用户体验的角度考虑重新设计风格和布局，还对宕机监控进行重构，采用全新的架构，能支撑更大的信息量，为用户提供更精准的宕机检测和切换。据悉，DNSPod陆续还会推出分国家线路、记录自动导入等功能，为用户打造最优质的DNS解析功能和服务。

顶一下

RSSリーダーで読むために変換しています

まるごとRSS

忘掉被苹果收购的wifiSLAM吧，看看不一样的LED室内定位技术ByteLight

Wed, 27 Mar 2013 17:44:07 CST

随着智能手机的普及，使用卫星导航对很多人来说已经是寻常事了，这也是近10年最重要的科技普及之一。但是再好的卫星导航系统，也有不太灵光的时候——尤其是当我们在室内时。于是有了很多辅助工具出现，比如使用WiFi三角校正和“混合”GPS（例如用GPS坐标，结合指南针、计步器和加速计的传感数据）的技术，也就是wifiSLAM公司采用的技术方案（上周末，有报道称苹果花了2000万美元将它收入囊中）。但这些数据通常不准确，也不够可靠。

一家名为ByteLight的公司，采用的另一种技术：通过LED照明设备提供准确的定位数据。这是室内定位目前较可行的技术方案之一。它在去年10月份刚刚拿到125万美金的风险投资。

ByteLight室内定位系统的工作原理是：控制LED光的脉冲，以一个特定的模式运行，这个细微的变化不会被肉眼注意到（它运行在几百赫兹的范围内），但可以被智能手机或平板电脑的相机捕捉到。利用这些捕捉到的调制过的数据，设备就能运行相应的app或者客户端来计算出用户在建筑物中具体的位置，精确度据称能达到1米的范围。同时，由于不用依靠WiFi或者数据网络，所有的一切都在终端设备上运行，所以定位也会非常迅速。

一个最基本的典型应用场景是：当你在一个展馆或者购物中心，要去找某个展位或品牌店，只需要拿出智能手机，运行相应的程序。这个应用程序会触发相机扫描LED的照明区域，并迅速将这些数据转化为你当前的位置信息。然后，手机就能导航你到目的地。

ByteLight使用的是 可见光通信的一种形式，但在成为一个室内定位系统之前，还需要建筑的LED光源中实现对ByteLight兼容的内置。好消息是，加入ByteLihgt后，灯光的性能不会有明显的影响，而且这个成本几乎可以忽略不计。但坏消息是，它不支持现有的LED系统升级，ByteLight的技术需要在更早的阶段就内置进去，也就是说LED企业需要与这个初创公司成为合作伙伴。到目前为止，ByteLight只与Solais签署了合作，其他的合作伙伴都还在洽谈之中。每天有大量的LED灯泡在市面上出售，这也意味着它每天都在大量的失去潜在客户。

ByteLight作为一个产品，还是很难定义的：这家公司不生产灯泡，也不生产灯泡开关，甚至不生产驱动（内置在LED灯泡中提供电源的那部分），它自己的定位是一个中间件的提供商，因为它不卖灯泡也不卖灯泡芯片。相反，它卖的是控制芯片、以及能通过摄像头读取LED光线信号的app的技术。这确实不太容易解释，因为它是在幕后确保这个系统正常运转的角色。至于信息的中继利用问题，这就非常简单了：完全没有数据的传输。灯泡可以被理解为一个独立的ID，它也可以被理解为是天花板上的二维码。

虽然ByteLight是一个非常聪明的想法，并已经准备好借助正在兴起的LED热潮，趁势而上，但它也有一些天然的局限性。首先，因为任何公司在安装LED照明的时候，都不会想到用它来室内定位，更别说想到ByteLight这家小公司了。而且在一般建筑的LED长达5万小时的照明过程中，ByteLight也无法去做改造更换。这家公司非常依赖灯泡厂商的合作，所以如果把技术卖给GE或者飞利浦，其实倒是很靠谱的。

不过，一个好消息是，目前还有大量的建筑没有转换为LED照明，而添加ByteLight的成本也是非常小的，还不需要任何网络设备。此外，它还很容易加入到像下一代的飞利浦色相照明系统中，所以可以在出厂时添加对ByteLight的兼容，不用对产品进行大规模的调整。

ByteLight也不是唯一一个在研究室内定位技术的公司，诺基亚正在开发蓝牙4.0的室内协助定位系统，苹果也刚刚收购了WiFiSlam公司，室内定位的战争硝烟其实早已经点燃。

不止是室内定位：LED灯还能变成局域网，进行每秒3Gb的数据传输

Sun, 07 Apr 2013 17:54:25 CST

我们之前介绍了利用可见光通讯技术，通过LED灯光实现精准室内定位的例子。实际上，这种灯泡和技术的用途不止于此，比如，它还能进行无线网络传输。

最近，德国 Fraunhofer Henrich Hertz Institute（以下简称HHI）宣布在实验室环境中，使用普通的 LED灯泡，成功实现了3Gbps的数据传输速度，在现实生活场景（比如展会中），这个系统也能够达到500Mbps的速度。

可见光通讯（visible light communications，简称VLC），有时它也被称作LIFI。最近几年它得到了尤其多的关注，一个很重要的原因是LED照明正在日益流行。与白炽灯和荧光灯不同，LED是固态电子器件，这就意味着它能够像其他电子元件一样控制，并且实现高速转换。VLC本质上也是WiFi，只不过它采用的是兆赫辐射（光），而不是微波（WiFi）——当然，它的接收终端是光电探测器，而不是天线。

遗憾的是， HHI的新闻稿里，没有太多细节的描述，除了3Gpbs之类的数字之外。以往的VLC系统，能够在4米的范围内实现速度为500Mbps的数据传输，或者是20米的距离内实现120Mbps速度的传输。

相比实际上使用的标准LED灯泡，他们的这个VLC系统是一个黑盒子——前边是有一个LED和光电探测器，其余的网络连接部分和以太网的接口都藏在盒子后边。

为了达到3Gpbs，HHI的研究人员找到了一个新办法：不再只使用一个LED灯，现在有3中颜色。还不清楚这种新技术的传输范围相比以往有没有改变，但它很可能是相同的。在展馆的环境中测试，3Gpbs成了500Mbps，仍然是非常快的速度。

可见光通讯有一系列的优点。理论上，LiFi能将任何的LED灯纳入网络连接中。LiFi的传输也在一个非常高的频率之中（几百赫兹），远远超出了固定天线和无线频谱的紧缩以及政策许可，出于同样的原因，LiFi可以广泛的用在那些会有射频干扰的地方，比如展会活动上，以及禁止射频干扰的地方，比如医院或飞机上。

HHI的研究人员声称，VLC提高了你的隐私安全。因为理论上，你的信号很容易用不透明的材料遮住，就可以防止别人的窥探。

当然，这个场景要变成现实，我们还需要等待第一个商业化的LiFi LED灯泡和具备LiFi模块的笔记本或者智能手机进入市场。目前虽然已经有许多初创公司和研究小组取得了不少的进展，但依然没有明确的线路图。

它在场景用途上很特别，比如可以通过路灯向汽车进行超高速的短距离传输的通信……这些技术并日益成熟，希望LiFi成为现实，真的只是时间问题了。

VIVOtech：使用近场通信（NFC）技术的免接触付款解决方案的市场领导者

Thu, 28 Jun 2012 22:17:00 CST

随着 Google 钱包的发布，NFC 近场通信技术与移动支付的结合又一次成为媒体关注的焦点。一旦NFC系统被普及，消费者在收银台付款时只需要简单地操作自己的手机。

说起ViVOtech，它并不是一个像Google、Visa、万事达卡那样家喻户晓的知名公司，但它在近场通信领域却处于行业的领先地位。ViVOtech的软件和系统将银行、零售商店和移动电话供应商紧密连接起来，为消费者提供无接触支付的服务。

成立于2001年的ViVOtech主要开发支付软件、NFC智能终端、非接触式读卡器和交易管理基础软件等。迄今为止，ViVOtech目前已在全球35个国家安装了超过80万套近场通讯技术设备，占据了美国进场通讯技术读卡设备市场80%的份额，你可以在一些大的零售商比如麦当劳或者出租车里看到它的读卡器。最近，ViVOtech获准成为Google手机钱包服务的合作伙伴。

公司首席执行官Mick Mullagh说，“传统的观点总是认为NFC仅是用于实现支付功能，但它并不只是取代信用卡的一种简单技术，事实上，它可以实现更多应用，比如用于零售商店或超市中智能货架的电子标签上，这或许将彻底革新人们的购物方式”。
NFC技术可适用于很多场景，比如移动支付、公交卡、门禁卡、车票门票、文件传输、电子名片、游戏配对、智能海报等。你可以通过带有NFC功能的手机买东西、签到、刷公交卡或门票，或者和别人交换名片、传输文件、联机玩游戏等。即使你手机没电了，仍然能把它当做一个交通卡使用，和我们手中的各种感应卡片完全一样。ViVOtech所提供的无线技术方案正是移动支付/手机钱包系统后端的核心配置中最重要的一环。

合作方式

要让非接触式支付变为现实，多个领域要联合起来。首先，消费者要拥有具有NFC功能的手机，其次零售商要装配具有NFC功能的收银终端，再次，手机制造商必须要安装NFC芯片，同时，银行和金融机构要能支持NFC支付，最后移动运营商也得加入到这一游戏。

例如，几家移动运营商已经联合起来试图主导NFC支付。AT&T、Verizon Wireless和 T-Mobile USA开始支持Isis支付平台，并且已经获得了主要的手机制造商和信用卡公司的支持。在电脑硬件方面，目前已经有130多款不同型号的手机和平板电脑，总数超过了4000万台。

NFC支付平台谷歌电子钱包已经开始在Sprint网络中的Nexus S手机上投入使用，可以连接谷歌的预付卡或花旗银行的PayPass万事达卡信用卡，苹果也将推出针对iPhone的支付平台。包括花旗银行和美国银行在内的部分银行也开始加入其中，推出基于NFC芯片的移动支付标签，客户只需将标签粘贴在手机上即可。

ViVOtech通过与Google、Paypals、亚马逊、银行以及移动手机供应商的合作，试图建立一个无线支付的世界。ViVOtech作为NFC技术的软件和硬件设备系统供应商，到底能为我们的未来生活带来怎样的消费体验？

用户体验

现实生活中，出门三大件包括手机、钥匙和钱包，最占体积的就是钱包，里面会有各种银行卡和信用卡，然后实际上不可能随时用到那么多银行卡，而电话是必须要随身携带的。那如果把卡放到电话里面，岂不是两全其美？ViVOtech的NFC技术就是解决了这个问题，当然这需要支持NFC技术的手机。那安全性如何保证呢？支持NFC的电话里面有安全芯片，其安全级别与万事达卡、VISA卡、中国银联卡的安全级别是一样的，将信用卡和借记卡安全的下载到手机上，并且通过触按NFC手机完成支付，同时也可以在手机上选取产品，实时获知价格和信息，在实体店购物时，通过不同手机上信息的选取来了解不同商品的信息。

NFC不仅仅是用来支付，通过NFC的移动解决方案可以提高消费者对商家的忠诚度，从而开发出许多创新的商业模式。例如开发出不同的应用程序确保消费者在购物几个月以后还会回来，还可以使用NFC的技术来进行使用手机优惠券的项目，大大提高商店的人流，进入商店的时候在NFC的接触点触动一下NFC手机，就知道这个商店的信息是怎么样的，有些什么样的货物和优惠信息。此外商家可以较低成本在商场出口安装NFC的接触点设备，NFC手机的持有者在一进门的时候就会了解这些信息，比如在麦当劳吃东西人很多，直接利用NFC手机进行点餐和支付，无需排队等位，通过NFC点击一下桌子上的识别标签他们就知道订单发给了谁，坐在哪个桌子。

NFC还可以用于商场的会员营销。商场会员卡一般都是在商场登记办理，有了NFC的电话只要点击智能手机，就可以自动地让商家把会员卡信息传到你的手机上，只要带着手机就相当于带着会员卡，节约时间更加便利，更容易接收到这些零售渠道的信息，而且低碳环保。这种技术应用带来的好处第一是节约成本，第二可以促进商家营收的增加，第三可以促进商家和客户之间一对一的营销形式，和客户之间建立起实时的客户分析构架。

发展预期

市场调研公司ABI Research预计，当前全球安装的NFC读卡设备已达到500万套左右，预计在未来3年内这一数量将会实现翻番，今年将有3500万部手机安装近场通讯技术芯片，明年安装近场通讯技术芯片的手机数量将会翻番。根据市场研究公司Berg Insight2012年3月的最新报告显示，今年NFC手机出货量将从2011年的3000万部增长到1亿部，到2016年，全球NFC手机将增长到7亿部。

面对即将来到的巨大的NFC市场，ViVOtech的应招除了巩固自身业务外，也掀起多轮融资风潮。2011年6月ViVOtech在第三轮融资中获得2400万美元投资，总融资金额达到8000万美元。截止到到2012年3月，第四轮融资中获得超出预期的投资。公司称该融资为内部融资，且并没有透露投资者以及具体金额。迄今为止，ViVOtech募集资本总额已达9600万美元。其投资者包括新加坡EDB Investments、SingTel Innov8、摩托罗拉解决方案公司风险投资部门、 Alloy Ventures、花旗银行投资部门、Draper Fisher Jurveston、DFJ Gotham、 First Data Corporation、Miven Ventures、摩托罗拉移动、诺基亚成长伙伴以及NCR。

ViVOtech计划于2012年进行首次公开募股，ViVOtech在美国近场通信读取设备市场占有80%的份额，销售额达“数千万”美元。到2014年，近场通信市场总额预计将达500亿美元。

竞争对手

2004年成立的NFC论坛致力于促进NFC技术在消费电子，移动设备和电脑的使用，现拥有包括制造商、应用开发商及金融服务机构等在内的160多个成员，其中以NFC技术为核心业务的主要有ViVOtech、INSIDE Secure、NTT DoCoMo、NXP Semiconductors、英飞凌、Toppan Forms、Clear2Pay、Gemalto、VeriFone、LEGIC Identsystems、NEXPERTS、proxama等12家企业，而VIVotech是其中为数不多的几家兼顾NFC软件和硬件系统集成业务及解决方案供应商之一。

移动支付功能是NFC手机中应用最有前景的一项功能，国外主要是以Google 钱包为首的电子钱包支付项目，依托运营商的Isis移动支付平台以及NFC设备提供商ViVOtech等公司市场推广。

Google 钱包是NFC移动支付的代表，借助自家的Android系统和Google Nexus手机，成为全球第一个大力推动NFC移动支付的科技公司；Isis是美国三大运营商AT&T、T-Mobile和Verizon联合创办的一个NFC移动支付平台，而ViVOtech作为 NFC支付系统软件和硬件设备提供商，提供了包括Google 钱包在内的美国项目中80%的NFC设备。

由于谷歌一直没有给运营商提供激励措施，以此让运营商吸纳谷歌钱包应用，运营商也有自己进军这一行业的想法，比如说上面提及的Isis平台，Verizon、AT&T以及T-Mobile美元等运营商已经加盟了Isis的阵营，运营商、银行甚至连手机厂商都有了，万事俱备，Isis 阵营只欠销售终端这一股东风。如果没有做好相应的收费终端设备，再好的移动支付服务也只能是空谈。所幸 Isis 在最近和世界两大收费终端巨头 VeriFone 以及 Equinox 达成了合作，未来这两家公司将联合 Ingenico 和 ViVOtech 为 Isis 提供硬件支持，移动支付公司VeriFone在开发自有的设备之前，采用的就是ViVOtech的NFC设备，正是有了ViVOtech的硬件支持，Isis 也因此有了向Google 钱包叫板的底气。

业内领先的Google 钱包和后起的Isis都选择终端硬件供应商ViVOtech 作为自己的合作伙伴，也足以说明ViVOtech 在NFC非接触支付领域内的江湖地位。

网站：http://www.vivotech.com/

本文来自 bukop.com (作者：鲁伟)

你可能也喜欢：
诺基亚：Lumia 610的NFC功能会推广到全球 (@wpmind)	秋叶乱弹之112－有技术却找不到市场 (@70man)	2011年近场通信技术（NFC）的发展及其用途	NFC支付对消费者有何意义？	基于手机通信录应用的前景
无觅

Feed enhanced by Better Feed from Ozh

争抢苹果：移动假急联通真急电信不急

Mon, 31 Oct 2011 09:55:53 CST

牛顿坐在树下被苹果意外地砸中了头，那是三百年前的事了。现在别再奢望有这样的幸运，苹果再也不会从天而降，反而是树底下无数挥舞的双手在争抢着它。中国电信、中国移动、中国联通都混杂在争抢者中，它们同样喊着“给我苹果”，但真实的心态却完全不同。

[信息图表]色情行业与Internet

Thu, 27 Oct 2011 08:08:49 CST

早在21世纪初，色情业就已经盯上了WWW，事实上互联网也是这个行业提升影响力创造收入的重要渠道，每天全球都有大量的内容和货物交易等相关信息在互联网上流动，以下是来自searchenginejournal的信息图表，揭示了色情业与Internet之间的关系。

中移动全国校园份额下滑三成动感地带亮红灯

Mon, 17 Oct 2011 09:38:03 CST

中移动在全国校园市场的份额不同程度受到冲击，部分省市甚至跌至70%左右，相比于此前超过95%的市场占有率，下滑近三成。在北京的一所高校中，中联通在校园的核心地带竖起了一面巨大条幅――“今天大家都用‘沃友’，飞信已经out了。”在电信重组的第三年里，中国移动传统优势地位已经动摇，在新增市场用户跌至五成之后，竞争对手对于校园这一中移动核心市场展开了攻势。

调查称70%被访者计划2012年底部署IPv6

Fri, 21 Oct 2011 16:04:30 CST

《IPv6 全球部署评估报告》2011年调查结果近日公布，数据显示，约1600名国际调查对象中超过70%计划2012年年底为其网络部署IPv6。《IPv6 全球部署评估报告》2011年调查结果于10月最先在肯尼亚内罗毕召开的互联网管理论坛上公布，此项调查表明IPv6在被认可、规划和实际部署方面积极发展。

2011年互联网趋势报告：移动起步用户界面演变

Thu, 20 Oct 2011 06:59:57 CST

在10月18日的WEB 2.0峰会上，凯鹏华盈(KPCB)知名分析师玛丽•米克尔(Mary Meeker)发表报告，谈及2011年互联网趋势。
下面是报告主要内容：

三大运营商到齐移动IM市场变数陡增

Wed, 19 Oct 2011 06:32:59 CST

号称“短信杀手”的类Kik应用正打着“免费、省流量”的旗号攻城略地，也获得了互联网大佬们的青睐，给手机IM（即时通讯）领域带来了新的变数。“米聊、微信、口信、有你”，互联网大佬们扎堆推出相应的应用产品，也牵动了运营商的敏感神经。

亚马逊宣布电子书格式KF8

Fri, 21 Oct 2011 22:25:26 CST

感谢手机先生的投递
亚马逊宣布了下一代kindle电子书格式Kindle Format 8（KF8），它将替代Mobi 7，并支持HTML5，KF8能让出版商创造出更吸引人的电子书，满足儿童图画书、漫画、技术类图书和烹饪书的丰富格式和设计需求。

中移动用户总数近6.34亿 TD用户达4316万户

Fri, 21 Oct 2011 10:43:41 CST

中移动刚公布9月份营运数据，期内客户净增加588.9万户，较8月份的577.7万户，微增1.9%，今年累计客户净增加4950万户。截止9月底，中国移动总用户数6.335亿户，其中TD用户达4316万户，平均每月每用户收入(ARPU)70元，与去年持平。

北京市政一卡通被指暴露用户位置信息

Mon, 10 Oct 2011 12:33:30 CST

北京市政一卡通用户只要在一卡通官方网站上把自己使用的一卡通卡号输入查询栏，用户所有的一卡通消费信息显露无遗。（见附图）

10月10日，北京市政一卡通用户只要在一卡通官方网站上把自己使用的一卡通卡号输入查询栏，用户所有的一卡通消费信息显露无遗，有网友质疑这有泄露用户位置信息之嫌。

金山毒霸工程师李铁军表示，“北京市政一卡通可以精确追踪持卡人的具体行踪。你想知道某个人每天去哪儿，不需要雇佣私家侦探，只需要记下他的一卡通卡号，到这个网站(http://www.bjsuperpass.com/)一查。。”

北京市政一卡通用户只要在一卡通官方网站上把自己使用的一卡通卡号输入查询栏，用户所有的一卡通消费信息显露无遗，储值消费、乘坐的公交车次、在哪上车或下车等信息都可查询到。

一位网友对此评论道：“有泄露隐私的嫌疑。当RFID应用越来越广泛时，当网络记录着一举一动时，人就变成了透明的了。应用系统如何保护用户的隐私，用户如何维护自己的利益，都需要考虑。”

值得注意的是，用户最担忧的问题是，北京市政一卡通消费查询的门槛太低，用户只需要输入卡号，而无需做其他验证。一位网友直接对此评价：“信息公开，无需申请，方便查询，公开泄密，毫无隐私！”

对于北京市用户而言，北京市政一卡通的确给人们的出行和生活带来很多便利。不过，除了此位网友的爆料外，此前也爆出一卡通系统存在漏洞，此前还有网络工程师利用公交一卡通漏洞破解密码后恶意充值的案例，不过北京市政公交一卡通官方也称，一卡通芯片的漏洞问题已经通过更换芯片和系统升级等方法进行弥补。

0条评论 | Afio

中国移动10月发布“飞聊”多个公测版本

Mon, 10 Oct 2011 22:05:04 CST

据消息人士透露，中国移动“飞聊”业务公测版本9月28日上线后，10月还将发布“飞聊”的多个公测版本。9月28日，中国移动“飞聊”公测版本在移动飞信官网发布。移动相关人士介绍，从9月28日到12月31日，属于飞聊公测期，主要是收集客户意见、完善产品功能、提升客户体验。

[图]IIS的没落

Mon, 10 Oct 2011 16:58:00 CST

感谢晨露博客的投递
Apache一直作为互联网上使用最广泛的服务器从web早期延续至今，居于第二位的应该属微软的IIS了。但是，各种迹象表明，IIS现在正在走下坡路了，其市场份额是在不断的下跌。究竟背后是什么因素在促使这种情况发生呢？