IT瘾应用推荐

用友“吓”跌停：华为为何做起了ERP？

Mon, 20 Mar 2023 23:01:00 CST

虎嗅注：据第一财经报道，有消息称，任正非近日在公司专家座谈会上表示，华为将在4月举办MetaERP宣誓。或受此影响，3月20日，用友网络开盘快速跌停，成交额30.35亿元。用友工作人员回应称，市场对此消息有一定过度解读。从行业角度看，ERP产品的发展成熟至少需要三到五年时间积累，就当前的竞争格局来看，华为相关产品更多是公司内部自用。用友与华为是战略级合作伙伴。

同日金蝶国际股价下跌18.77%。金蝶国际回应21世纪经济报道，金蝶是华为的深度战略合作伙伴，华为采用了金蝶的苍穹平台，华为的全球人力资源系统是金蝶与华为共建的。

本文来自微信公众号：财经十一人（ID：caijingEleven），作者：吴俊宇、谢丽容，原文标题：《除了应对美国断供，华为自研基础软件还为什么》，题图来自：视觉中国

自2019年起被美国政府连续多轮限制至今，华为按照“一切都需要靠自己”的新逻辑，走在既定的节奏上。

3月19日，华为创始人任正非在华为“难题揭榜”火花奖专家座谈会上提到，华为用自己的操作系统、数据库、编译器和语言， 做出了自己的管理系统MetaERP软件。MetaERP是华为内部业务资源管理软件，经历了华为全球各部门的应用实战、公司总账使用年度结算的考验。

ERP（企业资源管理）软件覆盖企业管理方方面面，包括供应链、采购、销售、订单、发货、库存、财务、客户关系、人力资源等。

ERP软件只是华为这三年来在基础软件领域的突破性成果之一。在基础软件开发工具方面，华为三年间完成13000+颗器件的替代开发、4000+电路板的反复换板开发。阶段性克服美国政府断供带来的生存问题。

自研软件业务是华为2023年的重点突破方向之一。《财经十一人》了解到，华为自研软件业务主要聚焦基础软件，尤其是基础软件中的平台软件。这延续了华为在根技术领域的投入。华为用自己的基础软件，做出了自己的管理系统MetaERP软件，这意味着，华为目前在基础软件四大领域（操作系统、数据库、中间件、编程工具）全部实现了自主可控。

MetaERP作为平台软件，竞争对手是Oracle、SAP这类高端ERP软件的市场。多位专业人士的判断是，华为自研MetaERP，目的是实现国产化突围，做大国内软件生态，而不是与合作伙伴分食应用软件市场。Oracle、SAP做大，依靠庞大的软件实施伙伴，MetaERP能走多远也将取决于这个因素。

对于行业来说，中国软件产业十多年来处于“大而不强”的状态， 现阶段需要有大公司亲自下场培育生态。国内企业软件公司普遍规模有限，如金蝶、用友年营收不超过100亿元，云订阅收入大于1亿美元的软件公司不超过五家。

任正非说，华为现在还处于困难时期，但在前进的道路上并没有停步。2022年华为的研发经费是238亿美元，几年后随着利润增多，在前沿探索上还会继续加大投入。

据了解，华为打算将MetaERP和一批设计工具向外部开放使用，公开给社会应用。

聚焦基础软件

中国软件产业长期存在 “重应用轻基础”的问题。具体表现为，偏重应用软件（财务、审计、税务、客户管理、办公协同等）的开发，忽略基础软件（操作系统、数据库、中间件、编程工具）的研发。

这带来的结果是，中国软件产业收入规模位居全球第三， 但在基础软件领域，中国收入规模仅位居全球第六，甚至低于日本、韩国、俄罗斯。

中国软件行业协会在2022年11月发布的《中国软件根技术发展白皮书》显示，2020年全球软件产业业务收入约10万亿美元。规模前七的国家和地区分别是：美国27000亿美元、欧洲21000万亿美元、中国8000亿美元、日本7000亿美元、印度3500亿美元、韩国3000亿美元、俄罗斯3000亿美元。

但在基础软件（操作系统、数据库、中间件、编程工具）领域，美国收入规模为8100亿美元，占全球该领域业务收入60%以上。欧洲2100亿美元、日本700亿美元、韩国450亿美元、俄罗斯450亿美元，中国仅为360亿美元。

中国在基础软件四大方向进展不一， 数据库和中间件目前已经有相对成熟的国产替代产品，但操作系统和编程工具目前均高度依赖国际企业。

操作系统市场方面，微软的Windows、苹果的MacOS两大桌面操作系统全球份额超过90%；谷歌的Android、苹果的iOS两大移动操作系统全球市场份额也超过90%。国产桌面操作系统均以开源Linux系统修改而来，国内市场份额不超过5%。

编程工具市场方面，微软旗下的Visual Studio、JetBrain公司旗下的IntelliJ IDEA占据集成开发环境（IDE）市场的主要份额。集成开发工具是开发软件的软件。一位软件开发技术人士对《财经十一人》表示， 微软在软件市场之所以强，一大原因就是，全世界的开发者都基于微软的软件工具研发软件， 开发结束后再把代码贡献到微软收购的Github代码托管平台。这意味着软件开发的工具、标准、创意都在微软生态上。

数据库市场方面，Oracle、微软、IBM是全球三大主导企业。IDC最新数据显示，Oracle在全球关系型数据库中份额约为42%的市场份额，微软为24%，IBM为13%。然而，数据库是目前国产基础软件领域替代最快、替代最好的领域。

中国数据库市场相对活跃，国产替代速度还在加快。目前国内云计算厂商都推出了自研数据库产品，如华为的GaussDB、阿里云PolarDB、腾讯云CynosDB。国内还有数百家基于开源数据库MySQL的国产数据库，典型企业友武汉达梦、人大金仓、南大通用、神州通用等信创四小龙。第三方市场分析机构Gartner预测，2025年中国分析型数据库市场海外厂商占比将只剩下30%，交易型数据库市场海外厂商份额也只会剩下50%。

中间件市场，微软、IBM、Oracle、SAP以及Salesforce均是典型企业。有软件技术人士对《财经十一人》表示，狭义的中间件指支持应用开发和集成的平台。由于企业业务和云、中台等技术结合越来越紧密，中间件角色变得愈加模糊。Oracle、SAP、Salesforce这类平台软件同时充当了企业资源管理、应用开发集成的功能。 华为此次推出的MetaERP也可以被视为这类平台软件。

华为目前在基础软件四大领域目前进展各有不同。

中间件、数据库是华为对外开放寻找商业化的重点领域。华为的GaussDB数据库目前在金融、政务领域已经有成熟的商业化路径。MetaERP作为平台软件，瞄准ERP软件。一种解释是，MetaERP和Oracle、SAP这类高端ERP软件的定位是一致的，目的在于满足国内大型企业内部资源管理的需求。

ERP软件与其说是一套软件，不如说是一套软件化的管理制度。它覆盖企业管理方方面面，包括供应链、采购、销售、订单、发货、库存、财务、客户关系、人力资源等。MetaERP满足的是中国企业本土化的管理诉求。Oracle、SAP做大，依靠的是庞大软件实施伙伴，MetaERP能走多远也将取决于这个因素。

操作系统、编程工具这两个被长期垄断的领域，华为此前给出了备胎方案。在操作系统方向，华为布局了两个产品，鸿蒙和欧拉。鸿蒙面向智能终端、物联网终端和工业终端；欧拉面向服务器、边缘计算、云以及嵌入式设备。编程工具方向，华为对外开放了华为云软件开发生产线 CodeArts。不过， 上述备胎方案目前都处于起步阶段，生态规模有限，仍有较长的路要走。

做厚软件生态

从更长远的眼光来看，华为推出MetaERP的另一个目的在于，做厚平台软件，做大软件生态。补足国内软件生态中平台软件不够强壮的短板。

中国企业软件行业一直以来的尴尬是，中国很难产生类似Salesforce、Oracle、SAP这样的大型软件厂商。上述三家企业软件公司最近一个财年的营收分别为314亿美元、424亿美元、329亿美元。市值分别为1849亿美元、2302亿美元、1365亿美元。

中国目前没有软件营收超过100亿元的上市公司，软件公司市值几乎都低于1000亿元。一位中国云厂商高管、企业软件投资人同时对《财经十一人》表示，2020年美国市场ARR大于1亿美元的软件企业至少有140家。但国内ARR（Annual Recurring Revenue，年度经常性收入，或SaaS云上订阅收入）大于1亿美元的企业不到10家，ARR大于3亿美元的企业为零。

中国IT支出结构中，软件的占比也长期低于世界平均水平。研究机构Gartner 2022年数据显示，2021年全球IT支出结构是，硬件占比19%、服务占比28%、软件占比14%。当年中国IT支出结构是，硬件占31%、服务占15%、软件占4%。硬件支出远大于软件，被认为是中国企业软件市场长不大的重要因素。

中国企业软件市场太过分散，目前以中小企业软件厂商为主。大公司长期不愿意下场，主要包含两个因素：一是国内IT支出结构，软件长期占比不足，大公司担心市场空间不足；二是云厂商下场做企业软件，容易抢走中小软件厂商的蛋糕，导致生态缺乏信任。

过去几年，中国云厂商始终坚持“被集成”的原则。云厂商和软件厂商之间界限分明，云厂商只做基础设施，软件厂商负责上层应用。其逻辑是让利合作伙伴，进而带动整个生态的飞轮效应。

这其实也是华为、亚马逊AWS的早期成功经验。华为企业业务早期让利集成商、渠道商、软件伙伴销售产品，成为国内最大的IT解决方案商。亚马逊AWS不触碰上层应用，而是交由SaaS企业负责，进而成为全球最大的云厂商。

然而在国内软件市场，这种策略目前看起来效果有限。一位头部云厂商技术人士解释，美国软件市场，云厂商、平台软件厂商、中小软件厂商这三层蛋糕行业格局很明显。亚马逊、微软、谷歌三家头部云厂商，Oracle、Salesforce、SAP、Adobe乃至IBM这些平台软件厂商，以及数百家上层应用软件，每一层的生态都很完善且力量相对均衡。

但在中国，中小软件厂商太小，平台软件厂商太少，应用底座不够稳固。中小软件厂商带不动底层资源消耗，因此需要大公司补足平台软件这个环节。

有行业资深技术人士分析认为，大公司做好平台软件，需要扮演两个角色：一是帮助中小软件厂商做好开发平台、集成平台，二是为中小软件厂商带来大客户资源。在他看来， 云厂商迟早会进入平台软件市场。

有管理咨询公司数字化业务合伙人对《财经十一人》表示，中国软件市场的格局中，大公司既要做云基础设施，还要做平台软件。相比亚马逊AWS这类云厂商，行业定位会变得更厚、更重。

软件开发工具自主的价值

近十年华为的研发费用投了大概8450亿元，有很大一部分的比例是投给软件的。MetaERP之外， 华为在应对软件开发工具断供的自主化方面做了部署。

软件的开发工具是根技术，一个软件生态必须要有生产软件的工具。即便是硬件制造，也需要软件开发工具的支撑。

以近年来大众所关注的芯片制造为例。光刻机用于芯片生产的光刻工艺，而光刻工艺又是芯片生产流程中最关键的一步，所以光刻机作为光刻技术的载体，是芯片制造不可或缺的关键生产工具之一。一台先进的光刻机，甚至可能影响一个国家的芯片产业发展进程。

软件的研发也类似于芯片制造。在软件开发过程中，同样需要许多类似光刻机的关键开发工具，它们是软件开发的前沿技术载体，是软件产品生产中不可或缺的基础。

如果缺少软件开发工具，整个软件产业的生存基础就会受到直接挑战。如同缺了操作系统，所有软件服务就无法运行；缺了数据库，所有应用数据就没有地方可以存放。缺了软件开发工具，所有软件应用就没办法进行开发和创新。

在软件开发工具方面， 大量中国软件企业直接购买美国商用工具，国产软件工具链大量依靠开源技术包装而成，一旦受到国外制裁，开源技术平台被禁用，将会直接导致业务停摆。全球范围内软件开发工具的核心厂商主要包括Microsoft、Jetbrains、Perforce、Atlassian、Adobe等，共占有市场份额约45%，此外还有Oracle 、Synopsys和Axure Software、Sparx Systems、 Trident Inforsol 等一批主要厂商。中国仍缺少匹配的类型公司，只有有限的自主工具。

进一步看， 现代软件开发已越来越多采用云上开发模式。在敏感与核心的软件中，如使用美国服务器与相关平台（Github、Gitlab）等，开发代码则需传递到美国服务器，数据生产、存储、传输、访问、使用、销毁等过程是否安全，并不可控，无法确认数据处理过程的保密性、完整性等。如发生极端情况，相关敏感数据可能被查看和利用，包括应用的关键信息，产品是否有漏洞等。

自2019年软件被陆续断供后，华为不再寄望于美国政府放松限制，确定了新的思路——采用自己研发加联合合作伙伴一起研发的策略，来实现自给自足，保障研发工具的连续性。范围涉及硬件（X86->ARM）、操作系统（Linux/Windows->欧拉）、数据库（Oracle->RDS）、中间件、应用软件改造五个大类的全栈自研替换，涉及几百个组件的替换，千万行代码的测试验证。

2022年12月开始，华为连续发布了11款软硬件开发工具和服务，华为自身的产品线研发，已经切换到自己的工具上。构筑起了一套涵盖软件开发全流程、全环节的软件开发生产线。

这其中，部分软件已经通过华为云对外提供服务，华为的思路很清晰， 这些设计软件华为自用的同时，也开放给其他企业使用。华为相关人士透露，华为近期还与伙伴发布一系列硬件开发工具软件，实现硬件工具的自给自足。

2022年8月13日，美国商务部发布新规，对EDA软件、超宽禁带半导体材料、压力增益燃烧（PGC）等四项技术实施新的出口管制，相关禁令生效日期为2022年8月15日。

作为芯片设计软件，EDA可以进行超大规模集成电路芯片的功能设计、物理设计、验证等。 EDA本身极其复杂，对于实现芯片自主化具有非常重大的意义。实现了EDA工具自主化，就能够基本达成半导体自主化的先决条件。

从业务领域看，EDA是芯片核心设计软件，首当其冲在情理之中。被制裁风险较小的是信息管理类工具，如需求管理、测试管理；风险比较大的是代码仓、制品仓、检查等与出包强相关的工具。即，越是核心的工具被制裁的风险越大。

华为近三年来在基础软件方面的补课和追赶对中国软件产业，乃至整个数字化生态有警示意义。

我们需要面对的现实是，从底层芯片到操作系统、根技术、开发工具和各类应用软件服务，美国的数字化生态体系已经“枝繁叶茂”， 而中国的软件产业经过多年发展和追赶，已基本构建了相对完整的结构脉络，但总体能力仍十分孱弱。

国产芯片、国产操作系统、国产基础软件以及国产软件生态构成了中国数字化大生态的核心骨骼。每一个技术都联系紧密，环环相扣。底层是芯片、中间是操作系统、数据库、中间件等，上层是大量的应用和服务。软件自主研发，首先要适配操作系统和硬件环境。

这是一条极其难走又不得不走的路，基础软件只是其中的一个环节。

本文来自微信公众号：财经十一人（ID：caijingEleven），作者：吴俊宇、谢丽容

创业中的应用安全体系

Sat, 01 Jan 2022 22:32:57 CST

1. 源起

在创业进程中，可能最开始我们会想着快速上线，一些性能、可用性或安全的问题是有时间就搞搞，没时间就放着；或者对于用户的一些异常行为，一些薅羊毛的行为没有特别的关注；又或者对于用户上传的个人资产没有做特别安全的隔离或保护等等。虽然现在看起来都没有引发大的问题，但是这些都是应用安全隐患，都是隐藏的雷，一旦被公众引爆，将惊天动地。

从更大的层面看应用安全，根据咨询公司 Gartner 统计数据显示，超过 75% 的安全攻击发生在代码应用层面。

Forrester 2020 年发布的调查报告《 Forrester Analytics Global Business Technographics Security Survey，2020》中显示，在 480 家全球企业已经确认的外部攻击中， Web 应用程序和利用丢失/被盗资产，软件漏洞分别位于第1，2，4名，占比达到了 39%、35% 和 30%，其中软件漏洞主要指对于安全漏洞的利用攻击，攻击 Web 应用程序主要指基于程序的 SQL 注入、跨站脚本攻击、远程文件包含等。具体如图 1 所示：

从上图来看，应用安全，资源保护是目前我们安全防护的最佳切入点。

应用安全是应用级别的安全措施，旨在保护应用内的数据或代码免遭窃取和劫持。它涵盖了在应用开发、设计、测试、部署，上线后运营期间等发生的安全注意事项，及相对应的保护系统和方法。我们主要解决应用层和数据层的问题，网络层，物理层的问题不在本文的讨论范围之内。

从创业过程来看，我们有哪些数据泄漏的问题，我们有哪些敏感信息很容易被人看到，我们运营活动上线后有没有被薅羊毛，我们的用户里面有多少是机器注册的，我们的系统存在多少应用级漏洞，黑产是不是可以无门槛或门槛很低的获取到我们的数据或资源，我们的新业务上线时有没有东西能保证其是安全靠谱的，我们有没有办法及时发现这些问题并解决这些问题，从流程，机制，工具，系统各个层面，这就是我们这里所说的应用安全体系。

1.1 是什么

是在部署常用防御工具和手段（比如防火墙、WAF 和 IDS 等）的基础上我们能做的流程、机制，工具、系统；
是要在应用层面，去解决我们工作中经常会碰到的安全问题；
是我们有意识的，主动的发现应用中的安全问题，发现用户的行为异常，业务异常，并给予解决。

1.2 不是什么

不是公司的安全防御体系；
不解决非技术安全相关问题；
不解决所有的安全问题；
不解决安全合规的问题；
不解决超大规模类 DDoS 攻击的资源性攻击。

2. 安全问题梳理

这里我们从外部安全和内部安全来看可能面对的安全问题，外部是指对外的服务，内部是指企业内部的管理和控制，这里通过一些问题来反思现状。

    外部安全
后台安全
    存储安全
        系统备份和恢复
            如果现在数据库被人删了，怎么办？如何快速恢复？
            如果现在代码全部被人删了或者 github 的账号完全不可用了，怎么办？如何快速恢复？
            如果现在阿里云的账号被封了，怎么办？如果有备用的账号，如何快速切换？
        配置存储
            如果配置中心挂了，有没有办法快速恢复？
            账号密码安全如何防护，代码配置中有吗？现在线上环境 apollo 的权限控制如何？
        MQ安全
            是否有必要的业务隔离？
            如果突破内网，是否有一定的鉴权逻辑？
    服务安全
        对外服务
            身份鉴权/访问控制
                用户资源安全（资产保护）
                    用户资源是否有访问鉴权？
                    用户资源或资产是否存在越权访问的情况？
            安全审计
                对用户的登录、注册和交易日志的审计
                对系统资源的异常使用的审计
                对重要系统功能的执行等的审计
                对其它重要用户行为的审计
            通信保密性
                传输通道加密
                内容加密
                传输加密（密钥是否存在漏洞的可能？）
            抗抵赖
                日志保留 6 个月
                操作详细流水日志
            容量安全
                各服务的 QPS 上限，容量评估
                资源消耗类服务的容量安全，是否存在很容易的攻击行为，如一些上传文件后的解析或者 AI 识别之类的
                MQ / DB 等是否有业务隔离和容量
            容错
                出错信息保护
                部分出错降级
        对内服务
            身份鉴权/访问控制
                服务间/接口访问控制
                服务间鉴权
                调用方身份识别
            抗抵赖
                详细调用日志
            应用生命周期的管理和隔离
            数据（包括用户数据）的管理和隔离
        安全框架
    资源安全
        商业化资源业务风控
        用户账号风控
        活动地址，接口地址，兑换码防穷举遍历
        在活动流程和规则上提高薅羊毛的门槛，形成规范
    数据安全
        数据量级泄漏
        业务数据泄漏
        敏感数据泄露
        防拖库、撞库
前台安全
    应用安全
        代码混淆
        应用加固
        安全密码控件
        敏感资料保护
        防代理
        常见 Web 攻击
            SQL 注入
            CSRF
            XSS
            爬虫
    接口安全
        SSL 加密传输
        参数加密
        防恶意调用，频控，降级
    账户安全
        身份验证
        登录验证码
        超时控制
        单点登录
        防信息泄漏 内部安全
管理后台安全
    严格且精细的权限控制
    商业化资源需要有审核流程，更细的权限控制，只能看到自己创建或者自己有权限的
    敏感信息（用户/订单/商业化）需要有针对敏感信息查阅的追溯手段和管控措施（是否考虑形成日报上报）
    对于钱相关的资源需要有监控和视图
代码和部署安全
    核心代码是否有专人管控
    上线的代码是否有必要的审核或 Review
    是否配置如同代码一样管控
    CI / CD 系统是否有必要的权限控制和安全管控
    CI / CD 流程是否实现自动化
    CI / CD 流程是否有必要的安全保护策略，如签名和密钥

如图 2 所示：

3. 如何建立应用安全体系

业界应用安全体系的建立有两主流方法论：一个是 SDL，另一个是 DevSecOps。

3.1 SDL 简介

SDL 是由微软最早提出的概念，安全开发流程（Security Development Lifecycle），在需求分析、设计、开发、发布所有阶段都引入安全和隐私原则，帮助解决软件安全问题，重点在于开发阶段，而安全培训是 SDL 最核心的概念。

SDL 大概流程如图 3 所示：

3.2 DevSecOps 简介

DevSecOps 是”开发、安全和运营”的缩写。它是一种文化取向、自动化方法和平台设计方法，将安全性作为整个 IT 生命周期的共同责任。 DevSecOps 的出现是为了改变和优化之前安全工作的一些现状，比如安全测试的孤立性、滞后性、随机性、覆盖性、变更一致性等问题；通过固化流程、加强不同人员协作，通过工具、技术手段将可以自动化、重复性的安全工作融入到研发体系内，让安全属性嵌入到整条流水线。

DevSecOps 是应用安全 (AppSec) 领域一个相对较新的术语，通过在 DevOps 活动中扩大开发和运营团队之间的紧密协作，将安全团队也包括进来，从而在软件开发生命周期的早期引入安全。这就要求改变开发、安全、测试、运营等核心职能团队的文化、流程和工具。基本上，DevSecOps 意味着安全成为共同的责任，而参与 SDL 的每个人都有责任在 DevOps CI/CD 工作流中构建安全。把安全融入到敏捷流程中，使得敏捷性与安全性并重。

DevSecOps 在软件开发生命周期更早期切入安全相关内容，就能更容易的收敛安全问题，让安全问题的解决成本更低，暴露在线上的完全问题更少。

DevSecOps 的过程有三个关键要素：

授权(empowerment)
赋能(enablement)
教育(education)

授权或者放权，将控制权下放给团队，团队在理性分析的前提下，做出独立决定而不用害怕失败或影响。这里的团队成员不仅仅有开发，还有商务，产品，安全，QA 等等，所有项目成员都是奔着同一个目标：打造自己的产品。

赋能是指正确的使用掌握在团队手中的工具和资源，使其具体可操作性，如打造一种注重自动化、通过工具来解决重复任务，并尽可能减少以后的操作并增强安全性的理念。赋能不仅仅是提供知识和工具，而是让这种知识和工具能够通过多种渠道和媒介可快速获取且好用，以便它可以被团队或是个人以他喜欢的方式去使用和分享。

教育，在团队中建立安全文化，通过分享和培训让所有的成员都具备安全意识和技能是整个过程中最重要的点。

最终 DevSecOps 落地时，对整个研发团队的要求是这样的：

安全测试由研发团队完成；
测试期间发现的问题由研发团队管理；
线上安全问题由研发团队负责处理；
解决安全问题的责任在于研发团队。

3.3 选择适合自己的

SDL 相对于 DevSecOps 更偏于传统，如果要严格执行起来，其存在流程重、人员要求重等问题，一般是需要有专职的安全团队来执行。但是要想直接达到 DevSecOps 的理想状态对于一个新创业的团队来说也是不现实的。

对于一个创业公司，可能需要更敏捷一些的方式，让敏捷性和安全性并重，所以我们更倾向于在 SDL 的基础上，融入部分 DevSecOps 的手段。

3.3.1 核心理念

研发团队对安全负责，一切安全问题都是研发团队的问题，专门的安全团队只提供技术支持和技术培训（可以适当花钱请第三方专业机构），规避安全信息共享壁垒和在有专职开发团队时，开发绕过安全监管等情况；
研发流程中全链条增加安全环节，安全不再是流程外的冗余流程，安全可以做轻，但是必须要有，特别是核心的逻辑，将安全前置；
专职的安全团队从实战的角度，以攻击者的角度来发现问题，反馈给研发团队自己解决（提供标准解决方案），反向考核整个研发团队的安全绩效；
建立高效的 SRC。

3.3.2 SDL 通用版

    安全培训
｜ 安全概念、威胁评估、WEB 安全、安全测试及隐私保护
    提高全体项目人员的安全意识
    进行安全培训
需求分析
｜ 建立安全标准；创建安全指标；风险点评估
    确定安全需求标准，制定安全需求表，供后续开发检测
设计阶段
｜ 建立设计方案标准；提出安全方案；风险评估建模
    建立技术方案安全标准
    对不同的业务形态提出不同的安全方案
    建立风险评估模型
开发阶段
｜ 使用安全的工具、弃用不安全的函数或方法；静态扫描
    使用安全的工具：包括开发团队使用的编译器，框架，组件等
    弃用不安全的函数或方法
    ｜ 安全规范编写代码，并在开发过程中对代码进行 Review
    静态分析
    ｜ 对代码进行安全脆弱性分析和渗透性测试
测试阶段
｜ 动态安全扫描；模糊测试；评估安全方案
    动态分析（其实就是黑箱测试）- QA
    模糊测试
    ｜ 故意向应用程序引入随机不良数据及格式，诱发程序产生故障。模糊测试的基础是必须了解熟悉程序的功能状态、设计规范等
    代码审计 - SRE
    ｜ 代码安全扫描，开发过程中，开发人员每次更新代码都要进行扫描，并有权限查看相关项目漏洞情况，进行整改（不允许有中高危以上漏洞）。开发有权对漏洞进行忽略处理，但需要承担相应后果。若不知道如何处理，可请安全组提供解决方案。
    WEB 应用扫描 - QA
    人工渗透扫描 - 第三方专业安全团队
部署阶段
｜ 应急响应计划或预案；安全流程确认；发布归档
    明确安全应急响应计划
    构建发布流程工具卡点 AST 工具集
        静态应用安全测试 (SAST)
        软件组件分析 (SCA)
        交互式应用安全测试 (IAST)
        动态分析测试 (DAST)
    发布归档
线上阶段
｜ 执行线上应急响应流程
    第三方专业安全团队发现问题
    安全问题等级制度
    安全问题响应流程

脑图如图 5 所示：

3.3.3 我们现在可以做什么

在项目早期进行如下的投入是合适的，并且只需要开发同学的增量工作来保持良好的测试覆盖率和持续的构建

单元测试和集成测试的覆盖范围要足够全面，以确保生产版本的缺陷风险低到可接受的程度，而不需要主要依赖人工进行的质检工作；
本身安全可靠的 CI/CD 流水线；
经常使用的、可靠的基础设施，可用于分开部署生产环境的回滚；
允许代码和配置分开交付的软件架构，如配置中心。

应用安全是一个系统化的，长期的工程，对于现在的我们来说，不可能一次全链条都上，也不可能一次性的把大家的安全意识提到理想的水平。如何在保障业务快速发展的前提下，兼顾安全防护是当下我们需要考量的问题。

参照 SDL 通用版，建立较好的流程规范，安全问题等级制度和响应流程。有必要的话请第三方安全团队作为专职安全团队，定期对公司内外部做安全扫描，参照安全问题等级制度和响应流程，处理线上的问题，并且反向考核现有公司内部研发团队的安全绩效。同时研发团队在流程和意识上逐步增加安全卡点，提升开发过程中的安全质量，通过一些初步的安全工具链，快速自动识别安全问题。

4. 结语

以上纯属个人对现有应用安全的理解，供大家参考，有错误或不明确的地方欢迎指正，有更好的更完善的方法，欢迎评论探讨。

最近在看一本书，里面有一句守夜人的誓言：“若暗夜终临，吾必立于万万人之前，横刀向渊，血染天穹”，而安全于业务就是那个立于万万人之前的我们。

5. 参考资料

https://zhuanlan.zhihu.com/p/146149814
https://zhuanlan.zhihu.com/p/73675141
https://www.jianshu.com/p/ba886a6a28d8
https://cloud.tencent.com/developer/article/1587312
https://www.whitesourcesoftware.com/wp-content/media/2021/04/forrester-report-the-state-of-application-security-2021.pdf

Knower – 能自动识别、提炼、检索、聚合的网络书签、文档收藏工具

Sun, 07 Mar 2021 16:06:59 CST

Knower 是一款在线网页、文档、笔记收藏工具，拥有 Chrome、Edge、Firefox 扩展，不同于传统收藏工具，用 Knower，无需手动输入分类、标签，它会自动帮你解决这个问题。@ Appinn

来自发现频道，介绍非常简单： 你的知识助手，收藏、管理你的知识。以至于青小蛙在第一次看到的时候错过了。其实 Knower 在发现频道的介绍并不简单，可以说非常详细，但对青小蛙来说最重要的“ 一句简介”太简单了。

Knower

Knower 是一个在线服务，拥有 Chrome、Edge、Firefox 扩展，主要用来收藏网页、文档（Office、PDF 文档等）、笔记，最重要的功能是可以自动识别、分类、检索、聚合，让你 只需要做收藏一件事，其它都交给 Knower。

一个按钮、一个功能

Knower 的浏览器扩展只有一个按钮、一个功能，点击一下就能将当前标签页保存到 Knower 中，整个保存过程就结束了。

Knower 会自动提炼网页关键词，并自动设置一个标签，虽然目前看来标签的命名还有很大的提升，但关键词提炼已经相当不错了：

全文检索

被收藏进 Knower 的内容，支持全文检索，就算有大量的收藏，只要记得一两个关键词，都会非常容易搜索到。

而每一个收藏，都有一个实体功能。

实体功能

实体这个名字比较不好理解，点击后就会出现四个框框，里面是从内容冲提炼出来的高频词、人物、地名、机构。

青小蛙测试了几个，还算准确，尤其一些人物，可以非常完整的提炼出内容中出现的人名。

标记、批注

对于懒人青小蛙来说，这就可以了，但对于勤人青老蛙来说，添加收藏之后才是开始。

Knower 可以自定义每一个收藏的标签，也可以对内容进行标记、批注、搜索、翻译：

以上这些功能，对于文档同样适用，你可以自己将 PDF、Docs 上传至 Knower 中，然后就能获得自动的标签、高频词、人物等信息，同样也能批注、标记。

你以为这就完了？

Knower 还有个很酷的视图树功能，一键生成一个挺酷的思维导图：

基本上这样就完了，另外还拥有多种配色、导出数据等功能，虽然页面设计算不上优美，不过功能点真是不错。这大概是青小蛙理想中网络书签的样子。

感兴趣的同学可以前往官网使用，或前往发现频道和开发者聊聊。Knower 目前免费。

常见分布式应用系统设计图解（十二）：证券交易系统

Sun, 27 Dec 2020 02:09:00 CST

这篇讲的是证券交易系统，这类系统包含的内容很多，但是我们还是把目光放在核心的交易部分，比如说股票交易。在某个可交易时间，如果卖家 A 要以至少 y 的价格卖掉股票 x，卖家 B 愿以至多 y 的价格买入股票 x，那么这个交易就可以发生。

虽说是交易系统，但是它和任何一个支付平台的交易系统有着显著的不同，它的核心是一个竞价匹配的机制，而非货币支付的机制，简单地说，这个机制包含了这样四个步骤：

挂单（可以是买单，也可以是卖单）
匹配（或者叫做撮合）
成交
清算

从非功能的角度看，有这样几条需求是这样的系统尤其要强调的：

Consistency，从单个交易的角度来说，主要就是事务性，这是交易系统最最基本的要求。系统不能用了是个灾难，但是如果交易数据错误了这就是个大得多的灾难。
Durability，交易数据必须要持久化。
Throughput，很多股票市场都是对全球开放的，吞吐量意味着对于交易高峰的接纳能力。
Latency，和吞吐量关系密切，可以放在一起讨论。大型交易系统的延迟的最小单位都是按微秒论的。从架构上看这类系统具备一些异步系统（比如下单支付系统）的特点，但是低延迟的要求决定了它的处理方式明显不同。

整个系统来看，包括挂单、匹配、交易和查询这样几个部分。实线部分表示的是写或读写操作，虚线是读操作。
假设有卖家和买家两个用户，分别在不同的时间提交了挂单请求，一个是卖单，一个是买单。
鉴权分为两个部分来完成，基础的部分由 API Gateway 来完成。
Exchange Server 收到原始挂单请求以后，首先调用 Sequencer 去获取一个时间戳，也包括一个基于时间戳生成的 ID。这个时间戳非常重要，因为交易的逻辑里面，对于买单卖单的匹配，以及同价单的优先级，都要基于时间戳的规则来进行。时间戳不能仅仅基于 Exchange Server 自己的时钟来进行，因为每台机器的时钟很可能都不一样。
对于买单，查询账户系统并扣住保证金。
将买单或卖单放入指定的队列，不同的股票有不同的队列来维护。这个队列本身是一个优先级队列，从宏观上看就是 order book。对于买单来说，买价越高越靠前；对于卖单来说，卖价越低越靠前。
不同队列的变更会被 router 通知到不同的匹配（撮合）引擎，这里有多个不同的引擎，每个引擎关注不同的队列变更。在每个引擎的内存中维护一个队列中靠近队列出口的买卖单集合，也是以优先级队列的形式维护在内存中（具体实现可以是堆）。
这样迅速的匹配就可以在内存中迅速发生并完成，内存的数据结构以 Snapshot + WHL 的方式持久化，以达到效率和状态不丢失的平衡。
如果这台机器崩溃，还有集群中的备用机可以顶上，并从上述的 Snapshot + WHL 中恢复之前的状态。这些机器都通过 Node Manager（比如 Zookeeper）来管理。
每次匹配完成，都有一个事件加入到 exchange 的队列中，每只股票都有自己的 exchange 队列。
Router 将队列的事件通知到相应的支付系统和 Tick Calculator。支付系统（或者是清算系统）会完成用户扣款或打款的操作，而 Tick Calculator 会根据交易信息改变当前的股价并持久化到数据库中（这里的数据库需要较大的吞吐量，可以根据股票种类+时间序做 sharding）。
用户可以查询自己的账户变更状况，用户也可以通过 Quotation 系统查询股价变更状况。

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接《四火的唠叨》

你可能也喜欢看：

通过DLNA让Windows电脑成为媒体存储设备

Sun, 13 Dec 2020 20:30:28 CST

　　由于电视盒子和智能电视的种种限制，导致很多视频无法在电视上播放，需要使用外部存储设备，例如U盘、移动硬盘、NAS等等，对于多个电视终端设备来说，移动硬盘等插拔起来不方便，使用起来易损坏，NAS搭建较为麻烦，需要额外成本，实际上，Windows电脑通过一些操作和设置，可以实现类似NAS的相同功能，而无需再购买额外设备，这里就介绍以下设置和使用的方法。

　　DLNA（Digital Living Network Alliance/数字生活网络联盟）是由索尼、英特尔、微软等发起成立的一套解决电脑、移动设备、消费电器之间互联互通的协议。它们的宗旨是“随时随地享受音乐、照片和视频”。它们的目标在于创建一套可以使得各厂商的产品互相连接，互相适应的工业标准，从而为消费者实现数字化生活。

　　DLNA与苹果的AirPlay功能比较类似，协议也大体相同，他们都可以让用户电脑或其他设备中的媒体内容连接到电视屏幕里，用户只要智能电视支持AirPlay或DLNA，即在智能电视上观看同一个局域网下的某个设备上的视频。

　　先要保证电脑和智能电视或电视盒子同处于一个局域网下，智能电视要支持DLNA功能，例如小米电视和小米盒子就支持DLNA功能，在其内置应用“高清播放器”里，可以看到同一个网络下的DLNA设备。

　　接着，我们需要在电脑上安装DLNA服务器，实际上，目前微软的Windows操作系统已经集成了DLNA服务器，也就是Windows Media Player软件，只需要做一些简单的设置接口。

　　在“设置”-“网络和Internet”-“共享选项”-“网络和共享中心”里，如果媒体流未启用，则点击“启用媒体流”。

　　第一，首先保证系统为Windows 7以上系统的Windows Media Player，打开“网络和共享中心”，点击左边的“更改高级共享设置”，在“流媒体”那一栏中点击“选择流媒体选项”然后点击“启用”。在弹出来的窗口中保持列表中的设备都是处于“已允许”的状态，然后点击“确定”。

　　第二，接下来打开Windows自带的Windows Media Player播放器，点击“媒体流”，勾选“自动允许设备播放我的媒体”，点“组织”-“管理媒体库”-“视频”，将电脑上的视频文件都集中在一个文件夹里，然后将这个文件夹添加到库中。

　　完成以上两步后，就可以将Windows Media Player的“媒体库”中视频通过DLNA分享到处于同一个无线WIFI网络环境中智能电视或电视盒子了。

　　在智能电视或电视盒子端，打开“高清播放器”，电视会自动搜索DLNA设备，如果设置都正常，会看到提示“1个DLNA设备”，点进去，选择“视频”-“文件夹”，即可看到电脑端的共享文件，点击视频文件即可播放。

　　经过上面的设置，我们的电脑就会变成一个类似NAS的设备，可以共享指定文件夹的视频，我们只要电脑硬盘足够大，里面放多少视频都可以在电视上播放。

ModSecurity：一款优秀的开源WAF

Tue, 10 Sep 2019 15:00:36 CST

一、ModSecurity3.0介绍

ModSecurity是一个开源的跨平台Web应用程序防火墙（WAF）引擎，用于Apache，IIS和Nginx，由Trustwave的SpiderLabs开发。作为WAF产品，ModSecurity专门关注HTTP流量，当发出HTTP请求时，ModSecurity检查请求的所有部分，如果请求是恶意的，它会被阻止和记录。

优势：

完美兼容nginx，是nginx官方推荐的WAF

支持OWASP规则

3.0版本比老版本更新更快，更加稳定，并且得到了nginx、Inc和Trustwave等团队的积极支持

免费

ModSecurity的功能：

SQL Injection (SQLi)：阻止SQL注入

Cross Site Scripting (XSS)：阻止跨站脚本攻击

Local File Inclusion (LFI)：阻止利用本地文件包含漏洞进行攻击

Remote File Inclusione(RFI)：阻止利用远程文件包含漏洞进行攻击

Remote Code Execution (RCE)：阻止利用远程命令执行漏洞进行攻击

PHP Code Injectiod：阻止PHP代码注入

HTTP Protocol Violations：阻止违反HTTP协议的恶意访问

HTTPoxy：阻止利用远程代理感染漏洞进行攻击

Shellshock：阻止利用Shellshock漏洞进行攻击

Session Fixation：阻止利用Session会话ID不变的漏洞进行攻击

Scanner Detection：阻止黑客扫描网站

Metadata/Error Leakages：阻止源代码/错误信息泄露

Project Honey Pot Blacklist：蜜罐项目黑名单

GeoIP Country Blocking：根据判断IP地址归属地来进行IP阻断

劣势：

不支持检查响应体的规则，如果配置中包含这些规则，则会被忽略，nginx的的sub_filter指令可以用来检查状语从句：重写响应数据，OWASP中相关规则是95X。

不支持OWASP核心规则集DDoS规则REQUEST-912-DOS- PROTECTION.conf,nginx本身支持配置DDoS限制

不支持在审计日志中包含请求和响应主体

二、安装部署

测试环境：centOS7.6阿里云镜像

升级软件和内核

  yum update

安装nginx： http://nginx.org/en/linux_packages.html#mainline

     yum install yum-utils
   vim /etc/yum.repos.d/nginx.repo
   [nginx-stable]
   name=nginx stable repo
   baseurl=    http://nginx.org/packages/centos/$releasever/$basearch/
   gpgcheck=1
   enabled=1
   gpgkey=    https://nginx.org/keys/nginx_signing.key
   [nginx-mainline]
   name=nginx mainline repo
   baseurl=    http://nginx.org/packages/mainline/centos/$releasever/$basearch/
   gpgcheck=1
   enabled=0
   gpgkey=    https://nginx.org/keys/nginx_signing.key
   yum install nginx
   yum install epel-release
   yum install gcc-c++ flex bison yajl yajl-devel curl-devel curl GeoIP-devel doxygen zlib-devel pcre pcre-devel libxml2 libxml2-devel autoconf automake lmdb-devel ssdeep-devel ssdeep-libs lua-devel libmaxminddb-devel git apt-utils autoconf automake build-essential git libcurl4-openssl-dev libgeoip-dev liblmdb-dev ibpcre++-dev libtool libxml2-dev libyajl-dev pkgconf wget zlib1g-dev

报错解决：Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again

解决办法：一句话：把/etc/yum.repos.d/epel.repo，文件第3行注释去掉，把第四行注释掉，修改为

1. [epel]

2. name=Extra Packages for Enterprise Linux 6 – $basearch

3. baseurl= http://download.fedoraproject.org/pub/epel/6/$basearch

4. #mirrorlist= https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch

克隆GitHub存储库:

  git clone --depth 1 -b v3/master --single-branch    https://github.com/SpiderLabs/ModSecurity

编译源代码：

     $ cd ModSecurity
   $ git submodule init
   $ git submodule update
   $ ./build.sh
   $ ./configure
   $ make
   $ make install

注意：安装中有报错fatal: No names found, cannot describe anything.是正常现象

下载用于ModSecurity的NGINX连接器：

  git clone --depth 1    https://github.com/SpiderLabs/ModSecurity-nginx.git

确定哪个版本的NGINX是运行在主机上的ModSecurity模块将加载:

     [root@guigu ModSecurity]# nginx -v
   nginx version: nginx/1.17.3

下载与安装版本对应的源代码：

     wget     http://nginx.org/download/nginx-1.17.3.tar.gz
   tar zxvf nginx-1.17.3.tar.gz

编译动态模块，复制到模块标准目录:

     cd nginx-1.17.3
   #./configure --with-compat --add-dynamic-module=../ModSecurity-nginx
   $ make modules
   cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/
   将以下load_module指令添加到/etc/nginx/nginx.conf的main中：
   load_module modules/ngx_http_modsecurity_module.so;

确定nginx模块加载成功：

  nginx -t

三、防护效果测试

ModSecurity 3简单示例

创建Demo web应用vim /etc/nginx/nginx.conf

     server {
   listen 8085;    

location / {

    default_type text/plain;

    return 200 "Thank you for requesting ${request_uri}\n";

    }
   }

重新加载nginx:nginx -s reload

确认nginx正常工作:curl -D – http://localhost

保护Demo web应用

创建/etc/nginx/modsec文件夹：mkdir /etc/nginx/modsec

下载推荐的ModSecurity配置文件

     wget     https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended
   mv modsecurity.conf-recommended modsecurity.conf

vim modsecurity.conf #在些文件中编辑以下配置

SecRuleEngine DetectionOnly

SecRuleEngine On

创建ModSecurity的主配置文件

  vim /etc/nginx/modsec/main.conf

Include the recommended configuration

  Include /etc/nginx/modsec/modsecurity.conf

A test rule

  SecRule ARGS:testparam "@contains test" "id:1234,deny,log,status:403"

报错解决：[emerg] “modsecurity_rules_file” directive Rules error.

     vim /etc/nginx/modsec/modsecurity.conf
   #SecUnicodeMapFile unicode.mapping 20127

配置nginx反向代理，vim /etc/nginx/conf.d/proxy.conf

#include /etc/nginx/conf.d/*.conf; #把这一行注释掉，不然80端口会有冲突

     server {
       listen 80;    
    
    modsecurity on;

    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    location / {

    proxy_pass [http://0.0.0.0:8085;](http://0.0.0.0:8085/)

    proxy_set_header Host $host;

    }

     nginx -s reload    #重新加载nginx
   curl -D -     http://localhost/foo?testparam=123    #能正常返回“Thank you for requesting /foo?testparam=123”
   
   
   curl -D -     http://localhost/foo?testparam=test    #则返回"403 Forbidden"，说明前面配置的那条modsecuriy规则生效了，并阻拦了testparam参数中带test的请求

在/var/log/nginx/error.log中可以看到拦截的详细日志

部署OWASP规则–CRS（Core Rule Set）

安装运行nikto漏洞扫描工具，用于测试CRS的防御效果

     
   git clone     https://github.com/sullo/nikto    #下载nikto
   cd nikto 
   perl program/nikto.pl -h localhost    #用nikto扫描nginx搭建的web系统（反向代理）
   扫描结果是+ 7687 requests: 0 error(s) and 308 item(s) reported on remote host    #扫描出308个问题

启用OWASP CRS

     cd /etc/nginx/modsec/
   wget     https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.2.tar.gz    #下载OWASP CRS
   cd owasp-modsecurity-crs-3.0.2/
   cp crs-setup.conf.example crs-setup.conf

在modsecurity主配置文件中include CRS的配置和规则

  vim /etc/nginx/modsec/main.conf

Include the recommended configuration

  Include /etc/nginx/modsec/modsecurity.conf

OWASP CRS v3 rules

     Include /usr/local/owasp-modsecurity-crs-3.0.2/crs-setup.conf
   Include /usr/local/owasp-modsecurity-crs-3.0.2/rules/*.conf

测试CRS

     nginx -s reload    #重新加载nginx配置
   curl     http://localhost    #返回Thank you for requesting /
   curl -H "User-Agent: Nikto"     http://localhost    #返回403 Forbidden，说明WAF防护已经生效，此处匹配的规则是user-agent中不能包含漏洞扫描器名字
   perl nikto/program/nikto.pl -h localhost    #再次用nikto扫描nginx搭建的web系统
   扫描结果是+ 7687 requests: 0 error(s) and 83 item(s) reported on remote host    #扫描出83个问题，比308个少了很多

在安装ModSecurity时，我们将演示应用程序配置为为每个请求返回状态代码200,但实际上并没有返回这些文件,Nikto将这200个状态码解释为它请求的文件确实存在,所以报告出83个问题，为了优化nikto，去除误报，我们做如下配置

  cp nikto/program/nikto.conf.default nikto/program/nikto.conf

vim nikto/program/nikto.conf #在第76行最后加上;-sitefiles，如下所示

  @@DEFAULT=@@ALL;-@@EXTRAS;tests(report:500);-sitefiles

之后再次用nikto扫描

  perl program/nikto.pl -h localhost

扫描结果是+ 7583 requests: 0 error(s) and 7 item(s) reported on remote host

可以看出问题只有7个问题，由于ModSecurity不支持响应（response）的检查，所以涉及此类的漏洞无法防御。但总体还是抵御了绝大部分的nikto的漏洞扫描。

参考链接：

https://www.nginx.com/resources/library/modsecurity-3-nginx-quick-start-guide/

https://github.com/SpiderLabs/ModSecurity

https://github.com/SpiderLabs/ModSecurity/tree/v3/master

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

前端离线化探索

Tue, 23 Jul 2019 18:54:31 CST

原文：前端离线化探索
作者：flyfu wang

飞机上的梗

某天，小明同学突然反馈：“昨晚发现根本无法使用你们的应用... ....怎么回事呢”。我和我的小伙伴们立马惊呆了，心想：“老司机多年的经验有一种预感，那就是同学你使用姿势不正确...（此处省略300字）”。然后默默排查了许久，答案竟然是：

“小明昨晚在飞机上”。

为了以后能够在飞机上愉快的玩耍，这里的离线体验我们有必要再着重优化下。自此，一个不分昼夜的需求快马飞鞭地提上了日程。

离线化带来的价值

在这个流量日益白菜价，不断提及云端计算、5g网络的时代，有人觉得，离线已经完全没有必要。谈及离线，仿佛想到的是深海老林，荒无人烟之处。事实上，离线离我们的生活很近，也非常频繁。高速公路、地铁隧道、楼道角落，以及诸多日常信号不稳定区域，这些场景每天都有大量用户经过，每天有成千万用户频繁因为网络问题，心底里吐槽抱怨过我们的应用，断网离线并非我们的错，但我们是否能够从用户体验的角度，尝试改善他们在进入弱网或无网络状态时的焦虑情绪呢，从而给产品带来更正向的体验收益，提升用户留存与口碑。

乐观UI

谈及改善用户焦虑情绪，很有必要介绍下乐观 UI [Optimistic User Interfaces]。乐观 UI 是一种界面的响应模式，它推荐前端在服务端接收响应之前，先更新 UI，一旦服务器返回，再变更为实际结果。

比如，用户点击按钮，前端更新数据状态为成功，请求到达后台，服务器响应，更新前端数据。因为99%的响应都是成功的，所以只有少部分用户需要退回到失败状态。

乐观 UI 不是一种先进的技术和新东西，而是一种“离线优先”思维模式下，改善用户体验情绪的设计。

前端离线化几种常用的方案

Application Cache

HTML5 最早提供一种了一种缓存机制，可以使web的应用程序离线运行。我们使用 Application Cache 接口设置浏览器应该缓存的资源，即配置manifest文件，在用户处于离线状态时，点击刷新按钮，应用也能正常加载与工作。

不过该接口很快被标准废弃了，原因之一是这是个设计很不合理的接口，比如更新不及时，无法做到用 javascript 精细化控制，可用性很差，如果你不严格的遵循其规则，会遇到很多坑。取而代之的是更强大的service-worker。

service-worker

正因为Application Cache一直无法有效的解决离线资源精细化控制，service-worker （以下简称sw）接口被设计出来了，比起Application Cache，它提供独立的后台JS线程，是一种特殊的worker上下文访问环境。在渐进式web应用 PWA中，sw为 Network independent特性提供了最核心的支持。

借助CacheStorage，我们可以在 sw 安装激活的生命周期中，按需填充缓存资源，然后在fetch 事件中，拦截 http 请求，将缓存资源或者自定义消息返回给页面。

service-worker 实现了真正的可用性及安全性。首先，相对于原有web 应用逻辑是不可见，它类似于一个中间拦截服务，中间发生任何错误，都会退回到请求线上逻辑。其次，它只能在 https 下运行保证了安全性。

sw对于我们的离线化方案而言，有一个致命的问题，就是ios webview 兼容性问题。ios 11.3以上自带的Safari是支持 ws，然而，苹果一贯的特性，默认UIWebView 不支持service-worker。

离线数据

事实上，我们的大部分离线场景将是会在本地独立 app 之中，借助客户端能力，我们可以把 web 代码包提前内置到客户端之中，然后使用一套代码更新机制，前端代码缓存问题可以得到解决。离线代码加载和更新逻辑本身不复杂，下面是一个简化图，具体特定业务场景下还需要考虑比如是否灰度用户，代码版本和数据是否同步等问题。

离线化方案的复杂度之一在于离线数据的处理，及如何对设计之初就没有考虑过“Offline First”的旧代码进行最小改造处理，既优先考虑在离线状态的基本功能，在线时再进一步增强。基于离线和在线逻辑解耦的考虑，我们应该本着最大限度减少对原有在线逻辑侵入的原则去思考离线化方案。我们看下常见的离线数据前端方案。

PouchDB

PouchDB 是一个跨平台javascript 数据库，内部封装了IndexDB、WebSql兼容前端处理.

一般而言前端pouchDB进行离线处理，搭配后台CouchDB，可以更方便双向数据同步。

Sync 接口专门用不同步前后的数据：

在中小型项目，特别是那种后台可以由前端接手的全栈式开发，pouchDB是一种不错的离线数据处理方案。此方案问题是压缩后任然有130多kb，并且依赖于特定后台方案，不够通用。

Redux-Offline

对于项目使用了 redux 数据管理的项目而言，最快捷的办法，就是使用 redux-offline，其基本思路是通过redux middleware 监听每次 acton 数据变化，然后将需要离线的数据序列化到本地（对于 web 浏览而言存储兼容顺序是indexdb—websql—localstorage），等下一次刷新页面时，优先从本地还原数据还原到 store 中。这种方案的好处是快速配置需要缓存的API接口到中间件即可，充分结合了 redux 特性，对于想要达到简单优先展示离线数据的应用而言，是非常不错的。

但这种思路带来的问题是操作数据不够灵活，本地储存数据无法方便的和其他非 redux逻辑共享。在离线数据量较大的情况，一次性读写，并同时序列化大量本地数据也会带来性能问题，对于频繁有数据变更的场景也不合适。

Redux与IndexDB结合

如果想要达到对数据精细化控制，并且同时不对原有在线逻辑有过多的侵入，我们可以在数据储存上用 IndexDB 替换后台返回数据，前端数据处理仍然复用原有redux。

业务数据的本地储存需要注意的就是合理抽象业务使用的数据，然后按照数据库设计的基本原则本地建表，这里也可以和后台同学聊聊，避免有遗漏的设计问题。

由于IndexDB 原生操作api比较粗糙，我们分装了一套通用DB底层操作库，同时将api接口抽象出来，以 git 子仓库的形式在各业务放公用。这里首先简化了前端业务层DB本地读写、排序等逻辑，便于相互关联项目的共用，其次将 DB 抽象出来也是为了更好的方便业务本身可以不依赖 IndexDB本身，可以结合客户端特性，给底层数据库替换及进行优化提供了便捷，或者对于纯web 端，为向下兼容可以使用WebSql、LocalStorage等兼容提供了拓展。

对于前端代码架构上，如何借助 redux将原有的在线请求后台接口，快速优雅的转换到对本地的读写呢？

比较合适的做法是，单独抽出一层redux 中间件，通过配置文件的形式，将需要离线的 API初始化时传进去，然后在middleware中，完成对 DB 的读写操作，将数据组装好给下一个 reducer，我们可以叫offline中间件。为了更进一步合理的对 api 参数分解出来，我们也需要在offline 中间件前将接口请求层再抽象一个中间件，我们叫 API middleware ，这样经过离线中间件的 api 参数已经被分解，可以直接作为查询 db 使用，同时也能服务于后台请求。

离线优先与数据同步

我们已经可以通过配置将需要离线的接口通过offline中间件进行离线化，那么这里面临着两种数据更新方式，第一种是在线时走正常逻辑等待后台数据返回，异步同步到本地数据库，再进行渲染；当判断离线时，从本地读取。还有一种是具备乐观UI的思维，配置了离线的接口，优先从本地进行数据操作，渲染UI，然后再将服务端数据与本地数据进行同步。显然，后者离线优先的方案显得更为明智。

数据同步分为本地向后台同步，和后台向本地同步。后者需要增加增量变更的逻辑，用于解决离线下用户数据由于其他原因发生的变更，比如当用户登录多台设备数据移动、删除等场景（前端离线增量变更涉及很多细节及业务相关考虑点，这里暂不细述）。

如何记录本地的数据变更然后同步到后台呢？这里我们需要定义一个数据变更的抽象，比如Change

里面功能主要是定义变更类型，字段等。每次抵达offline中间件的数据通过一个数据同步管理器对变更进行注册，待合适的时机再去同步。数据同步管理器主要接受change，进行diff管理，判断数据是否有变化，及去重管理，最后再触发异步同步任务。同步可能会失败，这里的超时，重试，失败退回处理都需要加以注意，保证同步的事务性。

储存安全

储存安全包括数据加密安全和储存大小问题。对于对称加密，前端查看，客户端必须要知道密匙，密匙本身绕不开加密的问题，理论上，不和服务端通信的离线状态，任何能够在前端能够离线下查看的数据，不管采用什么加密手段，数据都能被还原。纯前端数据加密并无可靠性，但是访问权限可以依赖于IndexDB浏览器同源策略进行数据安全隔离。避免明文储存和加大数据直接还原的难度才是思考的方向。

有一个容易忽视的安全问题是 iframe, 它可以访问它所嵌入的源的 IndexedDB 库，所以我们需要保证页面全部资源可信任。

采用IndexDB 的储存方案涉及到一个储存大小问题，浏览器的最大存储空间是动态的，总共为可用磁盘空间的50％，每个站点为所用空间的20%，超出限制的写入将导致数据被删除，并且导严重在的数据丢失。因为从浏览器本身无法直接获取到 IndexDB 储存空间（以字符串方式计算性能不可靠，也极不准确），从产品统计角度，限制储存条数是一直思路之一，当然更好的方案是采用端上储存比如larveldb，杜绝此类数据丢失现象。对于纯 web 端，采用浏览器插件拓展的形式也值得尝试（比如 Google doc），更合理的保证数据安全。

结

离线化是很多前端项目不会设计进去的特性，因为对于大部分纯展示型 web 项目而言，它的收益性价比低。但作为工具型，创造型应用而言，离线会是一个具有长期受益的特性，想象一个艺术家，在飞机上看着风景，突然灵光一现，打开我们的产品进行创作，提示它无法使用，可是不小的损失....

AlloyTeam 欢迎优秀的小伙伴加入。
简历投递: alloyteam@qq.com
详情可点击腾讯AlloyTeam招募Web前端工程师(社招)

Flutter 2019 产品路线图正式公布

Fri, 18 Jan 2019 14:17:57 CST

2019

Flutter 1.0 的发布对我们来说是一个很重要的起点，长路漫漫，我们仍有很多工作要做。这里我们向大家公开我们的产品路线图（Roadmap）规划，一方面是保持开源项目的透明度，另一方面，开发者们也可以根据我们的工作优先级来制定更适合的工程方案。

以下几点我们今年会着重关注：

核心和基础
易用性
生态系统
移动端之外的支持
动态更新
工具链

我们的计划会根据大家的反馈以及新的市场变化来做调整，这份路线图里的内容不尽然是我们一定会完成的工作。如果你有任何反馈，我们鼓励你通过 Issuse，或者在我们的邮件群组等与我们保持联系。Flutter 是一个开源项目，我们鼓励你参与到我们当中来。

版本发布

使用 Flutter 的开发者们可以选择一个「频道」来「接收」我们的版本更新和变化，我们目前有四个频道：master、dev、beta 和 stable，质量和稳定性从前向后依次递增，发布速度当然也会是依次相对放缓。

我们计划每个月发布一个 beta 频道的版本，这个发布通常会是在月初，全年会在 stable 频道发布四个较大的「正式」版本。在生产环境里，我们建议开发者们使用 stable 频发布的 Flutter 版本。如果你想了解更多关于我们的版本发布流程，可以查看发布流程这篇 Wiki。

关注领域

核心和基础

我们的首要任务依然是为 Flutter 现有的核心和基础添砖加瓦：

修复 Bug：Bug 修复的优先级主要是基于 Issue 下的互动数量，比如 GitHub 自带的一些针对 Issue 的表情互动，点赞等；
性能调优：包括减少内存、引擎占用空间（包大小），提高帧率等。如果开发者们有特别的性能基准要求，可以通过 devicelab 测试数据给我们看一下；
改进 Flutter 测试流程：以确保为开发者们提供稳定的版本构建不会出现版本回归；
改进错误消息提醒：通过 Google 用户研究（User Research）团队的工作，使错误提醒更具备可操作性以及包含一些常见的解决方案；
API 文档改进：特别是提供示例代码和图表等，让我们的 API 文档更易用。

易用性

为新晋使用 Flutter 的开发者清扫绊脚石，如：

完善和满足希望使用混合工程（将 Flutter 集成到于现有的 Native 工程项目）的开发者们的需求，如提供新的插件模板和 Android 内嵌 API；
更新 Flutter 官方文档以提供更详尽的文档和使用教程；
在 Flutter 应用里管理 state 的最佳实践；
更好的帮助 iOS 开发者：投入时间持续更新和维护我们的 Cupertino widgets；
在非完整工具链和运行环境下更容易体验和使用 Flutter。

生态系统

在 Flutter 中生态系统意味着使用 Flutter 的开发者们可以便捷地完成任何他们想做的事情，甚至在 Flutter 框架不提供提供开箱即用支持的情况下也如此。我们花费了大量的精力在工具和基础设施建设的工作上，以支持围绕着核心 Flutter 技术而蓬勃发展的生态系统。Google 也会投入时间开发插件和工具来贡献这个生态。

2019 年我们会特别关注的生态系统建设工作：

更好的 C/C++ 库支持，包括从 Dart 到 C 或 C++ 之间的相互调用；
推进官方开发 / 维护的 Packages（调用原生系统的插件和纯 Dart Package）达到与核心框架代码相同的质量和完整性；
在 iOS 和 Android 上完成地图和 WebView 插件的开发；
确保 Flutter 应用可以使用一些谷歌服务，比如应用内支付和 YouTube；
提供本地推送通知和本地数据存储的支持。

移动端之外的支持

我们将继续把 Flutter 拓展到更多形态的终端，以实现我们的目标：构建一个便携 UI 工具包，在任何需要的地方画出每一帧像素。

更好的支持键盘和鼠标的输入；
完善可以让 Flutter 可以运行在 Web 平台的 Hummingbird 项目；
继续尝试让 Flutter 运行在桌面级的平台之上（如 macOS 和 Windows）。

动态更新

Dart 语言平台为 Flutter 应用开发提供了热重载（Hot Reload）的特性，让开发者们无需重新部署就可以把代码推送到应用中去。

Android 上的动态修复：让开发者直接将代码更新从服务器推送到 Android 应用里；
动态载入：让应用里不常用的部分延迟加载。

工具链

继续投入精力支持 Visual Studio Code，Android Studio 和 IntelliJ，使它们能够作为开发 Flutter 的主力 IDE；
增加对 Language Server Protocol 以及其他开放协议的支持；
通过改进开发过程中的分析、调试体验，让开发者更简单地提高应用的整体质量和性能；
持续提升模版的体验，让 Flutter 的上手开发既快又简单。

里程碑及计划时间

如果你对我们每个月将会发布什么感兴趣的话，你可以我们 GitHub 上的 milestones 页面查看。计划赶不上变化，我们的里程碑可能会因为某些 Issue 而被改变，所以我们不能保证每个里程碑的确定完成时间。

欢迎对本文作出反馈。

文/ Flutter 社区：（微信 ID：flutter-io）
原始 Wiki 地址 https://github.com/flutter/fl...

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.

德勤咨询：人工智能与商业应用研究报告（附下载）

Thu, 03 Aug 2017 00:56:41 CST

报告下载：添加199IT官方微信【i199it】，回复关键词【人工智能与商业应用研究报告】即可

商业机构中的领导者对人工智能的商业影响力感到既担忧又兴奋。全球各地的公司正逐渐意识到这一新技术的力量，并开始探索如何应用人工智能提升企业竞争力。

本文基于Efma和德勤联合进行的EMEA（欧洲、中东、非洲三地区） FSI（金融服务业）调查结果，并引用了业内多家公司的见解和案例研究，分析了人工智能的逻辑建模、行业现状以及理解和利用人工智能技术所需要采取的行动。

1. 人工智能应用领域

人工智能有三大主要应用领域：认知自动化，认知参与和认知洞察力。

认知自动化

在这一领域，人工智能的主要领域是机器学习，机器人流程自动化（RPA），和其他能够自动化深层领域知识开发的认知工具。我们已经看到人工智能设备自动化了那些传统上需要训练有素的工人才能完成的任务。

手写和字符识别是认知自动化应用的最佳范例，它可以支持高强度、复杂繁琐的办公业务，以帮助企业降低风险和成本。例如，可以使用自然语言处理和OCR技术从文档中提取关键信息。

认知参与

人工智能的下一阶段是认知技术“代理”：系统通过认知技术与人类建立密切关系。

认知系统开启了文本/图像/视频等“非结构化”数据的力量，为银行和客户提供定制化的产品和服务并创造新的收益流。

最常见的例子是语音识别接口，它可以执行语音指令，降低温控器或打开电视频道。同时，也出现了一些使用认知参与的新型应用领域，这些领域需要人工智能接触到更复杂的信息并执行数字化任务。比如接收病人入院，或者推荐产品和服务。

认知洞察力

认知洞察力是指从各种数据流中提取概念和关系，用来生成隐藏在大量“结构化”和“非结构化”数据中的相关答案。

总的来说，认知洞察力可以检测来自多个数据源数据的关键内容和相关联系，从而获得更深入和可操作的洞见。

随着处理数据量的增加，观察和预测的准确性得到了提高。人工智能不仅可以深入了解已经发生的事情，而且还能分析正在发生的事情，以及预测接下来可能发生的事情。这可以帮助商业领袖制定计划，帮助员工提高他们的业绩。例如，在全球呼叫中心，客服人员使用多功能客户支持程序来回答产品提问，接受订单，调查账单问题，并解决客户的其他困扰。

根据斯坦福大学主题为“2030年的人工智能与生活”的调查研究，专家预测人工智能将在以下八大领域发挥重要作用：交通，服务型机器人，医疗，教育，低资源社区，公众安全，就业与工作以及娱乐产业。另一方面，美国劳动部在2016年发布的报告中提到“65%的在校学生未来将被雇佣于现在尚未存在的工作岗位”。这些预测告诉我们，在不久的将来，人工智能技术将与我们的生活产生紧密联系，对工作和生活等多方面造成深远影响。

2. 人工智能中的监管问题

接下来的问题是:经济发展和社会各界需要做出哪些准备来迎接人工智能光明的未来？

在2017年初，欧洲议会提出一系列管理人工智能的法规，用来规定相关道德准则，以及人工智能犯错的责任归属问题。

议会调查员Mady Delvax强调了建立一个欧洲机器人监管机构的重要性，该机构将通过提供技术支持来协助政府部门。他还建议起草一份道德行为准则，用以指导机器人工程项目并确定他们的行为责任。

事实上，问责权或法律责任是人工智能争议中的关键问题。自动驾驶汽车的兴起就是最明显的例子，相关各方有必要去定义具体的保险计划，并确定损害赔偿的责任。在未来，智能自动化机器人将被赋予某种“法律人格”。最后 Delvaux的报告强调，机器人可能会对社会产生长期影响，政府部门需要密切关注这些趋势，创造新的就业岗位和税收模式。

3. 人工智能发展现状

为了了解金融服务行业在人工智能应用方面的现状和前景，Efma和德勤联合进行了一项大型调查, 调查范围涉及超过3000人, 受访者主要为金融服务公司技术和业务方面的高管，大多受访者表示，新认知技术的应用将增强工作的可控性，并减轻员工的工作负担，而不是将人们的劳动力完全替代。

对于“贵公司在人工智能应用领域处于什么阶段”这一问题，约90%的公司表示已经开始在他们的工作中使用人工智能技术，或正处于对这一新技术的学习中。

从下面的调查结果可以看出，数据安全(网络犯罪)、组织影响(人才需求和人员分配)、技术实施、控制权丢失和可持续性等问题是企业考虑人工智技术时可能产生的困扰。

调查数据显示，一个公司越处在认知技术实现的前沿阶段，就越难找到合适的人才。这可能是因为在技术越成熟的阶段，就越需要受过高级培训并有特定技能的专家。而在初始阶段，通用的知识就足够了。另一个重要事实是，在初始阶段，企业应用认知技术的主要障碍是缺乏组织。

有很多人担心人工智能技术可能会抢走人类的工作。然而，调查中91%的受访者认为新型认知技术可以协助或支持员工工作，而不是替代他们。

同时，调查显示大多数组织需要通过外聘来弥补人工智能技术的人才空缺，但是在聘请合适的专业人才时他们大多会遇到困难，所以未来在员工培训领域也将会产生大量投资机会。

至于人工智能的应用价值，不同的行业似乎都在寻找不同的技术解决方案。因此，有必要进行多元化的技术供应来扩大市场份额，满足更多的消费者需求。

4. 德勤观点

“一些认知技术供应商和客户正在越过“科学研究项目”的阶段，使用人工智能技术来优化业务流程。现在是时候帮助企业寻找适合使用人工智能技术的业务领域，并且思考如何使用这一新技术来优化核心流程。”

这是德勤美国高级顾问，Tom Davenport教授在2015年底对认知技术发展的看法。德勤调查显示， 86%的受访企业高管从2014年开始对认知技术有所获悉。从那时起，认知创新浪潮就已从美国向海外发展。这一事实表明，人工智能正在从一个初步构建的理念发展为可以实际操作的商业应用。

尽管人工智能技术的发展十分迅速，但是在技术应用落地时仍然会面临企业文化和组织架构带来的阻碍和挑战。一些管理层人员青睐于存在巨大机遇的发展机会，而另一些管理者更希望采取渐进的方式进行发展。企业中推动人工智能技术实施的领导者需要意识到，目前并不存在一个万能的解决方案。从德勤的调查中可以看出人工智能领域存在着多样化的应用案例，企业可以选择构建一个具有突破创新意义的人工智能客户服务体系，于此同时也可以选择一个低风险的解决方案，如后台流程自动化。

报告下载：添加199IT官方微信【i199it】，回复关键词【人工智能与商业应用研究报告】即可

您可能也喜欢的文章：
以改革为动力砥砺前行：汽车行业国企改革研究（附报告下载）	揭秘人工智能：商业领袖需要了解的认知技术	德勤咨询：2017年度足球财务报告（附下载）	德勤咨询：开展商业地产创新准备迎接未来城市（附下载）	德勤咨询：2017年欧洲、中东和非洲(EMEA)地区保险数据分析研究（附下载）
无觅

万字干货｜移动应用广告之商业变现的实现策略

Wed, 07 Jun 2017 17:37:50 CST

从事移动广告商业变现多年，总是觉得产品与商务的同事是一对“欢喜冤家”。站在开发者的角度，关注用户体验最优是无可厚非的，但“养家糊口”的问题关系着我们的生存。其实两者并没有那么根本地对立，只是缺乏一个统一的目标和相对协调的方法。

本文大纲如下：

01 概述

02 广告交易模式

03 参与者

04 广告样式设计

05 变现实验流程

06 技术对接流程

07 推广物料设计

08 相关的数据指标

09 去广告化

10 结语

01 概述

端午节期间，又有不少亲戚来向我询问那些每年他们都会问一次的问题：“其实你的工作是干啥的？”我曾经回答：我是做商务拓展的、商务运营的又或者是商务策略的，然后后面附上一大堆专业名词的解释。而今年，我做了一个自认为非常接地气的回答：“我就是帮你们手机里面安装的那些app赚钱的”，这样他们似乎立刻就懂了。

如果换在几年前，可能你说app这个词汇的时候，也只有40岁以下的人能立刻明白你在说移动应用，当时app开发者还是把所有的精力放在拉新和用户盘活的问题上。但在用户跟随市场不断被教育的大环境下，我90岁的外婆今年也用微信发出了人生第一个红包。这昭示着移动app时代已经从抢占入口向可持续发展完全转型了。随着后发app的准入门槛越来越高，单纯从拉新到用户盘活的阶段，就很有可能烧光了投资者的资金。所以，这明快的节奏要求开发者必须把用户盘活和用户变现，放在同一阶段进行。

移动应用变现的六大模式

能称之为模式的，必须能够符合“可持续发展”这个原则。例如，在手游开始爆发的2012~2013年，不少观点认为融资上市是一种最为便捷的变现模式。但近几年随着VC们越来越谨慎的投资态度，能够IPO的移动应用少之又少，而且就算得到一个良好的起点，也不代表能够支撑app的长远发展。因此，细挑一下，能够符合可持续原则的常用模式，有以下六个：

1、增值服务

免费应用+IAP（应用内购买）这个符合“中国特色”的变现潮流无可否认还是最受热捧。大部分的用户愿意花费更多的资金在喜欢的免费应用的增值服务上，而不倾向花费哪怕一元去购买一个未曾使用过的应用。游戏类应用的IAP更多是通过“加速”来促使用户付费，简单来说就是用金钱来买时间。而社交类应用有诸如表情商店这样的虚拟商品来促成消费。工具类应用则会给你提供更多更高级的功能和特权享受，诸如人工服务或者是更大的储存空间。

增值服务变现无疑是最为传统并且比较理想化的变现模式，但能促使用户产生付费行为的前提，是用户具备非常好的粘度，且增值功能具备很强的不可替代性。不少开发者会尝试把一些基础功能也放在增值服务当中促使用户付费，那么这所必然带来的是用户的大量流失。

2、广告服务

说到广告服务，必然又会触及开发者们的敏感神经。原因在于其与用户体验总是背道而驰。但原生广告的出现无疑是最大程度的降低了对用户体验的损害。原生广告不限形式，融入产品，不妨碍用户的正常使用体验，我们将会在后面铺开详叙。

而我认为广告服务是对比起IAP更具备可持续变现能力的模式，原因在于它并不需要用户为了使用你的app功能而买单。而对广告产生点击兴趣，并且最终形成购买的用户来说，广告并没有对其产生负面体验，反而是一种需求的满足。

3、电商导购

从严格意义上说，电商导购也属于广告服务的一种，但他的潜在价值却比起其他广告服务模式高出很多。最明显的例子就是在新浪微博大部分的流量都导入了天猫和淘宝之后，其广告收入就已经超过了新浪门户收入的一半。并且对比起其他的广告服务，电商导购似乎对于用户体验的破坏是最小的。原因在于购物俨然已经成为了用户的最基本需求，也似乎变成了移动app的基本功能板块。

但并非所有的移动app使用电商导购模式都能创造出可观的收入。它要求开发者具备良好的技术对用户进行个性化的商品推荐。并且在不具备大流量的前提基础下，做电商导购往往掷地无声。

4、应用分发

同样地，应用分发其实也属于广告服务变现模式的一个分支。但它更倾向于工具类的超级app使用。只要能让用户更为方便快速地获得想要的APP，那么应用分发的变现潜力无疑是巨大的。

但移动分发市场的争夺异常残酷，百度、豌豆荚、腾讯应用宝、360手机助手呈现出瓜分天下之势。正所谓“得入口者得天下”，不是“装机必备”类的超级app，通过应用分发来变现无论规模还是可持续性，都显得捉襟见肘。

5、硬件销售

易信的“青果摄像头”、墨迹天气的“空气果智能空气监测仪”，有小部分的app已经走上了“软硬结合”这条非常具备情怀的变现之路。他们依靠用户对于app某种功能极高的使用粘度，去进行硬件配套。又或者是在某个领域具备一定的用户权威，进而发布一系列的周边产品。就反响来说，这无疑是最受聚光灯关注的变现模式。

但移动app做硬件销售，最符合“雷声大雨点小”的特征。就变现程度本身而言可谓是少之又少。无可否认存在佼佼者，但大部分都是仅仅赢得一片掌声。

6、线下服务

从硬件销售转变成为提供线下服务，路子就立马宽了很多。这也是许多O2O类型的app能够持续变现的原因。照相应用推出证件照功能、养生应用上门看诊、美食社区应用提供外卖服务，出行导航类应用给你打车租车。最近几年，O2O在国内已经呈现出无所不能的态势。想必不少吃瓜群众也认为这些应用已经赚疯了。

但不难看出，在一波“烧钱”之后，能够存活下来的O2O移动应用都具备一些特点。要么能够重度垂直聚焦特色行业（美甲、医疗），要么触及了广大用户的高频刚需（打车、吃饭），要么是一些在互联网+上已经形成线上线下营销闭环的零售大佬（苏宁）。因此不得不说，线下服务的变现模式的确很美，但适用范围有限。

广告变现的必然性

在看完这“诸多”的变现模式之后，如果你产生了我的路子还很多的想法，那我必须说明白这残酷的现实。其实六大变现模式不外乎两类，广告变现（广告服务、电商导购、应用分发）与非广告变现（IAP、硬件销售、线下服务）。我相信还愿意花上一点时间看这篇文章的开发者，必定已经是对钱产生了紧急且迫切的欲望。那么你就几乎只剩下广告变现这一种选择。

就如我们开文的时候提到，在如今的移动应用市场，用户盘活与用户变现必须放在同一阶段进行，这其实说白了就是一个“以战养战”的思路。非广告变现的三种模式要么就是适用范围特别窄，要么就是需要我们先花上大量的时间去培养用户粘度，积累产品优势。可惜，我们最缺的就是时间。“三军未动，粮草先行”，比竞争对手更快积累资金优势，往往才是产品发展的最大保障。

开发者所处困境

我承认把手中的移动应用进行广告商务化不是一个容易的决定，因为接下来将面临一大堆的问题。在这里，我打算把开发者可能面临的疑惑以提问的形式一一列出，如果里面存在你的困惑，那么就有你继续看下去的价值：

我应该选取怎样的位置来尝试做广告？
广告与用户体验是必然违背的吗？有没有两全其美的方法？
是不是只售卖品牌广告，会对产品的危害度更小？
我的广告位应该如何定价？
接入第三方广告平台，是一件非常麻烦且耗费成本的事情吗？
如何把握广告主的资质审核？
广告主的投放物料设计水平参差不齐，怎样才可以更加规范？
为什么很多广告主在投放一段时间之后，都因为效果原因放弃投放了？
我的广告位置创造的收入，如何评定是优秀还是不够呢？
我现在又想把广告位去掉了，这相当于我做了无用功吗？

02 广告交易模式

在回答上述问题之前，我们首先要了解一些广告交易的基本知识。如果站在广告主的角度看，目前市场上存在至少五种广告交易模式：程序化直接保量交易、首选交易、头部竞价、RTB实时竞价公开交易、私有交易等。多种交易模式是根据是否存在竞价、是否保量、展示优先级别以及计费方式来划分的。具体可以参照下图。

而站在我们开发者的角度，我们只需要弄懂其中的两个大类：一是程序化直接交易，也就是我们俗称的品牌广告；二是RTB实时竞价交易，也有人直接把它说成效果广告。而在我们的移动应用广告变现过程中，基本离不开这两种模式。

程序化直接交易（品牌广告）

程序化直接交易（Programmatic Direct）简单来说就是一种不竞价的模式。媒体跟广告主协商好价格以及基本的流量预估，就可以直接进行一对一交易。一般来说会采用CPD（按天付费）或者CPM（按展示付费）的结算形式。这种包断流量的采购模式一般比较符合品牌广告主的铺量需求，因此也称为品牌广告。

RTB实时竞价交易（效果广告）

RTB实时竞价（Real-Time Bidding），就是媒体将广告资源接入RTB交易市场，让广告主参与实时竞价购买流量。对比起程序化直接交易，RTB实时竞价交易的流量库存和价格都是不固定的，竞价规则为“价高者得，次高价结算”。由于广告主往往会根据自身的转化成本来设定出价，因此大部分的竞价广告也称为效果广告。效果广告的可采购库存流量，一般都是在品牌广告售出后剩下的部分，也称为剩余流量。换句话说，对于广告主而言，流量获取的优先级是品牌广告大于效果广告。移动app在广告变现的探索中，一般迈向成熟阶段的标志，就是接入RTB的交易市场，这会使整体的广告变现效率更高，售出率更稳定且更可持续。

品牌广告 VS 效果广告

对于一些产品质量比较过硬的移动应用的开发者来说，售卖品牌广告几乎是广告商业化的第一步选择。当我们在陆陆续续的收到品牌广告回款的时候，不禁会提出这样的问题：我们还有必要接入RTB竞价市场，去售卖效果广告吗？

品牌广告的确存在一些天然的优势使得它更容易受到媒体的青睐。首先愿意包断流量购买品牌广告的广告主，一般都是资质齐全，具备一定知名度的品牌广告主，这样的广告用户的接受程度会更高。另一方面，品牌广告主的物料设计专业度普遍来说会更好。最后，由于其包断性质，品牌广告的售价一般会更高，就单个流量的变现水平来看，是十分可观的。

尽管如此，但我依然坚持认为，开发者们必须将广告资源尽可能地接入RTB交易市场，让更多的广告主进行竞价投放，理由如下：

1. 品牌广告的售出率不能长期保证在60%以上，更不要说100%

特别对于一些属性比较垂直的移动应用来说，本来针对的广告主行业市场就很窄。如果恰逢遇到行业淡季，售出率就会更加惨淡。而竞价效果广告几乎可以保证每天都有广告主进行竞价投放，运营得好可以常年保持100%的售出率，广告变现更加可观，可持续。因此品牌广告优先售出，效果广告竞价剩余流量才是最稳定的广告变现模式。

2. 在这个品效合一的年代，品牌广告与效果广告的界限已经逐渐模糊，品牌广告主也不是傻子

因此对于每个季度调整一次的刊例，我们做不做溢价好呢？我们溢价的依据又在哪里呢？答案就在效果广告的点击单价中。如果效果广告主普遍承认媒体的质量，在流量争夺的过程当中就会逐渐的提升点击单价，从单价的提升幅度，我们就可以判断出品牌广告的售价是否需要调整。一般来说，品牌广告的单天售价定在效果广告收入的3倍较为合适。因此，效果广告才是促进我们媒体整体流量变现水平提升的基石。

3. 用户体验

多好的广告物料质量，整天看同一个广告主的广告谁都烦。而且在这广告即内容的原生时代，我们同样要给用户看到不一样的东西，来激发他们的点击和购买欲望。一个个品牌广告主去洽谈显然是效率低下的，因此接入RTB竞价市场，是广告主数量充裕的起码保证。

4. 并不是所有的广告位都能作为品牌广告来售卖的

现在的品牌广告主更偏向购买面积大，具备一定互动性质的广告位置。例如开屏广告，线上活动，皮肤定制等等。就算是图文信息流，也未必能够受欢迎。但恰恰相反的是，效果广告主却非常喜欢这样的位置，因为更加原生的广告设计往往能够带来更好的效果。移动应用就一个开屏，但却可能存在多个tab，多个功能区域。因此只有效果广告，才能够普遍适用所有的广告形式。

03 参与者

在开发者进行广告变现的过程当中，会跟许许多多的人打交道，他们在整个广告投放节点上面充当着不同的角色。如果非常“粗暴”的划分的话，不外乎流量的拥有者【媒体】、为媒体服务的【供应方平台】、流量的消费者【广告主】以及为广告主或代理服务的【需求方平台】。但如果更加细致的看，开发者在整个广告变现的推进过程中，有可能接触到职能更为具体的人员，如产品PM、审核人员，物料设计师等等。

媒体

从广告载体的维度来划分，媒体分为PC网页、移动网页和移动APP三种。在本文，我们仅讨论移动APP这一种媒体。媒体在整个广告投放流程当中充当“供货商”的角色。提供什么样的广告位，划分多少的流量，允许什么行业的广告主进行投放，定什么样的售出价格等等一切决策，严格意义上都是媒体最终决定的。作为广告变现过程的源头，媒体的决策很多时候将会决定起步是否正确。但往往开发者对于广告投放细节的了解又是最少的。这种落差会导致非常多的媒体在广告商务化的进程当中困难重重，这时候就需要更多的角色参与到里面来。

供应方平台

供应方平台就是我们常说的SSP（Sell-Side Platform）。但目前SSP和广告交易平台Adx（Ad Exchange）的职能在国内基本上已经合体。媒体就是将广告资源对接到Adx进行售卖。Adx一般分两种：一种是聚合了各种媒体流量的第三方Adx；另一种是一些拥有自有流量的大型媒体的私有Adx。而一般在媒体资源的对接过程当中，我们会首先与广告交易平台的三种人打交道：

商务拓展（BD）：确定接入具体的广告资源、售价、分成方式与比例。
产品/运营（PM/PO）：确定具体的接入方式（JS/API/SDK），以及跟进整个技术对接流程。
审核人员：确定允许投放的广告主行业、品类，以及需要具备的基本资质。确定可投放的广告形式（落地页表单，一键下载等）。

需求方平台

需求方平台又称为DSP（Demand-Side Platform），简单来说就是给广告主和代理提供广告实时竞价投放的平台。可以比较粗暴的认为，上文提到的广告交易平台是对接媒体的，而需求方平台则是对接广告主的。那么我们媒体开发者会跟需求方平台产生什么交集吗？答案还是有的。

市场上现在存在很多混合型的DSP公司，意思就是他们除了对接Adx以外，还会自建广告交易平台来进行流量采购。也就是说广告交易平台与需求方平台合二为一。有道智选，360MAX就是这方面的代表。而面对这样的混合型DSP公司，作为媒体开发者的我们同样会有机会接触三种人：

商务运营：从宏观上清楚整个广告资源投放情况的人，他们会定时制作一些数据报表，给媒体开发者呈现广告位置的广告主结构，变现优劣甚至广告主的效果情况。并且对于媒体的广告商业化进程提供合理的建议（诸如应该设置多少的限价，流量释放的节奏，品牌销售政策如何制定等等）
物料设计师：帮助广告主进行广告物料的设计，在保证广告主效果的同时，需要优先考虑媒体的用户体验，因此跟媒体开发者存在交集。
一线销售与广告投放顾问：最清楚广告主情况的一线业务人员，具体执行广告主引入以及管理广告活动及其投放策略的人。

广告主/代理

购买流量进行广告投放的最终需求方。广告主购买流量的需求是多样的，有些是为了单纯的曝光，有些会是注重考核用户的前端行为（注册、下载等），更有甚者会精细的分析用户的后端行为（呈现意向、下单购买等）。广告主通过种种的考核方式来判断媒体的质量，最终选择是否投放以及分拨多少的广告预算进行投放。因此对于需要进行广告变现的媒体来说，广告主才是最终的“衣食父母”。

04 广告样式设计

如果你已经坚持阅读到这里，那么接下来肯定关心如何执行的问题。但在此之前，我们先要关注的是，我们的广告都长成什么样？这就必须得提及我们前文提到的原生广告。

原生广告（Native Advertising）

原谅我没有什么礼貌的说一句，现在是个广告交易平台都说自己卖的是原生广告。自2012年底这个名词被提出之后，它的定义域就被拓得越来越宽，并且逐渐模糊。这里，我认为不少关注用户体验的开发者是被“欺骗”的。我想把原生广告回归到最为本质的三个特征，大家姑且可以看看自己手中app的广告，真的都很原生吗？

原生广告是从用户体验出发的盈利模式。这句大白话告诉开发者两个最为根本的问题—你要关注用户体验，以及你要盈利。因此在判断你的广告位能不能带来很多钱的同时，你得留意你的日活用户量趋势，NPS值的变化以及用户在评论区是否已经炸毛了。
广告具备有价值的内容。这里面区别于传统广告的是，原生广告不能是单纯的广告信息，而是能对用户产生价值的广告内容。这就是从“要你读”到“我想读”的转变。当然，大家对于“有价值”的判断是存在差异的。但是纯交易型的广告信息显然违背了原生广告的初衷。
广告的呈现符合视觉整合原则。原生广告讲求的是广告即产品本身，植入不破坏页面本身的和谐，构筑不影响用户的使用体验。因此，你硬要跟我说浮动banner也是原生广告我是不服的。如果广告对产品原有内容产生了遮挡，那其实本身就没有遵循视觉整合，也没有从用户体验出发。

具体广告样式

下面列举一些常见的广告样式：

信息流广告最早于2006年出现在Facebook上，随后就应用在了各种社交媒体的用户好友动态之中。而发展到了现在，信息流广告已经不限于社交媒体，只要具备一定的内容（不论内容是由用户产出还是媒体自身产出），都可以安插信息流广告。下图从左到右分别为正常的图文信息流广告、大图形信息流广告以及icon功能型小信息流广告。

按钮广告也叫图标广告。早期的按钮广告是由banner通栏广告演变而来的。而在app原生广告时代，按钮广告往往会跟产品的功能按钮放在同样的页面，在视觉整合上更加统一。但缺点在于可传达的内容信息受尺寸限制而变得很少。

开屏广告是APP里面面积最大的广告，同时也是最受品牌广告主青睐的广告位。其实开屏广告从严格意义上称不上原生，对用户也存在启动延时的干扰。但由于“启动app正常来说都是有启动页”这个印象已经对用户教育完全，因此大家都能比较顺从的接受这样的设定。不过许多开发者为了进一步降低对用户的干扰，会增加跳过按钮或者缩小广告素材的尺寸等等。

仅次于开屏广告展示面积的样式，一般来说就是焦点图广告了。但焦点图广告会显得更加的原生。原因在于焦点图出现在内容位，用户下意识的都会认为是具备可读内容的。并且图文样式+自动轮播机制，会更容易吸引用户眼球。

激励视频广告在最近也成为了国内移动app广告市场的新宠。我们其实在很多的国外游戏里面很早就接触过这种广告，就是让你看一段游戏视频，就能给你几百金币或者某些特殊道具的广告。对于广告主而言（以CPC结算为例），激励视频广告的效果比较取决于计费节点设置在什么位置。如果用户点击视频就计费，效果一般很差（用户只是冲着奖励去）。但市面上也有不少良心广告平台将计费节点设置在视频播放结束后的落地页点击上。这样做能够过滤掉一大批的无效用户，广告主的效果会有相当好的保证，同时也对用户提供了实实在在的福利。

不在这里一一列举的原因还是我开始所说的，对于开发者而言，这些类型的广告样式严格意义上来说是“假原生”（当然也有例外）。它们都会不同程度的对用户正常使用app功能产生较大的干扰，对此判断的标准，还是我前文所说的三大本质特征。

05 变现实验流程

弄清楚了广告样式，让我们立即进入正题，这可能是整篇文章大家最关心的部分。从零做起，我们来模拟一下移动app变现的起步实验阶段如何进行。

广告位置选取

我们应当选取app哪个位置来放第一个广告？这个问题我们需要从用户体验和变现潜力两个方面来探讨。首先是用户体验方面，我们需要给用户提供一个从无广告环境逐渐转移到有可接受广告环境的适应期，这里面需要注意到这样一些问题：

（1）避免立刻在首页设置广告

你希望你还在进行测试的广告一下子就被所有用户看到吗？答案当然是否定的。当然我们还可以通过流量切分的方法来控制看到广告的用户数量。但不要忘记，站在长远的角度看，一个移动app最具变现潜力的位置绝有可能就在首页。在我们还没有选择合适的广告主以及还不清楚广告测试数据的前提下，立即在首页进行广告测试很容易使我们判断错误。这无论对用户体验还是变现进程来说，都显得操之过急。

（2）避免设置大面积广告

优先考虑内容，优先考虑内容，优先考虑内容，重要的事情说三遍。这也是我在上面提到的原生广告原则之一。而在非常有限的手机屏幕上，没有一个用户希望无效信息占据太多的位置。现在很多用户讨厌一些门户网站的web端首页，就是因为顶部的双份加大矩形广告+对联广告+浮窗广告使得他们只可以看到新闻头条的一个标题……

（3）放在下面与右面

没有用户在打开app之后的浏览目的是看广告的，因此我们需要让用户立刻达到他们的首要目的。从上而下，从左到右的阅读习惯决定了我们需要把广告放在下面或者右面。

（4）不要放在最下面

看完第三点之后看第四点，你一定觉得我是一个神经病。我需要解释的是，广告不是用户阅读目标的部分，因此如果在整个手机屏幕里面，广告处于可读内容的最底部，那么它往往会被立刻忽略。这时候，广告会成为用户的阅读中止符。因为在阅读到广告为止的内容时，用户已经认为整个阅读任务完成了。

因此我们需要把广告从任务中止符的角色，转变为增加下一个任务起始符的角色。意思是，在广告的下面，你必须再次露出小部分的可读内容。这一点在信息流广告上面尤其重要。具体的操作方法就是，研究市面上主流手机屏幕的大小，然后让广告出现在第一屏接近底部而又露出一些第二屏内容提示的位置上。那么用户在从上而下阅读的时候，必然会经过你的广告位置，这不会对他们造成太大干扰，还可以起到“客官请休息片刻”的作用。

（5）不要去尝试浮动遮挡

在首次广告变现的测试上，我认为对于浮动类型的广告应该是0考虑的。所有直接遮挡用户阅读信息的广告带给你的都只有用户的投诉以及广告的误点击。

说完了牌坊，我们来开始丢点节操。除了用户体验外，变现潜力同样是我们需要考虑的因素。在这个维度上，我们选取测试广告位置同样需要注意一些方面：

（1）需要具备一定的流量

虽然我们说过不要在首页立刻进行广告测试，但不代表我们就去选择一些非常边角又或者跳转个二三级页面的位置。因此太少的流量没有任何的测试价值，或者说难以得出可信的测试结论。我们可以选择一些用户通过一次点击之后会常进的功能区域，例如“我的”这样的位置。

（2）选取点击率有可能高的位置

没有进行过任何的广告测试，我们怎么判断哪些位置的点击率有可能高呢？这时候我们就需要去看内容的点击率。原生广告的样式一般来说都会跟当前页面的可读内容的样式保持基本一致，因此可以用内容的点击率作出一定的折损来推测广告位的可能性点击率。但这里需要注意的，部分含有引导或者激励用户点击的位置，点击率不可以参考（例如签到位置），也不适合选取作为广告位置。因为含有激励措施的位置会导致用户的非真实点击，造成广告主效果崩盘。（可参考前文对激励视频广告的描述）

（3）需要斟酌是否选择用开屏来进行首次测试

不少移动app开发者会比较热衷用开屏来进行广告变现的首次测试。但其实我认为，开屏位置具有很多的特殊性，以至于他其实并不能代表这个app的广告变现潜力。况且，开屏广告代表着整个app“最具价值”的部分，我们不太可能用很低的测试价格来放上市面，必然也是使用品牌刊例的方式来进行售卖。那么一般情况下也只有追求曝光的品牌广告主来进行投放，往往这些品牌广告主不会提供任何的广告后续效果反馈。换句话说，用开屏广告来代表某个移动app的广告变现潜力来进行测试，是测试不充分并且欠缺说服力的。

说了一大堆，就让我举个合适作为首次变现测试的广告位置。这是某个工作效率类APP。我们选择【我的】页面的小信息流来进行测试。大家可以发现，这个广告位符合我们说到的很多原则：不在首页、日均流量仅次于首页、样式原生（不遮挡内容）、面积小、放在页面中下部分（用户阅读完整功能区视觉必然经过）。

在最后需要强调的是，上面所说的原则全部都是针对单个移动app第一次的广告变现测试来说的。在起步阶段我们需要更加保守且谨慎，但不是说首页广告、开屏广告等这些样式不可行，只是他们应该放在后面来做。

实验广告主选取

我们到底用什么类型的广告主来进行首次的广告测试？这里面需要再一次围绕我们的测试目的：在不大尺度破坏用户体验的前提下，评估某广告位置的变现潜力。不难看出，对用户有益的广告是既能够满足用户体验，又能够带来广告效果的。因此，我们需要先了解我们的用户是什么类型的用户。

清晰具体的用户画像几乎是所有广告变现测试的前提。他直接决定着我们应该选取的广告主行业、具体产品、客单价范围以及物料制作风格。理论暂且不说，我们就直接看几个例子。

之前替某个工作效率类的移动app做信息流的广告测试。由于我们起步的测试价格比较优惠，因此当时有游戏、电商、教育、金融四个行业的广告主产生了测试意向，而我们只能选择一个。四个广告主分别推广的产品是手游、化妆品打折季活动、儿童早教产品、信用卡黑卡免费办理服务。我们详细地看了该app的用户画像：男性用户占比在73%，这让我们首先排除了电商广告主的测试；年龄分布在21~26岁，儿童早教产品似乎不会有太多转化，因为这个年龄段的父母很少；企业管理者以及职员占比60%以上，因此我们觉得游戏的表现预估不会太好。最后我们选择金融信用卡黑卡产品进行测试，因为用户画像的属性非常符合：税前收入5K以上的用户占50%以上，具备一定的收入能力；一二线城市占比超60%；本科以上学历人士占58%。总体来说，我们可以把该app的用户定义为具备一定收入水平的男性商务人士。

好的用户画像可以使得我们在进行广告主选取时候少走很多弯路。甚至对物料设计风格也是如此，曾经我们在某个电商的打折季活动物料上，放了一个粉红色的保温瓶。当后来得知他们的男性用户占比更大的时候，把保温瓶的颜色更换为黑色，点击率就翻了一倍。

资质与物料审核

一般来说，很多广告交易平台都会自带审核部门，他们具备标准化的审核流程、规范的审核系统以及高效的自动审核机制。但在我们进行首次广告变现测试的时候，往往不能立刻适用这些标准化流程。究其核心原因，就是对于首次广告测试，我们需要非常的谨慎，务必要选择资质优秀素材优质的广告主进行测试。站在这个角度，“哪些广告主不能投”的黑名单审核机制并不适用。“只允许哪些广告主可以投”的白名单机制更为稳妥。况且在人工运营的测试阶段，广告主数量不会很多，我们理应先抛弃自动化的系统，而更为细致的case by case去选择广告主和投放素材。

人工运营实验流程

有了广告位置，准备好了测试广告主和广告素材，就可以正式“开干”了。在没有接入系统之前，整个广告投放的实验流程，几乎都是全手动运营的：

（1）广告上线前准备

上线前充分测试，确保新上线的广告产品功能正常，广告展示/点击等数据上报无误。此外，还需要对测试广告主提供的投放链接进行测试。这里面包括，链接是否能正常打开，打开的响应速度是否会过慢。在页面里面进行注册、下载、下单等行为时，效果是否能成功监测。说到转化跟踪监控，一般来说广告主与媒体都不会完全信任对方提供的数据，因此大部分没有接入系统的非标准测试环境下，都是采用第三方进行效果监控。

（2）广告上线

是否应该让所有用户立刻看到广告，这是一个值得斟酌的问题。一般来说，比较稳妥的做法是先划分一部分的流量上线广告（如20%），一方面可以进一步在线上测试广告功能和流程是否存在bug。另一方面可以看看用户对此的反弹程度是否强烈。

另外，我们需要珍惜每一次的测试机会。能够做到尽量细的数据监控是最好的。例如分时段的查看广告的流量和点击情况。以此来判断广告位置的前端数据分布情况。例如我们会发现工作效率类的app在早上9点钟的流量与点击比较大，阅读类的app在下午6点之后呈现数值高峰等等，这都会对我们日后的运营提供很多重要的信息。

同时，我们应该在广告投放期间，尽可能多的搜集广告主的数据反馈。包括落地页面的到达PV，实时的转化数据等等。如果广告的跳出率异常的高又或者转化数据异常的差，我们都需要进一步的去确认广告的线上流程是否存在问题。在首次的广告投放测试当中，首要任务就是要保证广告正常的投放出去。

（3）广告上线后反馈

这可能是整个广告变现测试最重要的一环。我们需要通过这次测试得出一些怎样的结论？整体来说，我们至少需要从用户体验、变现水平和运营成本三个方面进行评估。

说到用户体验，大部分开发者可能第一时间想起的就是通过NPS值来判断，但我不得不说这可能相当困难。因为一般来说，我们都不会为了上线一个广告功能而单独发一个包，因为这样用户体验会非常糟糕。所以捆绑一些用户功能来发一个新版本显得更为合理。而NPS的测量则是针对这整个版本而言的，你无法因此而判断是否广告功能影响了这个数值。因此，更为直接的方法应该是，我们直接去看用户评论区，是否有大量的用户针对新上线的广告功能进行投诉或者抨击，这样虽然看上去不那么客观，但却是最有效和快速的。

变现水平的评估，只要方法得当，则会比用户体验评估来得更加“有理有据”。很多时候，我们会按照一定的测试价格来收取广告费用，但这个测试费用其实并不代表我们未来的可能预估收益。这里举两个例子会更加直接：

我们跟某广告主进行信息流广告首次测试合作，以一个成功注册40元的价格进行CPA结算。我们划分了20%的流量进行此次测试，测试三天，最终给广告主带来了300个注册，因此我们收取了40*300共12000元的广告测试费用，日均收入为12000/3=4000元。倘若未来全量投放，日均收入会是4000元/20%=20000元
事实上，这个广告位置的全流量有300W，这次测试监控的点击率为1%。也就是说，如果未来全量上线的话，会产生300W*1%=3W个点击。我们在划分了20%流量的前提下，日均给广告主完成了100个注册，因此转化率为100/20%/3W=1.67%。对比同类型的媒体，67%转化率的媒体，平均出价水平大概在2.5元左右。我们打算未来实现CPC全量竞价投放的收入预期就是3W*2.5=75000元。

发现了吗？实际上我们看到的测试费用并不等于我们未来可能的变现能力。这里面的原因是，在没有接入系统之前，数据的监控会显得尤其困难，广告主更多的会偏向于使用CPA来进行结算。并且在没有其他广告主竞争的情况下，点击单价和点击率都不会呈现一个峰值状态。所以我们在做预估的时候，就需要向B的思路那样，做出更有可能接近真实值的评估。

在进行了用户体验和变现水平的评估之后，基本上我们就会得出是否对此广告位进行完全商业化的结论了。当然，有时候一次的测试不能够说明问题，我们还需要进行多几轮的测试，将测试的流量占比逐步放大，并且更换一些不同行业不同品类的广告主来尝试。但需要注意的是，我们的测试是建立在全手工运营的基础上，这必定会耗费我们大量的人力成本。从物料审核、上线操作到数据监控、费用结算都没有系统支持。因此，我们需要评估整个运营成本跟我们预估的变现收入是否对等。不过归根到底，如果在测试结论稳定的前提下，作出了此广告位全面商业化的决定后，尽快接入广告交易平台实现标准化系统投放，才是最高效的途径。

06 技术对接流程

媒体实现广告的标准化系统投放，其实并不是一件很“重”的事情，但却能在运营效率以及变现收入上都带来非常大的提升。目前市场上基本上都是使用API对接或者SDK对接两种模式。接下来，我们会分别简单介绍一下。

API对接

服务端对接即可，其优点是可快速对接并上线，且媒体方对流量的分配、控制也更加灵活便利，因此导致客户端出bug的风险也会较小。但缺点是难以实现广告SDK的全部功能，例如用户的上下文信息捕获、广告的预加载、渲染加速、性能监测等。这些功能的缺失可能影响广告系统的自动优化，进而对广告点击率、填充率、广告收入产生影响。

SDK对接

SDK对接需要改动客户端，开发量相对API对接来说会稍大一些。我们同时需要确保广告SDK足够稳定，不会给产品带来bug。因为毕竟是客户端集成，如果出现bug，需要客户端发新版才能修复。但其优点是可利用到SDK的全部广告优化功能，通过收集详细的用户信息、加速广告加载渲染、完善广告数据监测等方法，来提升媒体流量的变现效率。

综合来说，在前期筛选广告合作方的阶段，用API对接更加灵活可控一些，当基本确定深度合作的广告平台伙伴之后，SDK对接是一个更好的选择。

07 推广物料设计

很多开发者认为他们对于广告物料的重视程度已经十分足够了。因为我们已经充分考虑物料会否破坏用户体验，影响产品调性，破坏视觉界面，违反法律规定等等。所以我们对广告主素材会执行非常“严格”的审核，从尺寸、大小、格式到色调、文字内容、排版样式。

这样做是完全没有问题的，但我在这里说的推广物料设计，考虑的却不仅仅是“合法”的标准。就如我上文提到的粉红色保温瓶换成黑色的问题一样，好的设计素材可以直接提升我们的变现效率。

但现实情况却是，市场上大部分的推广物料都是由广告主自己提供的。倘若广告主制作的素材已经达到了“合法”的标准，那么作为媒体的我们没有理由去要求广告主作出频繁修改。况且，很多时候我们不知道修改的标准是什么，只是提出一些肉眼看上去更“美丽”的建议。这就等于我们对于品牌广告主物料的态度，我们经常认为他们的物料质量是高的，因为看上去“高端打次上档次”。但我们却忽略了，品牌广告主往往不会关注物料的后续效果数据情况，又或者不是不关注，只是无法度量（传统的奢饰品和快消行业，很难把他们的最终销量跟某个广告效果关联起来）。但效果广告主则不一样，每一个物料的真实效果，都会影响他们的最终出价，从而影响媒体的真实变现。

怎么解决这个问题？需要对媒体广告变现负上责任的，除了我们开发者自身还有的就是广告交易平台。对，我们必须在推广物料设计上对广告交易平台有更严格的要求。一方面对广告主的推广效果负责，另一方面对媒体的变现效率负责。这使得广告交易平台必须真正花上精力，去研究优秀推广物料的事情。

接下来就是选择的问题，市面上有哪些在这方面做得比较出色的广告交易平台？对此，我可以先大概告诉你，他们是怎么做的。他们会用大量的素材投放到媒体当中，持续的收集点击率、转化率等数据。然后将一张素材按照版式、色调、元素、文案等单位拆分开来。跟踪这些单位在不同素材和不同媒体里面的数据表现，然后重新组合。不断的通过A/B test和定量分析，最终形成适合这个媒体投放的若干个素材模板，进而推荐给广告主或者接入程序化创意后台，形成普遍的投放。没错，这绝对不是广告主自己能做到的，也不是通过媒体审核可以做到的。这需要一个团队持续的研究和运营。在市面上，目前能做到这一点的，拥有高智能程序化创意后台的广点通算一个；拥有一个庞大设计师团队，给广告主持续提供广告素材制作的有道智选算一个。

08 相关的数据指标

在整个广告商业变现的进程当中，无论是人工运营阶段还是接入系统后的标准化运营阶段。给我们提供一切决策依据的，就是数据，那我们一般需要关注哪些数据？

每日活用户贡献收入

一个移动应用广告创造多少收入算高？如何判断这个位置的广告价值如何？就是看这个指标。直接用该广告位置的收入除以日活用户。这个指标可以针对单个产品页面来看，也可以针对整个移动应用来看。广告变现良好的应用这个数值一般在3分钱以上。

每日活用户接受展示

广告展示数/日活用户数。这个指标更多的是站在用户体验角度考虑的。简单来说就是用户使用app，一天会看到多少次广告。这个指标的好坏没有标准，全在于我们的接受程度以及与之匹配的NPS值的变化。但如果这个数值大于10，我们得考虑一下，广告是否放得太多了。

ECPM值

广告每千次展示可以获得的收入。该指标能够更加直接的体现具体某个位置的变现能力。ECPM = 收入/广告展示次数×1000，而放在效果广告领域，收入=广告展示次数×点击率×点击单价，因此ECPM=点击率×点击单价×1000。点击率大部分时候会收到物料素材吸引度的影响，而点击单价很多时候会受到广告主后端ROI的影响。因此ECPM能够更为全面的体现单一广告位的价值。

09 去广告化

小时候学政治的时候，我就一直有一个疑问。原始社会按需分配，到了共产主义社会也是按需分配，这中间都经历了啥？老师告诉我们，他们的区别在于生产力在不同的水平上。这个问题似乎跟我们的广告商业变现有异曲同工之妙。在我们没有广告的时候，要把广告放上去。而当广告变现到达一定的发展瓶颈的时候，我们又会把一部分拿掉。

我就更为直接一点吧，所谓的去广告化，我们常用的手段就是会员制度。市面上所有的app会员服务，第一条福利几乎都是去除广告。这部分选择成为会员而去除广告的用户，往往也是认为广告体验较差，不会去点击任何广告的用户。也就是说会员制其实是筛选掉一部分对于广告收入贡献无效的流量。而且通过会员制，我们还能从这批用户里面重新创造一笔财富。来到这个阶段，品效合一、系统标准化运营、会员制度三者结合，移动应用的商业变现就基本形成一个稳定且可持续发展的模式。

10 结语

从事移动广告商业变现多年，总是觉得产品与商务的同事是一对“欢喜冤家”。站在开发者的角度，关注用户体验最优是无可厚非的，但“养家糊口”的问题关系着我们的生存。其实两者并没有那么根本地对立，只是缺乏一个统一的目标和相对协调的方法。

根据可考究的历史记载，中国早在公元前3000年就出现了实物广告。当一个部落需要用布匹来交换隔壁的小羊羔时，他们就开始用尽方法来“宣传”他们的衣服。那个时候的人们对广告更多是一种原始的需要。难道到了今天，我们可爱的用户就不需要广告了吗？

写这篇文章，给予所有的移动应用开发者，写给那些已经走在或者即将踏上广告商业变现之路的“部落人们”，愿你们获得成功并且给我们分享你的经验。另外，也不妨带上你们的“小羊羔”找到我们，我们期待跟各位有更深层次的合作。

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

被阿里收购168天后的豌豆荚，得到了什么又失去了什么？

Wed, 21 Dec 2016 18:00:20 CST

五个多月前，阿里巴巴宣布收购豌豆荚，创业六年，豌豆荚尘埃落定。可是五个多月后的今天，豌豆荚又出现在了人们的视野里。

12 月 20日下午北京雾霾压城，豌豆荚战略发布会，公布了被阿里巴巴收购后的 168 天里，豌豆荚到底做了什么以及对未来的打算——内容分发战略。

“内容分发战略，通过应用前置出来的内容和服务去吸引用户，更快地触达用户，用户在下载应用之前，已经成为目标用户去使用。同时，通过阿里大数据分析，把用户想要的内容精准提供给用户，并且根据内容的使用行为积累数据进行下一步更精准的预测。”阿里巴巴文化娱乐集团豌豆荚总经理张博在演讲中这样介绍。

像之前“豌豆荚一览”便是采取了这样的策略，把应用内的内容聚合起来经过简单加工传递给用户，呈现在豌豆荚的信息流中，在用户未下载应用的时候便可以对应用内的优质内容有一定程度的感知。

在几个月前豌豆荚刚被收购的时候，豌豆荚的联合创始人王俊煜曾在自己的公众号里发表过一篇文章《不是终点》承认了豌豆荚在渠道和商业化方面的短板。

我自己对豌豆荚最为骄傲的是产品和品牌，而外界对我们在商业化和渠道能力上的作战能力欠缺一直有所批评，这点我虚心接受。并入阿里巴巴，恰好能增强豌豆荚应用分发业务在这上面的工作。在阿里巴巴的帮助下，我们的客户和合作伙伴在豌豆荚的投入也会触达更多的用户，有更好的效果。这绝对是一件好事。

被阿里巴巴收购后，豌豆荚确实补足了这两块短板。借助阿里巴巴的大数据和阿里大文娱（比如神马搜索）的渠道，豌豆荚的用户数和分发量比以前有所上涨，最近的一则数据报告也显示了豌豆荚市场份额的提升。阿里巴巴也成功把自家不成器的 PP 助手等应用商店和豌豆荚整合，能够往应用商店前三的位置靠一靠，也能为自家产品矩阵带去更多的流量。

据介绍，豌豆荚由于接入了阿里巴巴，包括搜索、电商、视频、地图、社交、应用、游戏还有用户移动各种各样的数据，从用户购买、下载行为的路线里面能够给用户非常精准的个性化应用推荐，个性化推荐应用效率提升了至少60%到200%。

豌豆荚目前的主页

有得到便有失去，熟悉豌豆荚的老用户可能并不会再喜欢现在的豌豆荚了，广告挤满了首页，KPI 压榨着最后一点剩余价值。但是对于阿里而言，能够触及到的用户规模更大，豌豆荚最开始起家的那一小部分忠实用户反而成为了可以抛弃的。

流量红利期已过，除了依托 BAT 或是手机硬件厂商，第三方应用商店没有以前那么好过，甚至有不少靠应用商店起家的都把自家的业务外包出去，去做其它比应用商店更赚钱多得多的事。豌豆荚内容分化战略听起来更像是做了应用宝这样的顶级应用商店玩家们不愿意也懒得做的事情，把故事继续说下去。

但是内容分发能够比今日头条做得更好么？很难。至于反复强调“会保持住自己的个性”，从现在豌豆荚的体验来看，倒不像会上嘉宾发言说的那样真切了。

连接 IFTTT 和即刻App，其实还可以连接更多

Thu, 06 Apr 2017 16:37:14 CST

IFTTJ 是一款利用 IFTTT Webhooks 机制，连接 IFTTT 与即刻App 的在线服务，让那些原本没有接入 IFTTT 的服务也能享受开放互联网的特性。@Appinn

来自发现频道：「连接 IFTTT 和即刻App，即 IF This Then Jike，然后就可以玩出很多花样了！」

Webhooks 是一个处理网页请求的机制，IFTTT 的 Webhooks 可以接受请求后触发 B 条件，也可以作为 A 条件实现后发送请求给 Webhooks，从而连接没有被 IFTTT 支持的服务，比如即刻。

即刻作为一款不错的阅读工具，用来接受 IFTTT 发来的各色内容，再推送至你的手机，蛮有意思，虽然也可以让 IFTTT 直接发送过来

在 IFTTT 的「如果 A 触发，就执行 B 中」，A 条件为任意，B 条件为 Webhooks，而 Webhooks 触发了 IFTTJ。

打开 IFTTJ 后就得到了一个专属地址，这个地址就是用来给即刻订阅使用的。然后在 IFTTT 配置将需要的信息使用 Webhooks 发送至这个地址即刻，具体使用可以参考 IFTTJ 提供的一个使用即刻订阅某人 Twitter 消息的例子。

「接下来，只要在即刻创建新提醒时，选择『RSS订阅源有更新』这个机器人，并填入你的专属 URL 就可以了！」

下载地址: http://ifttj.wong2.me/

apppackge:

容器内应用日志收集方案

Fri, 16 Dec 2016 09:04:22 CST

容器化应用日志收集挑战

应用日志的收集、分析和监控是日常运维工作重要的部分，妥善地处理应用日志收集往往是应用容器化重要的一个课题。

Docker处理日志的方法是通过docker engine捕捉每一个容器进程的STDOUT和STDERR，通过为contrainer制定不同log driver 来实现容器日志的收集，缺省json-file log driver是将容器的STDOUT/STDERR 输出保存在磁盘上，然后用户就能使用docker logs <container>来进行查询。

在部署一个传统的应用的时候，应用程序记录日志的方式通常记录到文件里，一般（但不一定）会记录到/var/log目录下。应用容器化后，不同于以往将所有日志放在主机系统的统一位置，日志分散在很多不同容器的相互隔离的环境中。

如何收集应用写在容器内日志记录，有以下挑战：

1) 资源消耗

如果在每个容器运行一个日志收集进程，比如logstatsh/fluentd 这类的日志工具，在主机容器密度高的时候，logstatsh/fluentd这类日志采集工具会消耗大量的系统资源。上面这种方法是最简单直观的，也是最消耗资源的。

2) 应用侵入

一些传统应用，特别是legacy 系统，写日志机制往往是没法配置和更改的，包括应用日志的格式，存放地址等等。日志采集机制，要尽量避免要求修改应用。

3) 日志来源识别

采用统一应用日志收集方案，日志分散在很多不同容器的相互隔离的环境中，需要解决日志的来源识别问题。

日志来源识别的功能借助了rancher平台为container_name的命名的规则特性，可以做到即使一个容器在运行过程中被调度到另外一台主机，也可以识别日志来源。

容器化应用日志收集方案

下面是我们设计的一个低资源资源消耗、无应用侵入、可以清楚识别日志来源的统一日志收集方案，该方案已经在睿云智合的客户有成功实施案例。

在该方案中，会在每个host 部署一个wise2c-logger，wise2C会listen docker engine的event，当有新容器创建和销毁时，会去判断是否有和日志相关的local volume 被创建或者销毁了，根据lables，wise2c-logger 会动态配置logstatsh的input、filter 和output，实现应用日志的收集和分发。

1）应用如何配置

应用容器化时候，需要在为应用容器挂载一个专门写有日志的volume，为了区别该volume 和容器其它数据volume，我们把该volume 定义在容器中，通过volume_from 指令share 给应用容器，下面是一个例子：demo应用的docker-compose file

web-data 容器使用一个local volume，mount到/var/log目录(也可以是其它目录)，在web-data中定义了几个标签， io.wise2c.logtype说明这个容器中包含了日志目录，标签里面的值elasticsearch、kafka可以用于指明log的output或者过滤条件等。

那么我们现在来看下wiselogger大致的工作流程：

监听新的日志容器->获取日志容器的type和本地目录->生成新的logstash配置：

1）wise2c-looger 侦听docker events 事件，检查是否有一个日志容器创建或者被销毁；

2）当日志容器被创建后（通过container label 判断）, inspect 容器的volume 在主机的path；

3）重新配置wise2c-logger 内置的logstatsh 的配置文件，设置新的input, filter 和output 规则。

这里是把wise2c-logger在rancher平台上做成catalog需要的docker-compose.yml的截图，大家可以配合上面的流程描述一起看一下。

优化

目前我们还在对Wise2C-logger 作进一步的优化：

1）收集容器的STDOUT/STDERR日志

特别是对default 使用json-file driver的容器，通过扫描容器主机的json-file 目录，实现容器STDIN/STDERR日志的收集。

2）更多的内置日志收集方案

目前内置缺省使用logstatsh 作日志的收集，和过滤和一些简单的转码逻辑。未来wise2C-logger 可以支持一些更轻量级的日志收集方案，比如fluentd、filebeat等。

Q & A

Q：有没有做过性能测试？我这边模块的日志吞吐量比较大。比如在多少量级的日志输出量基础上，主要为logger模块预留多少系统资源，保证其正常稳定工作？

A：没有做过很强的压力，但是我们现在正常使用倒没碰上过性能上的瓶颈。我们现在没有对logger做资源限制，但是能占用300～400M内存，因为有logstash的原因。

Q：「生成日志容器」是指每个应用容器要对应一个日志容器？这样资源消耗不会更大吗？k8s那种日志采集性能消耗会比这样每个应用容器对应一个日志容器高么？

A：是指每个应用容器对应一个日志容器。虽然每个应用有一个日志容器，但是，日志容器是start once的，不会占用运行时资源。

Q：你说的start once是什么意思？我说占资源是大量日志来的时候，那么多日志容器要消耗大量io的吧，CPU使用率会上升，不会影响应用容器使用CPU么？

A：不会，日志容器只生成一下，不会持续运行。

Q：怎么去监听local volume？

A：可以监听文件目录，也可以定时请求docker daemon。

Q：直接用syslog driver，能做到对应用无侵入么？

A：启动容器的时候注明使用Syslog driver的参数即可，这样几乎没有额外资源占用。

Q：这种方案是不是要保证应用容器日志要输出到/var/log下啊？

A：不是，可以随意定义，logstah可以抓syslog。

Q：syslog driver能收集容器内的日志文件么？容器内不同流向的日志能区分么？

A：容器内应用的本地日志syslog可以收集，分流同样可以完成，但是容器内的本地日志这个我个人觉得跟容器环境下的应用无本地化、无状态化相悖吧。

Q：最后你说到，重新配置logstash中配置文件，看上去感觉你又是通过wiselog这个容器去采集所有日志的？只不过是动态配置logstash里面参数。

A：是的，现在收集工作是logstash来完成的，单纯的文件收集，可选的方案还挺多的，也没有必要再造轮子了。

Q：那这个方案其实有个疑问，为什么不学k8s那种，直接固定那目录，通过正则表达式去采集日志文件，而要动态这么做？有什么好处吗？目前我感觉这两套方案几乎一样。

A：为了减少对应用的侵入。因为很多用户的现有系统不能再修改了，这样做也是为了减少用户现有程序的修改，为了最重要的“兼容现有”。

Q：除了kibana还有没别的可视化方案？

A：针对es来说，还没有别的更好的方案。

Q：如果是挂载log目录，logstash就可以去宿主机收集了，还需要别的插件做什么？

A：通过容器可以识别出来这个应用的业务上的逻辑，可以拿到service名称。

Q：有的应用输出的log名都是一样的，不会有冲突吗，比如我启动2个容器在一个宿主机上，都往xx.log里写入会有问题。

A：不会，给每一个应用容器配一个日志卷容器就可以解决这个问题。这个问题也是我们出方案时一个棘手的问题。所以这个方案的一个好处就是，每一个应用的都可以随意设置日志目录，不用考虑和别的应用冲突，也不会和同宿主机同一应用冲突。

Q：上次听别人说全部把日志扔到标准输出里，不知道靠谱不？

A：有人报过这种处理方式，日志量大时，docker daemon会崩溃。

同样基于应用内搜索，“一览”才上线半年多，豌豆荚为什么又发布了“轻桌面”？

Sat, 30 Jan 2016 17:32:06 CST

没有安装 app，却能在 Android 手机桌面看到该 app 的图标，点击进去可以阅读内容。不同 app 还能按主题“合体”在一起，在一个有时间线的信息流页面里阅读“合体” app 的内容。

联翩科技出品、 1 月 29 日晚刚刚发布的豌豆荚轻桌面，就能做到上面说的这些“神奇的”事情。今年 1 月，豌豆荚将豌豆荚一览、Snap 效率锁屏（现已更名豌豆荚 Smart 锁屏）两款产品拆分了出来，成立一间新公司——联翩科技。

豌豆荚轻桌面发布后，爱范儿第一时间联系上豌豆荚联合创始人兼 CEO 王俊煜，联翩科技联合创始人、《Android 开发精要》作者范怀宇，以及工程师许彬，一起聊了聊豌豆荚这个新产品。

不是 app，却干着 app 的活

打开豌豆荚轻桌面，搜索感兴趣的 app，点击右上角的“+”符号，将一个预览版 app 添加在桌面。然后就能在不安装该 app 的情况下，预览阅读它提供的内容。

通过豌豆荚轻桌面添加的预览版 app，图标设计基本与原生 app 无异，不过右上角有一个“豌豆荚轻桌面”预览版的标志。

所谓预览版 app，其实相当于一个 app 的快捷方式，点击后直接跳转到轻桌面这个原生 app 的显示页面。所以，如果预览内容后觉得该 app 值得下，也可以通过豌豆荚轻桌面安装完整版。

除了能预览 app 里面的内容，豌豆荚轻桌面还有个 MixUp 功能——将 app 分成了不同话题集合，添加感兴趣的话题集合后，就能以信息流的方式，看完该话题集合下 app 的所有内容。

目前，豌豆荚桌面收录的应用数量超过 500 个，和豌豆荚一览收录的基本同步。

（豌豆荚轻桌面）

如果你用的是 Android 5.0 及以上版本的手机，还能看到预览版 app 像原生 app 一样显示在历史应用里。“这个需求是我提的，哈哈哈。”王俊煜颇为得意地打趣道。

工程师许彬告诉爱范儿：“这个功能的实现其实是基于 Android 5.0 之后的新 API，可以为 app 不同页面指定不同的 document，Chrome 就是用这个方法。”

许彬说的是，从 Android 5.0 开始，Chrome 移动浏览器有了一个新的功能——合并标签页与应用，Google 在有意模糊网页和原生 app 的边界。

此外，开发团队还“细心地为不同的应用使用了他们自己的主色调”。比如爱范儿的红色调，One·一个的蓝色调，以及 Product Hunt 的橙色调。

豌豆荚轻桌面目前还只有 Android 版本，“iOS 版本还没有具体的时间表，而且由于两个系统的差异，形态上肯定有变化”。

又一个基于应用内搜索的产品

豌豆荚轻桌面和之前的豌豆荚一览一脉相承——基于应用内搜索技术。

所谓应用内搜索，即用户可以在应用内搜索产品中检索到其它应用中的内容，这一行为打破了各个 app 之间隔离的状况，使内容在一个平台上共享。

2015 年 7 月，豌豆荚一览在 iOS 端和 Android 端同步上线。得益于应用内搜索技术，一览能把散落在手机已有 app 内的文章、图片和视频都抓取并串联起来，在同一个页面中以卡片流的形式展示给用户。

手机里还没有的 app，用户也可以选择用 “添加” 的方式发现一览收集的其他 app 内容。如果觉得内容好，想直接下载 app，一览也提供了安装按钮。

2015 年 12 月，“在打磨应用内搜索技术以及运营豌豆荚一览的过程中，发现不少需求点用另一种形态来满足会体验更好，于是逐渐萌生了做豌豆荚轻桌面的想法。”范怀宇告诉爱范儿。

（豌豆荚一览）

2016 年 1 月初，团队开始动手开发，不断地把这个想法打磨完善，“另一种形态”的产品逐渐成型。1 月 29 日晚，豌豆荚轻桌面上线，其中一种发布渠道就是豌豆荚一览。

豌豆荚团队表示，一览和轻桌面这两个产品分别满足不同的用户需求。豌豆荚一览是一个有时间线的产品，主要给内容重度用户一次刷完所有关注 app 的内容，提升效率。

“轻桌面按照兴趣和话题分组更多一点，关注细分的兴趣，让用户更好地发现 app、体验 app，在满足这些需求时候也更加直截了当。”范怀宇说道。

“现在我们实现这两个产品其实都基于同一套框架，成本还是比较小的。”许彬补充道，“通过让每个产品更加专注，而不是做一个大而全的应用，反而可以满足不同用户的特定需求，也可以让我们更好地了解到用户真正需要的东西。”

目前，轻桌面的 Android 客户端工程师也只有许彬一个人。“去年一年，不论是服务还是客户端，我们都积累了非常多内部定义的‘标准化’模块，期望有机会像乐高那样不断组织成有趣的形态。”范怀宇告诉爱范儿，“轻桌面和一览严格意义来说，很多人力是复用的。短期来看，两个产品会各有侧重独立迭代，相关重合的部分，会共同来改进。我们没有严格的划分，就是一个团队。”

“内容和服务一定会离用户越来越近”

2014 年参加一次访谈时，王俊煜这样描述豌豆荚的转型：

现在（2014）的豌豆荚像 97 年的 Yahoo！。移动互联网刚起步，用户也不知道智能手机到底能做什么，所以需要应用分发平台给用户推荐各种 app。

豌豆荚正在从 97 年的 Yahoo！向 99 年的 Google 转变。Yahoo！是一个网站，而 Google 跳过了站点（website）把一个个网页（page）连接起来，注重直接的信息、内容消费。目前移动互联网的 app 把信息隔离、分散了，像大海里的鱼缸，豌豆荚想做的事情就是要把这些分散的信息串联起来。

基于这样的理念，豌豆荚于 2014 年 3 月发布了 “应用内搜索技术协议”，规定了应用内内容的检索、收录和应用调起标准。

2015 年 1 月，豌豆荚发布基于应用内搜索的独立产品 Snap 效率锁屏（豌豆荚 Smart 锁屏），用户不需解锁就可以处理信息。没有安装相关应用，则会直接打开应用的 HTML5 页面。再接下来就是豌豆荚一览和豌豆荚轻桌面。

产品在“注重直接的信息、内容消费”和“串联分散信息”上逐渐深化的同时，豌豆荚也将豌豆荚一览、豌豆荚轻桌面和豌豆荚 Smart 锁屏这三个产品拆分开来，成立联翩科技。

王俊煜告诉爱范儿：“对于应用分发的未来，我自己不敢做太大的预言，但内容和服务一定会离用户越来越近。”而分发 app 起家的豌豆荚，在弱化 app 形态的道路上越走越远。

欧狄

长期关注虚拟现实动态，工作邮箱：oudi@ifanr.com。

邮箱

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

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

阿里数娱：2015年TV应用商店数据报告

Fri, 22 Jan 2016 17:15:37 CST

日前，阿里数娱发布旗下TV应用商店的年度数据报告，公开2015全年TV应用的下载总量达1.95亿，活跃家庭用户总量达1293万。数据显示，教育天地、生活娱乐类应用崛起，用户活跃量跃居第二;经济发达地区家庭对TV应用的需求更旺盛，符合智能电视的地域发展趋势;一起公布的还有六大分类应用的累计TOP10下载和活跃量排行榜。

下载活跃总量连攀高峰，生活娱乐类应用崛起

阿里数娱TV应用商店2015年度整体数据图

从2015年月度数据趋势来看，年初开始，阿里数娱TV应用商店的下载量和活跃家庭用户量均呈稳步上升趋势，9月开学季历经一个小高峰，于11月到达全年最高值。11月，下载量环比增幅达183%，活跃用户量环比增幅达51%，用户一个月内平均下载7个应用。六大应用分类里，实用工具和游戏的数据表现照常坚挺，生活娱乐类应用以占比15%的下载量勇夺第二高占比的用户启动活跃量，表现甚为亮眼，说明客厅场景的文娱需求很高。

而从阿里数娱TV应用商店的活跃用户在国内的地域分布来说，经济发达地区家庭对TV应用需求更旺盛，契合智能电视区域分布趋势。整体来看，山东和河南人口基数大，以高活跃家庭用户数位列第1梯队;广东、江苏和浙江紧随其后，位列第2梯队。

2015年度TV应用下载/活跃量累计排行榜一览

综合来看，阿里数娱TV应用商店整体及各分类的Top10累计下载和活跃量榜单上的应用重合度都很高，说明阿里TV用户忠诚度很高，下载应用以后持续使用，粘度很好。

阿里数娱TV应用商店全品类Top10累计排行榜

在2015年度TV应用整体Top10榜单上，优酷CIBN合一影视强势夺得下载和活跃量双料冠军，恰恰广场舞和咪咕爱唱成为本年度成长最快的家庭娱乐应用，佳可视和视频聊天齐齐上榜说明客厅用户对于远程视频、异地聊天的重要需求。

阿里数娱TV应用商店Top10实用工具类排行榜

热门的工具类应用主要集中在TV设备的性能优化、本地管理和视频聊天播放等块面，用户刚需属性非常显著。

阿里数娱TV应用商店Top10健康养生类排行榜

广场舞风靡全球，先跟着TV上的恰恰广场舞和辣妈学起来!健身、瑜伽以及线上医疗也是家庭里的热门主题，总有一款应用可以帮助你健康生活。

阿里数娱TV应用商店Top10生活娱乐类排行榜

优酷CIBN合一影视和华数TV成为最受用户欢迎的应用，边看边淘，电视淘宝打开全家一起欢乐购物的新世界。家庭娱乐以视频为首，购物、资讯、美食和社交等追随其后。

阿里数娱TV应用商店Top10音乐K歌类排行榜

在家里听歌唱K，足不出户，娱乐全家自带笑果。虾米音乐活跃用户量最高，咪咕爱唱和咪咕音乐同上榜成为客厅KTV最大赢家，而主打好音质的HiFi音乐上线不久也同样得到了用户们的青睐。

阿里数娱TV应用商店Top10教育天地类排行榜

作为TV儿童的最爱，教育天地类应用是客厅的小霸主。贝瓦儿歌、才智小天地分列双榜前二，儿歌、动画和图书成为教育三宝。

阿里数娱TV应用商店Top10游戏排行榜

TV游戏发展至今，热门IP游戏强势占据市场主流，植物大战僵尸、博雅斗地主等拥有最高下载和活跃量毫不意外。

您可能也喜欢的文章：
阿里移动凭大数据进入应用分发领域 PP助手发布2016年“数据+”战略	阿里研究院：2015年中国数据经济发展关键问题探索（附报告g）	酷传：2015年App年度数据报告	软猎：2011年11月中国区苹果应用商店数据报告	2014年Q2小米应用商店分发数据报告
无觅

股市稳赚不亏？标普 500的 40 年的投资回报

Sun, 03 Jul 2016 22:09:31 CST

本文翻译自 GitHub 项目 zonination/investing 的描述文件 README.md。译者对原文顺序有所改动。

原文以 MIT 协议发布，已征得作者 Zoni Nation 许可进行翻译。译文版权归统计之都所有，转载请注明出处。

很多人是从 Reddit 上的 “个人理财”（/r/personalfinance）板块的贴子和评论里认识我的。我最近也经常逛“美丽数据”（/r/dataisbeautiful）板块。（译者注：Reddit 是一个在美国受众广泛的娱乐、社交及新闻网站。它与论坛类似，注册用户可以在网站上发布文字和链接。）

前段时间，我开始了我的第一个数据可视化项目。我先从 Robert Shiller 的标普 500 数据项目中下载了标普 500 的一些数据，开始了疯狂的数据可视化之旅。

最近，我终于把手头上的其他几个项目处理好，安定下来，于是我又回到这些数据上，同时决定用它完成一个完整的可视化项目。

这里引用美联储主席 Alan Greenspan 对股神 Warren Buffet 说过的一段话：

Warren，你让我太震惊了！你只要不去理会股票市场的短期甚至长期的衰退，咬紧牙关，什么也不做，不卖出任何一支股票，你就总能获得好的股票收益。也就是，你只要把你所有的钱都投到股票里，然后回家看也不看它们一眼，之后你获得的收益比每天尝试进行股票交易的情况还要高。

“个人理财”板块上经常有人在讨论长期持仓（buy and hold）策略的资金安全问题，是选择长期持仓，还是选时操作捕捉市场（time the market）。在这个可视化项目中，我尝试做下面三件事情：

客观地回顾标普 500 相关股票的各个切面的长期投资收益（过去和现在）。
验证和量化 “Invest Early and Invest Often” “早投资，勤投资” 这一格言。
观察使用长期持仓策略会带来什么，以及这个策略的收益。

长期持仓收益

长期持仓收益与平均收益

上图由标普 500 的历史收益数据生成。在第一年，我们把标普 500 的每一支股票一年内的收益，加上股息减掉通货膨胀，把计算得到的数值作为第一年的相对收益，并以点的形状绘制到图形中。然后，我们使用同样的方法处理第二年，第三年的数据，依次类推。具体代码见于文末，过程挺无聊的。这个程序可能会花很长一段时间来运行。

简单的说，在上图里，如果你选择投资了 X 年，你将会得到一个基于历史数据的 Y 的收益分布。

我知道了，你一定迫不及待地想问我：“等等！Zoni，这个历史长达 145 年，没有人能够活这么长时间来进行投资啊！！”

我考虑到了，因此让我们来分析一个更为实际的问题，如果你在 20 岁的时候进行投资，在 60 岁的时候退休，也就是投资 40 年的时间，结果会是怎么样的呢？下图就是对应的结果。

等一下！让我们放大来看一下那些亏损的年份。

提醒一下，这些结果是收益的分布。经过 1 年的投资，股票可能涨了也可能跌了。经过 20 年投资，你几乎可以保证不会亏本。经过 40 年的投资，你会获得很大的收益。

那每一个投资时长对应亏损的概率是多少呢？代码在这里，运行代码可以生成下图。

这些结果已经考虑了美国历史上历次最严重的股票崩盘，如大萧条、上世纪 70 年代的衰退、黑色星期一、互联网泡沫、2008 年金融危机等。同时，我们注意到，股票市场都能够在这些危机的一段时间后得到完全的恢复。

下面是一个基于历史数据，使用不同时长的长期持仓策略仍然会亏损的年份。注意到，一些年份覆盖了某个特定的时期。

长期持仓 10 年 (11.8%)：
1908 1909 1910 1911 1912 1929 1930 1936 1937 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1998 1999 2000 2001
长期持仓 15 年 (4.73%)：
1905 1906 1907 1929 1964 1965 1966 1967 1968 1969
长期持仓 20 年 (0.0664%)：
1901
长期持仓 25 年 (0%)：
无

这些分析没有考虑到，一些年份的收益可能刚好到达平均水平，而一些年份收益可能会偏高。

让我们重新绘制之前一个图形，把 Y 轴的范围设置为 0% 到 100%，可以得到下图。

用一句话总结之前的结果，那就是：长期持仓，长期投资，而不是短期，不要选时操作捕捉市场，同时，即使你在市场高位开始投资，在长期里你仍然能够获得不错的收益。

声明

注意到，本项目模拟的股票投资组合是 100% 的美国股票。虽然很多结果显示 100% 的美国股票投资可以获得不错的收益，但是这不是一个理想的投资组合。

一个投资组合需要由一组多样化的美国股票，国际股票和债券构成。这样的多样化的投资策略能够对冲市场动荡，同时帮助投资者获得比本项目更为理想的收益。

同时，这个曲线只关注到了一次投资的一次性远期回报的问题。一个典型的投资者，通常不会选择这种方法作为长期的投资策略，而是选择平均成本投资法，分多期投入资本。（这样的策略会让曲线更为平滑。）

如果你对理财感兴趣，不妨继续阅读“深入阅读”章节的几篇文章。

常见问题

问：为什么不选择平均成本投资法（Dollar Cost Averaging ），而是选择总额投资法（Lump Sum Investing）？

答：

这个问题有点难回答。我把分析的源代码都公开出来了，它们是开源的，你可以按照你想法来修改代码，进行对应的分析。同时，我还想提几点：

在本研究中，把现金乘数（cash multiplier）作为主要的结果，就是使用无量纲的指标作为研究的结果，因此需要确定一个基期的数值。也许选择使用每年购买一份的标普 500 的股票更适合这个无量纲的问题？
数据中提供了通货膨胀的数据，如果你选择使用美元作为单位，你就需要考虑它。例如，怎么样对比 1992年 1 美元和 2002 年的 1 美元的价值呢？
平均成本投资法需要考虑折现的问题，你需要准确地调整现有算法来反应目前使用的总额投资法的投资情况。

我的预测是，使用平均成本投资法将会使图形更加“瘦小”，让更多的数值往平均值压缩。这样会使投资更为安全一些，但是得到较慢的收益增长。

问：这个项目中的资产组合为 100% 股票？那换成债券、国际股票，或者是三者的组合会怎么样？

答：

拥有这些数据是我的梦想。如果有人有类似的国际股票、债券、票据、现金、比特币或者其他类似的数值的数据，请在 Reddit 上私信我。

我希望总有一天我能分析美股、债券、国际股票混合资产的数据。

问：如果股票市场刚好在我退休的时候崩盘了，全世界都穷得响叮当，美元汇率下跌，我该怎么办？

答：

好吧，下面是几个小点子：

你能够假设这个灾难真的发生了，但是你同样可以想象你的假设几乎不可能发生。真正的风险不是基于概率的，而是发生的概率乘以事件的损失程度。
不，这个灾难不是一定会发生的，快干了这碗鸡汤。
没人会建议购买 100% 的美国股票作为退休保障，而更多的是选择债券。
“天快塌了”这类口吻是给会赚钱的标题党用的，跟这些人较真真是没意思。

其他可视化结果

这个图形是一个动画，它展示了投资时长为某一特定年限，随着投资时长的增长，每一年的收益分布的具体变化情况。

让我们逐帧地来看这个图形：

数据来源

Robert Shiller 整理和维护的标普 500 数据

深入阅读

源代码

# 注意：我的代码写得很垃圾，你将就着看吧

# 设置工作目录，引入对应 R 包
setwd("~/Dropbox/R/Stock Market")
library(ggplot2)
library(scales)
library(lubridate)
source("z_theme.r")

# 数据源：
# 我强烈建议使用下面的链接来获得最新的数据。
# "https://raw.githubusercontent.com/datasets/s-and-p-500/master/data/data.csv"

sp500<-read.csv("stocks.csv", stringsAsFactors=FALSE)

# 如果你使用的数据是自行从数据源下载的，请注释掉下面这一行代码，同时取消注释下方的“主循环”代码。
stocks<-read.csv("returns.csv", stringsAsFactors=FALSE)

# 处理日期:
# 格式化日期，让 R 能够识别它们.
sp500$Date<-as.Date(sp500$Date,"%Y-%m-%d") 

# 标普 500 始于 1923 年， 其他历史数据来自于 Shiller. 如果你只想要“真实”的标普 500 历史数据，请取消下面一行代码的注释。
# sp500<-subset(sp500,sp500$Date >= as.Date("1926-01-01","%Y-%m-%d"))

# 计算实际收益 (所有股息都被重新投资)
sp500$real.return <- 1 # 最开始，在股票市场中投资一元
for(r in 2:nrow(sp500)){
  sp500$real.return[r]<-
    # 前一期的价格
    sp500$real.return[r-1]*
    # 乘以上一个月价格的百分比
    (((sp500$Real.Price[r]-sp500$Real.Price[r-1])/
        (sp500$Real.Price[r-1]))+1)+
    # 最后加上上一个月的股息，它们被全部重新投资
    (sp500$Real.Dividend[r-1]/sp500$Real.Price[r-1])*
    (sp500$real.return[r-1]/12)
}

# 主循环 - 计算收入数据集
# 如果使用的数据是自己从数据源下载的，请取消注释下面的代码
# 警告：下面的代码会运行较长时间。
###############
# stocks<-data.frame(NA,NA,NA,NA)
# names(stocks)<-c("year","real","percent","inv.year")
# for(f in 1:145){
#   sp500$future.f<-NA    #远期标普 500 价格
#   sp500$cpi.f <- NA     #远期 CPI
#   sp500$future.r <- NA  #远期实际收益
#   for(n in (f*12+1):nrow(sp500)){
#     # 计算 f 年的远期价格
#     sp500$future.f[n-f*12] <- sp500$SP500[n]                      # 远期标普 500 价格
#     sp500$cpi.f[n-f*12] <- sp500$Consumer.Price.Index[n]          # 远期 CPI
#     sp500$future.r[n-f*12] <- sp500$real.return[n]                # 远期实际收益
#     stocks<-rbind(stocks,c(f,sp500$future.r[n-f*12],                   # 记录所有数据
#                   (sp500$future.r[n-f*12]-sp500$real.return[n-f*12]) /
#                     sp500$real.return[n-f*12],
#                   year(sp500$Date[n-f*12])
#                   ))
#   }
#   print(paste(f, " of ", 145, " completed: ", round(f/145*100,2),"%",sep=""))

# 使用现金乘数:
stocks$multip<-stocks$percent+1
# write.table(stocks,"returns.csv") # 保存收益数据集

# 绘制图形
ggplot(subset(stocks,year<=40&inv.year>=1957),aes(x=year,y=multip,group=year),na.rm=T)+
# geom_boxplot(outlier.shape=NA,coef=0,fatten=0,fill="steelblue",color=NA)+
  geom_jitter(color="limegreen",alpha=.05,width=1)+
  ggtitle("Returns After Investing")+
  stat_summary(fun.y="mean",colour="black",fill="limegreen",geom="point",shape=21)+
  ylab("Cash Multiplier (After Inflation and Dividends)")+
  xlab("Years Invested in US Stocks (Buy and Hold)")+
  scale_y_log10(breaks=2^c(-3:15),
                # 转化为文本，以美化图形输出结果
                labels=as.character(2^c(-3:15)))+
  scale_x_continuous(breaks=seq(0,200,5))+
  geom_smooth()+
z_theme()

您可能也喜欢：
利用shiny包快速搭建可视化原型系统	Editor: 一行R代码来实现繁琐的可视化 \| 统计之都 (中国统计学门户网站，免费统计学服务平台)	一行R代码来实现繁琐的可视化	粉丝地图的可视化	使用ggtree实现进化树的可视化和注释
无觅

浅谈移动应用的技术选型

Tue, 11 Oct 2016 12:05:21 CST

在这个巨变的时代，技术选型是个很难做决定的事情，而移动应用技术领域在几个巨头（Google，Facebook，Apple etc.）的带动下更是日新月异。所以说要选择一个适合业务需求并且匹配开发人员能力的技术方案并不是一件简单的事情。我也只是在移动开发上做过一点微小的工作，此处仅能抛个砖，希望各位有玉的大神尽管砸过来。

做移动应用开发，说起来技术方案不外乎HTML5（没错，做Mobile Web其实也算是一种移动应用）、Native（在Android上不管是用Java、Kotlin还是Scala，iOS上不管是用Objective-C还是Swift）和使用原生UI，用JavaScript来实现逻辑的诸如React Native一类的方案。除此之外，还有结合HTML5和Native的Hybird混合方案。不同的技术方案有着不同的适应场景，至于具体如何选择，接下来我简单地谈谈自己的理解。

1、HTML5

也就是Web App的方案。这种方案最大的优点在于“Write Once, Run Everywhere”，不管你是Android还是iOS，都可以用一套代码搞定，在国内的话还能对接微信公众号，给用户提供一个方便快捷的入口，并且还有版本升级容易的优势（毕竟服务器是受自己控制的）。但是这种方案的缺点也很明显——无法使用系统级API，只能做为一个临时的入口，用户很难留存，并且因为浏览器性能的原因，很难带来很好的用户体验。

所以说Web App的主要适用场景还是在于作为对非核心业务在移动端的入口补足，或者是作为用户轻量、低频使用的体验增强。

美团移动网站引导页

美团移动网站首页

美团的移动网页就是很典型的例子，主要还是提供给不经常使用的用户一个入口，网站内部还是在尽量引导用户下载使用客户端。

2、Hybird

Hybird是一种兼顾Native与HTML的开发模式，但根据实现的不同，还可以再细分为两种实现方案：

在Native App中使用WebView加载远端Web资源
使用Cordova/PhoneGap等框架通过WebView加载本地资源进行页面渲染

第一种方案其实已经应用得非常普遍了，很多应用的展示页面都是通过这种方式实现的。因为展示页面需要的正是能够轻易更换内容及布局的格式，并且这种纯展示的页面也并不需要复杂的动画与特效，使用Web页面是一个非常合适的解决方案。

而第二种方案前一段时间非常火，因为它在跨平台，在高效开发以及快速发布上有着明显的优势，毕竟Web内容只需要开发一次就可以在各个平台使用。而且将资源打包到本地也可以在一定程度上缓解从远端加载静态资源导致UI展示延迟的问题，并且还可以通过桥接Native和Web来调用一些Device的API。但其劣势也很明显，一是通过WebView执行代码效率较低，很难实现一些炫酷的效果，并且还存在不同设备的兼容性问题；二是如果想调用相关平台的API，需要针对平台单独进行开发，如果在应用中用到了大量的Device API，那么开发的效率将大大降低；三是很难应用到平台相关的新特性，比较难做出有特色的产品。

使用HTML页面来实现纯展示页面是非常推荐的一种方案。而Cordova/PhoneGap则更适用于对Mobile预算有限的公司、创业团队，或者对App进行快速的上线验证。

正好之前有个项目就用到了这种方案，为一家业务转型的零售商提供了使用一套基本代码来完成Android和iOS两个平台的App和微信公众号的相关页面的技术方案。

零售商Android应用零售商微信端

3、React Native

把React Native单独拿出来，是因为确实不能简单的将它分到其它任意一种方案里面去。React Native确实是最近最火的跨平台App解决方案了。它脱胎于React，因为React基于Virtual DOM来进行界面渲染，所以用Native的View来替换掉原本React的HTML DOM就顺理成章的引出了React Native的概念。

它与之前的跨平台方案有一个本质的区别，在于：其它方案都在追求写一次code解决所有平台的问题，而React Native的理念在于“Learn Once, Write Anywhere”。虽然大部分代码是平台无关的，但是平台相关的代码都需要单独实现，这虽然对跨平台带来了不便，但是引入的好处也是显而易见的，View层的部分通过原生组件实现，性能比其他WebView的方案不知道高到哪去了。而且React Native整套的逻辑代码都通过JavaScript实现，这样就让跨平台应用能够方便的复用逻辑代码。另外虽然React Native没有支持使用CSS来实现样式，但是提供了类似CSS的样式表支持，有过UI开发经验的人都能够非常快的上手。由于前端React也是非常的火，很多React社区的很多产出都可以在React Native上借鉴使用。

React Native对于没有复杂动画效果的一般应用来说不失为一个很好的解决方案。而且对于一些小型的企业级应用也是非常适用的。但是，React Native对于Android平台的支持度是不如iOS平台的，而且现有的非常成熟的应用也较少，所以说如果要在一些面向用户量很大，讲求用户体验的App中使用还是要慎重考虑的。

但是，其实Facebook已经在自家的App上用起来了，而且实测效果还是很好的。不过呢，人家毕竟是自家维护的，所以说真正要在项目上用可能还是得试了才知道效果。

facebook Androidfacebook iOS

4、原生应用

原生应用的开发真的是让人又爱又恨。爱在于你可以在它上面施展拳脚、使用新特性、实现炫酷的效果。而恨则在于它跨平台性几乎为零，除了资源外几乎没有可重用的东西，即使是相似架构上的逻辑你也得再实现一遍。使用原生开发，能够方便地添加动画效果，调用底层硬件，所有的限制仅仅是来自平台的限制。但是正常情况下需要对不同的平台搭配不同的开发人员，而且如果要追求良好的用户体验，整个应用的设计还得满足相应平台的设计规范，这不仅是对Dev的考验，也是对UX的考验。不过如果真的对App的质量有很高的要求，我觉得这一切的付出也还是都是值得的。

如果针对的是要求硬件性能、讲究动画效果、追求用户体验的应用，还是建议分平台单独设计，并且都使用原生的技术方案来实现。其实这也是目前市面上大部分企业做出的选择。

使用原生开发我个人还有一个观点，就是 设计上要尽量遵守原生应用的设计规范，如果想要一套设计通吃所有平台，最终只会搞一个不伦不类的应用出来。知乎算是国内在这方面做得比较好的应用了，也取得了不错的效果。

知乎

其实，在真正启动项目之前，在进行技术选型时，除了要考虑更符合业务的架构外，还要考虑开发人员的能力及技术栈。毕竟最后App还是由Dev们开发的。如果仅仅考虑业务而不考虑开发人员的技术能力来选择技术方案，不仅有一种钦定的感觉，而且最后往往坑到的还是自己。

我们常说：工具是死的，人是活的。考虑多种因素，在技术选型上做出更充分的考量，才是真正正确的选择。所以说又回到那句老话上：“It depends…”

浅谈移动应用的技术选型，首发于文章 - 伯乐在线。

2015年度中国大数据最具创新场景应用服务提供商排行榜

Tue, 19 Jan 2016 13:17:58 CST

伴随着互联网的深度发展，巨大的信息流背后产生的海量数据成为一块蕴含财富的宝藏。数据之所以成为新商业经济社会的必争之物，在于它实际场景中的应用价值。数据只有被应用到具体的商业场景和产业生产中才具有价值和意义，企业之所以将建立的交易数据库、客户数据库等视为企业核心竞争力，是因为得数据者得用户、得用户者得天下。企业之间的激烈竞争是商业社会优胜劣汰的必经之路，如何利用好数据，将之转化为有价值的数据财富应用到产业化场景中，是当下企业建立竞争壁垒的首要问题。

以下是互联网周刊发布的《2015年度 中国大数据最具创新场景应用服务提供商》，该榜单整理的是国内最具创新能力的大数据应用服务型企业，从四个维度：技术能力，服务能力，发展潜力以及市场影响力对创新能力进行了综合评分。当然，该排名并不能保证百分百的全面与精准，该榜单梳理的目的主要是帮助大数据生态产业链条上的各家公司更好的发展，以及大数据所服务的客户更加了解大数据。

大数据赋予精准营销能量无穷大

每一次营销，都将形成循环效果。通过定位用户群、分析用户内容偏好、分析用户行为偏好、建立受众分群模型、制定渠道和创意策略、试投放并收集数据、优化确定渠道和创意、正式投放并收集数据、实时调整投放策略、完成投放评估效果等，完整的数据应用过程不断把控营销质量与效果，实现从效果监测转向效果预测。

借助大数据及相关技术，我们可针对不同行为特征的客户进行针对性营销，甚至能从将一个产品推荐给一些合适的客户到将一些合适的产品推荐给一个客户，得以更聚焦客户，进行个性化精准营销。国内在用大数据做精准营销方面最具创新性的企业有集奥聚合，品友互动，百分点，亿赞普，晶赞科技等。

还有，电商是最早利用大数据进行精准营销的行业，除了精准营销，电商可以依据客户消费习惯来提前为客户备货，并利用便利店作为货物中转点，在客户下单15分钟内将货物送上门，提高客户体验。马云的菜鸟网络宣称的24小时完成在中国境内的送货，以及京东刘强东宣传未来京东将在15分钟完成送货上门都是基于客户消费习惯的大数据分析和预测。

电商可以利用其交易数据和现金流数据，为其生态圈内的商户提供基于现金流的小额贷款，电商业也可以将此数据提供给银行，同银行合作为中小企业提供信贷支持。由于电商的数据较为集中，数据量足够大，数据种类较多，因此未来电商数据应用将会有更多的想象空间，包括预测流行趋势，消费趋势、地域消费特点、客户消费习惯、各种消费行为的相关度、消费热点、影响消费的重要因素等。依托 大数据分析，电商的消费报告将有利于品牌公司产品设计，生产企业的库存管理和计划生产，物流企业的资源配制，生产资料提供方产能安排等等，有利于精细化社会化大生产，有利于精细化社会的出现。

大数据更懂交通出行

最近两年，智能手机中的公众交通出行应用软件开始得到发展，大数据不仅会便利在线打车企业，还可以为智慧城市的规划带来积极影响。根据大数据反映的城市各路段拥堵情况、出租车行驶路线的分布等情况，城市管理部门可以更合理地规划城市道路和交通管理方案。

值得注意的是，虽然打车软件企业都在挖掘大数据的价值，但这一市场也在呈现差异化的特点。例如，目前优步青睐派单制，而滴滴快的则大力推广抢单制。究竟哪种方式更适应用户需求，或许还需市场检验。

从整体上看，今年随着打车软件新的解决方案的集中推出，基于大数据的应用也不断增长。可以预见的是，今后围绕着出行大数据的创新和市场竞争的增强，公众出行也会获得更多丰富的选择和便利。

大 数据安全 问题刻不容缓

随着大数据时代的到来，数据的收集和存储更加方便，同时跨境流动更加频繁，安全问题愈发凸显。我国在发展大数据产业的过程中，部分企业收集用户数据的使用权限边界界定不清，用户隐私和权益遭受侵害，一些重要数据被非法倒卖、流向他国，安全威胁已经从个人层面上升至国家安全层面，亟须引起重视。在大数据面前，既要贴心的服务又要保护隐私，这是一个两难的境地。

在传统的PC互联网时代，电脑连接还有明显的边界，需通过线缆连接，这时的安全问题可以靠防病毒、查杀流氓软件、防火墙等进行防御；但进入到互联网新阶段，特别是移动互联网时代，手机等终端打破了对网络边界的定义，手机和个人隐私信息联系在一起，安全问题变得更加严重。

目前用户数据的收集、存储、管理与使用等均缺乏规范，更缺乏监管，主要依靠企业自律，用户无法确定自己隐私信息的用途。而且国内大数据的安全应用仍多停留于想法，仍需进一步探究如何落地。大数据首先应建设一套规范且灵活的建设标准与运行机制，规范化建设可以促进大数据管理过程的正规有序，实现各级各类信息系统的网络互联、数据集成、资源共享，在统一的安全规范框架下运行。

大数据技术的发展带来企业经营决策模式的转变，驱动着行业变革，衍生出新的商机和发展契机。驾驭大数据的能力已被证实为领军企业的核心竞争力，这种能力能够帮助企业打破数据边界，绘制企业运营全景视图，做出最优的商业决策和发展战略。其实，不论是哪个行业的大数据分析和应用场景，可以看到一个典型的特点还是无法离开以人为中心所产生的各种用户行为数据，用户业务活动和交易记录，用户社交数据，这些核心数据的相关性再加上可感知设备的智能数据采集就构成一个完整的大数据生态环境。

目前大部分企业面临的挑战不是缺少数据，而是数据太多。通过新型技术，大数据价值可能被充分地挖掘和利用。大数据要发挥价值，必须与业务融合，能够带来实际业务收益。大数据的应用模式仍处于探索阶段。

您可能也喜欢的文章：
数据客：中国大数据2015大事记	艾瑞咨询：2014年12月热门网络服务数据排行榜Top10	中国移动社交服务综合实力排行榜——信息图	App Annie：2014年7月中国iOS发行商和应用排行榜	2012年第18周中国Android应用下载排行榜
无觅

中文文本处理简要介绍

Thu, 07 Jan 2016 03:50:18 CST

本文作者李绳，博客地址 http://acepor.github.io/。作者自述：

一位文科生曾励志成为语言学家
出国后阴差阳错成了博士候选人
三年后交完论文对学术彻底失望
回国后误打误撞成了数据科学家

作为一个处理自然语言数据的团队，我们在日常工作中要用到不同的工具来预处理中文文本，比如 Jieba 和 Stanford NLP software。出于准确性和效率的考虑，我们选择了Stanford NLP software，所以本文将介绍基于 Stanford NLP software 的中文文本预处理流程。

中文文本处理简要介绍

与拉丁语系的文本不同，中文并不使用空格作为词语间的分隔符。比如当我们说“We love coding.”，这句英文使用了两个空格来分割三个英文词汇；如果用中文做同样的表述，就是“我们爱写代码。”，其中不包含任何空格。因而，处理中文数据时，我们需要进行分词，而这恰恰时中文自然语言处理的一大难点。

下文将介绍中文文本预处理的几个主要步骤：

中文分词
标注词性
生成词向量
生成中文依存语法树

Stanford NLP software 简要介绍

Stanford NLP software 是一个较大的工具合集：包括 Stanford POS tagger 等组件，也有一个包含所有组件的合集 Stanford CoreNLP。各个组件是由不同的开发者开发的，所以每一个工具都有自己的语法。当我们研究这些组件的文档时，遇到了不少问题。下文记录这些问题和相对应的对策，以免重蹈覆辙。

Stanford NLP 小组提供了一个简明的FAQ—— Stanford Parser FAQ 和一份详细的Java文档 —— Stanford JavaNLP API Documentation。在这两份文档中，有几点格外重要：

尽管PSFG分词器小且快，Factored分词器更适用于中文，所以我们推荐使用后者。

中文分词器默认使用GB18030编码（Penn Chinese Treebank的默认编码）。

使用 -encoding 选项可以指定编码，比如 UTF-8，Big-5 或者 GB18030。

中文预处理的主要步骤

1. 中文分词

诚如上面所言，分词是中文自然语言处理的一大难题。 Stanford Word Segmenter 是专门用来处理这一问题的工具。FAQ请参见 Stanford Segmenter FAQ。具体用法如下：

  bash -x segment.sh ctb INPUT_FILE UTF-8 0

其中 ctb 是词库选项，即 Chinese tree bank，也可选用 pku，即 Peking University。 UTF-8是输入文本的编码，这个工具也支持 GB18030 编码。最后的0指定 n-best list 的大小，0表示只要最优结果。

2. 中文词性标注

词性标注是中文处理的另一大难题。我们曾经使用过 Jieba 来解决这个问题，但效果不尽理想。Jieba 是基于词典规则来标注词性的，所以任意一个词在 Jieba 里有且只有一个词性。如果一个词有一个以上的词性，那么它的标签就变成了一个集合。比如“阅读”既可以表示动词，也可以理解为名词，Jieba 就会把它标注成 n（名词），而不是根据具体语境来给出合适的 v（动词）或 n（名词）的标签。这样一来，标注的效果就大打折扣。幸好 Stanford POS Tagger 提供了一个根据语境标注词性的方法。具体用法如下：

  java -mx3000m -cp "./*" edu.stanford.nlp.tagger.maxent.MaxentTagger -model models/chinese-distsim.tagger -textFile INPUT_FILE

-mx3000m 指定内存大小，可以根据自己的机器配置选择。 edu.stanford.nlp.tagger.maxent.MaxentTagger 用于选择标注器，这里选用的是一个基于最大熵（Max Entropy）的标注器。 models/chinese-distsim.tagger 用于选择分词模型。

3. 生成词向量

深度学习是目前机器学习领域中最热门的一个分支。而生成一个优质的词向量是利用深度学习处理 NLP 问题的一个先决条件。除了 Google 的 Word2vec，Stanford NLP 小组提供了另外一个选项—— GLOVE。

使用Glove也比较简单，下载并解压之后，只要对里面的 demo.sh 脚本进行相应修改，然后执行这个脚本即可。

CORPUS=text8                                    # 设置输入文件路径
VOCAB_FILE=vocab.txt                            # 设置输入词汇路径
COOCCURRENCE_FILE=cooccurrence.bin              
COOCCURRENCE_SHUF_FILE=cooccurrence.shuf.bin
BUILDDIR=build
SAVE_FILE=vectors                               # 设置输入文件路径
VERBOSE=2           
MEMORY=4.0                                      # 设置内存大小
VOCAB_MIN_COUNT=5                               # 设置词汇的最小频率
VECTOR_SIZE=50                                  # 设置矩阵维度
MAX_ITER=15                                     # 设置迭代次数
WINDOW_SIZE=15                                  # 设置词向量的窗口大小
BINARY=2
NUM_THREADS=8
X_MAX=10

4. 生成中文依存语法树

文本处理有时需要比词性更丰富的信息，比如句法信息，Stanford NLP 小组提供了两篇论文： The Stanford Parser: A statistical parser 和 Neural Network Dependency Parser，并在这两篇论文的基础上开发了两个工具，可惜效果都不太理想。前者的处理格式是正确的中文依存语法格式，但是速度极慢（差不多一秒一句）；而后者虽然处理速度较快，但生成的格式和论文 Discriminative reordering with Chinese grammatical relations features – acepor中的完全不一样。我们尝试了邮件联系论文作者和工具作者，并且在 Stackoverflow 上提问，但这个问题似乎无解。

尽管如此，我们还是把两个方案都记录在此：

  java -cp "*:." -Xmx4g edu.stanford.nlp.pipeline.StanfordCoreNLP -file INPUT_FILE -props StanfordCoreNLP-chinese.properties -outputFormat text -parse.originalDependencies

  java -cp "./*" edu.stanford.nlp.parser.nndep.DependencyParser -props nndep.props -textFile INPUT_FILE -outFile OUTPUT_FILE

结论

预处理中文文本并非易事，Stanford NLP 小组对此作出了极大的贡献。我们的工作因而受益良多，所以我们非常感谢他们的努力。当然我们也期待 Stanford NLP software 能更上一层楼。

本文原载于 https://acepor.github.io/2015/12/17/General-Pipelines/。

您可能也喜欢：
LDA-math-文本建模	LDA-math-LDA 文本建模	上海R用户沙龙会议纪要（Jan 20, 2013 @联合创业办公社）	十八般武艺，谁主天下？	COS沙龙第30期（北京）纪要
无觅

Java 应用发布后，需要关注的7个性能指标

Wed, 16 Dec 2015 19:49:38 CST

在某个重大发布之后，都需要记录相应的指标，本文介绍了最重要的几个 Java 性能指标，包括响应时间和平均负载等。为理解应用程序在生产环境中如何运行，就需要遵循一些 Java 性能指标。

在以前，当软件被发布后，开发者是没有方法去了解它在生产环境中的运行情况；而现在，几乎任一个你可以想到的指标都可以被监测和报告。时下，开发者面临的问题并不是缺乏信息，而是信息过载、过大。因此在数百台服务器同时工作的情景下，跟踪记录信息就变得越来越困难，虽然多数开发者为了深刻理解产品系统仍旧需要利用日志文件，但依然阻挡不了它们逐步被取代的命运。

本文整理了一些重要的指标，使开发者在不借助任何日志文件的情况下，便于理解应用程序在生产环境中运行的具体过程。谈到对 Java 性能的影响，除了像用户负载（或者 AWS 云服务器停机）这样的外部因素，新功能发布可能是最常见的诱因。所以在那些新功能发布之后的敏感时段，遵循相应准则变得更为关键。

数字至上

在逐个讨论指标之前，先来强调一个重要问题。有这样一个观点：如果某个观点可以得到数字支持，那么它一定是毋庸置疑的。但是这里存在的问题是，当给你呈现时，很多因素会歪曲你对数据的理解。这么说可能有点抽象，这里可以对比这两个测量用例：首先，在一个简单的时间序列中，观察某一个特定基本指标如何随着时间推移而变化；其次，从不同的角度观察数据，并保存关注的性能百分比，底线就是一定要关心留意的那个指标所产生的影响，并给以完整性检查以便对其评估。

例如，假设我们正在观察中值/50百分点处的事务响应时间，因为该点的响应时间已被广泛用作指示符，很多公司将其作为主要KPI之一。在实际中，若单个页面浏览人数达到几十及以上（一般远远超过40），就意味着该用户有99.999...%的可能会经受比中值更差的结果（数学公式可简单的表示为：1 –（0.5 ^ 40）。因此什么百分点更有意义呢？即使观察点设在第95的百分点，然后你的单页面浏览人数远大于40，那么大部分的用户仍会经受比之前更糟糕的响应时间。若符合多个页面浏览量，事情会更加复杂。想阅读更多关于百分点的知识，了解其对数据的误导，可点击此处进入Gil Tene 的博客。

家下来我们来仔细解读指标的选择，看看它们各自代表什么，并学习如何来理解这些指标。

1. 响应时间与吞吐量

响应时间用来衡量应用程序中的事务处理速度，它也可以从 HTTP 请求层和数据库层来观察。有些最慢的查询需要最优化解决，而响应时间可以缩小该查询的范围。吞吐量从另一个角度观察处理过程，并显示应用程序在给定时间域中处理多少请求，通常单位为每分钟（cpm）。

测量响应时间的方法之一就是使用像 New Relic 或者 AppDynamics（就是曾在以前的博客讨论的）那种 APM（应用性能监控工具），通过这些工具，可以追踪平均响应时间，并可以直接在主报告仪表板上与昨日或者上周的平均响应时间作比较，这些比较有助于查看新的部署如何对应用程序造成了影响。另一种方法是通过测量网页处理的百分位数，来测量 HTTP 请求完成响应所需的时间。

也可以内部监测响应时间，但是需要硬代码，例如通过 Dropwizard 指标发送数据并在 Graphite 上发布。尽管看来将这些数据和其他标准关联时会出现最有用的见解，但更多的见解仍涵盖在接下来的方法中。

要点1: 确保所使用的采集方法可以实现从不同角度观测数据，并开始进入百分位层面。

可行工具：

图为 OneAPM 上监控到的 Java 应用程序响应时间和吞吐量

2. 平均负载

第二个广泛使用的衡量指标就是服务器的平均负载。平均负载习惯上分成3部分，在最后的1、5和15分钟（从左到右）显示其结果。只要分数低于机器内核的数量，就是无压力状态，一旦超过内核数，就意味着机器处于压力状态。

平均负载除了可以简单测量 CPU 利用率，更着重于考量每个内核目前在队列中有多少进程。某内核利用率达100%，但是却即将结束任务，而另一内核在队列中还有6个进程要处理，这两种情况是截然不同的。CPU 这一概念并没有涵盖其区别，但是平均负载却可以从大局中考虑此问题。

若在 linux 系统上跟踪平均负载情况，一个极好的方式就是通过 Hisham Muhammad 利用 htop 完成。丰富的色彩加上生动的视觉化效果，瞬间使得命令行有了 NASA 仪表板的即视感。

要点2： 要确定负载，仅靠资源利用率是不够的，还需要格外注意以便充分了解队列中的进程。

可行工具:

htop

图为在一台服务器上运行 htop 以检测负载，平均负载显示在界面的右上角。

3. 错误率（及如处理）

错误率观测有多种方法，而多数开发人员都利用高层次标准——在整个应用层考察错误率，比如在所有 HTTP 请求中考察失败的 HTTP 处理总数。但是还有一个经常被忽视的具体点：特定事务的错误，这与应用程序的运行状况有直接的影响。代码中某一特定方法失败、生成日志错误及发生异常的次数占总调用次数的比重，也要予以显示。

图为 OneAPM 对事务中的错误率监控，随时间监控应用错误率情况。

但是这些数据对其本身并没有太大的意义。第一步，从正在处理的事件中优选出最紧急的一件，找到日志错误或异常；第二步，从实际根源处着手，并予以修复。而且基于此问题，已有相应的解决办法。有了 OneAPM ，就没有必要根据日志文件去找错误提示，因为关于服务器状态的所有信息都会在同一界面显示，包括堆栈踪迹、实源代码、变量值及每个错误调用的应用实例。

要点3： 要解决错误率增长的根本原因，仅靠日志文件是不够的，为了得到大量关于我们所需指标的数据，还需要利用一些错误率监控工具。

4. GC率和中止时间

垃圾回收器行为异常，是导致应用吞吐量和响应时间突然下降的主要原因之一。读者想要了解关于垃圾回收过程的更多知识和相关的标准，可阅读深入理解Java虚拟机（第2版）。

分析 GC 日志文件是理解 GC 中止时间和频率的关键。如果不自行分析，或者使用类似于 jClarity 的工具，这种指标是没有办法直接使用的。所以要确保使用合适的 JVM 参数打开 GC 日志采集，以便分析。

要点4： 请记住，分析不同指标的相关数据，要保持开阔的思维，这样容易发现它们之间的互相影响。

可行工具:

5. 业务指标

应用的性能不是仅仅依赖于快速响应，也非错误率，另一个方面就是业务指标。其业务责任也不是只由产品/销售人员全权负责。收入、用户数、与应用中特定区域的互动等，这些都对理解软件的运行极为关键。若要从业务角度观察，你所配置的修复方法和新功能是如何影响底线的，以上因素与新部署的时间标记一起作用这一点至关重要。我们固然希望情况向好的方向发展，但假如事态恶化，一旦你把所有数据都存在同一位置，要想知道哪里出了问题需要修复，这就相当容易了。

此外，将业务指标与错误率、延时等数据实时连接起来，这种能力是极有力度的。然后会让人不由自主地深入研讨到底是什么错误或异常造成了这次最主要的问题，接着就可以按照对业务目的影响优先考虑它们。想要搞清楚遍布各处的所有异常及日志错误，就得使用集成开放的监测工具。所以，保持数据开放，使其可以输出到选择服务中，这是极其重要的。

假如你要利用 Graphite 将汇报的业务指标集中化，这就要求你所使用的工具对发送数据开放。例如，我们的工程组就将汇报指标通过 StatsD 发布出来，因此相应数据就可以指向任一用户选择使用的仪表板上。

要点5： 先入先出式数据已是过去式，在使用指标时，也需要让它们和其他来源的数据相关联。

可行工具:

6.正常运行时间和服务运行状况

该指标为整体的工作定下基调。除用作警示媒介外，它还可用于在一段时间内自定义 SLA，以便观察当为用户提供功能完备的服务时所用时间的百分比。

我们通过运行使用 servlet 的 Pingdom 来解决这个问题，它会对所有应用程序事务中参与的服务进行检查，包括数据库和 S3 等。

要点6： 正常运行时可能是二进制指标，但是通过聚合多个值的方式在堆栈中定位薄弱点。

可行工具:

Pingdom

图为用 Pingdom 监测正常运行时和应用运行状况。

7.日志规模

以上讨论到的指标除了 GC 都没有提到日志，但这个仍然不可忽略。日志文件的副作用就是它们一直在增长，如果不留意其大小以及抑制，那么后果不堪设想。当日志不受控制，磁盘驱动器很可能被撑爆，服务器中会充斥着垃圾文件，运行缓慢，因此，一定要密切关注日志规模，否则随时会崩溃。

一个广泛使用的解决办法就是，使用 logstash 等将服务器上的日志分块，再将其送入Splunk、ELK 等其他日志管理工具中存储，或者直接简单地存入 S3。另一种方法就是在某一时间将日志文件翻转再截断，但此法要冒信息丢失的风险。和大部分开发人员一样，目前我们还必须依赖于日志。

要点7： 日志会给人带来很大的困扰，尤其是当你用某些外部服务来处理日志时，你会被 GB 指控。这时就要重新考虑一下这个问题，还应该开始降低日志大小。

最后的思考

我们可以看到这一趋势：目前在产品中，应用里的数据采集器正逐渐脱离对日志文件的依赖。软件分析的新世界越来越开放，数据更加智能化，已不再是以前枯燥的数字，而是带有丰富的情境。我们很兴奋地看着世界的改变，并期待和你们一起共建崭新的未来。

原文地址： https://dzone.com/articles/7-java-performance-metrics-to-watch-after-a-major-1

通过客户端软件访问Gmail的方法

Sun, 20 Dec 2015 23:14:28 CST

　　Gmail对于很多中国用户来说是很难舍弃的服务，现在虽然Gmail所有客户端通讯协议（IMAP、POP3、SMTP等）端口均被屏蔽，导致用户无法正常访问Gmail邮箱，不过，通过一些设置，我们依旧可以通过客户端软件来访问Gmail服务。

　　首先，需要在Gmail里设置其支持IMAP，这样才能在客户端里使用IMAP来访问Gmail。设置方法是：登录 Gmail，点击右上方的齿轮图标，然后选择设置，点击转发和 POP/IMAP，选择启用 IMAP，点击保存更改。

　　 电脑客户端软件

　　电脑客户端我推荐使用Microsoft Outlook，其他客户端建议优先用国外的软件如Windows Mail、Thunderbird等。

　　首先修改一下电脑的Hosts文件，在Windows系统里，打开C:\WINDOWS\system32\drivers\etc\hosts文件，在末尾添加如下内容，然后重启电脑即可，腾讯管家、360卫士、金山卫士可能会提示病毒或非法修改系统，请不必理会，并将Hosts文件加入白名单。

173.194.192.109 imap.gmail.com
173.194.192.109 pop.gmail.com
173.194.193.108 smtp.gmail.com

　　接下来需要在Outlook里配置客户端。打开 Outlook，在“账户信息”界面里点“添加账户”，然后选择“电子邮件帐户”，然后选择“手动配置服务器设置或其他服务器类型”-“Internet电子邮件”，之后添加IMAP服务器，填写的内容如下：

　　接收邮件 (IMAP) 服务器 - 要求 SSL

　　imap.gmail.com

　　端口：993

　　要求 SSL：是

　　发送邮件 (SMTP) 服务器 - 要求 TLS

　　smtp.gmail.com

　　端口：465 或 587

　　要求 SSL：是

　　要求身份验证：是

　　使用相同的设置作为接收邮件服务器

　　完整姓名或显示姓名：[用户的姓名]

　　帐户名称或用户名称：用户的完整 Gmail 地址 (username@gmail.com)。

　　电子邮件地址：用户的完整 Gmail 地址 (username@gmail.com)。

　　密码：用户的 Gmail 密码，如果 Gmail 设置了两步验证，则为新增应用的密码。

　　设置好了以后，用户即可通过Outllook来访问Gmail服务。

　　 iPhone/Android手机端设置

　　手机端访问Gmail的方法，和使用电脑客户端的方法基本一样，也是使用IMAP协议来访问，不过不同的是，未越狱的iPhone是无法修改Hosts文件，因此填写IMAP服务器和SMTP服务器的时候，不能填写上面的域名地址，而需要直接填写IP地址才行。

　　在iPhone里的设置方法是，新建一个邮件帐号，邮件类型选择“其他”，设置里选用IMAP的方式，在输入IMAP地址的时候写IP地址，不要写域名，IP地址就是上面Hosts里的IP地址，用户名为Gmail地址，密码为Gmail密码，SMTP设置如出现提示信息，点详细信息，信任该IP，之后即可在手机上继续使用Gmail。

　　此外，在iPhone客户端里，还可以设置一下Gmail邮件的归档，邮件设置“账户”高级里，存档邮件修改为Gmail所有邮件，将丢弃邮件转移到归档邮件，即可在手机上方便使用Gmail的邮件归档功能。

　　最后，如果上述Google的IP地址未来无法访问了，最新的IP地址获取方法如下：添加微信公众号 williamlonginfo ，然后发送关键字google，即可获得最新的IP和设置方法。发送关键字gmail，可获得Gmail的最新IP和设置方法。

评论《通过客户端软件访问Gmail的方法》的内容...

微博：新浪微博 - 微信公众号：williamlonginfo
月光博客投稿信箱：williamlong.info(at)gmail.com
Created by William Long www.williamlong.info

广电行业 | 大数据在用户流量分析中的应用 2015年上半年电视互动业务分析

Mon, 21 Dec 2015 00:45:51 CST

199IT数据中心微信账户：i199IT

大数据是什么？如何出现和应用在人们的生活中？我们可以先来设想一个生活场景：当你早上醒来打开电视，遥控器已经自动更换到你以往关注的财经频道；当你准备开车去上班，导航仪已经按照目前的路况规划了你的上班路线，及时避开了拥堵路段；在你上班的时候，手机提醒你快到结婚纪念日了，同时用你的消费喜好数据为你推荐了几款礼物以作备选；当你结束一天的工作回到家中，电视已经根据你的内容喜好为你推荐好了频道和节目，这就是大数据应用。

最近一项研究表明，采用大数据的公司比不采用大数据的公司利润平均高6个百分点。6个百分点也许不那么起眼，但在激烈的市场竞争中，这是可以让企业生存下来、脱颖而出的资本。过去几年，无论是医疗、健康、交通、公共安全，还是生活、购物、旅游、娱乐，都已经逐渐建立起大数据分析系统。大数据的应用也从早期的数据密集型行业（例如电信、金融、能源、科研、互联网），逐步向非数据密集型行业扩张。

近年来，广电行业也开始注重大数据的应用。在广电行业领域内，并不缺乏大数据，关键在于如何应用大数据。观众除了喜欢黄金时段看电视，还喜欢在哪些时段打开电视？他们收看电视都有哪些习惯？解决这一切问题的基础还是数据。

1 大数据的核心是数据

小样本时代正在逐步被大数据时代所取代，但如何应用大数据？如何得到多维度的数据做到领域间的融合呢？在某研掉机构看来，大数据的实现基础在于采集的数据源覆盖量广、维度多。

在数据种类和终端方面，某研掉机构已与多家大型网络运营商达成独家合作模式，获取到多源终端（包括机顶盒、IPTV、PC端、智能电视、平板电脑、手机等）的用户行为数据，同时联合新浪微博，增加互联网维度，实现数据跨屏采集，目前数据范围已涉及娱乐、互联网、消费生活等多个领域。

在广电数据采集范围方面，某研掉机构已在全国范围内覆盖9500万户家庭，其中包括北京、天津、上海、广东、河南、陕西、四川、贵州、海南、吉林、福建等10多个省市的全数据。凭借自主研发的Data Plus大数据运营决策系统及中国传媒大学的资深学术背景，某研掉机构对全网数据实现了高效准确的采集和运算。在这样的数据基础上，大数据的核心价值在一点点被构建出来。

某研掉机构通过瑞智云2.0平台进行数据分析与挖掘，将这些数据结果结合互联网等数据运用到广电行业的运营决策中，为电视台、频道、栏目影视剧制作者以及广告商提供参考。

2 大数据在电视节目分析中的应用：电视剧《怒放》的收视分析

为电广传媒文化发展有限公司制作的电视剧《怒放》进行数据分析，某研掉机构从剧本入手分析，通过对剧本各个维度的解析，同时结合历史数据，从而对该剧播出后的收视效果做出预测，而预测结果与实际播出效果非常吻合。同时对该剧在播出期间的各个市场的表现情况、该剧的用户行为特征和流入流出的情况，某研掉机构也做了详细的分析。

北京市场更爱言情戏。电视剧《怒放》播出期间，各市场用户接触最多的电视剧题材均为爱情言情、战争、都市生活，这三类题材的电视剧整体为河南市场收视效果最好，北京市场爱情言情题材电视剧的到达率最高，其他市场均为战争题材电视剧的到达率最高（如图1）。

战争题材在北方更受欢迎。战争题材电视剧在陕西市场所占的收视份额最高，河南市场紧随其后，北京和广东市场战争题材电视剧的收视份额相当，为18%上下，可见，战争题材的电视剧在西北、华中地区很受欢迎。

CCTV-1播出的电视剧《怒放》在河南市场的收视份额最高，陕西市场次之，广东市场收视份额与其他市场相差较大，说明CCTV-1《怒放》在西北、华中地区深受用户喜爱（如图2）。

各市场CCTV-1《怒放》忠诚用户占比，河南市场最高，潜在用户占比为陕西市场最高，北京市场忠诚用户和潜在用户占比最低。可见，CCTV-1《怒放》在河南市场的用户群最好（如图3）。

CCTV-1《怒放》在各市场全天时段1小时忠诚和潜在用户的收视率和到达率趋势基本一致，且忠诚用户的收视率和到达率高出潜在用户1倍以上。

CCTV-1《怒放》在河南市场全天时段1小时的收视率明显高于其他市场，广东市场全天时段1小时的收视率低于其他市场；河南市场全天时段1小时忠诚和潜在用户收视率峰值出现在23:00—24:00，其他市场忠诚和潜在用户的收视率高峰出现在20:00—22:00（如图4）。

各市场全天时段的收视走势为战争题材新剧的首播时段提供收视数据支持。

北京市场和陕西市场用户群下午时段的平均收视要高于上午时段，广东市场上下午时段收视相差不大，河南市场下午时段的平均收视高于上午时段，此外，河南市场战争题材整体收视环境最好，为战争等题材电视剧的二三轮推广提供了参考。

北京市场CCTV-1《怒放》各集收视表现中，第34集收视率最高，为3.103%；该集收视率进点较高，随着剧情的展开，收视率逐步上升，在21:16—21:17到达峰值3.742%，此时，流出用户最多，流入用户也处于较高水平，之后收视率有所下降，在21:33—21:34下降到2.874%后，剧情出现大的转折，收视率继续上升，片尾处收视率直线下降。

3 大数据在电视互动业务分析中的应用：2015年上半年电视互动业务分析

电视节目的直播业务具有线性特征，观众在选择收看节目时受到的限制较多，而互动业务的开设在很大程度上弥补了电视平台的不足，也给了观众更多选择。同时，越来越多的观众也开始在某些场景中选择时移业务和回看业务作为辅助的观看手段。

观众通过手中的遥控器对互动业务进行自主操作，互动业务的数据能充分反映出忠诚观众群及其节目内容偏好，因此，对互动业务及其用户数据进行综合、多维分析具有非常重要的意义。本例将集中梳理分析2015上半年互动业务的使用情况。

2015年电视互动业务中电视剧类的日均到达率、播出量、收视时长均有波动和回落，通过2015年上半年互动业务的排行来具体分析电视剧、综艺节目、频道的综合实力和观众的忠诚度，可以挖掘更多现象背后的社会原因。

2015年1—5月电视时移业务总体分析。以电视剧为例，2015年上半年时移业务的日均到达率、播出量、收视时长呈高度正相关关系。2015年上半年，电视剧类在时移业务的日均到达率和收视时长随电视剧播出量的增加呈下降趋势。在4、5月份下降到低位，其中爱情言情、栏目剧、战争题材的收视时长缩水最大（如图5）。造成电视剧时移业务数据下滑的原因除播出量减少外，还与上半年电视平台播出电视剧的质量不高有很大关系。

2015年上半年电视剧及综艺节目时移收视排行。在上半年电视剧时移业务榜单中，CCTV-1上榜率最高，可以看出CCTV-1作为资深频道品牌，受众忠诚而且广泛，在这一平台播出的剧集普遍有着不错的收视效果。而从播出题材来看，观众利用时移业务收看爱情言情和社会伦理两类题材电视剧的比重最高。在卫视频道组中，湖南、江苏、浙江、东方四大卫视包揽前十。从节目题材来看，卫视播出的电视剧题材更加丰富和均衡，其中武侠、戏说演绎、都市生活也都是观众喜欢收看的类型（如图6、图7）。

据2015年上半年综艺节目时移业务榜单分析，在央视组中，CCTV-1所占比重最大。由于上半年年初有中国最重要的传统节日——春节，榜单中的时移节目与春节相关的最多，共占5成，节目类型以综艺晚会最多，占6成，这也可以从侧面看出春节在传统文化和民族凝聚力中的重要性。而从卫视榜单中能看出，老牌综艺节目仍然具有号召力，并且忠实观众多，而热度高的新节目也令观众瞩目（如图8、图9）。

2015年上半年时移业务频道收视排名央视频道组中，CCTV-1高居榜首，高度体现了央视综合频道的综合实力，其凭借权威的新闻、热门电视剧和综艺节目等，始终保持高度的观众黏性。另外，通过榜单可以看出，观众对体育、音乐等节目的忠诚度也比较高。

在卫视频道组中，湖南卫视、江苏卫视、浙江卫视、东方卫视依然是第一梯队中实力相当的频道，通过轮番的电视剧战和综艺战，不仅快速提高了整体竞争力，也拉开了和其他卫视的距离（如图10）。

2015年1—5月电视回看业务总体分析。与时移业务相比，回看业务更能显示观众对频道和节目的忠诚度。由2015年上半年电视剧回看业务的日均到达率可知，1月到2月有较大幅度下降，之后是小幅波动。电视剧回看业务收视时长数据与日均到达率和播出量相比差别较大，呈逐月下降趋势，其中爱情言情和都市生活均呈现出先上升后下降的趋势。

2015年电视剧回看业务中，央视组榜单被CCTV-1和CCTV-8包揽，节目类型充分反映了CCTV的频道定位，以反特/谍战和社会伦理占比最大。

在卫视组中，由于受回看内容和忠诚用户影响的原因，电视剧回看业务与时移排名略有不同，北京卫视、安徽卫视进入榜单，其中湖南卫视及其高清频道占到了4成。

剧集题材以爱情言情比重最高，说明爱情依然是观众最喜欢也是最主流的题材类型，其次为戏说演绎、社会伦理和时代变迁类题材。

在综艺回看业务榜单中，CCTV-1占据大半壁江山，CCTV-6和CCTV-3均分榜单其余席位。受春节影响，节目类型依然是以综艺晚会为主，显示出时段特点。

在综艺节目回看业务卫视组中，整体格局相对时移业务有所改变，湖南卫视、江苏卫视、浙江卫视、东方卫视所占比重有所下降，北京卫视、辽宁卫视、湖北卫视上榜，但湖南卫视依然领跑，浙江卫视其次。在节目类型中，综艺晚会占6成，都与春节主题有关；真人秀占3成，《奔跑吧，兄弟》回看最高；择偶占1成，这也从侧面说明年轻人的婚姻问题仍是社会关注的主要问题之一。

在2015年上半年回看业务央视组频道排名中，CCTV-1稳居第一，另外，CCTV-8、CCTV-6、CCTV-5、CCTV-少儿排入前五，说明关注电视剧、电影、体育、动画片等节目的观众忠诚度非常高。在卫视组中，湖南卫视、江苏卫视、浙江卫视继续保持前三甲，东方卫视排在第六，安徽卫视凭借播出的《月亮拥抱太阳》排入前五。

随着互联网及移动互联网的发展，一度造成电视节目观众流失。自2014年以来，月均电视节目到达率超七成，高质量、大制作电视节目的出现，使节目内容成为热门话题在互联网上广泛传播。

随着时移、回看等技术的发展和普及，打破了电视节目播出收看受时间限制的特点，即使观众错过了喜爱的节目，通过时移等功能，依然可以在电视机前收看。这些技术手段有效地把观众吸引回了电视荧屏，未来电视互动业务会有更长远的发展。

4 大数据在用户流量分析中的应用：看穿用户收视行为

用户流动分析是针对某一时段或在某一节目播出过程中，通过对用户收视流向的监测，呈现出该时段内用户收视行为及偏好，并对同时段内播出节目的竞争力及竞争对手进行具体的分析。

对节目或者频道进行用户流动分析不仅可以把握观众对于节目内容的收视行为反馈，同时还对节目内容改进和编排提供了有效的数据参考。下面就通过几个例子了解一下用户流动分析是如何应用到实际的节目分析中去的。

图11、图12是针对某频道18:10—23:10这一时段，频道内及频道间用户流动情况的分析，两幅图分别展示了周间和周末的用户在线曲线和观众流动数据。

数据显示，在频道内的不同节目内容区间中，用户在线率持续较高的是在电视剧时段，而22点之后在线率持续走低；周末的在线观众明显高于平时。

而从频道间流向可以看出，从该频道流向其他频道的用户数量，南方影视和南方卫视分列一二位，其中重叠时段的内容以电视剧、综艺节目和新闻类别为主；从用户行为上可以推断，观众很有可能在不同的剧集之间选择，同时也在浏览选择其他内容的节目。

从用户流动数据中透露出的细节，不仅可以看到观众对不同的剧情、演员的收视反应，还可以看到同时段竞争节目的用户流向。如果增加更多维度，相信可挖掘的信息还会有很多。

结束语

大数据的应用还有更多种可能，在未来综合更多领域的数据也会有更加全面的应用案例，我们也有理由相信，未来大数据应用将会有更多的融合与跨界。

作者，李林杰，北京中传瑞智市场调查有限公司副总经理

《传媒》

http://media.people.com.cn/n/2015/1202/c400317-27881797.html

您可能也喜欢的文章：
广电总局：2013年全国广播电视行业总收入达到3734.88亿元	D-Matrix：2014年上半年度中国平板电视线上零售市场监测	电视遥控应用Peel：截止2013年8月用户达到2500万	乐视：2015年智能电视应用行业报告	预计2013年全球超高清电视面板年出货量或达350到400万片
无觅

提高Hadoop Balancer 迁移block速度的方法

Fri, 19 Jun 2015 11:04:42 CST

如何提高Hadoop Balancer迁移block的速度？

1）增加DataNode用于balancer的bandwidth。

dfs.datanode.balance.bandwidthPerSec
52428800

这个值是DataXceiverServer上BlockBalanceThrottler控制的带宽大小。该单位是Byte，如果机器的网卡和交换机的带宽有限，可以适当降低该速度。Hadoop系统默认是1048576 （1MB）。

2）增加DataNode上转移block的Xceiver的个数上限。
DataNode上同时用于balancer的Xceiver的个数受到了BlockBananceThrottler限制。可以适当调大如下的配置。

dfs.datanode.balance.max.concurrent.moves
50

这个值默认是5。如果仅仅在Balancer的hdfs-site.xml修改配置而没有修改DataNode下的配置，Balancer会抛出如下的WARN LOG：

2015-06-18 15:54:24,253 WARN org.apache.hadoop.hdfs.server.balancer.Dispatcher: Failed to move blk_1366768180_1100055981849 with size=134217728 from 172.22.6.25:1004:DISK to 172.22.5.23:1004:DISK through 172.22.5.99:1004: block move is failed: Not able to receive block 1366768180 from /172.22.6.5:33544 because threads quota is exceeded.

查看DataXceiverServer，如果同时执行Balancer的Xceiver的个数upperlimit是5个，将DataNode上这个参数调大才可以增加迁移Block的速度。
附带SourceCode：
/** Check if the block move can start.

* Return true if the thread quota is not exceeded and

* the counter is incremented; False otherwise.

synchronizedboolean acquire() {

if (numThreads >= maxThreads) {

returnfalse;

}

numThreads++;

returntrue;

}

(这里maxThreads 就是’dfs.datanode.balance.max.concurrent.moves’控制的)

From Binospace, post 提高Hadoop Balancer 迁移block速度的方法

文章的脚注信息由WordPress的 wp-posturl插件自动生成

Copyright © 2008
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
)

两款免费的Android应用代码安全检测工具

Sun, 05 Jul 2015 20:00:00 CST

‍‍FreeBuf前不久刚刚报道过，美‍‍图秀秀、gReader、福昕PDF阅读器等14款Android应用易遭中间人攻击。今天，央视《新闻直播间》也用“黄金三分钟”介绍了安卓手机上存在的名为“寄生兽”的通用型安全漏洞，影响规模达到数以千万级的用户，市面上安卓90％APP都中招。

今年6月Android智能手机在美国的市场份额上升2.8%，达到64.9%。而这带给安卓开发者及用户更多的则是对移动安全及隐私问题的担忧。

‍‍如果你是正在开发手机应用的程序员，那你应该阅读一下 OWASP手机-十大移动威胁。或许你会好奇哪些安全工具可以帮助你解决安卓应用程序日益增长的复杂性难题。嗯，其实是很多工具的。

这篇文章将介绍两个免费的静态分析工具，可以从集成开发环境（IDE）直接扫描你的代码。‍‍

Android Lint

这是个什么？
这是由IDE 安卓工作室官方提供的一个静态代码分析器。

它有什么用？

检测列表是相当长，而安全检测的数量却十分有限。通常重要的定期检测仍在使用这个工具。

安装包

没有！正如之前提到的，这是IDE 安卓工作时官方的，但是如果你只想要与安全相关的检测，你可以使用这个“ 只要安全”文件。

视频演示

FindBugs 与 Find Security Bugs插件

这是个什么？

FindBugs是一款受欢迎的静态分析引擎，广泛用于Java社区。发现安全漏洞（ Find Security Bugs）是一该工具的一个插件，为分析提供了安全规范。

它有什么用？

安全插件 FindSecBugs的主要焦点在于标记漏洞，比如应用程序中不安全的通讯、密码学的误用以及一些敏感部分。

安装包

FindBugs的安装及配置可以通过几个简单点击就能完成。如果你仍然坚持使用Eclipse（前官方IDE），Eclipse市场中也有一个相同的插件。

视频演示

这里有一个简短的视频，展示了FindBugs在安卓工作室的集成。

（注意：这里使用的是Find Security Bugs的一个旧版本）

接下来，我们再聊点什么呢？

不幸的是，程序客户端安全问题仅仅是冰山一角。你的应用程序后端也特别需要注意。毕竟，OWASP十大移动威胁的头号风险便是薄弱的服务器端控制。

另一个不错的建议便是在持续集成环境中将这两种工具结合使用。

BlackHat USA 2015 即将到来

我将在黑帽大会上展示FindBugs的安全插件，演示IntelliJ和SonarQube的集成。如果你已经使用了该工具，有任何问题都请不要犹豫地反馈给我。

如果你从事的是安卓开发工作，也不要错过在同一时间段的 QARK的展示。

如果你有任何可以运用到安卓上的新安全规范，不要犹豫快去GitHub吧。

参考文献

OWASP：Source Code Analysis Tools 静态代码分析工具列表

NIST：Source Code Security Analyzers 另一些不错的按语言分类的工具列表

Android Lint：Android Lint的官方文件

Find Security Bugs：Github网站的FindBugs安全插件

Mobile Security Wiki：一个全面的资源列表，包括用于安卓的工具

*参考来源： blog，转载需注明来自FreeBuf黑客与极客（FreeBuf.COM）

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

Thu, 02 Jul 2015 16:54:50 CST

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

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

Cordova, Ionic, AngularJS 都是什么？

Cordova

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

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

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

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

Ionic

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

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

AngularJS

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

设计目标：

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

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

开发环境

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

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

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

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

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

开发工具

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

网页大图片应用技巧浅析

Wed, 11 Mar 2015 18:17:39 CST

用图像创造场景感，增强用户的真实体验，近些年来，图片作为背景填充整个屏幕的设计越来越广泛，曾经只有时尚潮流网站或者摄影类站点才会特别依赖富有冲击力的图像，但是现在几乎任何类型的网站都有可能采用这种大图片作为背景，特别是企业品牌宣传、产品介绍等等。

在设计网页过程中，需要用到大量的图片，而且找到的图片大多风格迥异、无品牌感，那么如何找到合适而又能正确地应用图片呢？

如何正确应用图片

整理了一些经验总结供大家参考：

1 .提炼关键词寻找图片

首先需要提炼产品特性关键词，通过关键词的形式寻找合适的图片。

上图是google云盘官网banner背景为一张在飞机向外看的图片，不难发现用这种比拟手法来表现云盘的口号“随时随地使用”，在任何时候、任何地点都可以使用文件。换位思考，假如我们来设计google云盘官网，首先提炼出关键词：随时随地、自动同步、超大空间等等，用最能突出特点和有代表性的关键词来寻找合适的图片。

上图是IBM旗下的MobileFirst产品，其主要为用户移动应用从创建到维护推出的一体化解决方案为广大用户提供更便利服务，那么根据项目提炼出关键词：手机、用户，该网站用了一张人拿着手机进行使用的图片，目的是为了突出项目的业务特点。

上图分别为苹果官网、研究无线电技术企业——高通的网站中运用的图片同样也是通过产品特点提炼的关键词来完成图片的选用。

2. 图片品牌化

什么是图片品牌化？通过关键词寻找到的图片进行深度加工处理，使之在项目中运用到的图片都是一整套的、风格统一的，比如可以在图片的色调、色彩饱和度与特色风格上做调整等等，下面举几个案例。

Google Drive官网摘取出来的图片，这些图片不难发现无论在色调、色彩饱和度上是一致的，特点是低饱和度、颜色深沉和图片噪点，颜色上新颖有特色、风格上具有明显的品牌统一性。

上图为SAP公司官网的系列图片，作为全球最大的B2B企业为各行各业、不同规模的其他企业提供解决方案，正如它运用不同行业场景的图片一样：色彩丰富、但色调又不过于鲜艳，它们所有用到的图片都有这些特点。

美国高通网站的品牌宣传图片让人印象深刻，品牌特点独树一炽，颜色上运用冷暖搭配，加以渐变效果巧妙地叠加于图片上，虽然颜色种类不多，但能在风格、品牌上具有强烈的统一性，让人对品牌辨识度有更加深刻的记忆性。

项目实践

去年做了几个腾讯云的项目改版，尝试新的风格探索，排版上采用了大图片为背景。设计过程中考虑到产品的长远发展，通过研究后发现图片统一风格在产品品牌推广上有着非常重要的作用，通过几经打磨快速整理了实现方案。腾讯云线上新版本的页面图片已经实现了统一风格。

总结

大图片作为背景的设计风格，这种设计方式虽然非常强有力地抓住用户的注意力，能准确应用图片而达到更大的体验效果是非常重要的，如果去掌握，了解项目背景，利用关键词的方式寻找更合适的图片，此外还需关注用户对产品的印象程度，那么图片的品牌化就显得格外重要，把产品所用的图片设计为一整套统一的风格出来的效果是不可估量的。

移动消息应用WhatsApp月活跃用户数突破7亿

Thu, 08 Jan 2015 22:20:10 CST

2014年1月7日上午消息，移动消息应用WhatsApp周二宣布，月活跃用户数已经达到7亿，高于去年8月公布的6亿。Facebook去年以220亿美元的价格收购了WhatsApp。

WhatsApp的用户数已经多于其他类似应用，包括Facebook Messenger，并成为全球许多人用来替代短信的一款服务。不过，Facebook希望该服务能吸引更多用户。

在此前的电话会议中，Facebook创始人及CEO马克·扎克伯格(Mark Zuckerberg)表示，他预计WhatsApp将给Facebook的盈利带来贡献，但WhatsApp需要首先积累10亿用户。目前看来，WhatsApp很快就能实现10亿用户的目标。

在约1年的时间里，WhatsApp的用户数增长了3亿。作为对比，Facebook花费了约1年半时间，才使用户数从4亿增长至7亿。不过，那是在2010年到2011年，即智能手机普及率还不是很高的情况下。

Facebook去年公布的数据显示，2014年上半年，WhatsApp产生了约2.3亿美元的亏损，营收仅约为1500万美元。与Facebook通过广告获得收入不同，WhatsApp的收入主要来自每年价格99美分的订购服务。WhatsApp联合创始人简·寇姆(Jan Koum)表示，在去年2月Facebook同意收购WhatsApp之后，WhatsApp放缓了商业化计划。

美国的消息应用市场并不像全球其他地区一样火爆。这部分是由于，在美国，手机套餐中通常包含无限量短信。在美国以外，WhatsApp面临着激烈的竞争，其对手包括中国的微信、韩国的KakaoTalk、日本的Line，以及同样来自美国的Snapchat。

移动市场分析公司Mobidia的数据显示，这些服务在不同国家有着不同的普及率。俄罗斯用户喜爱KakaoTalk，日本市场更青睐Line，而印尼用户喜欢黑莓Messenger。不过，WhatsApp在印度最受欢迎。

您可能也喜欢的文章：
2015年1月WhatsApp用户总数突破7亿	WhatsApp：2014年4月全球用户数突破5亿	WhatsApp：2013年12月活跃用户达4亿四个月增长了1亿	WhatsApp：2014年8月WhatsApp全球月活跃用户突破6亿	WhatsApp月活跃用户突破3.5亿
无觅

Flurry：信息类应用月保留率达到68% 是平均值的近2倍

Thu, 02 Apr 2015 01:55:11 CST

199IT原创编译

由于WeChat等移动信息服务的竞争，SMS正在慢慢消亡，2015年3月Flurry发布的数据显示移动讯息用户忠诚度十分高。

根据调查，讯息应用保留率比普通移动应用的更高。下载一个月后，讯息应用保留率是平均值的1.9倍，68% vs. 38%。到2015年1月，移动讯息应用保留率更加领先，2014年1月下载的讯息应用中62%保留到12个月后，比平均值11%高5.6倍。

移动用户不断与其他人交流，因此移动讯息应用使用率更高，平均每天使用9次，是移动应用日均使用率（1.9次）的4.7倍。

对应用来说保留是难能可贵的，根据Apptentive的数据，全球移动应用平均月保留率是32%，年保留率是11%。

但是，调查显示了提高应用保留率的关键：互动。下载后第一个月通过某种方式接触用户的应用保留率是57%，没有互动的应用保留率是25%。有互动的应用的年保留率是25%，没有互动的应用年保留率只有7%。

编译自：eMarketer 译者：孙莹

您可能也喜欢的文章：
Flurry：iPhone App平均消费19美分	Flurry：美国应用占全球玩家70%时间	Flurry：2011年12月人们每天平均花在应用上的时间上升至94分钟	Flurry：揭秘用户参与度最高的应用类别	Flurry：APP的魔力--信息图
无觅

Java代码审计基础(一)

Wed, 04 Mar 2015 08:35:15 CST

本文重点是让大家了解JAVA代码审计的基础，会以漏洞示例的方式介绍JAVA代码中常见Web漏洞的形成和针对的修复方案，文章是在国外网站上看到的，因为在接触JAVA代码审计，感觉挺高大上的文章，很适合对JAVA代码审计感兴趣的童鞋找感觉之用，就根据自己的理解翻译了过来，拿去某平台投稿，被鄙视说太基础，就只好发自己的Blog上了。

SQL注入

SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序，而这些输入大都是SQL语法里的一些组合，通过执行SQL语句进而执行攻击者所要的操作，其主要原因是程序没有细致地过滤用户输入的数据，致使非法数据侵入系统。

漏洞示例：

<%@page import="java.sql.*"%>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title> </title>
</head>
<body>
<% 
        String user = request.getParameter("user");
        String pass = request.getParameter("pass");
        Class.forName("com.mysql.jdbc.Driver");
        Connection con = (Connection)                                                              
        DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "root" ,"");
        Statement st= con.createStatement();
        ResultSet rs=st.executeQuery("select * from users where username='"+user+"' and password='"+pass+"' limit 0,1");
        if(rs.next())
        {
                out.println("Login success");
        }
        else
        {
                out.println("Login failed");
        }
%>

在上述代码中，开发者使用声明的类来创建一个SQL语句，并执行它来获取一个有效用户的用户名和密码。由于使用拼接SQL语句，并且没有做任何防注入的手段，导致存在SQL注入漏洞，可以绕过登录验证。

修复后的代码如下：

<%@page import="java.sql.*"%>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title></title>
</head>
<body>
<% 
    String user = request.getParameter("user");
    String pass = request.getParameter("pass");
    Class.forName("com.mysql.jdbc.Driver");
Connection con = (Connection) 
DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "root" , "");
    PreparedStatement ps=(PreparedStatement) con.prepareStatement("select * from users where username=? and password=? limit 0,1");
    ps.setString(1,user);
    ps.setString(2,pass);
    ResultSet rs=ps.executeQuery();
    if(rs.next())
    {
        out.println("Login success");
    }
    else
    {
        out.println("Login failed");
    }
%>
</body>

修复后的代码使用了PreparedStatement预编译的方式，使用这种方式无需对传入的参数进行过滤等处理，因为由于PreparedStatement内置了字符过滤，因此是能够防止SQL注入的。

数据明文存储

11年底CSDN的数据在网上泄漏，据说库中的密码都是明文存储的，因此导致非常大的影响。如果使用了复杂的加密存储，即时数据泄漏，密码也有可能不会破解成功，下面看看JAVA代码中数据明文存储的设计缺陷是如何形成的。

漏洞示例：

<%@page import="java.sql.*"%>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title></title>
</head>
<body>
<%
String user=request.getParameter("user");
String pass=request.getParameter("pass");
Class.forName("com.mysql.jdbc.Driver");
Connection con=(Connection)DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "root" ,"");
PreparedStatement ps = (PreparedStatement) con.prepareStatement("insert into users_crypt values(?,?)");
ps.setString(1,user);
ps.setString(1,pass);
int res = ps.executeUpdate();
if(res>0)
{
out.println("Register success");
}
else
{
out.println("Register failed");
}
%>
</body>

可以看到上面的代码对获取到的user和pass的没有做任何的加密处理，直接存储到数据库中，导致存在明文存储的缺陷。

修复后的代码如下：

<%@page import="java.util.Calendar"%>
<%@page import="java.text.SimpleDateFormat"%>
<%@page import="java.text.DateFormat"%>
<%@page import="java.math.BigInteger"%>
<%@page import="java.security.MessageDigest"%>
<%@page import="java.sql.*"%>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title></title>
</head>
<body>
<%
    String user=request.getParameter("user");
    String pass=request.getParameter("pass");
    DateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
    Calendar cal = Calendar.getInstance();
    String reg_time = (dateFormat.format(cal.getTime())).toString();
    String original = pass+reg_time;
    String s = pass+reg_time;
    MessageDigest m = MessageDigest.getInstance("MD5");
    m.update(s.getBytes(),0,s.length());
    String calc_hash = new BigInteger(1,m.digest()).toString(16);
    if(calc_hash.length()<32)
    {
        calc_hash = "0"+calc_hash;
    }
    Class.forName("com.mysql.jdbc.Driver");
    Connection con=(Connection)DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "root" ,"");
    PreparedStatement ps = (PreparedStatement) con.prepareStatement("insert into users_crypt values(?,?,?)");
    ps.setString(1,user);
    ps.setString(2,calc_hash);
    ps.setString(3,reg_time);
    int res = ps.executeUpdate();
    if(res>0)
    {
        out.println("Register success");
    }
    else
    {
        out.println("Register failed");
    }
%>
</body>
</html>

修复后的代码将用户注册的时候输入的密码和注册时间组合加密之后保存在数据库中，这样如果数据泄漏，不阅读源代码很难将密码破解成明文形式，大大降低了泄密之后的影响。

失效的会话管理

该漏洞主要是因为Web应用程序没有正确的执行会话管理，例如用户登陆前的会话Cookie和登录后的是一样的，另外一个例子是当用户点击退出的时候，Session不会失效。

示例漏洞代码：

<%@page import="java.sql.*"%>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title> </title>
</head>
<body>
<% 
    String user = request.getParameter("user");
    String pass = request.getParameter("pass");
    Class.forName("com.mysql.jdbc.Driver");
    Connection con = (Connection) DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "root" , "");
    PreparedStatement ps=(PreparedStatement) con.prepareStatement("select * from users where username=? and password=? limit 0,1");
    ps.setString(1,user);
    ps.setString(2,pass);
    ResultSet rs=ps.executeQuery();
    if(rs.next())
    {
        session.setAttribute("useracc", rs.getString("user"));
        out.println("Login success");
    }
    else
    {
        out.println("Login failed");
    }
%>
</body>

修复后的代码：

<%@page import="java.sql.*"%>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title> </title>
</head>
<body>
<% 
    String user = request.getParameter("user");
    String pass = request.getParameter("pass");
    Class.forName("com.mysql.jdbc.Driver");
    Connection con = (Connection) DriverManager.getConnection("jdbc:mysql://localhost:3306/userdb", "root" , "");
    PreparedStatement ps=(PreparedStatement) con.prepareStatement("select * from users where username=? and password=? limit 0,1");
    ps.setString(1,user);
    ps.setString(2,pass);
    ResultSet rs=ps.executeQuery();
    if(rs.next())
    {
        session.invalidate();
        request.getSession(true);
        session.setAttribute("useracc", rs.getString("user"));
        out.println("Login success");
    }
    else
    {
        out.println("Login failed");
    }
%>
</body>

以上修复后的代码中，用户在登录的时候，首先会让之前的session失效，然后又获取新的seesion。

XSS漏洞

Xss漏洞小伙伴们应该都比较熟悉了，攻击者可以向网页中注入恶意的JS或者HTML代码，有反射XSS、存储XSS、DOM XSS三种。

漏洞示例：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>XSS Vulnerable</title>
</head>
<body>
    <form action="xss-vuln.jsp" method="post">
        Enter your name: <input type="text" name="name"><input type="submit">
    </form>
 
<%
    if(request.getMethod().equalsIgnoreCase("post"))
    {
        String name = request.getParameter("name");
        if(!name.isEmpty())
        {
            out.println("<br>Hi "+name+". How are you?");
        }
    }
%>
 
</body>
</html>

从上面漏洞代码中可以看到，对用户提交的name参数没有做任何的输入过滤和输出的编码，直接输出在HTML代码中，导致存在反射XSS漏洞。

修复后的代码：

<%@page import="org.apache.commons.lang.StringEscapeUtils"%>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
Patch 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>XSS Patched</title>
</head>
<body>
<form action="xss-patch.jsp" method="post">
Enter your name: <input type="text" name="name"><input type="submit">
</form>

<%
    if(request.getMethod().equalsIgnoreCase("post"))
    {
        String name =  
        StringEscapeUtils.escapeHtml(request.getParameter("name"));
        if(!name.isEmpty())
        {
            out.println("<br>Hi "+name+". How are you?");
        }
    }
%>
</body>

上面修复后的代码对用户提交的name参数进行了HTML的编码处理，使用了StringEscapeUtils类的escapeHtml方法，该方法会自动对特殊符号进行HTML编码处理。该类是包含在 commons-lang-2.4.jar包中的。

越权漏洞

如果一个Web应用程序不正确检查用户是否被授权访问的特定的资源，就有可能导致产生越权漏洞。例如帐号A在登录的状态下，遍历访问请求中的ID就可以查看其它人的相关信息。

漏洞示例代码：

<%@page import="java.util.Enumeration"%>
<%@ page import="java.sql.*" %>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Account Balance</title>
</head>
<body>
<%
    int flag = 0;
    Enumeration e = session.getAttributeNames();
    while (e.hasMoreElements())
    {
        String name = (String) e.nextElement();
        String value = session.getAttribute(name).toString();
        if(name.equals("useracc") && !(value.isEmpty()))
        {
            flag = 1;
            break;
        }
    }
    if(flag == 1)
    {
        String accno = request.getParameter("accno");
        Class.forName("com.mysql.jdbc.Driver");
        Connection con = (Connection) DriverManager.getConnection("jdbc:mysql://localhost/mydb", "root", "");
        PreparedStatement ps = (PreparedStatement) con.prepareStatement("select * from account_balance where accno=? limit 0,1");
        ps.setString(1,accno);
        ResultSet rs = ps.executeQuery();
        if(rs.next())
        {
            String s = rs.getString("balance");
            out.println("<h1>Welcome to your account</h1>");
            out.println("<br>Account Number: "+session.getAttribute("useracc"));
            out.println("<br>Your current balance is: "+s);
        }
        else
        {
            out.println("Error: Contact administrator.");
        }
    }
    else
    {
        response.sendRedirect("login.jsp");
    }
%>
</body>
</html>

在上面的代码中，没有判断用户Session,导致通过修改accno的值就可以遍历返回的结果信息。

修复后的代码：

<%@page import="java.util.Enumeration"%>
<%@ page import="java.sql.*" %>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Account Balance</title>
</head>
<body>
<%
    int flag = 0;
    Enumeration e = session.getAttributeNames();
    while (e.hasMoreElements())
    {
        String name = (String) e.nextElement();
        String value = session.getAttribute(name).toString();
        if(name.equals("useracc") && !(value.isEmpty()))
        {
            flag = 1;
            break;
        }
    }
     
    if(flag == 1)
    {
        String sess_accno = session.getAttribute("useracc").toString();
        String accno = request.getParameter("accno");
        if(sess_accno.equals(accno))
        {
            Class.forName("com.mysql.jdbc.Driver");
            Connection con = (Connection) DriverManager.getConnection("jdbc:mysql://localhost/mydb", "root", "");
            PreparedStatement ps = (PreparedStatement) con.prepareStatement("select * from account_balance where accno=? limit 0,1");
            ps.setString(1,accno);
            /*
            This line will be better
            ps.setString(1,sess_accno);
            */
            ResultSet rs = ps.executeQuery();
            if(rs.next())
            {
                String s = rs.getString("balance");
                out.println("<h1>Welcome to your account</h1>");
                out.println("<br>Account Number: "+session.getAttribute("useracc"));
                out.println("<br>Your current balance is: "+s);
            }
            else
            {
                out.println("Error: Contact administrator.");
            }
        }
        else
        {
            out.println("Unauthorized Access Detected");
        }
    }
    else
    {
        response.sendRedirect("login.jsp");
    }
%>
</body>
</html>

上面修复后的代码，判断了用户的Session，在为True的情况下才能够查看返回的信息，因此当用户遍历accno的值来尝试获取返回结果时，会提示无权访问。