IT瘾移动推荐

从Flutter聊聊跨平台移动研发方案

Tue, 26 Apr 2022 08:12:17 CST

Flutter 是一款由 Google 开发的开源、跨平台移动端开发框架。Flutter 使用 Dart 作为开发语言，这是一门简洁、强类型的编程语言。它允许使用同一个代码库构建高性能、漂亮的 iOS 和 Android 应用，Flutter还提供了两套视觉库，可以针对不同的平台有不同的展示效果。此外，通过自定义的 Flutter 引擎可以将其嵌入到其他平台。

一直以来，跨平台工具采用以下两种方法之一：

在原生应用程序中嵌入 web view ，像构建网站一样构建应用程序。
封装原生平台里的控件并为它们提供一些跨平台的参数。

Flutter的特别之处

为了使移动端开发变得更好，Flutter 尝试了一种不同的方法。它提供了开发人员工作的框架应用程序和能够托管应用程序的可移植运行时的引擎。该框架依托 Skia 图形库而构建，提供了实际渲染时用到的 widgets，而不仅仅是原生应用控件的包装器。就像 web 包装器选项提供的那样，该方法可以灵活的以完全自定义的方式构建跨平台应用程序，同时还会提供流畅的性能体验。与此同时，Flutter 自带的丰富的 widget 库以及一些开源的 widgets 使其成为一个功能丰富的平台。

目前已经有不少大型项目接入Flutter，阿里的闲鱼、头条的抖音、腾讯的NOW直播，都将Flutter当做应用程序的开发语言。除此之外，还有一些其他中小型公司也在做。

Flutter的整体架构

简单明了的说，Flutter 分为三大部分：由 Dart 语言负责的 Framework 层；Dart 语法执行器；Skia 图像处理引擎。

Flutter 也可以理解为开发SDK或者工具包，其通过Dart作为开发语言，并且提供Material和Cupertino两套视觉控件，视图或其他和视图相关的类，都以Widget的形式表现。Flutter有自己的渲染引擎，并不依赖原生平台的渲染。Flutter还包含一个用C++实现的Engine，渲染也是包含在其中的。

Flutter的跨端优势

1、如果以后想在 Google 的新系统上跑程序的话，用Flutter来编写是一定没错的。

2、Flutter 用 Dart，学习 Flutter的同时会使我们掌握一门新的语言，买一送一。 3、Flutter 天生支持 iOS 风格的控件，称为 Cupertino，这样我们可以一套设计，一套code跑在两个系统上。

4、学习Flutter的过程会改变手机端app开发的思维，毕竟只有一个activity，全程跟个游戏引擎一样， 60帧每秒绘图。

5、Hot reload，极大地加速了开发效率。

6、Flutter 提供 method channel 给 Android 和 iOS，其实可以只用 Flutter 来开发UI，其他底层逻辑可以封装Android 和 iOS 分别的 lib package，然后直接Rx封装写回 method channel，也是一种新的开发模式。

7、性能更好，兼容性更好，开发起来更有乐趣，这才是程序员的人生，正好 Flutter 都能满足。

跨平台方案的比较

NATIVE

原生应用程序在使用新功能时带来的困扰是最少的。由于应用程序是使用平台供应商自己（Apple 或 Google）的控件构建，为了让用户体验更加符合给定的平台，因此他们通常遵循这些供应商制定的设计指南。大多数情况下，原生的应用将会比那些跨平台构建的应用性能要好一些，尽管在很多情况下两者的差异可以忽略不计，不过具体还要取决于底层跨平台技术。原生应用的一大优势是：当需要时，他们可以立即采用 Apple 和 Google 在测试版中开发的新技术而不用等待第三方的集成。构建原生应用的主要缺点是缺乏跨平台的代码复用，如果同时开发 iOS 和 Android 应用，那么开发成本可能会很高。

REACT NATIVE

React Native 允许原生应用使用 JavaScript 构建。应用中用到的控件实际上都是原生平台里的控件，所以用户使用起来感觉和原生应用一样。对于那些 React Native 没有提供的需要自定义的应用，仍然需要使用原生开发。当需要定制的模块比较多时，某些情况下，在 React Native 中开发不如使用原生开发更合适。

XAMARIN

当谈到 Xamarin 时，有两种不同的方法将会被提及。跨平台方法：Xamarin.Forms。该方法不同于 React Native，但是从概念上讲是相似的，因为它也是抽象原生控件。同样的，在定制方面它也有和 React Native 同样的缺点。第二种方法：Xamarin-classic。该方法分开使用 Xamarin 的 iOS 和 Android 产品来构建适用于特定平台的功能，就像直接使用 Apple/Android 原生功能一样，只不过在 Xamarin 中需要使用 C# 或 F# 。使用 Xamarin 的好处是可以共享非平台特定的代码，例如网络、数据访问、Web 服务等。

NATIVE+小程序

说起这个可能首先会想到「原生 + HTML5」，至少一些业务功能通过H5的形式实现，可以节省安装包的体积，也可以实现快速更新。但会发现 HTML5 开发的方式，性能体验问题较大。比如，HTML5 页面在用户手机上经常出现打不开、一直加载中、卡顿，而且H5很多系统权限获取不了，也不支持本地缓存，需要访问通讯录、调用硬件、访问蓝牙啥的这些 H5 都是无法支持的，导致还是有大量的功能不得不放到客户端上实现。

由于国内的特殊的原因，在微信、支付宝的带动下小程序成为移动端的时代搅局者，小程序具有强大的 Web 渲染引擎、提供丰富组件、支持本地缓存、避免 DOM 泄露等等这些都是，而且小程序技术也有利于帮助App实现「松散耦合」，比如当App的一些业务功能用小程序的形式替代，那么这个小程序可由团队或者个人独立开发、独立部署、独立管理生命周期，随时上下架而不影响APP主体，实现APP复杂业务动态化，多维发布。

目前也有国内厂商推出了成熟的解决方案，之前有了解到 FinClip ，这个框架对标微信小程序的功能，相同的代码，既能在微信端跑，也能在自己的 App 里跑，效果是一样的，相当于把已经上架的微信小程序能够直接搬到自己的 App 能运行。开发一次就能够在包括 Linux、Windows、MacOS、麒麟等操作系统运行。这意味着，PC 端、车载设备、智能电视都能使用小程序了，实现了“一次开发，到处运行”。

不再钟情于移动端开发

Thu, 30 Sep 2021 14:04:03 CST

投身于移动端开发（iOS 为主）也有些年头了，但这几年它带来的乐趣却越来越少，曾经可以为了实现一个效果凌晨三点起床 Coding，现在能让我三点起床的估计只有 Deadline 和失眠了。为啥会这样呢，大概有这么几个原因：

手机的阴暗面

正如把宇航员送上天的火箭，也可以把导弹「送」到其他国家，科技往往有两面性，App 也不例外，抖音上可以学到新的知识，也能偷走一下午的时间。

很羡慕那些能与手机和谐相处的人，不受蛊惑又物尽其用，我做不到，最近在尝试把它放在看不见的地方，出门就放包里，让 Apple Watch 扮演传呼机的角色。Cal Newport 的 Digital Minimalism 里描述的内容比较符合我对手机的使用理念，简单来说就是把智能手机当作非智能手机来使用。非智能手机有个很好的特点是有明确的使用场景，且不具有成瘾性。

App 开发商们在意的是 DAU（每日活跃用户数）、停留时间、用户粘度，他们会充分利用人的心理来定制化开发功能，用极低的成本来让你获得正反馈，这种正反馈的感觉驻留在大脑后，就很容易被再次触发，进而影响专心工作的时间和质量。在各个 App 的合力助攻下，手机就越来越像个黑洞，把本可以用来休息、独处、自省、思考、锻炼、社交、阅读、创作的时间都吸了进去。

严歌苓说「人间极乐之事，无不是苦中作乐。生命一天不达到那个浓度和烈度，没有到达那个敏感度、兴奋点，瘾就没过去，那一天就活得窝囊」。这个「瘾」和手机的「瘾」有一个关键的区别：思考在其中占的比例。App 为了达到 Hook 的效果，会尽可能地降低认知负担，也就是「思考」的参与，同时提供源源不断的内容供消费，或者让你时不时地想回访。就像「象与骑象人」，要去某个地方，可以是象（非理性）说了算，也可以是骑象人（理性）说了算，前者明显更好说服。时间一长，象的话语权就会越来越大，有时骑象人明显感觉到有问题，却发现很难干预，比如抖音刷的时候很过瘾，过后又会觉得有愧疚感，因为当象终于累了的时候，骑象人才能说得上话。

所以我更喜欢工具类 App，在特定的场景帮用户解决特定的问题，但自己去做这类 App 又是另一回事了。

行业现状

对于移动端开发来说，大概有业务开发、研发支撑、基础架构这几个方向。对业务开发来说，要找到乐趣其实不容易，一方面是产品会催着上线，另一方面产品设计也较难产生「wow，cool，好想把它做出来」的感觉，如果有 Code Review 兜底的话还会好一点，不然很容易产生技术债。一个功能一旦上线就不能轻易下线，这些技术债也会随着时间的累积慢慢发挥它的威力。而新 Feature 不能停，也要不断地还债，光是要理清这些债务就很费功夫，改动起来就更难了。而这些改动很难描述成漂亮的数字和业绩，对晋升帮助不大，所以大家都愿意做新业务，然后产生新的债务，如此循环。

基础架构主要围绕性能优化、组件化、动态化、基础类库展开，研发支撑主要是 CI / CD，辅以一些提高效率的工具，虽然业内相关的文章不少，但落实到每个公司内部都会有自己独特的问题和技术挑战。不过我在这些方面的意愿不强烈。

职业发展

如果只是从事移动端开发，那么这个职业的生命周期还是挺短的，一方面移动端开发的门槛并不是很高，新人更有冲劲，也更愿意学。另一方面，随着年龄的增长，即使你也还能拼，对薪资也没有太高的要求，团队融入和管理成本都会是问题。所以不要被还不错的待遇迷惑，尽早想好 pivot 的方向，当机会出现时可以及时把握住。比如：技术管理，技术专家，独立开发者。

「技术管理」是一个有高杠杆率的岗位，考验综合能力，要能够且愿意处理各种杂事，有技术判断力，制定团队规划，考虑团队成员成长等等。

「技术专家」则需要在某一领域持续耕耘和深挖，要有扎实的技术功底和耐心，但如果这个领域本身的生命周期就不长，那这个方向就有待商榷了。

「独立开发者」是一条很难走的路，能坚持下来的不多，获得可观回报的就更少了。它独特的魅力在于可以享受更纯粹的创作乐趣，也能被用户的正反馈所激励。但要有至少一款还不错的产品，同时需要有一定的门槛，不然很容易被竟品赶上或超越，还要时刻留意新的产品机会，开发之外的事情也不少，都要 hold 住。

这几条路线对我来说，要么能力上有欠缺，要么意愿上不强烈。

So What’s Your Plan?

我对自己的认知是更喜欢探索和创作，脱离移动端可以更好地释放这些热情，当然这也可能是一个错觉。巴菲特在 1998 年的佛罗里达演讲里说：「财务自由之后想做什么工作，现在就该做什么工作，是那种期待第二天到来的工作，这样的工作才是理想的工作，能学到东西，充满激情」。探索和创作是我目前最想做的事，那就先把它做了吧。

如果不 Work 怎么办，发现自己对这两件事只是浅浅的喜欢，无法形成可持续发展怎么办？

It’s OK，但这个过程必须要帮自己弄清楚一件事：我的长处是什么？要有所作为，就要发挥自己的长处，可以采用的方式是「回馈分析法」：事先记录下自己对结果的预期，9 到 12 月后，再将结果与自己的预期比较。（该方法来源于彼得·德鲁克的「如何实现自我管理」）

如果结果符合预期，那很好，可以继续走下去，如果不符合预期，至少断了这个念想，避免在从事其他工作时，老是记挂着「要是我能去做 xx 就好了」。

为什么是现在呢？因为「找到自己喜欢的事」越早越好，随着年龄的增加，身体的维护成本会越来越高，羁绊也会越来越多，热情会慢慢降低，大脑的运算能力也会下滑。虽然稳妥的方式可能带来更高的收入，但这都是有代价的。

Ironically，当我有了较充足的时间可以去探索自己喜欢的事时，手机成了一个不小的阻碍，因为太容易拿起来，然后可以玩很久。Deep Work 并不容易，稍微 Deep 一会，就想浮出水面，这方面还需要不断地训练。

中国主机托管TOP5：中电信、万国数据、世纪互联、中移动、中联通

Tue, 21 Sep 2021 23:40:14 CST

研究公司 Synergy Research Group 的最新数据表明，亚太地区的主机托管市场仍呈现碎片化，导致主要国家或地区市场的领导者排行榜上出现一系列广泛的主机托管服务提供商。

基于今年第二季度的主机托管收入，NTT 和 Equinix 是整个亚太区的两大领跑者。它们也是有资格声称在亚太区最具势力的两家公司，因为每家公司在至少四个主要的亚太国家或地区拥有相当大的市场份额。

该地区排名第三至第五的公司都是几乎完全专注于本国市场的中国公司：中国电信、万国数据和世纪互联（21Vianet）。虽然这些公司受益于国内市场的绝对规模，但在两个或多个国家或地区市场表现强劲的其他老牌主机托管提供商包括：KDDI Telehouse、STT GDC、Global Switch、Digital Realty 和 Keppel。

已定有积极增长计划的进入多个国家或地区比较晚的新来者包括：AirTrunk、普林斯顿数字集团和秦淮数据。

领导者排行榜的多样性反映了亚太市场的结构。虽然亚太区拥有庞大的中国和日本两大主机托管市场——它们在规模上仅次于美国市场，但这两个国家占亚太区收入的比例不到 60%。

该地区接下来的几大国家或地区市场是新加坡、澳大利亚、印度和中国香港地区，它们在全球主机托管十大市场排行榜上都占有一席之地。除了这六大亚太国家或地区外，韩国是个庞大的市场，目前增长势头非常强劲。

相对于其他地区，亚太区目前的规模仅次于北美，但远远领先欧洲中东和非洲（EMEA）。亚太区的增长速度远快于这另两大地区，未来五年其增长速度将继续超过它们。2022 年，亚太区将超过北美，成为全球最大的区域性主机托管市场。

Synergy Research Group 的首席分析师 John Dinsdale 表示说：“亚太区是一个非常值得关注的市场。虽然乍一看该地区似乎与欧洲市场有几个共同特点，但实际上大不相同。亚太区在监管问题、文化问题、经济问题、商业问题和运营问题等方面的同质化程度不如欧洲。对于非中国数据中心运营商来说，中国是一个极难立足发展的地区，而日本和印度也都是难以渗透的市场。但亚太区仍然是一个高速增长的地区，该地区备受超大规模运营商的关注，这将有助于推动未来增长，尤其在主机托管市场的批发业务这一块。”

本文链接

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

Fri, 28 May 2021 20:17:22 CST

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

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

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

筛选框架的要求：

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

Cordova

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

优点：

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

缺点:

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

UI框架

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

参考资料

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

Ionic

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

技术要求

HTML + CSS + AngularJS

优点：

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

缺点：

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

AppCan

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

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

优点

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

缺点

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

参考：
Phonegap VS AppCan

使用案例：
我爱我家App 等

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

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

Dcloud

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

优点：

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

缺点：

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

学习路线：

APICloud

优点：

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

缺点：

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

React Native

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

缺点：

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

总结

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

原因：
Cordova

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

DCloud

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

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

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

AppCan

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

Ionic

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

React Native

学习成本高

Flutter 2 来了：专为 Web、移动与台式机环境构建

Thu, 04 Mar 2021 17:25:15 CST

下一代 Flutter 专为 Web、移动与台式机环境构建而成。

今天，我们宣布 Flutter 2 正式亮相！作为 Flutter 的一次重大版本升级，Flutter 2 将帮助开发人员立足任意平台创建起美观、快速且能够轻松移植的应用程序。在 Flutter2 的支持下，您可以使用相同的代码库将原生应用程序发布至 iOS、Android、Windows、macOS 以及 Linux 五大系统阵营之上。此外，Flutter 2 还能够完美契合 Chrome、Firefox、Safari 以及 Edge 等网络浏览器，甚至可以被嵌入至汽车、电视与智能家居当中，借此带来最普遍、最具便携性的计算体验。

我们的目标，是从根本上改变开发人员的应用程序构建思路。不同于以往对于特定平台的依赖，如今开发人员们可以将希望创造的体验本身作为出发点。Flutter 帮助您将品牌与设计诉求充分纳入应用体验当中。Flutter 的运行速度极快，能够将源代码编译为机器码；我们还支持有状态热重载，确保您在解释环境中获得良好生产力，并在应用程序运行时做出变更并立即查看结果。Flutter 是一套开放式核心框架，而且已经有成千上万贡献者通过软件包生态系统做出扩展贡献。

在今天发布的 Flutter 2 当中，我们将 Flutter 由移动框架扩展为一套可移植框架，努力确保您的应用程序能够在几乎无需任何调整的前提下轻松运行在不同平台之上。目前，单在 Play Store 软件商店中就存在超过 15 万个 Flutter 应用，且每款应用都可以获得 Flutter 2 提供的免费升级，由此在无需重写的情况下直接运行在目标台式机及 Web 环境当中。

目前，世界各地的客户都在积极使用 Flutter，包括微信、Grab、Yandex Go、Nubank、Sonos、Fastic、Betterment 以及 realtor.com 等高人气应用。在谷歌，同样有 1000 多名工程师正在使用 Dart 与 Flutter 构建应用产品，其中的代表包括 Stadia、Google One 以及 Google Nest Hub。

就在几个月前，Google Pay 刚刚转投 Flutter 的怀抱，借此在生产力与质量方面取得了重大进步。通过统一代码库，项目团队消除了不同平台之间的功能差异，并削减了超过 100 万行代码。Google Pay 还报告称，如今团队工程师们的效率大为提升、技术债务显著减少，发布流程也变得更为统一（例如 iOS 与 Android 上的安全审查与试验）。

Flutter 为 Web 应用添助力

Flutter 2 当中最具份量的升级，当数对 Web 的生产质量支持能力。

Web 在早期发展阶段主要以文档为中心。时至今日，Web 平台已经相当丰富并提供大量平台 API，可提供硬件加速下的 2D 与 3D 图形处理能力、灵活的布局与绘图 API，共同构建起高度复杂的应用程序。Flutter 的 Web 支持充分吸纳了上述创新优势，提供一套以应用程序为中心的框架体系，能够发挥现代 Web 提供的一切功能。

新版本主要关注以下三大应用场景：

渐进式 Web 应用（PWA），将 Web 的广泛覆盖范围与桌面应用程序的功能优势结合起来。单页应用程序（SPA），一次加载并与互联网服务之间持续传输数据。将现有 Flutter 移动应用引入 Web 环境，实现两种体验间的代码共享。

过去几个月以来，我们一直努力实现稳定的 Web 支持能力，并在性能优化方面取得了大量进展。除了添加一套由 WebAssembly 构建的全新 CanvasKit 驱动型渲染引擎之外，我们还公布了 Flutter Plasma——由社区成员 FelixBlaschke 构建的演示方案，用以展示如何通过 Dart 与 Flutter 困难构建起复杂的 Web 图形体验。现在，这些体验已经能够在台式机与移动设备上原生运行。

我们一直在扩展 Flutter 以构建起行业最佳的 Web 平台。最近几个月，我们引入了文本自动填充功能，对地址栏 URL 及路由的控制机制以及 PWA 清单功能。为了将台式机浏览器与手机浏览器统一起来，我们又添加了交互式滚动条与键盘快捷键、增加了台式机模式下的默认内容显示密度，同时增强了屏幕阅读器对于 Windows、MacOS 以及 Chrome OS 辅助功能的支持能力。

我们已经发布 Flutter 构建的部分 Web 应用程序示例。在教育类用户中，iRobot 公司以其高人气 Root 教育机器人而闻名。Flutter 对于 Web 的生产级支持帮助 iRobot 将现有教育编程环境轻松迁移至 Web，相关功能也借此顺利登陆 Chromebook 及其他网络浏览器。关于相关进展以及选择 Flutter 的原因，请参阅 iRobot 发布的说明博文"。

另以 Rive 为例，这是一款专门面向设计师群体的强大工具，能够在任意平台上创建出自定义动画。其更新 Web 应用程序现已提供 Beta 测试版，完全由 Flutter 构建而成，充分展示了 Flutter 新版本提供的全面服务。

Flutter 2 登陆台式机、折叠式设备与嵌入式设备

除了传统移动设备与 Web 平台之外，Flutter 也开始为其他设备类型提供支持。在本文中，我们将以三位合作伙伴为例，聊聊 Flutter 的强大可移植性表现。

首先是 Canonical，我们双方合作将 Flutter 引入桌面环境，借此 Canonical 工程师们贡献的代码支持 Flutter 在 Linux 上的开发与部署。Ubuntu 团队展示了由 Flutter 重写的全新安装程序的早期演示效果。对 Canonical 而言，最重要的就是如何在各类硬件配置之上提供稳定且令人愉悦的使用体验。展望未来，Flutter 将成为 Canonical 构建后续桌面与移动应用程序时的默认选项。

接下来是微软，软件巨头同样在不断扩大对 Flutter 的支持。除了在 Flutter 当中建立更完善的 Windows 支持能力之外，微软此次同样宣布将对 Flutter 引擎提供全面支持，借此支持更多新型折叠式 Android 设备。这类设备将引入新的设计模式，相关应用能够扩展显示内容或利用双屏特性提供并行体验。结合 Surface 工程团队的博文，他们展示了自己的工作成果并邀请更多参与成员，希望借 Flutter 之力提升 Surface Duo 及其他同类设备的体验质量。

最后，全球汽车巨头丰田公司也宣布了相关计划，着手构建由 Flutter 提供支持的车载信息娱乐系统，希望借此将最佳数字体验引入汽车产品。使用 Flutter 代表着车载软件的开发方式将出现重大变化。之所以选择 Flutter，是因为丰田看中了其出色的性能与一致性使用体验、快速迭代、易于掌握的人机工程学设计以及与智能手机相匹配的良好触控机制。通过使用 Flutter 的嵌入器 API，丰田得以针对车载系统的独特需求对 Flutter 做出量身定制。

我们很高兴能够与丰田及其他厂商积极合作，将 Flutter 应用于汽车、电视及其他嵌入式设备。未来几个月内，我们也将继续分享更多实际用例。

不断发展的 Flutter 生态系统

目前，Flutter 与 Dart 已经拥有超过 15000 种软件包，分别来自 Amazon、微软、Adobe、阿里巴巴、eBay 以及 Square 等。除 Lottie、Sentry 以及 SVG 等关键软件包之外，sign_in_with_apple、google_fonts、geolocator 以及 sqflite 等 Flutter Favorite 首选软件包同样值得关注。

现在，我们宣布正式推出 Google Mobile Ads for Flutter 的 Beta 版本。这是一种能够与 AdMob 与 AdManager 配合使用的全新 SDK，可提供包括横幅广告、插页广告、原生广告与奖励视频广告在内的多种广告格式。此前，我们一直在与多位主要客户共同试用此 SDK，例如南美洲最大的独立艺术家音乐平台 SuaMúsica 等。如今，我们决定开放 Google Mobile Ads for Flutter SDK 以供行业广泛使用。

我们还将对 Flutter 插件做出更新，包括多项核心 Firebase 服务：Authentication, CloudFirestore, Cloud Functions, Cloud Messaging, Cloud Storage 以及 Crashlytics，外加 sound null safety 支持以及对 Cloud Messaging 软件包的全面更新。

Dart: Flutter 背后的独门绝技

如前文所述，Flutter 2 拥有灵活的多平台与多设备可移植能力。而这种轻松过渡至 Web、桌面与嵌入式设备的优势，在很大程度上要归功于 Dart——针对多平台开发并进行优化的谷歌编程语言。

在构建应用方面，Dart 提供一套独特的功能组合：

稳健的可移植表现，其编译器能够面向移动与台式机设备生成高性能的英特尔与 ARM 机器码，并为 Web 环境提供经过严格优化的 JavaScript 输出。所有目标皆可使用相同的 Flutter 框架源代码。支持有状态热重载的迭代开发，充分支持桌面与移动设备，同时提供现代 UI 编程中的异步、并发模式设计提供相应的语言构造。谷歌级性能水平，可跨越一切平台实现良好性能表现，提供 sound null safety 以保证运行时与开发过程中的 null 约束能力。

从目前来看，还没有哪种语言能够像 Dart 这样将所有功能优势融合起来。也正因为如此，Dart 成为 GitHub 上发展速度最快的语言之一。

Dart 2.12 现已正式发布，也是自 2.0 版本之后我们推出的最大规模发行版，可充分支持 sound null safety。Sound null safety 有望消除 null 引用引发的异常，为开发及运行时提供良好保障，允许开发人员明确指定哪些类型中可以包含 null 值。最重要的是，这项功能并非空降落地：您可以按自己熟悉的方式将其逐步添加至代码内，而后配合迁移工具实现 null 值保护。

此次更新还包含 FFI 稳定实现，允许您编写出能够与基于 C 语言的 API 进行互操作的高性能代码；由 Flutter 编写的全新集成化开发者与分析器工具；外加众多性能与体量方面的改进，能够在无需重新编译的前提下进一步实现代码升级。关于更多详细信息，请参阅 Dart 2.12发布的公告博文"：

Flutter 2：现已发布

关于 Flutter 2 还有很多新鲜内容可讲，但受到本文篇幅所限，我们无法一一尽述。实际上，全部 pull 请求记录与说明构成的文档长达 200 页！感兴趣的朋友请访问 Flutter 2独立技术博客，在这里了解关于新功能与性能改进的更多信息"。

我们还与加拿大屡获殊荣的设计团队 gskinner 合作开发出新的展示成果——Flutter Folio。Folio 是一款剪贴板应用程序，适用于一切设备平台。其小屏幕体验专为内容捕捉所设计；大屏幕支持允许您立足台式机与平板电脑以大家熟悉的方式完成编辑操作；Web 体验则专门针对共享操作开发而成。这一切量身定制体验都将共享同一套开源代码库，您可以随时查看并参与贡献。

如果您还没有体验过 Flutter，请千万不要错过它将给您应用程序开发体验带来的重大提升。在 Flutter 中，我们还提供一套开源工具包，可通过单一代码库构建起面向移动、桌面、Web 以及嵌入式设备的出色应用程序，将谷歌级别的质量水准引入您的实际需求场景当中。

Flutter 为自由开源项目，我们期待有更多朋友使用 Flutter 2 构建起精美绝伦的开发成果！

原文链接：

https://developers.googleblog.com/2021/03/announcing-flutter-2.html"

对话中国移动：支撑数亿用户的基础设施如何实施云原生改造？ | 顶尖技术团队访谈

Wed, 17 Mar 2021 16:04:28 CST

如今，数字化转型已经成为绝大多数企业重要且迫切的发展战略之一。在这样的战略之下，企业上云成为大势所趋，基于容器、微服务、DevOps、服务网格等新型云原生技术正在深刻推动着企业 IT 变革，以实现全面数字化转型。而中国移动作为这批浪潮中的先行者，早已全面拥抱云原生技术并自主创新研发了磐基容器云、磐舟云交付平台。本期顶尖技术访谈录"，InfoQ走进中国移动信息技术中心，探索云原生变革背后的故事。

近几年，数字化转型和云原生改造成为业界两大热词，运营商也开始了与技术的又一次较量。作为支撑数亿用户日常生活的必备基础设施平台，其改造难度是非常大的。本文，InfoQ走进中国移动信息技术中心，一起聊聊他们如何看待数字化转型与云原生的意义。为什么要做云原生改造？决定改造后，人从哪找？团队KPI咋定？流程是什么样的？传统企业有必要自研吗？转型过程中有哪些注意事项......

为什么需要云原生？如何推进？

从2008年开始，中国移动就一直在探索转型升级之路，试图抓住“数字经济”带来的发展机遇。2008年，电信运营商按照“六合三”的方案进行了重组，进一步加剧了三大运营商之间的竞争，中国移动凭借着2G时代语音业务的网络效应迅速成为佼佼者。

随着3G时代的到来，整个行业又开始面临语音业务增长缓慢和收入减少的压力。2013年12月，中国移动获得固网宽带牌照成为全业务运营商。至此，三家运营商正式开启全业务领域竞争。

4G时代，面对更加激烈的竞争局势，中国移动提出“三条曲线”的发展策略，即：第一条曲线是中国移动语音和短彩信；第二条曲线是流量经营，主要是依靠4G的拉动；第三条曲线则是数字化服务。中国移动明确从网络、终端和营销三个方面向流量经营转型，并且更注重第三条数字化服务曲线的发展。

5G时代，基于5G数字化网络基础设施，中国移动打造泛在接入、泛在联接、泛在算力的信息高速，深化智慧运营创新，实现体验经营跃升，更加有效保障数字经济战略落地。

2019年，中国移动决定从通信服务向空间更广阔的信息服务转型升级，围绕“力量大厦”的总体思路，以高质量发展为主线，打造基于规模的融合、融通、融智价值经营体系，构建高效协同的能力、合力、活力组织运营体系。

对于体量巨大的中国移动来说，转型并不容易，这背后到底有哪些考虑呢？

InfoQ：您对数字化以及数字化转型的理解是什么？这在中国移动内部是如何执行的？

A：我之前也在想到底什么是数字化，“转型”二字又意味着什么。众所周知，中国移动是运营商，而运营商最开始做的事情在我看来就是数字化的，就是跟数字打交道的。那么，数字化转型是什么呢？

转型意味着变革，我觉得可以从三个层面理解：一是战略层面的转型，公司全力推进智慧中台构建，持续汇聚共性能力、对内支撑更多的业务场景、对外实现能力共享，促进公司数智化运营和全社会数智化转型；二是技术层面的转型，虽然以前也用到很多数字化的技术，但传统的IT技术与现在的云计算、人工智能相比有很大不同，解决的问题和关注的重点都不相同，这是技术层面的转型；三是业务转型，运营商早期的主要业务是电话、短信，现如今随着5G的出现，我们的业务越来越丰富。

综上，中国移动明确了总体发展目标，即创世界一流企业，做网络强国、数字中国、智慧社会主力军。确立通过推进数智化转型，实现高质量发展的发展主线，结合经济社会数字化转型“五纵三横”的特征，形成中国移动的战略内核。

围绕战略目标，我们开始更加关注数字化的价值。以往我们关注的是技术本身可以解决的问题，现在把重心更多地放在数字化如何赋能业务发展，如何赋能商业模式转型。这对IT提出了更高要求——即需要通过组织变革来支撑更高的目标，实现更高能力的锻造。

注：五纵三横指经济社会数字化转型呈现“五纵三横”的新特征。其中的五纵指的是基础设施数字化、社会治理数字化、生产方式数字化、工作方式数字化、生活方式数字化；三横指的是线上化、智能化、云化。

InfoQ：我们做云原生化改造的背景是什么？这和数字化转型的关系是什么？

A：多年前，我们的IT系统承载在小型机、磁盘阵列、传统商业数据库上，传统的IT架构，应用横向扩展能力较差；2008年起，我们从小型机向X86演进，大型的企业级应用向分布式服务化架构升级；2010年左右，我们引入虚拟化技术，大力推进基础设施云化，业务规模化扩展和灵活性得到提升，实现了底层资源的共享；2015年前后，我们逐渐从虚拟化向容器化过渡，不只是基础架构在快速变革，应用架构和交付也在升级，把大型复杂软件应用拆分成多个简单应用，各应用之间松耦合，从而降低了系统复杂度，还可以做到独立发布部署、独立扩展和跨语言编程，当然这一切的变化也将驱动我们研发、运维工作模式的转变。

在我看来，以往通过虚拟化技术将一台X86服务器虚拟化为多个虚机，当成物理机使用，这样的模式只解决了资源共享的问题，而云化不仅仅是基础设施和平台的变化，应用也需要做出调整，在架构设计、开发方式、部署维护等各个阶段都基于云的特点进行构建。云原生正是以应用为中心，应用开发之时便基于云的方式。只有这样才能更好地发挥出云的优势，更好地赋能业务发展。具体来讲，我们对于应用的要求主要是指：

1.敏捷。随着市场的快速发展，竞争日益激烈，对新功能的上线速度要求越来越高，我们需要化解高速的业务发展和系统稳定之间形成的矛盾，让“大象”能够起舞。

2.海量。我们需要支撑更多的互联网新业务、新玩法，需要足以支撑海量、高并发、高性能的业务系统架构。

3.简单。提高运维效率，解放劳动力。

在这样的背景下，中国移动IT系统建设全面拥抱云原生技术。

通过云原生改造，原本直接运行在虚拟机或者物理机上的业务系统，如今以高内聚、低耦合的应用独立运行在在容器里。以前一个新的应用系统需要从下到上完全自己重新搭建，现在大部分底层共性能力可以复用，极大地提高了开发效率，降低了成本，这就是我们所说的厚PAAS、薄应用。

根据多年的实践经验，我们打造了磐基容器云，以及磐舟云交付平台，面向内部IT系统提供承载和服务支撑，主要包括面向客户服务和业务管理的业务支撑系统(简称BSS或B域)、面向通信网络管理的网管支撑系统(简称OSS或O域)、面向企业内部管理的管理信息系统(简称MSS或M域)。

InfoQ：您方便介绍下整个云原生的改造历程是什么样的？

A：中国移动是首个完成大规模、分布式电信业务支撑系统X86化、容器化改造的运营商，领先同行业近两年时间。最早启动云原生改造的系统叫网状网，这个系统支撑了200多个业务平台，700多个业务，包括金融类、互联网类、全网业务订购类、客服类、实时鉴权类、区块链等业务，峰值交易量为75万笔/分钟。完成改造后，在高可用、故障自愈等方面效果尤为突出，当应用模块升级或某个服务不可用时，服务可快速从容灾节点拉起，用户访问无感知。

另一个实现云原生改造的系统是中国移动集中化物联网支撑系统。这个系统是物联网产品集中化管理能力一点接入、统一运营的业务支撑系统，提供了端到端的业务受理、服务开通、计费账务和综合结算等能力，支撑亿级连接高效运营。系统采用微服务化的设计理念，基于我们团队自研的磐基容器云平台，快速构建敏捷开发和智能化运营的容器化业务系统。

截至目前，共有40多个系统运行在磐基容器云上，集群规模约6600台服务器，业务容器数近4万个。

在业务迁移上云方面，我们总结并形成标准化的上云规范和云原生改造优秀实践案例。跟业务部门对接的过程中，前期会有个布道的过程，对租户进行相关培训，同时了解业务需求，完成梳理架构、容量预估，提供针对性的解决方案和指导；其次，业务部门采用微服务的设计理念，遵循“前端横向整合"，后端纵向解耦，服务提供与应用分离”的原则进行架构设计，完成容器化改造及微服务拆分；最后，逐步分离松耦合业务，完成部分流量切换验证，最终完成业务部署上线。在指导业务迁移上云的过程中，我们非常重视提前介入和收尾复盘，做到三同步：同步监控、同步高可用、同步安全。

团队人员及KPI制定

如火如荼的云原生世界，大部分人才被云厂商招致麾下，传统企业如何组建合适的研发团队呢？

InfoQ：您方便简单介绍下目前我们部门的人员组成吗？主要工作是什么？

A：我们部门是中国移动信息技术中心（公司）下属研发创新中心，还有一个牌子叫平台能力共享中心。目前部门共300余人，作为公司创新驱动的引领者、核心能力的内化者、技术演进的研究者、共性能力平台的运营者、核心测试能力的提供者，全面负责IT领域PAAS、AI、区块链、IPA等平台级产品的研发、测试、维护和运营推广；云原生平台的研运工作是我们部门的核心工作之一。

InfoQ：确定改造之后，承担云原生改造的团队人员大概来源是什么？

A：云原生平台核心研发团队近50人，包括架构设计、开发、运营、运维人员，承担整体架构设计，演进方向及新技术跟踪，容器云、DevOps以及智能运维等模块研发集成，为各业务部门提供云原生改造解决方案咨询、支撑、部署和维护服务。

团队成员一部分来源于公司内部, 在建设电信业务过程中多年积累的IT人才，抽调并重组，另一部分来源于社会招聘和校园招聘，我们也通过猎头专门招聘有经验的架构师。

我们更希望团队员工知识更加全面。不仅对容器等云原生技术方面有要求，也希望员工更多的了解中国移动为什么要做数智化转型，要对运营商业务应用架构演进敏感，热爱新技术，真正解决好现有系统的问题。综上，我们对人才的整体要求可以概括为“四懂”：懂需求，懂市场，懂客户，懂技术。

InfoQ：您方便介绍下内部是如何对人员进行培训的吗？

A：数字化战略方面，公司内部会定期组织“知识赋能行动”等系列培训；云原生技术分享方面，我们会请内部人员或者外请一些大厂的技术专家做分享；应用上云改造和实践方面，基于磐基容器云平台，为租户提供体系化的培训课程，包括K8S应用管理及云原生技术实践。后面也会逐步完善认证体系，为架构设计、开发、运维人员提供相应的培训及认证服务，云原生技术更新太快，需要我们的员工终身学习。

InfoQ：业务方的态度如何？

A：基于技术发展趋势和公司战略要求，各租户对于数字化转型意义的理解在逐渐深化，目前公司有序推进系统全面上云，各部门积极配合IT系统云原生改造。

通过云原生改造，租户发现上云可以明显提升资源使用率、提高应用高可用性，加快迭代上线速度；另外，部分开发运维工作可以交由云原生平台实现，业务部门可以更专注业务创新，创造更多的业务价值。

云原生改造的整个过程对业务人员来说，也是学习提升、能力锻造的过程，毕竟，云原生技术是未来的发展趋势。

InfoQ：你们整个团队的KPI是什么？

A：我们团队的KPI有以下三个部分：一是研发方面，重视需求采集分析，以应用为中心规划、设计产品，解决业务问题并且完成升级，跟随云原生社区的技术发展，提升产品开发、交付效率。二是推广应用方面，整个平台在公司内部支撑系统的规模要不断的提升,成为IT系统的技术底座。三是稳定支撑方面，要求能快速定位故障，并对故障快速排查解决（单体应用或SOA架构，故障定位相对容易，应用微服务化改造后存在大量的微服务，故障很难快速定位、对症下药，需要构建完善的监控体系和端到端服务跟踪工具；我们想到另一个比较好的解决方案是智能运维——AIOps，进一步提升故障定位和解决效率），真正实现我们团队提出的“乘舟上云，稳如磐基”。

InfoQ：公司层面对完成云原生改造有什么目标吗？

A：我们的目标是通过磐基容器云平台和磐舟云交付平台的打造，助力IT系统完成云原生改造，逐步实现全云化演进。

对于新建应用，要求云上构建；对于存量的业务系统，云原生改造是循序渐进的。结合云原生价值和业务痛点，对于需求频繁变更、大规模、分布式架构的业务支撑系统优先改造；对于一些缺乏开发团队维护的遗留系统、需求很少变化，以及业务逻辑耦合紧密、比较大的存量单体应用，暂缓改造。

另外，考虑到改造代价和价值，全部“重构应用代码”，并不是应用改造的唯一途径，对很多仍然在发挥作用的存量应用来说，重构封装应用代码的“应用运行时”也是一种更稳妥、有效的形式。

自研的动力是什么？如何选型？

在转型的过程中，中国移动基于云原生的理念，采用K8S和容器技术，自主研发了磐基容器云以及磐舟云交付平台。磐基容器云已经获得CNCF 的一致性认证和可信云容器平台的认证，磐舟云交付平台也获得平台级的DevOps 解决方案先进级认证。目前，磐基容器云平台已经支撑内部IT系统40 余个，覆盖BMO三域；磐舟云交付平台也逐步规模化运营，已有30余个系统正在使用这个平台，实现了X86、ARM双平面研发运行，大大增强了我们对IT系统软件资产的自主可控能力。

磐基容器云平台架构图

作为运营商，中国移动为什么有动力自研技术呢？

InfoQ：作为传统企业，为什么我们有动力自研核心技术？

A：可以从两个层面来看，在宏观层面，国家鼓励自主可控和科技创新，我们中国移动积极响应国家号召，大力推进核心能力内化，增强“端到端”自主可控能力，不断培养科技创新人才。

在需求层面，外部产品更加通用，平台的定制化程度及开发响应速度比较弱；不能很好的满足我们的业务场景、运营运维流程、研发规范要求，业务系统共性能力也很难得以快速的沉淀。

云原生改造的道路上，在构建、发布、运行三大领域都有更多的开源项目可以选择，我们可以站在巨人的肩膀上，引入、集成、优化和增强，让自研过程更加轻松。

InfoQ：自研之前有做过选型对比吗？

A：以往，合作伙伴开发的业务支撑系统在开发，运行过程中用到了容器云产品。在生产过程中，我们发现通过容器云平台很好的解决了弹性伸缩、故障自愈、容灾等问题；同时，我们对K8S的特性、包括一些关键组件的选型有了一定的积累。在此基础上，我们开始自研，并对K8S、容器底层技术，做了一些封装和优化，以提高其稳定性和安全性。

事实上，PaaS的范围太大了，也不可能完全自研。我们也会根据租户的需求，引入部分优秀组件快速地解决生产问题，如国产数据库、国产中间件以及容器安全方面的能力。我们会通过联合创新的方式，引入一些合作伙伴的高质量产品，实现生态链企业合作共赢。

容器云研发期间，我们也在打造全栈全场景的混合架构，业务可以根据场景需求，在双算力的平台下融合部署，混合调度，实现业务能力互备，资源共享。

硬件层面，在X86 基础上引入 ARM 算力，并向互联网公司学习，结合云原生改造需求，研发定制了云原生容器服务器。

在操作系统层面，积极拥抱开源社区，中国移动拥有自研的操作系统，也在积极探索openEuler开源操作系统部署应用，并尝试多元化容器运行时部署。

中间件层面，我们与东方通、中科院软件所、电子技术标准化研究院、国家信息中心、工商银行等单位一起中标了国家2020年基础支撑软件中间件项目，推动定制化中间件的研发和应用。

数据库层面，联合了业内5家企业进行联合创新，在应用场景中进行测试验证。通过不断的验证打磨，推动自主可控国产数据库的成熟落地。

请勿“人云亦云”

任何热门技术都逃不过“泡沫”，我们现在已然到了“不懂云原生不好意思出门的”境地，而热浪中总有喜欢看热闹不嫌事儿大的人，搅浑水的人以及淘金者。作为亲身实践者，中国移动又有哪些好的建议呢？

InfoQ：我们可以理解为云原生平台是某种形式的中台吗？

A：云原生平台实现了底层技术能力的复用，加快了应用上线速度，我们都认为是一种形式的技术中台，或者说数字化转型的技术底座。

InfoQ：对于希望做云原生改造的企业而言，您有哪些建议呢？

A：一是对于云原生改造，企业需要有自己的总体规划。系统整体架构未来要如何演进，各业务系统现存哪些问题和痛点，有哪些新的需求；二是云原生改造对人员的要求比较高，要具备架构的自主掌控力；三是云原生改造要循序渐进，平台部门要制定明确的研发、交付、运维规范，指导业务系统有序上云；四是要及时复盘，及时评估上云之后的效果和指标量化价值；五是运维支撑一定要跟上，包括安全体系，要构建完善的运维监控工具，解决好故障定位和监控难的问题；最后，构建一个成熟的系统往往需要一个相对比较长的运维和迭代过程，我们积极拥抱云原生的同时，也要做好踩坑的准备，稳步前行。

嘉宾介绍：

张春中国移动信息技术中心研发创新中心副总经理

魏宝辉中国移动信息技术中心研发创新中心架构师

郑文雯中国移动信息技术中心研发创新中心架构师

赵淳中国移动信息技术中心研发创新中心运营总监

迷你书推荐

中国顶尖技术团队访谈录（2021年第一季）开放下载"

本季精选了来自中国移动、vivo、苏宁、腾讯、网易等公司技术团队在技术落地、团队建设方面的实践经验及心得体会。InfoQ希望通过这样的记录，能够让一家家品牌背后的技术人员形象更加鲜活，让更多人感受到他们的可爱与坚持。

如果你正在传统企业经历了完整的数字化转型过程或者正在互联网公司进行创新技术的研发，并希望InfoQ可以关注并采访你所在的技术团队，可以添加微信：13051771597，请注明来意及公司名称。

有赞零售移动 CI/CD 实践

Sat, 05 Sep 2020 00:00:00 CST

点击关注“有赞coder”

获取更多技术干货哦～

作者：原野

部门：零售移动

一、背景

随着有赞零售业务的蓬勃发展，为了尽早交付有价值的应用满足客户需求，我们采用了敏捷开发的模式，快速拥抱变化的同时保持竞争优势。从 2019 年起，零售客户端的发版周期更改为每周一次，这对移动端的持续集成与交付提出更高的要求。如何根据现有的团队规模，在有限的资源下，快速搭建稳定可靠的持续集成与交付系统，我们有了自己的实践与思考。

二、问题与挑战

对于一个业务需求的开发或者迭代，移动开发同学除了编写代码，还需要经历打包、测试，如果 QA 同学反馈问题，则需要进行修复，然后再次经历打包、测试，直至测试通过，才能交付产品。整个过程中，开发同学需要手动提交 MR，手动触发打包构建以及实时监控打包流程的状态。如此下去，开发同学手头上的工作会被频繁打断，去跟踪处理这些流程的衔接，必然会严重影响开发专注度，降低开发生产力。

那么，随着业务的复杂，项目的壮大，团队人员的增多，这类问题会愈发严重。而且，在编码过程中，一些通过文档规定或是意识上达成的共识，实际执行起来会变得越来越困难，这些都是不可持续的。因此，从代码提交到最终打包交付便成了保证代码与产品质量，十分重要的一个环节。

三、自动化流程体系

持续集成与交付系统是一块大又杂的领域，我们这次主要介绍一下从代码提交到打包交付的一套自动化流程体系，解决上述提到的问题。由于有赞零售的代码是托管在 GitLab 平台上的，因此我们采用基于 GitLab CI 搭建持续集成平台，当然我们也使用 Jenkins 配合做一些辅助性的工作。

3.1 流程与架构

3.1.1 流程

我们先从一个开发工程师的角度，来整体感受一下现在的开发及交付的流程。开发工程师首先从 dev分支 checkout 出自己的 feature分支进行迭代，在迭代过程中不断地向自己的 feature分支提交代码，提交代码过程中会有本地检查这一道保障，当需求开发完成，在 feature分支上构建出对应的阶段提测包并提交 QA 进行测试，测试通过后，提交 MR 准备合并入 dev分支，通过编译检查和 Code Review 后，才能允许合并至 dev分支。在 dev分支上的代码是可靠的，会有静态检查再次进行保障，而且也会有 QA 进行回归测试，直至所有 bug 修复完毕，交付最终的产品进行验收。

3.1.2 架构

这套体系主要分为 5 个部分，下文会具体介绍一些细节：

CI（持续集成）：GitLab、Jenkins
CD（持续交付）：MBD、APUB、移动助手 App
检查：编译检查、本地检查、静态检查
Code Review：Git Hooks、GitLab CI
消息与闭包：企业微信消息通知、企业微信群机器人、企业邮件、检查报告、JIRA…

3.2 打包与分发

持续集成与交付的目的是快速迭代，并且交付稳定可靠的产品。从移动端的角度来看，我们可以理解为快速构建出不同分支、版本，且稳定可靠的应用包。并且，能够将应用包快速分发到 QA、PM、UED 等各个业务方同学手上。

3.2.1 打包

有赞零售的打包接入了有赞的移动构建集成平台 MBD (Mobile Build)，MBD 提供了便利的打包操作，支持 iOS、Android、Weex 等多个构建集成平台，可以选择任意分支、版本进行构建，并且提供了可远程调用的 API 方便持续集成。当然，如果技术团队还没有类似的构建集成平台，或者现阶段去开发一个平台的效益并没有那么高，也可以选择通过 Jenkins 搭建 iOS 或 Android 的自动化打包构建任务，实现成本较低。

简单介绍一下 MBD 的使用流程，首先需要添加组件，填入工程的一些重要信息（如 Bundle ID、SSH 地址…），再编写构建脚本（如运行 pod、fastlane…），根据组件创建出对应的集成单。我们后续的打包流程，主要就是通过已经创建的好的集成单，输入对应的版本号、分支名等信息，触发集成单的构建，最后处理构建反馈的结果，构建产物就是可供下载的应用包。

3.2.2 分发

为了减少 QA 和开发之间的低效沟通以及优化 App 包的分发流程，我们急需一个平台来统一管理分发公司内部的 App 包，于是有赞移动应用发布平台 APUB (App Publish) 应运而生。与 MBD 无缝衔接，可以实现从构建到发布、热修复、交付一系列流程的打通，并且提供了有赞移动助手 App 这个入口，方便下载各个业务线的 App 包。

有赞移动助手 App 提供了许多好用的功能：

正式版、测试版应用的下载
内网网关、开发环境的切换
应用包的基础信息（打包人、包版本、包体积、构建分支…）

想要了解有赞移动基础设施建设相关内容，可以详见文章：有赞移动基础设施建设的实践和思考

3.3 检查体系

不过，谈到持续集成与交付，我们不能忽略了一个关键点：出包的可靠性。如何保证出包的可靠性呢？答案：检查。

3.3.1 编译检查

编译检查可以认为是最重要的守门员，编译检查能否通过，直接决定了打包能否成功。我们的第一反应是可以通过修改编译脚本，在每次打包前加入编译检查，来确保出包的可靠性。然而，这其中潜藏着一个很严重的流程性问题。原本出包是一个箭在弦上的事情，但是，因为在出包前加入了编译检查，使整个流程受这个前置条件的影响。想象这样一个场景，一旦编译检查出问题，我们就得通过日志定位问题，然后找相关工程师进行修复，修复完毕，再触发打包，可能又检查出新的问题，反反复复，使得出包变得非常的低效。

为了解决上述的问题，我们调整了检查策略。在一些可靠的分支，如 dev、release 进行 MR 的时候，通过 GitLab Runner 触发编译检查的 Pipeline，只有检查通过，相关的代码才能够被允许合入对应的分支。

为了能让大家有个简单的概念，介绍一下几个名词：

GitLab Runner：GitLab CI 提供注册 CI 服务器的接口，执行构建任务的一个服务，即 Pipeline 运行的具体环境，能够运行 Pipeline 并将结果发送回 GitLab，通常是和仓库托管的服务区分开来，部署在不同的机器上
Pipeline：一次 Pipeline 其实相当于一次构建任务，里面可以包含 CI 不同阶段的不同任务，我们的编译检查就是运行在这个流程中，触发的条件也很多，我们选择 MR 的时候触发编译检查的 Pipeline

至于 GitLab Runner 如何搭建就不再赘述了，可以查看官方文档。我们可以来感受一下 GitLab CI 的架构设计：

我们对于编译检查进行了一些提速优化，使得平均时间稳定在 5 分钟左右：

全量编译和差量编译的区分
可忽略编译的文件，进行白名单配置
缓存外部依赖文件…

3.3.2 本地检查

由于资源有限，目前的 GitLab Runner 是单机状态，并没有进行多机并发处理。所以，如果一股脑全部依赖编译检查，一旦同一时间段内 Pipeline 数量变多，很可能就会处于排队等待中，MR 的环节也会因此变得十分的冗长。除了优化编译检查，我们可以把部分检查的时机再提前。

本地检查，具体一点可以叫做本地代码提交检查。本地代码提交检查可以有效的保证代码提交质量。除了 Lint 这类的代码风格统一的检查，在业务上，最重要的是对跨模块的代码修改做了一定的限制，还可以检查一些关键的配置文件是否被不小心修改。

举个小例子，比如 A 同学没有修改 RetailStock 模块的权限，但是 A 同学在 RetailStock 下的 YZStockBundle.h 文件增加了一行注释，准备提交代码。会在 git commit 这个时机，进行本地代码提交检查，发现了 A 同学修改了 RetailStock 模块的代码对其进行提醒，并且提供了一个 Code Review 的 URL 链接通过 git diff 展现代码修改的内容，如果真的由于业务需要，可以由 RetailStock 模块的相关负责人 Review 后同意修改。

搭建本地代码提交检查，需要使用 Git Hooks，我们这边 hook 了 commit-msg，当然你也可以 hook prepare-commit-msg、 pre-commit等其他 Git 钩子将脚本进行更精细的拆分。

简单介绍一下，如何配置本地代码提交检查。

deploy_git_hooks.sh：部署脚本，方便小伙伴一键配置
commit_msg_analyzer.sh：本地代码提交检查的入口脚本

工程目录结构：

  .   
├── .git   
│   ├── hooks   
│   │   ├── commit-msg   
│   │   ├── commit-msg.sample   
└── scripts   
└── git-hooks   
├── commit_msg_analyzer.sh   
└── deploy_git_hooks.sh

deploy_git_hooks.sh：

  #!/bin/bash -l   
   
current_dir=$(cd $(dirname $0) pwd)   
scripts_dir=$(dirname $current_dir)   
project_dir=$(dirname $scripts_dir)   
git_dir="$project_dir/.git"   
git_hooks_dir="$git_dir/hooks"   
   
commit_msg="$git_hooks_dir/commit-msg"   
analyzer="$current_dir/commit_msg_analyzer.sh"   
   
if [ ! -d $git_dir ]; then   
echo ".git not exist"   
exit 1   
fi   
   
if [ -f $commit_msg ]; then   
echo "commit-msg already exist"   
exit 1   
else   
if [ -f $analyzer ]; then   
chmod +x $analyzer   
ln -sf $analyzer $commit_msg   
echo "deploy success"   
else   
echo "commit_msg_analyzer.sh not exist"   
exit 1   
fi   
fi

commit_msg_analyzer.sh：

  #!/bin/bash -l   
   
# 校验提交说明是否标准   
# 检查代码风格   
# 检查是否存在关键配置文件的修改   
# 检查是否存在跨模块的修改   
# ...

3.3.3 静态检查

静态检查可以在编码规范，代码缺陷，性能等问题上提前预知，从而保证项目的交付质量。现阶段自助研发一套静态检查工具，投入产出比并不高，但是我们可以借助三方框架快速搭建起来，并且定义了一些错误的过滤规则，让我们更加聚焦迫切需要解决的问题。iOS 侧我们选择了 Clang 支持度最好的 scan-build 作为首选，以及精度最高的 Infer 作为配合使用。Android 侧首选 Android Lint，其内容涵盖了大部分 Android 的检测内容，并且使用 FindBugs 作为 Android Lint 在 Java 语言层上的补充。

iOS：scan-build + Infer
Android：Android Lint + FindBugs

对于可靠的分支，比如 dev 分支，我们选择定时触发，如每天晚上触发。当然，开发者也可以选择主动触发，选择对应的分支执行静态检查。静态检查报告会通过企业微信消息通知的方式，发送给执行者。定时触发的静态检查，检查出错误后，除了生成报告，而且会根据错误找到相应的模块负责人，创建 JIRA Issue。

3.4 Code Review

Code Review 的重要性是毋庸置疑的，这里提到的 Code Review 并不是指项目开发完成后组织的 Group Code Review，主要是针对持续集成与交付过程中，需要或者说必须要进行的一环。我们前面讲到的本地代码提交检查后，发现有跨模块代码的修改，就是需要相关模块的负责人进行 Code Review 的。

对于那些可靠的分支进行 MR 的时候，则必须要经过两个同学 Review 后确认没有问题，才能允许进行合入操作。Review 时，可以对需要改进的代码进行评论。从进行 Review 的同学角度来说，不仅能够看到新需求的逻辑与问题，还可以碰撞不同的架构思想。从被 Review 的同学角度来说，则可以发现一些由于思维定式或者粗心造成的问题，也可以采纳一些好的建议，让代码更加健壮且优雅。

通过 GitLab CI 的 Merge Request 机制，可以很方便快捷的搭建这套体系。每个 MR 只有通过了 Pipeline 并且所有 Reviewer 的评论都得到解决，最终由拥有 MR 权限的同学进行 Merge 操作。

简单介绍一下，GitLab Merge Request 几个好用的功能：

不仅支持对整个 MR 进行评论，而且支持对每行代码进行评论，并且评论后会自动将其标注为 待解决的状态
在提交 MR 的时候支持配置目标 Approvers 以及 Reviewers，在对项目进行配置的时候也可以配置至少需要哪几个同学同意才能进行 Merge
可以设置只有 Pipeline 执行通过才允许进行 Merge，这里的 Pipeline 就是指前面提到的编译检查，只有检查通过了，有合并权限的 Reviewer 才被允许点击 Merge 按钮进行合入操作

日常实践中，我们发现了直接通过 MR 进行 Code Review 的一个痛点。比如在一个稍微大一点的项目开发中，动辄就是几百个 Changes，几千个 Additions 或 Deletions。这样不仅 Reviewer 需要耗费大量的时间去理解逻辑和审查代码，而且往往也很难发现一些隐藏很深的问题，简而言之，就是使得这次的 Code Review 非常的耗时且低效。

我们也在积极探索和实践更好的 Code Review 的形式，有个简单思路就是将最后 MR 进行前置分解，通过调整 GitLab Flow 把 Code Review 放到每个分解的 MR 中。

3.5 消息与闭环

持续集成与交付过程中，消息与闭环也是非常重要的一环。能够减少沟通成本，能够在自动化的流程中，让使用者更加无感知，不用时不时的去跟踪处理流程的衔接。监控的成本大大降低，正常情况下感知流程进行的节点即可，重点只需要关注异常流程，因为这个时候需要人工介入处理。

目前，主要依赖的消息通知方式：

企业微信的消息通知
企业微信的群机器人
企业邮件

闭环方式中，最值得一提的是搜集出包的变更集。应用包在提测期间，也经常会有一些 bug 产生，修复后需要重新打包，如何比较 2 个提测包之间的差异及变更？这里，给出 2 个解决方案：

3.5.1 方案一

根据上述的流程体系可知，目前可靠分支的代码合并都是需要通过 MR 的方式。我们可以搜集 2 个提测包之间所有的 MR 提交，并规定好 MR 的提交模板， 变更内容就是其中的必填项之一，然后过滤出提交信息中的 变更内容，由群机器人进行通知。

这是我们目前采取的方案，对现有的流程以及小伙伴们的操作习惯改变最小。小伙伴们提交 MR 的时候，只需要根据提供的 MR 模板填入对应信息即可。还有一个好处， 变更内容更像是 MR 申请者对本次改动点的总结，能够更好的概括此次 MR 涉及的改动点。而且，我们规定在提测期间的每个 MR 都是需要有对应的 JIRA Issue 链接，方便 QA 追踪及回归。

3.5.2 方案二

首先，需要规范 git commit，这一步可以通过一些开源的工具解决，比如：commitizen。最终通过 git log 的方式，过滤出 2 个包之间新增的所有 git commit。

这样做的好处是，能够通过 git log 获取到所有代码提交的改动信息。坏处是，需要规范 git commit 流程的学习成本，其次是庞大的 git commit 信息是否真的有必要？大量的 git commit 信息不仅冗杂，而且不能很好的区分到底哪些是为了修复某个问题而产生的提交。

当然，也可以解决这个问题，就是前面提到的需要严格规范每一次的 git commit。简而言之，严格执行规范本身就是不可持续的，可能对小伙伴们的操作习惯改变也较大，因此快速落地的成本也会比较大。但是，规范 git commit 仍然是一个很好举措，它的价值远远不只是为了搜集变更集，也是开发过程中排查问题的一个好习惯，是后期需要真正落地的一个规范。

流程中，还有一些比较重要的闭环方式：

核心用例自动化报告
静态检查报告
JIRA Issue

四、思考与展望

在持续集成与交付系统实践过程中，并没有一套所谓最好的或者是标准的解决方案。每个公司或者团队所处的阶段不同，提供的资源不同，采用的方案也会不一样。但是，如果你目前正在或者将要做相关实践时，一定要衡量好投入产出比，确保整个流程尽可能的简化，尽可能的减少使用者的学习成本，将其系统化、高效化以及自动化。

当前，有赞零售业务仍然处于快速增长阶段，移动端在持续集成与交付这块才有了一点雏形。未来我们的建设主要会集中在 2 个方向，更加健壮的代码管控体系和更加完备的自动化测试流程。如上文所述，随着业务越来越复杂，涉及的角色越来越多，代码集成的管控需要更加严格，而严格的代码集成管控将增加团队成员每次提代码的痛苦。如何做到差异化的检查和准入，将是未来持续集成的建设方向。

目前，除了移动端发版核心用例 UI 自动化，还有大量的测试 Case 都需要 QA 人工保障。我们希望未来能够尽可能地采用自动化为主的方式进行测试，覆盖大部分的场景，而让 QA 可以集中精力测试新功能或非常边界异常的场景验证。

附上邮箱 zhouyuanye@youzan.com，可内推、聊技术和思考产品。

扩展阅读：

传工信部调整网间结算标准：电联失意，移动摘“帽”

Wed, 04 Mar 2020 07:51:33 CST

C114讯 2月26日消息（水易）网传，工业和信息化部发布了一份关于调整互联网骨干网网间结算政策的通知。文件中指出，为深入贯彻落实网络强国战略，构建科学合理的网间结算关系，加快推进网络设施建设和提速降费，促进我国互联网产业和数字经济发展，经深入研究论证，对我国互联网骨干网网间结算政策予以调整。消息一出，引发了业内广泛关注和讨论。

涉及多项政策调整

一是，2020年7月1日起，取消中国移动与中国电信、中国联通间的单向结算政策，实行对等互联，互不结算。7月1日前，维持现有网间结算政策和结算标准，即中国移动应向中国电信、中国联通支付互联网骨干网网间结算费用，结算标准不高于8万/G/月。

二是，为扶持市场新进入者，激发市场活力、促进行业整体高质量发展，2020年1月1日起，中国电信、中国移动和中国联通下调对中国广电、中信网络的结算费用，下调比例不低于现有标准结算价（8万/G/月）的30%。

三是，2020年1月1日起，教育网、科技网、经贸网、长城网等公益性网络与中国电信、中国移动和中国联通的互联网骨干网之间实行免费互联。

四是，各互联网骨干网互联单位应严格遵守相关法律法规，不得使用第三方违规带宽资源进行网络互联，确保各骨干网网间路由合规配置。

五是，中国教育和科研计算机网网络中心、中国科学院计算机网络信息中心、中国国际电子商务中心、中国长城互联网网络中心等公益性网络互联单位应严格遵守“专网专用”原则，不不得利用公益性网络资源非法从事电信业务经营活动。

六是，实行以网间质量为核心的监督管理机制，依据《互联网骨干网网间通信质量监督管理办法》，加大网间扩容争议协调解决力度。对违反规定的互联单位，依法实施提醒、督办，约谈、警告、行政处罚等，保障网间通信畅通。

将利好哪些企业？

政策发布之后，被讨论最多的无非是谁将获益，谁将损失一部分收入。很显然，作为传统模式下，收取网间结算费用的中国电信和中国联通而言，不可避免的将减少一大笔收入。

短期来看，这一政策的最直接受益方无疑是中国移动，不同于语音和短信的网间结算，中国移动与中国电信、中国联通之间的骨干网互联网网间结算一直是单向的，也就是说中国移动的用户访问中国电信、中国联通数据中心内的内容和服务所产生的带宽，中国移动就需要支付相应的费用。要知道早期的IDC资源基本都掌握在中国电信和中国联通手中，按照中国移动现阶段的用户基数来说，这是一笔不小的支出。相反，对于中国电信和中国联通来说这是一笔可观的收入，因而有人戏称这是直接抢走了电信联通的一块肉。

与此同时，对等互联，互不结算之后，中国移动甩掉了被强扣在头上多年的“二级运营商”的帽子。当然，中国移动能够收获这个政策，最根本的原因是用户体量已经形成规模，截至2020年1月，中国移动的移动用户数累计达到9.49415亿户，固定宽带用户数累计达到1.88271亿户，需要对等互联来满足用户的需求。再加之，随着近年来中国移动对IDC资源不惜成本的投入，以及对骨干网带宽的投入成效明显，网络规模不断扩大，有足够的体量和资本与中国电信和中国联通对等互联。

另外，对于中国广电而言，一直以来，中国广电的用户基数相对较小，网络规模小，运营主体也分散，基本是一省一个运营主体的情况，为了满足这小部分用户的需求，必须要向传统三大运营商支付网间结算费用，在流量爆炸性增长的今天，这是一笔不少的支出，所以中国广电一直希望能够在网间结算方面获得政策的扶持。虽然此次并没有获得与中国移动一样的待遇，但是也获得了一定的政策优惠，更有利于其未来5G的发展。

不过，在笔者看来，此次政策调整的最大受益方是中信网络。中信网络的骨干网资源与其余几家存在不同，其目标市场是2B市场，潜在客户也是CSP（云服务提供商）、行业与企业用户，而这部分用户对带宽的需求相较个人用户更为可观。去年，工信部已向中信网络颁发了新的基础电信业务牌照，中信网络获准从事互联网国内数据传送业务，再加上这次网间结算费用政策的支持，更是如虎添翼。长远来看，某种程度上，按照中信网络比三大运营商更加理解政企客户市场需求，将对三大运营商在政企市场形成一定冲击。

当然，对于普通消费者而言，则是最终的受益方。一方面中国移动与中国电信、中国联通实现对等互联后，减少网间结算过程将在一定程度上提升用户体验；另一方面，无论是取消网间结算费用，还是降低网间结算费用，或许会带来一定的降费空间。

Vue 移动端框架

Thu, 27 Feb 2020 00:00:00 CST

1. vonic

vonic 一个基于 vue.js 和 ionic 样式的 UI 框架，用于快速构建移动端单页应用，很简约。
中文文档| github地址| 在线预览

vonic

2. vux

vux 基于WeUI和Vue(2.x)开发的移动端UI组件库。基于webpack+vue-loader+vux可以快速开发移动端页面，配合vux-loader方便你在WeUI的基础上定制需要的样式。小编在开发微信公众号的时候使用过，欢迎来评论区吐槽。
中文文档| github地址| 在线预览

vux

3. Mint UI

Mint UI 由饿了么前端团队推出的 Mint UI 是一个基于 Vue.js 的移动端组件库。
中文文档| github地址| 在线预览

Mint UI

4. Muse-UI

基于 Vue 2.0 和 Material Design 的 UI 组件库
中文文档| github地址

Muse-UI

5. Vant

是有赞前端团队基于有赞统一的规范实现的 Vue 组件库，提供了一整套 UI 基础组件和业务组件。
中文文档| github地址| 在线预览

Vant

6. Cube-UI

滴滴 WebApp 团队实现的基于 Vue.js 实现的精致移动端组件库
中文文档| github地址| 在线预览

Cube-UI

7. vue-ydui

Vue-ydui 是 YDUI Touch的一个Vue2.x实现版本，专为移动端打造，在追求完美视觉体验的同时也保证了其性能高效。目前由个人维护。
中文文档| github地址| 在线预览

vue-ydui

8. Mand-Mobile

面向金融场景的Vue移动端UI组件库，丰富、灵活、实用，快速搭建优质的金融类产品。
中文文档| github地址| 在线预览

Mand-Mobile

9. v-charts

在使用 echarts 生成图表时，经常需要做繁琐的数据类型转化、修改复杂的配置项，v-charts 的出现正是为了解决这个痛点。基于 Vue2.0 和 echarts 封装的 v-charts 图表组件，只需要统一提供一种对前后端都友好的数据格式设置简单的配置项，便可轻松生成常见的图表。特别感谢 @书简_yu的贡献。
中文文档| github地址| 在线预览

v-charts

10. Vue Carbon

Vue Carbon 是基于 vue 开发的material design ui 库。
中文文档| github地址| 在线预览

Vue Carbon

11. Quasar

Quasar（发音为/kweɪ.zɑɹ/)是MIT许可的开源框架（基于 Vue），允许开发人员编写一次代码，然后使用相同的代码库同时部署为网站、PWA、Mobile App和Electron App。使用最先进的CLI设计应用程序，并提供精心编写，速度非常快的Quasar Web组件。
中文文档| github地址

Quasar

12. Vue-recyclerview

使用vue-recyclerview掌握大型列表。
github地址| 在线预览

Vue-recyclerview

13. Vue.js modal

易于使用，高度可定制，移动友好的Vue.js 2.0+ modal。
在线文档| github地址| 在线预览

Vue.js modal

14. Vue Baidu Map

Vue Baidu Map是基于Vue 2.x的百度地图组件。
中文文档| github地址| 在线预览

Vue Baidu Map

15. Onsen UI

将Vue.js的强大功能和简单性带入混合和渐进式Web应用程序。
在线文档| github地址| 在线预览

Onsen UI

Vue PC端框架

别走，还有后续呐······
如果小伙伴们有比较好的移动端框架，欢迎在评论区留言砸场，谢谢你的贡献。

看完文章还有福利拿，往下看
小伙伴可以在公号【grain先森】后台回复【190301】获取130套简历模板。后期小编会建微信群和大家交流分享，期待你们哦！

移动端flex布局实战

Thu, 11 Jul 2019 10:14:50 CST

原文网址： http://yanhaijing.com/css/2016/08/21/flex-practice-on-mobile/

做过移动端的同学都知道移动端布局太难了，终端太多了，传统的布局方式已经力不从心，各种新的布局方式被发明

在flex之前，传统布局有流式布局（就是默认的方式），绝对定位布局，弹性布局（em），和浮动布局，其中浮动布局并不是为布局而设计的，使用起来略显繁琐

2009年，对前端来说是不平凡的一年，html5定稿，es5.1发布，flex应运而生，天生响应式，生而为布局，使用及其简单

但是理想很丰满，现实很骨感，flex三改其规范，浏览器实现不一，各种神坑，本文将总结2017年移动端使用flex的最佳实践和经验

兼容性

2017年9月份，现在来看下flex的兼容性，可以发现绝大部分都是绿色

上图中红色箭头代表我们应该兼容的浏览器情况，在国内，UC和QQ浏览器的份额不容忽视，上图中的 1 2 3 其实代表flex的三版语法，flex有09年版语法，11年版语法和标准语法；右上角带黄色小方块的代表需要添加-webkit-前缀

将上图总结一下，移动端需要的兼容情况如下：

安卓	2.1-4.3	4.4-∞	UC 11.4	QQ 1.2-∞
语法版本	09版	标准	09版	标准
是否前缀	是	否	是	否

iOS Safari	3.2-6.1	7.1-8.4	9.2–∞
语法版本	09版	标准	标准
是否前缀	是	是	否

再来看一下百度给出的移动设备的统计情况，分别是安卓和ios，可以发现现在需要兼容安卓4.1+，IOS7+，这里百度给出的数据，当然你应该根据自己产品的统计情况来确定兼容情况

总结一下本文各处的最佳实践，兼容性目标是安卓4.1+，IOS7+，UC和qq浏览器

属性对照

通过上面的目标和caniuse，很容易得出我们需要写09和标准两版语法，只有在两版语法中都存在属性才能使用，下面给出两版语法的对照关系，注意这不是语法指南，语法指南请看结尾处的推荐资料

容器的属性

容器属性包括：

display
flex-direction
flex-wrap
flex-flow
justify-content
align-items
align-content

display

标准版	09版
display: flex	display: box
display: inline-flex	display: inline-box

flex-direction

标准版	09版
flex-direction: row	box-orient: horizontal; box-direction: normal
flex-direction: row-reverse	box-orient: horizontal; box-direction: reverse
flex-direction: column	box-orient: vertical; box-direction: normal
flex-direction: column-reverse	box-orient: vertical; box-direction: reverse

flex-wrap

标准版	09版
flex-wrap: nowrap	box-lines: single
flex-wrap: wrap	box-lines: multiple
flex-wrap: wrap-reverse	无

flex-flow是flex-direction和flex-wrap两个属性的简写，09版无对应属性，09版可以分开写两条属性

justify-content

标准版	09版
justify-content: flex-start	box-pack: start
justify-content: flex-end	box-pack: end
justify-content: center	box-pack: center
justify-content: space-between	box-pack: justify
justify-content: space-around	无

align-items

标准版	09版
align-items: flex-start	box-align: start
align-items: flex-end	box-align: end
align-items: center	box-align: center
align-items: baseline	box-align: baseline
align-items: stretch	box-align: stretch

align-content，09版无对应属性

项目的属性

项目属性包括：

order
flex-grow
flex-shrink
flex-basis
flex
align-self

order

标准版	09版
order: number	box-ordinal-group: number

flex-grow，09版无对应属性

flex-shrink，09版无对应属性

flex-basis，09版无对应属性

flex，标准版的flex是一个复合属性，09版的box-flex仅支持配置数字

标准版	09版
flex: flex-grow flex-shrink flex-basis	box-flex: number

align-self，09版无对应属性

09版的语法对flex项目的可配置功能非常弱，仅能调整顺序和伸缩性

采坑经验

一般来说只要09版语法有对应功能，就可以使用了，但是移动端还有一些坑，导致某些属性不能用

justify-content: space-around 不能用，旧版语法没有，但是可以用space-between+容器的padding模拟

flex-wrap: wrap 不能用，对应的旧版语法 box-lines: mutiple 大部分浏览器不支持，也就是说不能折行

uc span行内元素作为子项时 display 必须设置为block，最好直接使用块级元素

实战

说了这么多下面给一份标准的写法，一个flex属性应该这么写

          webkit前缀09版
webkit前缀标准版
标准版

举个例子，display: flex要这么写

          display:-webkit-box;display:-webkit-flex;display:flex;

一定有同学说这也太麻烦了，有没有啥简单的办法呢？还真有，共有三种办法，感谢前辈

第一种，编辑器插件，有一个叫做autoprefix插件，sublime就可以安装，你只需写标准属性，然后按一下快捷键就能够自动填充前缀属性。这种方法用起来最简单，但这种方法后面会不太好维护，比如有一天不需要09版语法了怎么破？？？一个一个去改吧，o(╯□╰)o

第二种，预处理器mixin，如果你用过less或者sass的话，一定知道mixin，下面已less 2.x为例，sass大同小异

      .display-flex(@display: flex) {
    & when (@display=flex) {
        display: -webkit-box;
    }
    & when (@display=inline-flex) {
        display: -webkit-inline-box;
    }
    display: e("-webkit-@{display}");
    display: @display;
}

.flex-direction(@direction) {
    & when (@direction=row) {
        -webkit-box-orient: horizontal;
        -webkit-box-direction: normal;
    }
    & when (@direction=row-reverse) {
        -webkit-box-orient: horizontal;
        -webkit-box-direction: reverse;
    }
    & when (@direction=column) {
        -webkit-box-orient: vertical;
        -webkit-box-direction: normal;
    }
    & when (@direction=column-reverse) {
        -webkit-box-orient: vertical;
        -webkit-box-direction: reverse;
    }
    -webkit-flex-direction: @direction;
    flex-direction: @direction;
}

.flex-wrap(@wrap) {
    & when (@wrap=nowrap) {
        -webkit-box-lines: single;
    }
    & when (@wrap=wrap) {
        -webkit-box-lines: multiple;
    }
    -webkit-flex-wrap: @wrap;
    flex-wrap: @wrap;
}

.justify-content(@justify-content) {
    & when (@justify-content=flex-start) {
        -webkit-box-pack: start;
    }
    & when (@justify-content=flex-end) {
        -webkit-box-pack: end;
    }
    & when (@justify-content=center) {
        -webkit-box-pack: center;
    }
    & when (@justify-content=space-between) {
        -webkit-box-pack: justify;
    }
    -webkit-justify-content: @justify-content;
    justify-content: @justify-content;
}

.align-items(@align-items) {
    & when (@align-items=flex-start) {
        -webkit-box-align: start;
    }
    & when (@align-items=flex-end) {
        -webkit-box-align: end;
    }
    & when (@align-items=center) {
        -webkit-box-align: center;
    }
    & when (@align-items=baseline) {
        -webkit-box-align: baseline;
    }
    & when (@align-items=stretch) {
        -webkit-box-align: stretch;
    }
    -webkit-align-items: @align-items;
    align-items: @align-items;
}

.order(@order) {
    -webkit-box-ordinal-group: @order;
    -webkit-order: @order;
    order: @order;
}

.flex(@flex) {
    -webkit-box-flex: @flex;
    -webkit-flex: @flex;
    flex: @flex;
}

在使用的只要一行就行了

      .container {
    .display-flex;
    .flex-direction(row);
    .justify-content(center);
}

上面的代码less编译完的结果如下

          .container{display:-webkit-box;display:-webkit-flex;display:flex;-webkit-box-orient:horizontal;-webkit-box-direction:normal;-webkit-flex-direction:row;flex-direction:row;-webkit-box-pack:center;-webkit-justify-content:center;justify-content:center;}

有同学说这么麻烦，我不想写啊？其实应该有人已经写好了，比如 compass，可以参考一下

这种方式的前提就是已经使用了css预处理器，可维护性比第一种方法更好；但是以我的经验来说，其实大部分项目的mixin未必是有人维护的，比如可能有一天不需要前缀版本了，但是并一定会有人去更新的

第三种，css后处理器，其实自从postcss出来之后，自动加前缀的活就该交给postcss来做了，有了这个插件我们只需要配置要兼容的浏览器版本就可以了，加前缀的事情后处理器自动帮你解决，最近babel也出了一个类似的babel-env

fis中可以使用 fis-postprocessor-autoprefixer这个插件，我在之前的文章《经验无线步骤页改版总结》中有介绍

webpack中可以使用 postcss-loader这个loader

终于可以和浏览器前缀愉快的玩耍了^_^

普及一个小科普知识，css后面的实验室性不会再以加前缀的方式进行了，而是会通过浏览器的设置方式来显示开启实验属性，因为前缀的方式不够优雅。。。这锅主要还是怪前端开发者，因为我们啊，只写webkit前缀，都不写标准属性，o(╯□╰)o

总结

希望本文能够帮助你更好的使用flex，少踩一些坑，现在在移动端已经可以任性的使用flex了，但pc端还不行，ie8。。。如果没有兼容性问题，那就快来使用这一好用的布局方式吧

最后我强烈建议大家阅读大漠老师的《图解CSS3》，这是我见过讲css3讲的最好的书了

Google Glass 企业版第二代发布，支持 Android 移动设备管理

Thu, 23 May 2019 01:34:43 CST

Google Glass 研发又有了新进展，周一 Google 发布了第二代企业版智能眼镜（Google Glass Enterprise Edition 2），售价为 999 美元。Google Glass 最早于 2013 年推出，当时面向普通消费者。

它利用微型投影仪将计算机生成的图像发送到用户眼中，图像看起来像是浮动在现实世界之中。最终因为原装 Google Glass 价格高昂和内置相机引发的隐私问题，针对消费者的最早 AR 设备宣告失败。

两年后 Google 推出了全新的 Google Glass，它将这款新产品重新定位为面向企业，为外科医生、工厂工人和其他专业人士使用的工具。企业版 Google Glass 升级了原有配置，更好的处理器，更高清的摄像头。如果用户不用来拍摄的话，续航时间能保持在 8 小时左右。第一代企业版的重量基本和传统眼镜相当，并仅在一边眼镜上方安装了小型投影仪。

第二代 Google Glass 和上一代外观设计上没有太大变化，不过依然在充电速度、芯片、镜架和移动设备管理方面进行了升级。

它会在功能更强大的高通 Snapdragon XR1 平台上运行，这一芯片专门针对 AR 和 VR 设计。Google 表示，凭借 XR1 的功能，新款智能眼镜将可以加入“计算机视觉和先进的机器学习功能”。

Google 还和史密斯光学公司合作开发出新的镜架，看起来和普通眼镜差不多，这意味着它相对其他智能眼镜而言，佩戴起来更为轻便。此外，电池续航时间和其他组件也有所改进。

这款新眼镜是基于 Android 平台开发，因此用户可以在移动设备上配置应用和服务。企业可以更便于分发给员工使用，并且能够管理员工的使用方式。一个例子是当设备遗失时，就会被设置为禁用状态。

第二代 Google Glass 企业版面向物流、制造和医疗等服务行业，主要客户包括 H.B 富勒、萨特健康、德国邮政 DHL 集团和 AGCO 等 50 多家公司。根据业务和 Google 签订合同的公司，他们能以更低的价格购买新产品。

之前有传言认为这款产品对标产品正是微软 HoLolens 2，后者于今年 2 月份推出，3500 美元的售价比 Google 新产品高出不少。不过现在看起来 Google Glass 企业版第二代似乎竞争力低一点，毕竟后者可以通过双眼查看，而且因为美国军方这个大订单，还加入了夜视仪功能。

去年 11 月，微软拿下美国陆军价值 4.8 亿的合同，包括首批订购 2500 个 HoloLens 眼镜，最终需求预计会达到 10 万个。而在微软推出 HoloLens 的 3 年里，本身也就卖掉 5 万个智能眼镜。

Google 没有透露初代 Google Glass 企业版的销售情况，来自独立产品分析机构 Forrester Research 的预计是到 2025 年它将贡献 20 亿美元销售额。

尽管新款 Google Glass 进行了不少升级，研发团队已经从 Google X 调整到AR/VR 部门，瞄准的消费对象还是企业和专业人士。普通消费者如果需要一款 AR 设备，面对 999 美元的定价，考虑购买的可能性并不算大。

题图来自：Google

我们做了一个壁纸应用，给你的手机加点好奇心。去 App 商店搜好奇怪下载吧。

移动跨平台技术方案总结 - xiangzhihong8的专栏 - CSDN博客

Sun, 17 Mar 2019 15:23:23 CST

“得移动端者得天下”，移动端取代PC端，成为了互联网行业最大的流量分发入口，因此不少公司制定了“移动优先”的发展策略。

为了帮助读者更好地学习WEEX，本节将对React Native、Weex和Flutter等主流的跨平台方案进行简单的介绍和对比。

React Native

React Native (简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架，是Facebook早先开源的React框架在原生移动应用平台的衍生产物，目前主要支持iOS和安卓两大平台。

RN使用Javascript语言来开发移动应用，但UI渲染、网络请求等均由原生端实现。具体来说，开发者编写的Javascript代码，通过中间层转化为原生控件后再执行，因此熟悉Web前端开发的技术人员只需很少的学习就可以进入移动应用开发领域，并可以在不牺牲用户体验的前提下提高开发效率。

作为一个跨平台技术框架，RN从上到下可以分为Javascript层、C++层和Native层。其中，C++层主要用于实现动态连结库(.so)，作为中间适配层桥接，实现js端与原生端的双向通信交互，如下图所示是RN在Android平台上的通信原理图。

在RN的三层架构中，最核心的就是中间的C++层，C++层最核心的功能就是封装JavaScriptCore，用于执行对js的解析。同时，原生端提供的各种Native Module（如网络请求，ViewGroup控件模块）和JS端提供的各种JS Module（如JS EventEmiter模块）都会在C++实现的so文件中保存起来，最终通过C++层中的保存的映射实现两端的交互。

在RN开发过程中，大多数情况下开发人员并不需要需要了解RN框架的具体细节，只需要专注JS端的逻辑代码实现即可。但是需要注意的是，由于js代码是运行在独立的JS线程中，所以在js中不能处理耗时的操作，如fetch、图片加载和数据持久化等操作。

最终，JS代码会被打包成一个bundle文件并自动添加到应用程序的资源目录下，而应用程序最终加载的也是打包后的bundle文件。RN的打包脚本位于“/node_modules/react-native/local-cli”目录下，打包后通过metro模块压缩成bundle文件，而bundle文件只包含打包js的代码，并不包含图片、多媒体等静态资源，而打包后的静态资源会是被拷贝到对应的平台资源文件夹中。

总的来说，RN使用Javascript来编写应用程序，然后调用原生组件执行页面渲染操作，在提高了开发效率的同时又保留了Native的用户体验。并且，伴随着Facebook重构RN工作的完成，RN也将变得更快、更轻量、性能更好。

Weex

作为一套前端跨平台技术框架，Weex建立了一套源码转换以及Native与Js通信的机制。Weex表面上是一个客户端框架，但实际上它串联起了从本地开发、云端部署到分发的整个链路。
具体来说，在开发阶段编写一个.we文件，然后使用Weex提供的weex-toolkit转换工具将.we文件转换为JS bundle，并将生成的JS bundle上传部署到云端，最后通过网络请求或预下发的方式加载至用户的移动应用客户端。当集成了Weex SDK的客户端接收到JS bundle文件后，调用本地的JavaScript引擎执行环境执行相应的JS bundle，并将执行过程中产生的各种命令发送到native端进行界面渲染、数据存储、网络通信以及用户交互响应。

由上图可知，Weex框架中最核心的部分就是JavaScript Runtime。具体来说，当需要执行渲染操作时，在iOS环境下选择基于JavaScriptCore内核的iOS系统提供的JSContext，在Android环境下使用基于JavaScriptCore内核的JavaScript引擎。

当JS bundle从服务器下载完成之后，Weex的Android、iOS和H5会运行一个JavaScript引擎来执行JS bundle，同时向各终端的渲染层发送渲染指令，并调度客户端的渲染引擎实现视图渲染、事件绑定和处理用户交互等操作。
由于Android、iOS和H5等终端最终使用的是native渲染引擎，也就是说使用同一套代码在不同终端上展示的样式是相同的，并且Weex使用native引擎渲染的是native组件，所以在性能上比传统的WebView方案要好很多。

当然，尽管Weex已经提供了开发者所需要的最常用的组件和模块，但面对丰富多样的移动应用研发需求，这些常用基础组件还是远远不能满足开发的需要，因此Weex提供了灵活自由的扩展能力，开发者可以根据自身的情况定制属于自己客户端的组件和模块，从而丰富Weex生态。

Flutter

Flutter是Google开源的移动跨平台框架，其历史最早可以追溯到2015年的Sky项目，该项目可以同时运行在Android、iOS和fuchsia等包含Dart虚拟机的平台上，并且性能无限接近原生。相较于RN和Weex使用Javascript作为编程语言与使用平台自身引擎渲染界面不同，Flutter直接选择2D绘图引擎库skia来渲染界面。

如上图所示，Flutter框架主要由Framework和Engine层组成，而我们基于Framework开发App最终会运行在Engine上。其中，Engine是Flutter提供的独立虚拟机，正是由于它的存在Flutter程序才能运行在不同的平台上，实现跨平台运行的能力。
与RN和Weex使用原生控件渲染界面不同，Flutter并不需要使用原生控件来渲染界面，而是使用Engine来绘制Widget（Flutter显示单元），并且Dart代码会通过AOT编译为平台的原生代码，实现与平台的直接通信，不需要JS引擎的桥接，也不需要原生平台的Dalvik虚拟机，如图1-5所示。
同时，Flutter的Widget采用现代响应式框架来构建，而Widget是不可变的，仅支持一帧，并且每一帧上的内容不能直接更新，需要通过Widget的状态来间接更新。在Flutter中，无状态和有状态Widget的核心特性是相同的，视图的每一帧Flutter都会重新构建，通过State对象Flutter就可以跨帧存储状态数据并恢复它。

总的来说，Flutter是目前跨平台开发中最好的方案，它以一套代码即可生成Android和iOS平台两种应用，很大程度上减少了App开发和维护的成本，同时Dart语言强大的性能表现和丰富的特性，也使得跨平台开发变得更加便利。而不足的是，Flutter还处于Alpha阶段，许多功能还不是特别完善，而全新的Dart语言也带来了学习上的成本，如果想要完全替代Android和iOS开发还有比较长的路要走。

PWA

PWA，全称Progressive Web App，是Google在2015年提出渐进式的网页技术。PWA结合了一系列的现代Web技术，并使用多种技术来增强Web App的功能，最终可以让网页应用呈现和原生应用相似的体验。

相比于传统的网页技术，渐进式Web技术是可以横跨Web技术及Native APP开发的技术解决方案，具有可靠、快速且可参与等诸多特点。

具体来说，当用户从手机主屏幕启动时，不用考虑网络的状态就可以立刻加载出PWA。并且，相比传统的网页加载速度，PWA的加载速度是非常快的，因为PWA使用了Service Worker 等先进技术。除此之外，PWA还可以被添加在用户的主屏幕上，不用从应用商店进行下载即可通过网络应用程序Manifest file提供类似于APP的使用体验。

作为一种全新Web技术方案，PWA的正常工作需要一些重要的技术组件，它们协同工作并为传统的Web应用程序注入活力，如图1-8所示。

其中，Service Worker表示离线缓存文件，其本质是Web应用程序与浏览器之间的代理服务器，可以在网络可用时作为浏览器和网络间的代理，也可以在离线或者网络极差的环境下使用离线的缓冲文件。

Manifest则是W3C一个技术规范，它定义了基于JSON的清单，为开发人员提供一个放置与Web应用程序关联的元数据的集中地点。Manifest是PWA 开发中的重要一环，它为开发人员控制应用程序提供了可能。

目前，渐进式Web应用还处于起步阶段，使用的厂商也是诸如Twitter、淘宝、微博等大平台。不过，PWA作为Google主推的一项技术标准，Edge、Safari和FireFox等主流浏览器也都开始支持渐进式Web应用。因此，可以预见的是，PWA必将成为继移动之后的又一革命性技术方案。

对比

在当前诸多的跨平台方案中，RN、Weex和Flutter无疑是最优秀的。而从不同的细节来看，三大跨平台框架又有各自的优点和缺点，可以通过表1-1来查看。

对比类型	React Native	Weex	Flutter
支持平台	Android/IOS	Android/IOS/Web	Android/IOS
实现技术	JavaScript	JavaScript	原生编码/渲染
引擎	JS V8	JSCore	Flutter Engine
编程语言	React	Vue	Dart
bundle包大小	单一、较大	较小、多页面	不需要
框架程度	较重	较轻	重
社区	活跃、FB维护	不活跃	活跃

如上表所示，RN、Weex采用的技术方案大体相同，它们都使用JavaScript作为编程语言，然后通过中间层转换为原生的组件后再利用Native渲染引擎执行渲染操作。而Flutter直接使用skia来渲染视图，而Flutter Widget则使用现代响应式框架来构建，和平台没有直接的关系。就目前跨平台技术来看，JavaScript在跨平台开发中可谓占据半壁江山，大有“一统天下”的趋势。
从性能方面来说，Flutter的性能理论上是最好的，RN和Weex次之，并且都好于传统的WebView方案。但从目前的实际应用来看却并没有太大的差距，特别是和0.5.0版本以上的RN对比性能体验上差异并不明显。
而从社群和社区的活跃来看，RN和Flutter无疑是最活跃的，RN经过4年多的发展已经成长为跨平台开发的实际领导者，并拥有各类丰富的第三方库和开发群体。Flutter作为最近才火起来的跨平台技术方案，不过目前还处在beta阶段，商用的实例也很少，不过应该看到google的号召力一直是很强，未来究竟如何发展让我们拭目以待。

示例

eros-yanxuan

简介

eros-yanxuan是基于 eros开发的Weex项目，部分页面参考了项目网易严选 weex 版本，欢迎star或fork。

运行

确保你本地已经集成了 eros 开发所需的环境。

clone 项目到本地：

      $ git clone https://github.com/xiangzhihong/eros-yanxuan.git

进入目录，下载前端所需的依赖：

      $ cd eros-yanxuan
$ npm install

iOS SDK

打开platforms目录下的WeexEros项目，在WeexEros中使用pod添加依赖。

      $ cd platforms/ios/WeexEros
$ pod update                // 下载 iOS 依赖
$ open WeexEros.xcworkspace // 自动打开项目

选中模拟器，点击绿色箭头运行 app 即可。

Android

对于Android工程来说，使用Android Studio打开platforms目录下的WeexFrameworkWrapper的Android工程，然后使用install.sh安装Android工程的需要依赖包nexus和wxframework。

具体可以参考自行导入项目，便可运行起来。

运行

项目根目录下运行 eros dev
关闭调试，拦截器，打开热更新
重新 build app

效果

Question

运行过程中出现问题在以下地址解决方法，如果没有找到，可以参考 eros快速入门新建一个Weex工程，然后将src和配置文件的代码拷贝过去。如果还有问题，请加群：515980159

移动跨平台框架Flutter介绍和学习线路

Sat, 16 Mar 2019 10:20:16 CST

Flutter简介

Flutter是一款移动应用程序SDK，一份代码可以同时生成iOS和Android两个高性能、高保真的应用程序。
Flutter目标是使开发人员能够交付在不同平台上都感觉自然流畅的高性能应用程序。我们兼容滚动行为、排版、图标等方面的差异。
在全世界，Flutter正在被越来越多的开发者和组织使用，并且Flutter是完全免费、开源的。

Flutter历史

说到Flutter，可能很多小伙伴都会以为它是新兴的的移动开发框架，其实不然，Flutter的历史最早可以追溯到2014年10月，其前身是Google内部孵化的Sky项目。

不过，随着Flutter热度的上升，特别是2018年Flutter陆续发布了Beta版和Flutter1.0，给很多小伙伴造成了一个误区：认为Flutter是最近新兴的一个开发框架。最近，Google又发布了 1.2正式版，并且官方也发布了今年的开发路线（参考 Flutter 2019 产品路线图），可以预见，Flutter将在2019年迎来真正的爆发和成长。

为了方便读者对Flutter有一个更深的了解，下面来看一下Fluter的历史：

2014.10 - Flutter的前身Sky在GitHub上开源；
2015.10 - 经过一年的开源，Sky正式改名为Flutter；
2017.5 - Google I/O正式向外界公布了Flutter，这个时候Flutter才正式进去大家的视野；
2018.6 - 距5月Google I/O 1个月的时间，Flutter1.0预览版；
2018.12 - Flutter1.0发布，它的发布将大家对Flutter的学习和研究推到了一个新的起点；
2019.2 - Flutter1.2发布主要增加对web的支持。

通过Flutter的历史，可以看出Flutter正在逐渐的走向成熟和壮大，它的生态圈也在不断的发展，所以现在学习Flutter是一个非常的好时机。

Flutter原理

相比React Native和Weex，Flutter实现跨平台采用了更为彻底的方案（参考移动跨平台技术方案总结）。它既没有采用WebView也没有采用JavaScript，而是自己实现了一台UI框架，然后直接系统更底层渲染系统上画UI。所以它采用的开发语言不是JS，而Dart（Dart是面向对象的、类定义的、单继承的语言。它的语法类似C语言，可以转译为JavaScript，支持接口(interfaces)、混入(mixins)、抽象类(abstract classes)、具体化泛型(reified generics)、可选类型(optional typing)和sound type syste）。
据称Dart语言可以编译成原生代码，直接跟原生通信，其原理模型图如下：

同时，Flutter将UI组件和渲染器从平台移动到应用程序中，这使得它们可以自定义和可扩展。Flutter唯一要求系统提供的是canvas，以便定制的UI组件可以出现在设备的屏幕上，以及访问事件（触摸，定时器等）和服务（位置、相机等）。这是Flutter可以做到跨平台而且高效的关键。另外Flutter学习了RN的UI编程方式，引入了状态机，更新UI时只更新最小改变区域。

系统的UI框架可以取代，但是系统提供的一些服务是无法取代的。Flutter在跟系统service通信方式，采用的是一种类似插件式的方式，或者有点像远程过程调用RPC方式，这种方式据说也要比RN的桥接方式高效。关于RN和Flutter到底谁更优秀，有兴趣的读者可以关注下官方的撕逼大战 React Native 团队怎么看待 Flutter 的。

Flutter 和 React Native 底层框架对比

React-Native、Weex 核心是通过 Javascript 开发，执行时需要 Javascript 解释器，UI 是通过原生控件渲染。Flutter 与用于构建移动应用程序的其它大多数框架不同，因为 Flutter 既不使用 WebView，也不使用操作系统的原生控件。相反，Flutter 使用自己的高性能渲染引擎来绘制 widget。Flutter 使用 C、C ++、Dart 和 Skia（2D渲染引擎）构建。

Skia 是一个 2D的绘图引擎库，其前身是一个向量绘图软件，Chrome 和 Android 均采用 Skia 作为绘图引擎。Android 自带了 Skia，所以 Flutter Android SDK要比 iOS SDK小很多。

在 ReactNative 中，引入了虚拟 DOM 来减少DOM的回流和重绘，系统将虚拟 DOM 与真正的 DOM 进行比较，生成一组最小的更改，然后执行这些更改，以更新真正的 DOM。最后，平台重新绘制真实的 DOM 到画布中。

React Native 是移动开发的一大进步，并且是 Flutter 的灵感来源，但 Flutter 更进一步。在 Flutter 中，UI 组件和渲染器已经从平台中集成到用户的应用程序中。没有系统 UI 组件可以操作，所以原来虚拟控件树的地方现在是真实的控件树，Flutter 渲染 UI 控件树并将其绘制到平台画布上。

如果说非要比较 Flutter 和 React Native的优势，可以参考下面几点：

UI 一致性

Flutter 因为是自己做的渲染，因此在iOS和Android的效果基本完全一致。 React Native存在将RN控件转换为对应平台原生控件的过程，存在一定的差异（如之前在调研里提到过的Button在iOS和Android下面显示效果不一样）。

动态化技术

Flutter使用的Dart语言，支持AOT和JIT两种模式，在Dev时候，通过JIT可以实现热重载，开发者可以即时的看到代码修改的效果。而在Release Build的时候，通过AOT事先编译，来最大化的优化性能。因此目前Flutter不支持代码的热更新，不过在 Flutter 2019 产品路线图）可以看到这方面的消息。

ReactNative 的代码通过加载 JSBundle.js执行，JSBundle.js可以保存在本地，也可以通过远程加载。目前有很多RN的热更新方案供选择。

App体积

Flutter iOS空项目 30M左右，Android空项目 7M左右。（iOS需要额外集成Skia） React Native iOS空项目 3M左右，Android20M左右。（Android会加入OKHttp导致体积增大）

Flutter 部分的底层功能在 Android 系统上已经有实现，因此 Android 上适配要好（RN在 Android 上有可能遇到兼容性问题）。

Flutter的优势

运行效率上，Flutter和ReactNative都可以达到理论上的60帧的刷新率，来实现「Native般的流畅体验」，Flutter是全Native在执行，基于底层代码(Android 上为 C++ with NDK,iOS 上为 C++ with LLVM)，而ReactNative是Native控件 + JavaScript代码，实际性能上，Flutter应该优于ReactNative，据官方文档，Flutter可以在支持的设备上达到120FPS，而ReactNative的文档上，只提到了可以达到60FPS。

兼容性上，Flutter 提供的 widget 都是基于 skia来实现和精心定制的，与具体平台没关，所以能保持很高的跨 os 跨 os version 的兼容性。 Flutter 从更基础的层去抹平平台差异，站在了更宽广、更可控的一个基础平台上去演变和发展。 Flutter 官方提供了大部分 Material Design 控件的实现（甚至比 Android Design Support 实现的更多）。

Flutter开发语言Dart

为什么要使用Dart语言

学习Flutter就不得不提到Dart，那Flutter和Dart有什么关系？确实有关系，早期的Flutter团队评估了十多种语言，并选择了Dart，因为它符合他们构建用户界面的方式，读者可以去八卦下为什么要使用Dart语言的推文。

Dart能成为Flutter不可或缺的一部分，根本原因还是因为其具有以下特性：

1）Dart是AOT（Ahead Of Time）编译的，编译成快速、可预测的本地代码，使Flutter几乎都可以使用Dart编写。这不仅使Flutter变得更快，而且几乎所有的东西（包括所有的小部件）都可以定制；
2）Dart也可以JIT（Just In Time）编译，开发周期异常快，工作流颠覆常规（包括Flutter流行的亚秒级有状态热重载）；
3）Dart可以更轻松地创建以60fps运行的流畅动画和转场。Dart可以在没有锁的情况下进行对象分配和垃圾回收。就像JavaScript一样，Dart避免了抢占式调度和共享内存（因而也不需要锁）。由于Flutter应用程序被编译为本地代码，因此它们不需要在领域之间建立缓慢的桥梁（例如，JavaScript到本地代码）。它的启动速度也快得多；
4）Dart使Flutter不需要单独的声明式布局语言，如JSX或XML，或单独的可视化界面构建器，因为Dart的声明式编程布局易于阅读和可视化。所有的布局使用一种语言，聚集在一处，Flutter很容易提供高级工具，使布局更简单；
5）开发人员发现Dart特别容易学习，因为它具有静态和动态语言用户都熟悉的特性。

编译与执行

历史上，计算机语言分为两组：静态语言（例如，Fortran和C，其中变量类型是在编译时静态指定的）和动态语言（例如，Smalltalk和JavaScript，其中变量的类型可以在运行时改变）。静态语言通常编译成目标机器的本地机器代码（或汇编代码）程序，该程序在运行时直接由硬件执行。动态语言由解释器执行，不产生机器语言代码。

当然，事情后来变得复杂得多。虚拟机（VM）的概念开始流行，它其实只是一个高级的解释器，用软件模拟硬件设备。虚拟机使语言移植到新的硬件平台更容易。因此，VM的输入语言常常是中间语言。例如，一种编程语言（如Java）被编译成中间语言（字节码），然后在VM（JVM）中执行。

另外，现在有即时（JIT）编译器。JIT编译器在程序执行期间运行，即时编译代码。原先在程序创建期间（运行时之前）执行的编译器现在称为AOT编译器。

一般来说，只有静态语言才适合AOT编译为本地机器代码，因为机器语言通常需要知道数据的类型，而动态语言中的类型事先并不确定。因此，动态语言通常被解释或JIT编译。

在开发过程中AOT编译，开发周期（从更改程序到能够执行程序以查看更改结果的时间）总是很慢。但是AOT编译产生的程序可以更可预测地执行，并且运行时不需要停下来分析和编译。AOT编译的程序也更快地开始执行（因为它们已经被编译）。

相反，JIT编译提供了更快的开发周期，但可能导致执行速度较慢或时快时慢。特别是，JIT编译器启动较慢，因为当程序开始运行时，JIT编译器必须在代码执行之前进行分析和编译。研究表明，如果开始执行需要超过几秒钟，许多人将放弃应用。

Dart的编译与执行

在创造Dart之前，Dart团队成员在高级编译器和虚拟机上做了开创性的工作，包括动态语言（如JavaScript的V8引擎和Smalltalk的Strongtalk）以及静态语言（如用于Java的Hotspot编译器）。他们利用这些经验使Dart在编译和执行方面非常灵活。

Dart是同时非常适合AOT编译和JIT编译的少数语言之一（也许是唯一的“主流”语言）。支持这两种编译方式为Dart和（特别是）Flutter提供了显著的优势。

JIT编译在开发过程中使用，编译器速度特别快。然后，当一个应用程序准备发布时，它被AOT编译。因此，借助先进的工具和编译器，Dart具有两全其美的优势：极快的开发周期、快速的执行速度和极短启动时间。

Dart在编译和执行方面的灵活性并不止于此。例如，Dart可以编译成JavaScript，所以浏览器可以执行。这允许在移动应用和网络应用之间重复使用代码。开发人员报告他们的移动和网络应用程序之间的代码重用率高达70％。通过将Dart编译为本地代码，或者编译为JavaScript并将其与node.js一起使用，Dart也可以在服务器上使用。

最后，Dart还提供了一个独立的虚拟机（本质上就像解释器一样），虚拟机使用Dart语言本身作为其中间语言。

Dart可以进行高效的AOT编译或JIT编译、解释或转译成其他语言。Dart编译和执行不仅非常灵活，而且速度特别快。

AOT编译和“桥”

前面讨论过一个有助于保持顺畅的特性，那就是Dart能AOT编译为本地机器码。预编译的AOT代码比JIT更具可预测性，因为在运行时不需要暂停执行JIT分析或编译。

然而，AOT编译代码还有一个更大的优势，那就是避免了“JavaScript桥梁”。当动态语言（如JavaScript）需要与平台上的本地代码互操作时，它们必须通过桥进行通信，这会导致上下文切换，从而必须保存特别多的状态（可能会存储到辅助存储）。这些上下文切换具有双重打击，因为它们不仅会减慢速度，还会导致严重的卡顿。

说明：即使编译后的代码也可能需要一个接口来与平台代码进行交互，并且这也可以称为桥，但它通常比动态语言所需的桥快几个数量级。另外，由于Dart允许将小部件等内容移至应用程序中，因此减少了桥接的需求。

布局

Dart的另一个好处是，Flutter不会从程序中拆分出额外的模板或布局语言，如JSX或XML，也不需要单独的可视布局工具。以下是一个简单的Flutter视图，用Dart编写：

  new Center(child:
  new Column(children: [
    new Text('Hello, World!'),
    new Icon(Icons.star, color: Colors.green),
  ])
)

并且随着Dart 2的发布，上面的代码也变得越来越可读，因为new和const关键字变得可选，所以静态布局看起来像是用声明式布局语言编写的：

  Center(child:
  Column(children: [
    Text('Hello, World!'),
    Icon(Icons.star, color: Colors.green),
  ])
)

至于，困扰原生开发人员的一个问题是：为什么缺乏专门的布局语言怎么会被称为优势呢？原生开发人员可以在下面的文章中找到答案：“ 为什么原生应用程序开发人员应认真看待Flutter”

学习路线

学习任何一门技术，最主要的渠道就是官方资料，由于是Google的产品，因此从一开始就受到很多开发者的喜爱，因此其社区建设也相对较快，读者可以现场 Flutter中文社区了解一些Flutter开发的基础，然后再结合一些开源项目进行学习。

Fluuter网上的学习资料也很多，可以参考下面的链接进行深入的学习： Flutter学习线路

如何建立一份移动UI设计规范？

Tue, 05 Mar 2019 11:17:37 CST

作者：白鹭漫谈在多人团队里，通常不同的设计师负责不同的流程，如果没有UI设计规范，不同的设计师就会对相同的组件做出不同的方案。产生大量重复工作，效率比较低。而制作设计规范和UI KIT之后，则可以直接利用KIT里的组件快速搭建好页面，把设计师从基础工作中释放出来，大大提升设计效率。目录 一、为什么要建立规范

用户体验一致
塑造品牌感
利于多人协作
方便维护和更新，减少冗余内容

二、规范的适用范围

适用于处于成长期和成熟期的产品。
规范不是越全越好。适合就是最好。

三、如何建立规范

整理产品的组件和复用的内容
基础规范（栅格间距基础网格颜色字体）
组件规范（按钮、导航、弹框、缺省图、标签、列表、卡片等等）

一、为什么要建立设计规范？

1 利于多人协作，提高效率 2 增强一致性，塑造品牌感 制作和遵循设计规范，能够保证整个产品的交互效果和视觉风格、乃至文案的统一性，提升用户的体验。 3 减少冗余内容，方便维护和更新 同类内容使用一样的组件，能够降低输出的内容量，减少冗余的控件和代码。同时也便于维护，在迭代时进行统一的更新和应用。 4 利于工作交接 方便设计团队和其他团队交接，如果团队有人员变动，也方便后续入职的同事能够通过规范迅速熟悉产品，快速上手。

二、规范的适用范围

前面的文章我提到过，如果产品处于启动期的话，这个时候最重要的事情是圈到第一波用户，让自己活下去。在这个阶段产品会频繁的改版、验证，迭代非常快，整个团队可能都处于拼命加班的状态。在这种情况下做设计规范文档显然事倍功半，一个是浪费人力资源，另外就算做了，在频繁更新的背景下也很难去执行。因此 设计规范文档更适合于那些跨越0-1阶段的产品，这个时候产品已经用有了一定的用户，团队也会扩张。这个时候我们可以选择制作基础的设计规范，比如栅格、配色、字体、图标规范等等。对于成熟期的产品来说，大版本更新的周期是非常长的，这个阶段通常会制作更为详细的设计指南、设计原则、do & don’t、品牌书、图标手册等等。

三、如何建立设计规范

电商类的产品对于大家来说都是比较熟悉的，就算不从事这个方面，日常使用也会很频繁，所以此次案例我们以下面这个电商APP作为示范。做规范时通常会有这两种情况： 1、不打算进行大版本更新的产品 对于小版本迭代的产品来说，建立规范只需要在sketch里把所有设计稿进行归拢和分类。直接根据现有的稿子梳理出规范，再对不符合规范的文件进行调整即可。 2、新版本新规范 而对于需要做新版本并且建立新版本规范的产品来说，在做设计稿之前，我们就需要先统一一些基础的内容，比如颜色、字体、栅格等等，然后在设计过程中去制作KIT、对基础的规范进行补充。

四、基础规范

1 制定统一的栅格系统 因为现在都是一稿适配多端，所以首先需要确定设计的基准尺寸，是基于iphone8？还是iphone 8P？或者1080*1920等等……每个公司设计稿的基准都不一样，我们是以一倍图为基准进行设计的，所以我这里的基准尺寸就是375*667，单位为pt。栅格一种情况是制定网格系统，网格系统的话首先要制定最小的设计单位，比如淘宝的最小单位是3，掌阅的最小单位是4，airbnb的最小单位是6……定好最小设计单位之后，界面中所有间距采用最小单位的倍数。假定我们最小单位4的网格，排版时横向和纵向的间距都是4的倍数，比如8、12、24。第二种情况是可以直接建立横向栅格系统，常用的是12栅格，12栅格比较好的地方是能够同时被2、3、4整除，因此能够根据具体需求灵活的设计各种模块。当然如果产品比较轻量化，是不需要这么复杂的栅格的，可以根据需求设置6、4甚至2栅格等等。 2 色彩规范 色彩规范主要表明色彩的色值和使用范围，一般会从品牌色、辅助色、基础色、状态用色等等。如下图所示。如果产品常用到渐变的话，需要注明渐变的角度以及渐变色的色值。包括产品如果有夜间模式的话，要额外注明日间和夜间模式下各个颜色的对应色值。当然这里的夜间模式说的是真·夜间，而不是微博那种直接加一个黑色透明度蒙层的伪·夜间。额外提一句，重要内容和正文内容要保证文本的可识别度，WCAG指南中指出，文本和背景色的对比度需要达到3：1。大家可以通过 https://webaim.org/resources/contrastchecker/ 的颜色对比检查器来核对颜色。我这里的品牌色和强调色对比度为3：1和6.3：1，而辅助颜色（比如标签）的对比度则在2-3之间。 3 字体 字体规范最需要注意的是提取出各个场景下需要用的字体和字号。需要注意的是，要标注上应用场景方便其他人理解。不然其他成员也并不知道到底什么时候应用一级标题、什么时候用二级标题。 4 图标 通常来说图标分为两种，功能性图标和展示性图标。功能性图标是为了引导用户理解和操作，需要表现精确和简介，方便用户识别其含义。功能性图标常规状态下为无彩色。展示性图标通常为页面入口，会有更多形状、颜色、质感的表达，吸引用户的注意力和点击欲望，强调差异性，比如各种品类区的图标、徽章、等级图标等等。图标规范通常来说会先定一些基础尺寸，梳理好各个页面的图标尺寸，进行整合，最后确定好几个基础尺寸，比如我这里的基础尺寸是4个。功能层级一致的图标尺寸要一致。为了保证不同形状的图标在视觉上保持大小一致，会制作一个图标的基础制作说明。制作说明里会统一图标的圆角、描边的粗细；如果是涉及到展示性图标的话，还会有图标的视角选择、配色的选择、以及如何表现质感等等等等 5 默认图 电商APP的话有大量的产品图片，所以我们也把默认的占位图样式进行了统一。因为我们这里样式都是一致的，所以采用了统一的规范，如果有多种默认样式，或者有其他类型的占位图，需要分别进行说明。

五、页面组件

页面组件通常包括导航栏、工具栏、弹框、列表、卡片、空状态等等，按照原子设计理念来说，还可以把组件拆分为原子、分子等更小的基础设计组件，比如角标、标签、按钮、图像、优惠券、选择器、进度指示器等等页面组件除了梳理出规范之外，通常会整理成一整套UI KIT，保存为sketch文件日常拖拽使用，或者导入为Libraries直接调用。当然，也可以直接在KIT上备注出规范和注意事项，具体输出什么格式这个看团队的需求即可。因为组件部分是一个比较庞大的内容，需要根据具体产品 1按钮 按钮一般有悬浮按钮、填充按钮、线框按钮和文本按钮等类型。其中悬浮按钮具有最高的优先级，属于强引导型按钮。按钮通常会有三种状态，常规状态、点击状态和不可用状态。因此在规范中需要标明按钮在这三种状态下的样式，比如颜色、投影、圆角、文字大小等等除此以外，也可能会有加载状态，也就是在点击按钮后，如果有1S以上的数据延迟，通常会考虑触发按钮的加载状态。加载状态的按钮样式为按钮上显示进度指示器。 2 导航 对现有页面的导航进行收拢和分类，比如我这里分类为常规标题样式、标签样式、搜索框样式、无标题样式、字母导航…… 标题需要注意文字的极限值，ICON尺寸和位置的话要考虑最小可点击区域，我这里icon的尺寸设置为24pt，但是热区是44pt，所以要注意间距的设置，热区不能重叠。 3 标签 标签通常有多个使用场景，我们可以对标签进行分组，比如运营类标签、内容属性标签、筛选标签等等然后对每类的标签统一样式、文字内边距以及说明适用场景。 4 弹窗 弹窗是为了提示和通知用户而位于页面内容之上的一种控件。它是引导用户专注于某一项任务，用户可以通过操作来关闭弹框。弹框包含模态（对话框、操作菜单）和非模态（toast、 snake bar等）两种形式。模态弹窗需要定义蒙层的样式（颜色、透明度），以及弹框内的文字说明和按钮。我这里拿一个对话框的规范进行举例，这是一个无ICON的双按钮对话框，因此在这里我们需要说明标题、正文文本、按钮以及背景遮罩的信息，还有字号、行距、文字极限值、文字色、按钮的状态等等…… 除此之外，组件类的规范可以配上常用案例、don’t&do，会更方便团队人员理解，防止错误状况。 5 列表 列表是由多个等宽的行组成的、按照一定规律排列的连续条目。列表在一些资讯类产品里会有更多的组合形式。我这款产品里用到的列表主要是单行和双行列表，那么我们就整理出对应的列表类型和需要说明的事项。

六、结语

写这篇文的初衷，是因为从去年底我建立公众号，并且在站酷发表了一些文章，得到了很多人的认可。很多粉丝私信我各种问题，陆续有人问我设计规范怎么做、交互规范什么样之类的问题。但是公司内部的文件确实没有办法公开分享，所以我就想说，那不如专门写一篇文章详细教大家制作移动UI设计规范吧。这篇的基础部分我做的比较详细，组件部分写的有些概括，主要是因为组件部分不是通用的，要根据自己的稿子进行整理和归纳，归纳好之后做好标注和规范说明即可，这部分是一个罗列的内容，所以就不必展开了…… 当然还有很多内容没有展开说，比如在Sketch里把KIT制作成Libraries统一使用，但是我想作为一篇设计规范入门教程目前应该足够了，更多的内容我在后续开新文去补充吧。

下载规范文档

素材名称：UI设计规范PDF.zip 格式：PDF 下载链接: https://pan.baidu.com/s/13EGxD7GmDTxVl0Dnw7sXlg 提取码: bpjq

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

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

中国移动科普：手机里的身份证照片应果断删除

Fri, 04 Jan 2019 19:40:48 CST

一个手机号、一台能上网的智能手机，仅靠这两样，在当下的社会生活中就能办成各种各样的事情，包括一些敏感的、数额不小的金融活动。1月4日，中国移动10086官方微博发布科普一张图， 提醒手机里存有身份证等个人隐私照片的朋友，果断删除，以免留下后患。

官方引述的例子是，李某打开存有赵先生身份证照片的手机相册后，利用这个不起眼的疏漏修改了失主的支付宝账号，刷走余额2000余元，甚至连花呗、借呗也没放过进行透支购物，最后还把手机折现千元，给对方造成了不小的损失。

86君另外提醒，除了身份证，账户密码、手机验证码、Apple ID/密码、各类单据、定位信息、各类证件复印件（书写进攻xx使用等）等类似的隐私信息都要留心保护好，以策万全。

Facebook开源移动端深度学习加速框架，比TensorFlow Lite快一倍

Sat, 29 Dec 2018 00:00:00 CST

方栗子发自凹非寺
量子位出品 | 公众号 QbitAI

Facebook发布了一个开源框架，叫 QNNPACK，是手机端神经网络计算的加速包。

官方表示，它可以 成倍提升神经网络的推理效率，几乎比 TensorFlow Lite快一倍。

这个框架，能够为很多运算加速，比如 DW卷积 (Depthwise Convolution) ，许多先进的架构里面都用得到。

目前，QNNPACK已经是 PyTorch 1.0的一部分，在Caffe2里就能直接使用。

其实，Facebook手机应用里面，已经部署了这个QNNPACK。也就是说，数以亿计的手机都在用了。

从哪个角度加速？

QNNPACK，这个名字眼熟么？

两年前，Facebook就推出过一个加速包，叫做 NNPACK，Caffe2Go用的就是它。

基于Winograd变换和傅里叶变换，有效减少卷积计算里的乘加运算 ( Multiply-Add) 。这样一来，3x3卷积可以只比1x1慢一倍，而不会慢8倍。

不过，世界变化很快。现在的计算机视觉 (CV) 神经网络里，用到的很多卷积类型， 已经沾不到NNPACK的光：

比如，1x1卷积，分组卷积 (Grouped Convolution) ，Strided Convolution，扩张卷积 (Dilated Convolution) ，DW卷积 (DepthWise Convolution) ，适用于精度/存储带宽受到限制的 (移动端等) 场景。

而CV神经网络，大部分推理时间，都花在卷积和全连接运算上。

这样的运算，和 矩阵乘法密切相关：

大内核的卷积，可以分解成im2col和一个矩阵乘法。

所以，有高效的矩阵乘法，才能有高效的卷积网络。

于是，QNNPACK出世了。

怎样加速矩阵乘法？

矩阵乘法，A x B = C。C里面的每一个元素，都可以看成 A中某行和 B中某列的点乘。

但直接在点乘基础上计算的话，一点也不快，会受到存储带宽的限制。

如果，能同时计算 A中多行和 B中多列的点乘，即 MRxNR，就能给运算速度带来猛烈的提升。

不需要太多，这样细小的改变就够了。

节省内存和缓存

模型训练，可能更需要高精度。但在训练完成后，推理部分对精度的需求可能就没有那么高了。

低精度的计算，有时对推理的 准确性不会产生明显的影响。

而这样的运算，不需要太大存储，并节省能源，有助于把AI部署在移动端。

QNNPACK用的线性量化 (Linear Quantization) 方案，与安卓的神经网络API兼容。

它假设量化值q[i]是用8比特的无符号整数 (Unsigned Integers) 来表示的，以及q[i]与真实值r[i]相关，关系如下：

与其他库不同，QNNPACK把矩阵A、B都放进一级缓存 (L1 Cache) ，目标是把所有对运算过程并不非常必要的内存转换 (Memory Transformations) 都删掉。

QNNPACK可以在一次微内核调用 (Microkernel Call) 里，处理A和B。

不需要在微内核之外，累积32位的中间结果，QNNPACK把32位的中间值融合进微内核，然后写出8位值，节省了存储带宽和缓存。

赢了TensorFlow Lite

开发团队用谷歌的视觉框架MobileNetV2里面的 图像分类模型来测试。

拿 TensorFlow Lite做对手，和 QNNPACK比了一场。

结果是，QNNPACK比TensorFlow Lite几乎快一倍，不论是在高端智能机，还是普通智能机身上。

所以，各位也去试一下？

GitHub项目页：
https://github.com/pytorch/QNNPACK

博客原文：
https://code.fb.com/ml-applications/qnnpack/

— 完—

加入社群

量子位AI社群开始招募啦，欢迎对AI感兴趣的同学，在量子位公众号（QbitAI）对话界面回复关键字“交流群”，获取入群方式；

此外，量子位专业细分群( 自动驾驶、CV、NLP、机器学习等)正在招募，面向正在从事相关领域的工程师及研究人员。

进专业群请在量子位公众号（QbitAI）对话界面回复关键字“专业群”，获取入群方式。（专业群审核较严，敬请谅解）

活动策划招聘

量子位正在招聘活动策划，将负责不同领域维度的线上线下相关活动策划、执行。欢迎聪明靠谱的小伙伴加入，并希望你能有一些活动策划或运营的相关经验。相关细节，请在量子位公众号(QbitAI)对话界面，回复“招聘”两个字。

量子位 QbitAI · 头条号签约作者

վ'ᴗ' ի 追踪AI技术和产品新动态

七年，我摸清了移动推广的所有套路

Wed, 21 Nov 2018 20:20:41 CST

今年是我干移动推广的第七个年头了，在这里我经历了很多很多事情。今天希望是给大家带来一个比较轻松，比较随意一点的、好玩一点的分享，是我在这七年里面感受到的或者看到的一些路上的风景。

第一章：渠道

首先我想问大家一个问题，七年前你用的什么手机？

那时候如日中天的诺基亚，砖头厂，还有摩托罗拉……

安卓在2011年已经超过了之前塞班系统成为我们国内最大的手机系统的阵型，那时候你们iPhone 4 其实也已经发布了。

那好，第二问题，五年前你们用什么APP看视频？

我觉得今日头条这个产品其实无论是对新闻来说，对阅读来说，特别是对广告投放来说，它其实是一个划时代的东西。

其实就是你关心的才是头条，或换成广告语来说，你喜欢看的才是广告。

那好，一年前你们用啥看视频？映客还是虎牙？

为什么会问这一二三个问题呢，这七年以来，大家在手机终端用的一些APP，关注的一些内容其实一直在变化，然后对于推广来说，其实是我们目标还是去营销人，还是以人为本。

所以其实整个推广是随着用户的生活各方面的变化而变化的。

我先讲一下渠道。

大概在2010年的时候，移动是一个非常牛的企业，大家看它在2010年已经 布局了视频、阅读、游戏、动漫、数据、音乐、位置、电子商务的基地，即使现在2017年看，它其实也是很牛的，也是很齐全的。

那好我们来看一下游戏基地，大家看一下这个画面，大部分地方我们推广是可以介入，或者说可以抢流量。但这是毫无意义的。当时是不能直接用钱来解决问题的，就是我们现在口头讲的未商业化。

那个时候我们怎么去抢资源？

移动会对每个合作伙伴评级ABCD，然后A你每个月可以拿什么资源走，B你可以拿什么资源走。

那如何决定这个账户的ABCD？

你提供了多少优质的游戏，所以那时候其实我们有一部分工作是找优质游戏去代理，甚至是收购。

官方活动则还是走比较常规的传包等等的套路。

那好，非常规的套路是什么？这就涉及了公关关系了。

资源还是有限的，任何位置其实它只有一个，你上了别人就没有了，所以为什么要给你，那肯定是优先考虑给熟人。

其次就是联运。

在当时看来这种游戏联运的模式是非常不成熟的，就是找人帮我推这个游戏，假如用户付费了10块钱，我后面反你一块钱。

干到后面大家都觉得找运营这件事有点费力了，那好，请问大家尝试过话费不知不觉的就没了吗？

不知情扣费，就是我在你手机上装一个病毒之类的网页，然后时不时就扣个10块钱、20块钱，然后你去找移动问的时候，他会告诉你你玩了什么游戏。

所以其实移动以前整个套路，或者说移动游戏基地整个套路就是这样的。

那好，其实看完第一个案例，或者说作为一个老推广，我给大家来总结几个注意点。

（1）资源永远是有限的

越优质的资源，就越有限，然后这些资源给了你，他就没有了。

我为什么要给你？或者说你凭什么可以拿到这些优质资源？

所以请记住“资源”，永远是推广的核心。

（2）解决我为什么给你这个资源的问题——人脉跟圈子

在中国，人情或人脉其实永远是各位做商务上面最比较重要的一环，可以解决很多非常规的问题，而非常规的问题你解决了，其实才能提升你作为推广的一个价值，不是说我只会花钱，不是说只能通过投放。

如何会维系这个人脉的圈子呢？

那其实我觉得最正向的第一个是，要 保持好奇心。

这种好奇心是对广告好奇心，是对投放模式的好奇心，是对这个市场行业的好奇心，我现在经常看到一些广告，其实我都觉得挺好玩的，我也挺愿意去研究它们，之后讲的就是 敬畏之心。

推广在各家公司应该也是碰钱碰得最多的，永远都是敏感部门。

如何保证在这条路上不入歧途，或者说是手上干干净净，毕竟大家都不想做着做着就像移动某些中高管就进去吃监狱饭了。

第二章：精准

到后面大家都在折腾是什么东西了，大家其实听到很多人说浏览器。

浏览器其实从塞班开始，它就是大家必备的一个工具。

其实很多推广，在引流的渠道上面，很多都是从浏览器开始的，什么文字链、图片等。

推广很重要的渠道阵地就在这里。

预装，相信大家都接触过，是从水货机，国产机，山寨机，自主刷room等开始的，虽然目前整个量级有一定萎缩，但有路子，还是有量的。

网盟，始于各种内嵌的广告/功能sdk，那时候流量还是比较充足的，目前就剩下积分墙还比较活跃。

论坛，论坛这个东西其实是从PC开始发展的，为什么说论坛，因为下面会有刷系统，因为这种东西都是从论坛下来的，你能刷系统之后，我就能够做自动下载，就是其实我会在你的rom里面植入一点东西，然后达到预装和自动下载的一个效果。

后面就是一些 比较常规的appsotre，第三方应用市场，还有一些大媒体的东西。

其实大家就在折腾渠道， 渠道这个玩意，其实这是我们去接触用户的一个桥梁统称。

今日头条的出现，对于广告投放来说是比较颠覆的。

它能告诉我们这些广告主，用户一些阅读的行为你是可以知道的，你是可以找到有特定阅读行为，或者说特定兴趣行为的一些人，然后它是怎么去判定你这个兴趣行为或者给你打标签。

你读什么文章，看什么文章，搜索什么文章。
账号登录，你总要QQ账号登录，微信登录是吧，其实你的数据你的一些标签，也是会有合作过去的。

还有输入法搜索，还有数据化的合作，其实直到现在，你在京东搜一件什么东西，或者说在淘宝搜一件什么东西，事后到今日头条，它很可能就会给你推荐相类似的一些东西，其实他们是有做底层的数据合作的。

其实就你在安卓装了一个应用之后，其实你的很多东西都是被它知道了，例如 LBS，例如IP，例如push了一些东西，所以它是通过这样标签加以运算联想，来给你打标签的。

广点通，广点通的底层其实是QQ资料的层。

QQ账户不用说了，你填的那些年龄、星座、兴趣等，还有社交账户的，然后腾讯其实它不止QQ，它还有浏览器，它还有其他的一些东西，你的一些聊天记录和搜索行为，也是判断你这个人标签的一些唯度。

之后还是你装了这个APP，你手机里的信息就跑不了了。

我们来看一下这个最近的手机厂商（以小米举例），因为其实你买了这台手机之后，你这个人也就是他的了，为啥呢？

首先他自己有自己的小米账号，还有他杂货铺一系列信息。

他知道你APP安装使用的习惯，你装了什么APP，你的使用时长、你的短信也是知道的，你发的push是否点击，兴趣点的问题，输入法输入行为这个也就不说了，这两个是共同的。

所以基本上你在小米，基本上你能搜的信息，就是接收到的信息，它都知道。

方才介绍的是一些找人的媒体，介绍下 找人的技术——Lookalike。

这个有些什么场景呢？

其实就是我有一群种子用户，这群种子用户是我可以提供的一堆手机号码，然后放到平台上用Lookalike这个技术去找人的时候，它就会把你提供的种子用户在这个平台说表现的标签拎出来，然后去做扩大。

当然后面还有很多这种相延续的一些东西，就是找到这帮人之后，找到这帮人其中有人点的广告之后，那点的广告的这个人在这些之前那些媒体平台里面是个什么标签。

它有十个标签的，那我后面就根据这十个标签再去做扩展，其实就是一个种子用户，然后去筛选用户，然后再去扩大的工具。

刚才在第二部分的时候，我跟大家讲了很多渠道。

到精准的时候，大家聚焦点开始从渠道/媒介往目标人群转移，大家会开始去思考，我这个APP，我需要什么样的人群，我应该如何去找到这些人群，那找到之后，我应该怎么去营销这些人群。

其实是整个精准，整个媒体投放技术升级之后带给推广的一些转化。

第三章：内容

同质化的广告慢慢破坏用户体验，在这时候，我们迎来了内容元年。

国内对广告或者对一些新型投放方式的不停探索，其实大家已经不再停留在一些图片或者说很简单的纯粹说利益上的一些事情。

其实从大家都开始去往高质量的内容去做的时候，会有这三点你可以推：

（1）其实优良的内容是可以被传播的，

它的娱乐性其实大家，会起码对他们的产品或者说他们的品牌留下一定的印象，即使是好的坏的。

（2）内容里面的创意其实是挖掘用户深层次的消费需求

就用借贷广告为例：我已经不跟你说，你可以借多少，多快就能到账，那其实是个产品都能说事情。

而是说你借钱之后，你可以去学习，创业，你不必在低声下气跟亲朋好友借钱，将借钱这个行为往正向的，有意义的目标靠，激发用户对借钱这个行为需求的唤醒。

然后假如我给你灌输了这个之前整个行业都没有讲的概念之后，你就会拉开我跟其他品牌的定位，就会记住之前的一些品牌。

（3）用内容去唤醒这些需求

这些我们的产品需求的时候，那用户的教育程度是会更深的，因为其实你已经帮他联想到，你借这笔钱你其实可以干嘛，然后也是更容易贴合我们生活上的场景。

第四章：品效

最近各个推广人都在讲品效合一，除了给效果广告一个华丽的不背kpi的“衣服”外，实际意义在哪里？

我们应该去怎么理解？

其实品牌玩法就是首先我排除掉完全不可能转化的人，就是这些人是完全不是我的目标用户，然后我去给这些有可能转化的人创造独特的、良好的品牌形象。以提升长期的转化还有毛利率的问题。

“效”则是我们找到最有可能够买，并且是马上转化的人，然后给予他超出预期的一些利益，然后带来直接的盈利或广告效果。

品效合一，这个结合起来的话，在一些传统的行业或者其他行业来说，是先品后效的。

举个例子，以前江湖卖艺的人，他们在做这种表演或者做这种盈利这种活动的时候，他会选一个好的街道或者一个好的地理位置。

然后选一个用户，最起码那些人不能太没钱是吧。时间上，最起码要有流量，我不是深夜来做。敲锣打鼓，然后说各种装逼的话，例如我打遍天下无敌手，什么小混混之王什么的东西，增加自己牛的背书，然后目的是招揽客人为观。

到下午的时候，这个卖艺者就会使出浑身解数，然后胸口碎大石那样去表演，然后目的其实是让围观的这些人尽快的转化成一个付费用户，其实品效，或者说先品后效的一些套路就是这样的。

回到我们的这些互联网投放来说，你很难在一个渠道上面先去跟用户说品牌，然后再去找到这些用户，再去兜回来，我要给你利益，这种操作是很难的，包括了频次和精准的问题。

那到今日，我们有什么样的解决方式去走品效合一的这条路子呢？

那我觉得首先KOL，其实他就是自带品牌的，并且他还自带流量，最牛的话，他能输出内容。

在和KOL的合作上，有非常多的困难点：

KOL只是能影响各自领域上面一小戳人，他的影响力其实很局限的。
他毕竟是我们的合作伙伴，他不能完全跟着我们的内部政策随时调整广告投放时间。

那么第二个在品效合一里面能走的通的，我觉得也就手机厂商这个玩意了。

它其实很简单，现在手机已经成为各位的，说的俗一点其实解决身份问题。你可以不带钱包，但你不能不带手机，这个比身份证还唯一一点。

只要我在这里找到一帮人，给他投品牌广告，然后再去根据点击这些品牌广告的人去做效果投放，其实特别简单的一个品牌合一。

品效合一，它简单吗？

我要怎么让这些人信服我们的品牌？我要给他输出什么内容？我要研究这种品牌投放频次，一个品牌的广告要给这些人骚扰多少次？或者说什么人才能记住这些品牌广告？

点了这些品牌广告或者说这些最有可能转化的人？我要给他什么样的刺激？或者我要结合一些什么场景、时间再给他刺激？

其实这里可以研究的东西，有很大的学问。

其实说了这么多，就是目前品效合一这些方法我们还在探索。

我还在路上，然后期待下一个七年。

作者： PPmoney，公众号：姑婆那些事儿（ID：gupo520）

本文由 @姑婆那些事儿授权发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash ，基于CC0协议。

H5 移动调试全攻略

Tue, 13 Nov 2018 00:00:00 CST

随着移动设备的高速发展， H5开发也成为了 F2E不可或缺的能力。而移动开发的重中之重就是掌握调试技巧，定 Bug于无形。

文章首发于 Jartto’s blog，转载请标明出处。

一、概要

因为移动端操作系统分为 iOS和 Android两派，所以本文的调试技巧也会按照不同的系统来区分。寻找最合适高效的方式，才能让你事半功倍。

文章会列举目前适合移动端调试的多种方案，快来选择你的最佳实践吧！

二、iOS 设备

Safari：iphone 调试利器，查错改样式首选，需要我们做如下设置：

浏览器设置：Safari - 偏好设置 - 高级 - 勾选「在菜单栏中显示开发」菜单
iphone 设置：设置 - Safari - 高级 - 打开 Web 检查器

大功告成，这时候通过手机的 Safari来打开 H5页面，我们通过浏览器开发选项可以看到：

iOS 模拟器：不需要真机，适合调试 Webview和 H5有频繁交互的功能页面。

首先下载 Xcode，运行项目，选择模拟器 iphonex，编译后就会打开模拟器，如下：

可以看到 H5已经在「壳子」中运行起来了，下来就可以尝试调用 Webview的方法，和「壳子」交互了。更多的调试技巧可以参考文章： iOS 模拟器调试。

具体的调试功能还是依赖浏览器的开发选项，与上无异，就不赘述了。

三、抓包

Charles： Mac OS 系统首选的抓包工具，适合查看、控制网络请求，分析数据情况。

Charles抓包首先需要配置手机代理， Wifi- 配置代理（IP 地址） - 手动，如下图：

配置好手机代理，这时候打开 Charles，就会收到确认提醒，选择允许。接下来就可以捕获手机的请求了，但是这些都是常规操作，我们来点高级的。

有意思的是：我们可以用本地文件来替换线上文件，方便调试，远程定位线上问题。

选择 Structure，找到需要替换的文件，右键菜单 - Map Local，如下图：

这时候就会打开一个弹窗，填写具体的配置：

OK，大功告成，快去改动本地文件吧，从此再也不怕线上调试了。需要注意的是如果抓取 HTTPS请求，要安装信任证书，下文会详细说明。

与之相应的是 Windows 平台的 Fiddler，功能大致相似，这里就不细说了。

四、Spy-Debugger

spy-debugger：移动端调试的利器，便捷的远程调试手机页面、抓包工具。

我们先来安装：

1	> sudo npm install spy-debugger -g

启动命令：

1	> spy-debugger

这时候，控制台会打印出如下信息，说明服务已经启动了：

       正在启动代理
       本机在当前网络下的IP地址为：10.200.24.46
       node-mitmproxy启动端口: 9888
       浏览器打开 ---> http://127.0.0.1:50389

最后一步，设置手机代理： 10.200.24.46，端口号： 9888。补充说明一下：

Android设置代理步骤：设置 - WLAN- 长按选中网络 - 修改网络 - 高级 - 代理设置 - 手动
iOS设置代理步骤：设置 - 无线局域网 - 选中网络 - HTTP代理手动

接下来，尝试一下抓包：

再打开调试页面：

HTTPS抓包，需要安装根证书，下文会详细说明。

五、Whistle

上面推荐了一款操作简单的调试利器，升级一下，看看更加强大的调试工具 whistle。

whistle：基于 Node实现的跨平台 Web调试代理工具。

whistle(读音[ˈwɪsəl]，拼音[wēisǒu])是基于 Node实现的跨平台抓包调试代理工具，有以下基本功能：

查看 HTTP、 HTTPS请求响应内容
查看 WebSocket、 Socket收发的帧数据
设置请求 hosts、上游 http/socks代理
修改请求 url、方法、头部、内容
修改响应状态码、头部、内容，并支持本地替换
修改 WebSocket或 Socket收发的帧数据
内置调试移动端页面的 weinre和 log
作为 HTTP代理或反向代理
支持用 Node编写插件扩展功能

大致了解后，我们来尝试安装：

1	sudo npm install -g whistle

淘宝镜像：npm install whistle -g –registry= https://registry.npm.taobao.org

whistle安装完成后，执行命令 whistle help或 w2 help，查看 whistle的帮助信息：

       run       Start a front service
       start     Start a background service
       stop      Stop current background service
       restart   Restart current background service
       helpDisplayhelpinformation

这里只列出部分命令，更多请 w2 help 查看。

看到上面的操作，我们何不试试缩写 w2 start来启动服务：

       w2 start

看到如下的输出，说明服务已经正常启动了：

这时候在浏览器打开链接，同时手机上配置代理（同 Charles），接下来就可以愉快的调试了。值得注意的是， whistle的功能远非如此，更多的扩展请移步官网文档，贴张图先预览下：

记得开启拦截 HTTPS：勾选 Capture HTTPS CONNECTs

六、安装 HTTPS 证书

对于 Charles，按照如下操作安装证书：

1	help-SSL - Proxying - install Charles root

弹出安装证书的提示框：

按照提示去手机浏览器打开： chls.pro/ssl，安装信任证书即可。

对于 spy-debugger， HTTPS抓包，需要安装根证书，选择 RootCA，扫描二维码按照提示信任证书。安装证书的时候需要注意以下几件事情：

1.手机必须先设置完代理后再通过(非微信)手机浏览器访问 http://s.xxx(地址二维码)安装证书；
2.手机首次调试需要安装证书，已安装了证书的手机无需重复安装；
3.手机和 PC保持在同一网络下（比如同时连到一个 WIFI下）；

切记：移动设备和 PC 必须在一个 WIFI 下。

七、真机调试

上面说了很多，但是实际开发过程中，我们不会等上线了才去验证兼容性，所以你可能需要提前「真机调试」。这里提供两种方式：

Chrome Remote Devices：依赖 Chrome 来进行远程调试，适合安卓手机。

首先，开启 Android手机的「开发者选项」，勾选「USB 调试」。
然后， Chrome中输入： chrome://inspect，进入调试页面。

很全面的一篇文章，可以参考： Chrome 远程调试。

localhost转 ip，扫描二维码手机显示，这个比较简单。

可以在浏览器安装一个 Chrome插件，用于将当前页面链接转换成二维码，这样就能边开发边真机预览，非常方便。

八、调试工具

这里推荐一款调试工具： vConsole，一个轻量、可拓展、针对手机网页的前端开发者调试面板。安装很简单：

1	npm install vconsole

如果未使用 AMD/CMD规范，可直接在 HTML中引入 vConsole模块。为了便于后续扩展，建议在 <head>中引入：

       <head>
       <scriptsrc="path/to/vconsole.min.js"></script>
       <script>
       varvConsole =newVConsole();
       </script>
       </head>

如果使用了 AMD/CMD规范，可在 module内使用 require()引入模块：

1 2	var VConsole = require('path/to/vconsole.min.js'); var vConsole = new VConsole();

请注意， VConsole只是 vConsole的原型，而非一个已实例化的对象。

所以在手动 new实例化之前， vConsole不会被插入到网页中。大概功能如下图：

看起来很完美，但是有个小缺点：网络请求，需要刷新页面，可是很多内嵌的 H5页面是没有机会刷新页面的，所以需要客户端童鞋配合增加刷新的功能方便调试。

九、场景分析

既然移动端调试有这么多种方案，那在实际操作中，我该如何取舍？

说了这么多钟方案，这里总结一下各个方案的适用场景，根据不同的场景去选择最佳的调试方案，这样才能更快速的输出， Carry全场：

1. Safari： iPhone调试利器，查错改样式首选；
2. iOS模拟器：不需要真机，适合调试 Webview和 H5有频繁交互的功能页面；
3. Charles： Mac OS系统首选的抓包工具，适合查看、控制网络请求，分析数据情况；
4. Fiddler：适合 Windows平台，与 Charles类似，查看、控制网络请求，分析数据情况；
5. Spy-Debugger：移动端调试的利器，便捷的远程调试手机页面、抓包工具；
6. Whistle：基于 Node实现的跨平台 Web调试代理工具；
7. Chrome Remote Devices：依赖 Chrome来进行远程调试，适合安卓手机远程调试静态页；
8. localhost转 ip：真机调试，适合远程调试静态页面；
9. vConsole：内置于项目，打印移动端日志，查看网络请求以及查看 Cookie和 Storage；

十、白屏处理

移动端的白屏是最头疼的问题，这里顺带提供几种分析问题的思路，以供参考。

1.方案分析 ☆
一般上线后出现问题，我们最容易想到的就是：是否是新代码引起的问题。所以有效解决手段就是「控制变量法」。

2.代码注释法 ☆
莫名奇妙的白屏，适合页面无异常日志，同时无请求发送，问题集中在单一页面的情况。这种问题比较直观，肯定是某一页面出现了代码异常或是无效的 return，导致页面渲染终止，但并不属于异常。这时候，「代码注释法」将是你的最佳选择，逐行去注释可以代码，直到定位问题。

3.类库异常，兼容问题 ☆
这种场景也会经常遇到，我们需要用可以调试页面异常的方式，如 Safari， Spy-Debugger， Whistle， vConsole查看异常日志，从而迅速定位类库位置，从而找寻替换或是兼容方案。

4.try catch ☆☆
如果你的项目没有异常监控，那么在可疑的代码片段中去 Try Catch吧。

5.Debug 包 ☆☆☆
在你的项目中装上 vConsole，并配合客户端 debug插件， 360度无死角监控异常，这才是最有效的方式。

6.ES6 语法兼容 ☆
一般我们都会通过 Babel来编译 ES6，但是额外的第三方类库如果有不兼容的语法，低版本的移动设备就会异常。所以，先用上文讲述的调试方法，确定异常，然后去增加 polyfill来兼容吧。

工信部：我国移动基站总数近640万个 3G/4G基站占比75%

Tue, 23 Oct 2018 18:23:32 CST

根据工信部发布的《2018年9月份通信业经济运行情况》显示，截至9月末，我国移动通信基站达639万个，其中3G/4G基站总数达到479万个，占比达74.9%。数据还显示，我国互联网宽带接入端口数量达8.58亿个，同比增长12.6%。基础电信企业继续加快“光进铜退”进程，光纤接入（FTTH/0）端口达到7.47亿个。xDSL端口总数下降至1822万个。

2016年9月末-2018年9月末互联网宽带接入端口数发展情况

2016年9月末-2018年9月末移动电话基站数发展情况

另据报告，前三季度，我国新建光缆线路350万公里，光缆线路总长度达到4130万公里，同比增长14.5%。接入网光缆、本地网中继光缆和长途光缆线路所占比重分别为65.9%、31.5%和2.6%。

日益增加的移动诈骗攻击分析简报

Fri, 05 Oct 2018 15:00:30 CST

移动设备，早就已经成为了攻击者的主要目标，因此移动端诈骗攻击的活动愈加频繁也就不足为奇了。目前，有大约58%的数字交易活动是通过移动端设备发起的，而且现在的网络攻击活动中有1/3也是针对移动端设备的。在美国就更加严重了，每年全球针对移动端的诈骗攻击增长率约为24%，但美国的同类攻击增长率每年约为44%，你们说惨不惨…

本文的数据来源于TreatMetrix发布的2018年第二季度网络犯罪报告【 PDF】，而这份报告的采样数据来源于研究人员对2018年第一季度里176亿条数字交易记录的分析结果。

ThreatMetrix的高层Alisdair Faulkner表示：“移动端设备已经迅速成为了人们访问在线商城和网络服务的主要方式了，因此针对移动端设备攻击活动的数量迅速增长，这也在我们的意料之中。除此之外，无论用户还是厂商，他们都喜欢移动端设备，而主要原因就是移动端设备可以当做一个人的身份标识。”

对于厂商来说，移动端交易比桌面端交易要更加安全。而对于用户来说，移动端交易实现起来也更加方便。这个过程中交易机制的基础规则为：独立设备可以通过身份验证机制来进行安全识别，而个人用户能够与移动端设备进行绑定，并通过内置的生物识别功能（例如面部识别、声纹识别和指纹识别）等健壮性较强的验证机制来对个人用户进行安全识别。

比如说，MasterCard（万事达卡）就率先在用户身份识别中采用了基于手机和生物识别的验证方案，但这样只会增加使用移动端设备完成金融交易的用户数量，因为这种方式也是一把双刃剑。卡巴斯基实验室的安全研究专家David Emm认为：“存储在服务提供商的数据库里的生物识别数据跟用户名和密码一样，是有可能被网络犯罪分子窃取的。一旦发生了数据泄露，客户的用户名和密码能够修改，但生物识别数据却是没法修改的，因为这种数据你一辈子都无法改变（整容也没用啊…）”

Faulkner补充说道：“但好消息就是，随着移动端设备的使用频率迅速增长，用户的总体识别成功率也在随之增高，因为各种移动端App为了抢夺市场，他们会设计出各种各样更高精准度的用户身份识别技术。然而，整个过程最关键也是最脆弱的环节就在于应用程序的注册阶段以及用户账号的创建阶段。”

需要注意的是，针对移动端设备的攻击活动很可能会在短期之内迅速增加，尤其是在欧洲的PSD2（开放银行条款）发布之后，而这一条款的主要目的就是推动新兴金融科技公司以及相关应用程序的增长和发展。这样一来，又会有更多的网络犯罪分子将他们的“矛头”指向这些“新人”，这也是不可避免的。其实整个金融服务行业已经徘徊在了改革的“悬崖”边上，而欧洲地区的各大银行也在小心翼翼地等待着，他们都在思考如何向第三方供应商（账户信息服务提供商或支付服务提供商）开放API接口才能让大家都满意。

目前，最大的威胁来自于设备欺骗，欺诈攻击者会尝试欺骗银行让他们认为此次“登录尝试”来自于新的用户设备，而目前有超过5%的交易尝试来被认定为此类攻击。身份欺骗则是第二大威胁，约占3.6%，但对于针对金融服务的特定攻击来说，网络犯罪分子通常会使用的是凭证窃取，而非身份欺骗。除此之外，这一季度有25%的新增电子商务账号应用都是欺诈攻击的产物，而这一数字跟2017年同期相比增加了130%。

其他常见的攻击类型包括IP欺骗、基于浏览器的中间人攻击或BOT攻击。使用僵尸网络发动的攻击活动也越来越频繁了，2018年第二季度总共检测到了26亿次BOT攻击，相较于2018年第一季度增长了60%，而这些BOT会使用自动化脚本和窃取到的凭证来尝试访问目标账号或进行欺诈交易。

ThreatMetrix还警告称，随着全球金融体的连接紧密度在不断加深，企业需要确保他们能够动态地去识别和分析各种欺诈活动，而此时基于行为的欺诈检测系统就可以“大放异彩”了。

*参考来源： securityweek，FB小编Alpha_h4ck编译，转载请注明来自FreeBuf.COM

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

Sat, 11 Aug 2018 20:28:52 CST

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

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

增速碾压

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

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

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

健康成长

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

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

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

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

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

自中国通信网

广东移动：终端行业分析报告

Thu, 09 Aug 2018 23:45:17 CST

报告结果总览：

1）相较于第一季度，第二季度市场略有缩小

2）华为表现不俗，市场占比，用户忠诚度均优于其他品牌

3）选择在6-12月内的换机用户比例有较大幅度增长

4）华为、苹果、OPPO、VIVO四大品牌中超50%的用户忠诚于原品牌

5）用户更爱换至安卓机，流向苹果用户数量减少

（一）手机市场总洞察：第二季度销量下滑，华为超过苹果，iPhone以及OPPO机型表现出色

2018年第二季度的三个月，用户新增手机数量相较于第一季度，减幅达到300多万台。

第二季度用户新增手机品牌中，华为销量超越苹果占第一，国产品牌占据了TOP5中的四席。

从用户换机前后的的市场份额占比看，OPPO及华为在第二季度的增长幅度最大，其中华为增长4.16%，OPPO增长4.62%

iPhone和OPPO机型表现出色，瓜分排名的前10。

（二）用户换机行为总洞察：超3成用户不到半年就换机，四大品牌用户忠诚度超50%

相比起第一季度，第二季度依然有34.59%的用户的换机周期是在半年内的，换机周期在6-12个月的用户大幅增长。

华为、苹果、OPPO及 VIVO的用户忠诚度均高于50%，即超过50%的用户还会换至原品牌。其中，华为的用户忠诚度高于其他品牌。

用户在手机品牌选择更换时有以下几个明显的转变：

1、华为用户更倾向于更换至苹果以及OPPO；

2、苹果用户更倾向于换至华为及OPPO；

3、OPPO用户更倾向于换至VIVO、苹果及华为；

4、VIVO用户更倾向于换至OPPO及华为。

* 数据来源：中国移动通信集团广东有限公司内部数据

* 数据对象：中国移动通信集团广东有限公司用户

* 取数时间：2018年4月-6月

* 备注：本报告结论均为取数时间段内广东地区移动客户新增手机市场，未包含其他区域及运营商。本数据通过客户使用服务过程中合法数据分析获得。

来自：广东移动

移动端跨平台开发的深度解析

Wed, 01 Aug 2018 00:00:00 CST

跨平台一直是老生常谈的话题，cordova、ionic、react-native、weex、kotlin-native、flutter等跨平台框架的百花齐放，颇有一股推倒原生开发者的势头。（事实上更多是共存发展）看完本篇，相信你会对于当下跨平台移动开发的现状、实现原理、框架的选择等有更深入的理解。

全篇内容较多，需耐心食用！　(///▽///)

一、前言

为什么我们需要跨平台开发？本质上，跨平台开发是为了增加代码复用，减少开发者对多个平台差异适配的工作量，降低开发成本，提高业务专注的同时，提供比web更好的体验。嗯～通俗了说就是： 省钱、偷懒。

本篇主要以react-native、weex、flutter，结合资讯展望，深入聊聊当前跨平台移动开发的实现原理、现状与未来。至于为什么只讲它们，因为对比ionic、phoneGap，它们更于 “naive” (˶‾᷄ ⁻̫ ‾᷅˵)。

超完整跨平台开源项目

类型	链接
react-native	https://github.com/CarGuo/GSYGithubApp
weex	https://github.com/CarGuo/GSYGithubAppWeex
Flutter	https://github.com/CarGuo/GSYGithubAppFlutter

百花齐放

二、原理与特性

目前移动端跨平台开发中，大致归纳为以下几种情况：

react native、 weex均使用JavaScript作为编程语言，目前JavaScript在跨平台开发中，可谓占据半壁江山，大有“一统天下”的趋势。
kotlin-native开始支持 iOS 和 Web 开发，（kotlin已经成为android的一级语言）也想尝试“一统天下”。
flutter是Google跨平台移动UI框架，Dart作为谷歌的亲儿子，毫无疑问Dart成为flutter的编程语言，如下图，作为巨头新生儿，在flutter官网也可以看出，flutter同样“心怀天下”。

flutter 官网野心勃勃

1、React Native

Facebook 出品，JavaScript语言，JSCore引擎，React设计模式，原生渲染

1.1、理念架构

“Learn once, write anywhere”，代表着 Facebook对 react native 的定义：学习 react ，同时掌握 web与 app两种开发技能。 react native 用了 react 的设计模式，但UI渲染、动画效果、网络请求等均由原生端实现。开发者编写的js代码，通过 react native 的中间层转化为原生控件和操作，比 ionic等跨平台应用，大大提高了的用户体验。

总结起来其实就是利用 JS 来调用 Native 端的组件，从而实现相应的功能。

如下图所示，react native 的跨平台是实现主要由三层构成，其中 C++ 实现的动态连结库(.so)，作为中间适配层桥接，实现了js端与原生端的双向通信交互。这里最主要是封装了 JavaScriptCore执行js的解析，而 react native 运行在JavaScriptCore中，所以不存在浏览器兼容的问题。

其中在IOS上直接使用内置的 javascriptcore，在Android 则使用webkit.org官方开源的 jsc.so。

图片来源网络

1.2、实现原理

和前端开发不同，react native 所有的标签都不是真实控件，JS代码中所写控件的作用，类似 Map 中的 key 值。JS端通过这个 key 组合的 Dom ，最后Native端会解析这个 Dom ，得到对应的Native控件渲染，如 Android 中 <view>标签对应 ViewGroup控件。

图片来源网络

在 react native 中，JS端是运行在独立的线程中（称为JS Thread ）。JS Thread 作为单线程逻辑，不可能处理耗时的操作。那么如 fetch、 图片加载、 数据持久化等操作，在 Android 中实际对应的是 okhttp、 Fresco、 SharedPreferences等。而跨线程通信，也意味着 Js Thread 和原生之间交互与通讯是异步的。

可以看出，跨平台的关键在于C++层，开发人员大部分时候，只专注于JS 端的代码实现。在原生端提供的各种 Native Module 模块（如网络请求，ViewGroup控件），和 JS 端提供的各种 JS Module（如JS EventEmiter模块），都会在C++实现的so中保存起来，双方的通讯通过C++中的保存的映射，最终实现两端的交互。通信的数据和指令，在中间层会被转为String字符串传输，双向的调用流程如下图。

图片来源网络，js调用native

图片来源网络，native调用js

1.3、打包加载

最终，JS代码会被打包成一个 bundle 文件，自动添加到 App 的资源目录下。react native 的打包脚本目录为 /node_modules/react-native/local-cli，打包最后会通过 metro模块压缩 bundle 文件。而bundle文件只会打包js代码，自然不会包含图片等静态资源，所以打包后的静态资源，其实是被拷贝到对应的平台资源文件夹中。

其中图片等存在资源的映射规则，比如放在 react native 项目根目录下的 img/pic/logo.png的资源，编译时，会被重命名后，根据大小 merged 到对应的是drawable目录下，修改名称为 img_pic_logo.png。

打包Android和IOS，肯定需要相应的平台项目存在，在 react-native init时创建的项目，就已经包含了 android 和 ios 的模版工程，打包完的工程会加载bundle文件，然后启动项目，如下图。这里就不展（tou）开（lan）了，有兴趣的可以看： React Native For Android 架构初探。

图片来源QQ空间移动开发团队，完成启动流程图

2、WEEX

Alibaba 出品，JavaScript语言，JS V8引擎，Vue设计模式，原生渲染

2.1、理念架构

“Write once, run everywhere”, weex的定义就像是： 写个 vue 前端，顺便帮你编译成性能还不错的 apk 和 ipa（当然，现实有时很骨感）。基于 Vue 设计模式，支持 web、android、ios 三端，原生端同样通过中间层转化，将控件和操作转化为原生逻辑来提高用户体验。

在 weex 中，主要包括三大部分： JS Bridge、 Render、 Dom，分别对应 WXBridgeManager、 WXRenderManager、 WXDomManager，三部分通过 WXSDKManager统一管理。其中 JS Bridge和 Dom都运行在独立的 HandlerThread 中，而 Render 运行在 UI 线程。

JS Bridge主要用来和 JS 端实现进行双向通信，比如把 JS 端的 dom 结构传递给 Dom线程。 Dom主要是用于负责 dom 的解析、映射、添加等等的操作，最后通知UI线程更新。而 Render负责在UI线程中对 dom 实现渲染。

图片来自网络

2.2、实现原理

和 react native一样，weex 所有的标签也不是真实控件，JS 代码中所生成存的 dom，最后都是由 Native 端解析，再得到对应的Native控件渲染，如 Android 中 <text>标签对应 WXTextView控件。

weex 中文件默认为 .vue ，而 vue 文件是被无法直接运行的，所以 vue 会被编译成 .js 格式的文件，Weex SDK会负责加载渲染这个js文件。Weex可以做到跨三端的原理在于： 在开发过程中，代码模式、编译过程、模板组件、数据绑定、生命周期等上层语法是一致的。不同的是在 JS Framework层的最后，web 平台和 Native 平台，对 Virtual DOM 执行的解析方法是有区别的。

实际上，在 Native 中对 bundle 文件的加载大致经历以下阶段：

weex 接收到 js 文件以后，JS Framework 根据文件为 Vue 模式，会调用 weex-vue-framework中提供的 createInstance方法创建实例。 (也可能是Rax模式)
createInstance中会执行 Js Entry 代码里 new Vue()创建一个组件，通过其 render 函数创建出 Virtual DOM 节点。
由JS V8 引擎上解析 Virtual DOM ，得到 Json 数据发送至 Dom 线，这里输出 Json 也是方便跨端的数据传输。
Dom 线程解析 Json 数据，得到对应的 WxDomObject，然后创建对应的 WxComponent提交 Render 。
Render在原生端最终处理处理渲染任务，并回调里JS方法。

得益于上层的统一性，只是通过 weex-vue-framework判断是由 Vue.js生成真实的 Dom ，还是通过 Native Api 渲染组件，weex 一定程度上上，用JS 实现了 vue一统天下的效果。

图片来源网络

weex 在原生渲染 Render 时，在接收到渲染指令后，会逐步将数据渲染成原生组件。Render 通过解析渲染数据的描述，然后分发给不同的模块。

比如控件渲染属于 dom模块中，页面跳转属于 navigator模块等。模块的渲染过程并非一个执行完，再执行另一个的流程，而是类似流式的过程。如上一个 <text>的组件还没渲染好，下一个 <div>的渲染又发了过来。这样当一个组件的嵌套组件很多时，或者可以看到这个大组件内的UI，一个一个渲染出来的过程。

weex 比起react native，主要是在JS V8的引擎上，多了 JS Framework承当了重要的职责，使得上层具备统一性，可以支持跨三个平台。总的来说它主要负责是： 管理Weex的生命周期； 解析JS Bundle，转为Virtual DOM，再通过所在平台不同的API方法，构建页面； 进行双向的数据交互和响应。

2.3、打包

weex 作为 react-native 之后出现的跨平台实现方案，自然可以站在前人的肩膀上优化问题，比如： Bundle文件过大问题。

Bundle文件的大小，很大程度上影响了框架的性能，而 weex 选择将 JS Framework集成到 WeexSDK 中，一定程度减少了JS Bundle的体积，使得 bundle 里面只保留业务代码。

打包时，weex 是通过 webpack 打包出 bundle 文件的。bundle 文件的打包和 entry.js文件的配置数量有关，默认情况下之后一个 entry 文件，自然也就只有一个bundle文件。

在 weex 项目的 webpack.common.conf.js中可以看到，其实打包也是区分了 webConfig和 weexConfig的不同打包方式。如下图，其中weexEntry 就是 weex 打包配置的地方，可以看到本来已经有 index和 entry.js存在了。如果有需要，可配置上你需要的打包页面，具体这里就不详细展开了。有兴趣可看： Weex原理之带你去蹲坑。

3、Flutter

Google 出品，Dart语言，Flutter Engine引擎，响应式设计模式，原生渲染

Flutter 是谷歌2018年发布的跨平台移动UI框架。相较于本人已经在项目中使用过 react native 和 Weex，Flutter目前仅仅是简单运行过Demo，毕竟还是beta 阶段，这里更多的聊一下它的实现机制和效果。

与 react native 和 weex 的通过 Javascript 开发不同，Flutter 的编程语言是Drat，（谷歌亲儿子，据说是因为 Drat 项目组就在 Flutter 隔壁而被选上(◐‿◑)）所以执行时并不需要 Javascript 引擎，但实际效果最终也通过原生渲染。

图片来源网络

如上图，Flutter 主要分为 Framework和 Engine，我们基于Framework 开发App，运行在 Engine 上。Engine 是 Flutter 的独立虚拟机，由它适配和提供跨平台支持，目前猜测 Flutter 应用程序在 Android 上，是直接运行 Engine 上所以在是不需要Dalvik虚拟机。（这是比kotlin更彻底，抛弃JVM的纠缠？）

如下图，得益于 Engine 层，Flutter 甚至不使用移动平台的原生控件，而是使用自己 Engine 来绘制 Widget （Flutter的显示单元），而 Dart 代码都是通过 AOT 编译为平台的原生代码，所以 Flutter 可以直接与平台通信，不需要JS引擎的桥接。同时 Flutter 唯一要求系统提供的是 canvas，以实现UI的绘制。咦？这么想来，支持web端也没问题吧！

图片来源网络

在Flutter中，大多数东西都是widget，而widget是不可变的，仅支持一帧，并且在每一帧上不会直接更新，要更新而必须使用Widget的状态。无状态和有状态 widget 的核心特性是相同的，每一帧它们都会重新构建，有一个State对象，它可以跨帧存储状态数据并恢复它。

Flutter 上 Android 自带了 Skia，Skia是一个 2D的绘图引擎库，跨平台，所以可以被嵌入到 Flutter的 iOS SDK中，也使得 Flutter Android SDK要比 iOS SDK小很多。

三、对比

这算是互相伤害的环节了吧。(///▽///)

类型	React Native	Weex	Flutter
平台实现	JavaScript	JavaScript	无桥接，原生编码
引擎	JS V8	JSCore	Flutter engine
核心语言	React	Vue	Dart
Apk大小 (Release)	7.6M	10.6M	8.1M
bundle文件大小	默认单一、较大	较小、多页面可多文件	不需要
上手难度	稍高？	容易	一般
框架程度	较重	较轻	重
特点(不局限)	适合开发整体App	适合单页面	适合开发整体App
社区	丰富，Facebook重点维护	有点残念，托管apache	刚刚出道小鲜肉，拥护者众多
支持	Android、IOS	Android、IOS、Web	Android、IOS（并不止？）

1、大小

上面Apk大小是通过 react-native init、 weex create和 flutter 创建出的工程后，直接不添加任何代码，打包出来的 release 签名 apk 大小。从下图可以看出，其中大比例都是在so库。

2、社群

react native 作为 Facebook 主力开源项目之一，至今已有各类丰富的第三方库，甚至如 realm、 lottie等开源项目也有 react native 相关的版本，社群实际无需质疑。当然，因为并完全正统开发平台，第三库的健壮性和兼容性有时候总是良莠不齐。

weex 其实有种生错在国内的感觉。其实 weex 的设计和理念都很优秀，性能也不错，但是对比 react native 的第三方支持，就显得有点后妈养的。2016年开源至今，社区和各类文档都显得有点疲弱，作为跨平台开发人员，大多时候肯定不会希望，需要频繁的自己增加原生功能支持，因为这样的工作一多，反而会与跨平台开发的理念背道而驰，带来开发成本被维护难度增加。

Flutter目前还处理beta阶段，但是谷歌的号召力一直很可观，这一点无需质疑。

3、性能

理论上 flutter 的性能应该是最好的，但是目前实际体验中，却并没有感受出来太大的差距，和 react native（0.5.0之后）、weex 在性能上个人体验差异不是很大。当然，这里并没有实测渲染的毫秒时间和帧率数据。

4、其他区别

Weex的多页面实现问题

weex 在 native 端是不支持 <keep-alive>的，这一点和 react-native 不同在与，如果在 native 需要实现页面跳转，使用 vue-router 将会惨不忍睹：返回后页面不做特别处理时，是会空白一片。参考官方Demo playground，native 端的采用 weex.requireModule('navigator')跳转 Activity 是才正确实现。

同时，weex中 navigator 跳转的设计，也导致了多页面的页面间通讯的差异。weex在多页面下的数据通讯，是通过url实现的，比如 file://assets/dist/SecondPage.js?params=0，而vuex和vue-router在跨页面是无法共用的；而 react native 在跨 Actvity 使用时，因为是同一个bundle文件，只要 manager 相同，那么 router 和 store 时可以照样使用的，数据通信方式也和当个 Actvity 没区别。

项目模板

weex 和 react native 模板代码模式也不同。weex 的模板是从 cordova 模式修改过来的，根据platform需求，用命令添加固定模块，而在 .gitignore 对 platforms文件夹是忽略跟踪。 react native 在项目创建时模版就存在了，特别是添加第三方插件原生端支持时，会直接修改模板代码，git代码中也会添加跟踪修改。

四、未来趋势

我们选择框架的时候，很多时候会关注框架的成熟度和生命力不是么(◐‿◑)。

1、React Native

“Airbnb 宣布放弃使用 React Native，回归使用原生技术”: Airbnb 作为 react native 平台上最大的支持者之一，其开源的 lottie同样是支持原生和 react native。

Airbnb 在宣布放弃的文中，也对 react native 的表示了很大量的肯定，而使得他们放弃的理由，其实主要还是集中于项目庞大之后的维护困难，第三方库的良莠不齐，兼容上需要耗费更多的精力导致放弃。

ps：（ Lottie库Airbnb出的是一个能够帮助解析AE导出的包含动画信息的json文件。这很好的解决了一个矛盾，设计师可以更专注的设计出各种炫酷的动画效果，而开发只需要将其加入支持即可。）

Facebook 正在重构 React Native，将重写大量底层。在经历了开源协议风波后，可以看出 Facebook 对于 react native 还是很看重的，这些底层重构优化的地方，主要集中于：

首先，改变线程模型。UI 更新不再需要在三个不同的线程上执行，而是可以在任意线程上同步调用 JavaScript 进行优先更新，同时将低优先级工作推出主线程，以便保持对 UI 的响应。
其次，将异步渲染功能引入 React Native 中，允许执行多个渲染并简化异步数据处理。
最后，简化桥接，让它更快、更轻量。原生和 JavaScript 之间的直接调用效率更高，并且可以更轻松地构建调试工具，如跨语言堆栈跟踪。

2、Weex

没有死！阿里公开Weex技术架构，还开源了一大波组件。2018年初的新闻可以看出，weex 的遭遇有点类似曾经的 Duddo（Dubbo因为内部竞争被阿里一度放弃维护），这波诈尸后 weex被托管到了Apache，而github的 weexteam如今也还保持着更新，希望后续能有多好的发展，拭目以待吧。

3、Flutter

Flutter 是 Google 跨平台移动UI框架，Dart作为谷歌的亲儿子在 Flutter 中使用，并且谷歌新操作系统 Fuchsia 支持 Dart，使用 Flutter 作为操作UI框架。这些集合到一起难免让你怀疑 Android 是否要被谷歌抛弃的想法。

或者如今先 Android 等平台上推广 Flutter 与 Dart，就是为了以后跟好的过渡到新系统上，毕竟开发者是操作系统的生命源泉之一。而 Java 与 JVM 或者可以被谷歌完全抛开。当然，目前看起来 Flutter 貌似还缺少一些语法糖，嵌套下来的代码有点不忍直视，或者到正式版之后，我们更能感受出它的美丽吧。

最后

内容有点长，其实很多点并没有细致的展开说明，但是通过本文，对于移动端跨平台的现状与未来，希望可能给你带来一点帮助。

超完整跨平台开源项目

类型	链接
react-native	https://github.com/CarGuo/GSYGithubApp
weex	https://github.com/CarGuo/GSYGithubAppWeex
Flutter	https://github.com/CarGuo/GSYGithubAppFlutter

其他React Native相关文章：

其他Weex相关文章：

Weex原理之带你去蹲坑

撸文真的好累

如何使用TensorFlow mobile部署模型到移动设备 - CSDN博客

Mon, 16 Jul 2018 15:24:42 CST

截止到今年，已经有超过 20 亿活跃的安卓设备。安卓手机的迅速普及很大程度上是因为各式各样的智能 app，从地图到图片编辑器应有尽有。随着深度学习的出现，我们的手机 app 将变得更加智能。下一代由深度学习驱动的手机 app 将可以学习并为你定制功能。一个很显著的例子是「Microsoft Swiftkey」，这是一个键盘 app, 能通过学习你常用的单词和词组来帮助你快速打字。

计算机视觉，自然语言处理，语音识别和语音合成等技术能够大大改善用户在移动应用方面的体验。幸运的是，在移动应用方面，有很多工具开发成可以简化深度学习模型的部署和管理。在这篇文章中，我将阐释如何使用 TensorFlow mobile 将 PyTorch 和 Keras 部署到移动设备。

用 TensorFlow mobile 部署模型到安卓设备分为三个步骤：

将你的训练模式转换到 TensorFlow
在安卓应用中添加 TensorFlow mobile 作为附加功能
在你的应用中使用 TensorFlow 模式写 Java 代码执行推理。

在这篇文章中，我将介绍整个过程，最后完成一个植入图像识别功能的安卓应用。

安装

本教程会用到 PyTorch 和 Keras 两个框架-遵循下列指导安装你想使用的机器学习框架。安装哪个由你选择。

首先，安装 TensorFlow：

pip3 install tensorflow

如果你是 PyTorch 的开发者，确保你安装的是 PyTorch 的最新版本。关于安装 PyTorch 的指导文件，请查阅我之前的文章：

https://heartbeat.fritz.ai/basics-of-image-classification-with-pytorch-2f8973c51864

如果你是 Keras 的开发者，使用以下命令安装：

pip3 install keras
pip3 install h5py

Android Studio（至少3.0 的版本）

https://developer.android.com/studio

将 PyTorch 模式转成 Keras 模式

这部分仅适用于 PyTorch 开发者。如果你使用的是 Keras，你可以跳到 “将 Keras 模式转成 TensorFlow 模式”章节。

首先我们要做的是将我们的 PyTorch 模式参数转成 Keras 中的同等参数。

为了简化这个过程，我创建了一个脚本来自动运行转化。在此教程中，我们将使用 Squeezenet 。这是一种很小但具备合理精确度的移动架构。在这儿下载预训练模式（只有5M！)。

在转权值之前，我们需要在 PyTorch 和 Keras 中定义 Squeezenet 模型。

如下图所示，在这两种框架下定义 Squeezenet，然后将 PyTorch 权值转成 Keras。

创建文件 convert.py，包括下面的代码并运行脚本。

import torch
import torch.nn as nn
from torch.autograd import Variable
import keras.backend as K
from keras.models import *
from keras.layers import *

import torch
from torchvision.models import squeezenet1_1

class PytorchToKeras(object):
def __init__(self,pModel,kModel):
super(PytorchToKeras,self)
self.__source_layers = []
self.__target_layers = []
self.pModel = pModel
self.kModel = kModel

K.set_learning_phase(0)

def __retrieve_k_layers(self):

for i,layer in enumerate(self.kModel.layers):
if len(layer.weights) > 0:
self.__target_layers.append(i)

def __retrieve_p_layers(self,input_size):

input = torch.randn(input_size)

input = Variable(input.unsqueeze(0))

hooks = []

def add_hooks(module):

def hook(module, input, output):
if hasattr(module,"weight"):
self.__source_layers.append(module)

if not isinstance(module, nn.ModuleList) and not isinstance(module,nn.Sequential) and module != self.pModel:
hooks.append(module.register_forward_hook(hook))

self.pModel.apply(add_hooks)

self.pModel(input)
for hook in hooks:
hook.remove()

def convert(self,input_size):
self.__retrieve_k_layers()
self.__retrieve_p_layers(input_size)

for i,(source_layer,target_layer) in enumerate(zip(self.__source_layers,self.__target_layers)):

weight_size = len(source_layer.weight.data.size())

transpose_dims = []

for i in range(weight_size):
transpose_dims.append(weight_size - i - 1)

self.kModel.layers[target_layer].set_weights([source_layer.weight.data.numpy().transpose(transpose_dims), source_layer.bias.data.numpy()])

def save_model(self,output_file):
self.kModel.save(output_file)
def save_weights(self,output_file):
self.kModel.save_weights(output_file)

"""
We explicitly redefine the Squeezent architecture since Keras has no predefined Squeezent
"""

def squeezenet_fire_module(input, input_channel_small=16, input_channel_large=64):

channel_axis = 3

input = Conv2D(input_channel_small, (1,1), padding="valid" )(input)
input = Activation("relu")(input)

input_branch_1 = Conv2D(input_channel_large, (1,1), padding="valid" )(input)
input_branch_1 = Activation("relu")(input_branch_1)

input_branch_2 = Conv2D(input_channel_large, (3, 3), padding="same")(input)
input_branch_2 = Activation("relu")(input_branch_2)

input = concatenate([input_branch_1, input_branch_2], axis=channel_axis)

return input

def SqueezeNet(input_shape=(224,224,3)):

image_input = Input(shape=input_shape)

network = Conv2D(64, (3,3), strides=(2,2), padding="valid")(image_input)
network = Activation("relu")(network)
network = MaxPool2D( pool_size=(3,3) , strides=(2,2))(network)

network = squeezenet_fire_module(input=network, input_channel_small=16, input_channel_large=64)
network = squeezenet_fire_module(input=network, input_channel_small=16, input_channel_large=64)
network = MaxPool2D(pool_size=(3,3), strides=(2,2))(network)

network = squeezenet_fire_module(input=network, input_channel_small=32, input_channel_large=128)
network = squeezenet_fire_module(input=network, input_channel_small=32, input_channel_large=128)
network = MaxPool2D(pool_size=(3, 3), strides=(2, 2))(network)

network = squeezenet_fire_module(input=network, input_channel_small=48, input_channel_large=192)
network = squeezenet_fire_module(input=network, input_channel_small=48, input_channel_large=192)
network = squeezenet_fire_module(input=network, input_channel_small=64, input_channel_large=256)
network = squeezenet_fire_module(input=network, input_channel_small=64, input_channel_large=256)

#Remove layers like Dropout and BatchNormalization, they are only needed in training
#network = Dropout(0.5)(network)

network = Conv2D(1000, kernel_size=(1,1), padding="valid", name="last_conv")(network)
network = Activation("relu")(network)

network = GlobalAvgPool2D()(network)
network = Activation("softmax",name="output")(network)

input_image = image_input
model = Model(inputs=input_image, outputs=network)

return model

keras_model = SqueezeNet()

#Lucky for us, PyTorch includes a predefined Squeezenet
pytorch_model = squeezenet1_1()

#Load the pretrained model
pytorch_model.load_state_dict(torch.load("squeezenet.pth"))

#Time to transfer weights

converter = PytorchToKeras(pytorch_model,keras_model)
converter.convert((3,224,224))

#Save the weights of the converted keras model for later use
converter.save_weights("squeezenet.h5")

上面是已经转好权值的，你所需要做的是将 Keras 模型保存为 squeezenet.h5。到这一步，我们可以抛弃 PyTorch 模型，继续下一步了。

将 Keras 转成 TensorFlow 模式

到这一步，你已经有了 Keras 模式，无论是从 PyTorch 转化而来的还是直接用 Keras 训练而获得的。你可以在这儿下载预训练的 Keras Squeezenet 模式。下一步是将我们整个的模型架构和权值转成可运行的 TensorFlow 模型。

创建一个新文件 ConvertToTensorflow.py 并添加以下代码。

from keras.models import Model
from keras.layers import *
import os
import tensorflow as tf

def keras_to_tensorflow(keras_model, output_dir, model_name,out_prefix="output_", log_tensorboard=True):

if os.path.exists(output_dir) == False:
os.mkdir(output_dir)

out_nodes = []

for i in range(len(keras_model.outputs)):
out_nodes.append(out_prefix + str(i + 1))
tf.identity(keras_model.output[i], out_prefix + str(i + 1))

sess = K.get_session()

from tensorflow.python.framework import graph_util, graph_io

init_graph = sess.graph.as_graph_def()

main_graph = graph_util.convert_variables_to_constants(sess, init_graph, out_nodes)

graph_io.write_graph(main_graph, output_dir, name=model_name, as_text=False)

if log_tensorboard:
from tensorflow.python.tools import import_pb_to_tensorboard

import_pb_to_tensorboard.import_to_tensorboard(
os.path.join(output_dir, model_name),
output_dir)

"""
We explicitly redefine the Squeezent architecture since Keras has no predefined Squeezenet
"""

def squeezenet_fire_module(input, input_channel_small=16, input_channel_large=64):

channel_axis = 3

input = Conv2D(input_channel_small, (1,1), padding="valid" )(input)
input = Activation("relu")(input)

input_branch_1 = Conv2D(input_channel_large, (1,1), padding="valid" )(input)
input_branch_1 = Activation("relu")(input_branch_1)

input_branch_2 = Conv2D(input_channel_large, (3, 3), padding="same")(input)
input_branch_2 = Activation("relu")(input_branch_2)

input = concatenate([input_branch_1, input_branch_2], axis=channel_axis)

return input

def SqueezeNet(input_shape=(224,224,3)):

image_input = Input(shape=input_shape)

network = Conv2D(64, (3,3), strides=(2,2), padding="valid")(image_input)
network = Activation("relu")(network)
network = MaxPool2D( pool_size=(3,3) , strides=(2,2))(network)

network = squeezenet_fire_module(input=network, input_channel_small=16, input_channel_large=64)
network = squeezenet_fire_module(input=network, input_channel_small=16, input_channel_large=64)
network = MaxPool2D(pool_size=(3,3), strides=(2,2))(network)

network = squeezenet_fire_module(input=network, input_channel_small=32, input_channel_large=128)
network = squeezenet_fire_module(input=network, input_channel_small=32, input_channel_large=128)
network = MaxPool2D(pool_size=(3, 3), strides=(2, 2))(network)

network = squeezenet_fire_module(input=network, input_channel_small=48, input_channel_large=192)
network = squeezenet_fire_module(input=network, input_channel_small=48, input_channel_large=192)
network = squeezenet_fire_module(input=network, input_channel_small=64, input_channel_large=256)
network = squeezenet_fire_module(input=network, input_channel_small=64, input_channel_large=256)

#Remove layers like Dropout and BatchNormalization, they are only needed in training
#network = Dropout(0.5)(network)

network = Conv2D(1000, kernel_size=(1,1), padding="valid", name="last_conv")(network)
network = Activation("relu")(network)

network = GlobalAvgPool2D()(network)
network = Activation("softmax",name="output")(network)

input_image = image_input
model = Model(inputs=input_image, outputs=network)

return model

keras_model = SqueezeNet()

keras_model.load_weights("squeezenet.h5")

output_dir = os.path.join(os.getcwd(),"checkpoint")

keras_to_tensorflow(keras_model,output_dir=output_dir,model_name="squeezenet.pb")

print("MODEL SAVED")

上面的代码将我们的 squeezenet.pb 保存到了 output_dir 中。并在同一文件夹中创建了 TensorBoard 事件。

为了更加清晰地理解你的模型，你可以用 TensorBoard 将它可视化。

打开命令行并输入

tensorboard –logdir=output_dir_path

output_dir_path would be the path to your output_dir.

一旦 TensorBoard 成功启动，你将看到提示让你打开如下 url COMPUTER_NAME:6006

将 URL 地址输入到浏览器中，将显示以下界面。

为了可视化你的模式，双击 IMPORT.

仔细看下该模型并记下输入和输出节点的名字（框架中的第一个和最后一个）。

如果你的命名和我之前代码一样的话，他们就应该是 input_1 和output_1 。

到这一步，我们的模型就可以调用了。

将 TensorFlow Mobile 添加到你的项目中

TensorFlow 有 2 个针对移动设备的库，分别是「TensorFlow Mobile」和「TensorFlow Lite.」Lite 版本设计得非常小，所有的依赖库大约只有 1M。它的模型也更优化。另外，在安卓 8 以上的设备中，还可以用神经网络 API 加速。与「TensorFlow Mobile」不同,「TensorFlow Lite.」目前还不太完善，有些层并不能实现预期的效果。此外，windows 系统还不支持编译库和将模式转成原生格式的操作。因此，在这个教程里，我坚持用 TensorFlow Mobile。

如果没有现存项目的话，使用 Android Studio，创建一个新的安卓项目。然后添加TensorFlow Mobile 依赖库到你的build.gradle 文件。

implementation ‘org.tensorflow:tensorflow-android:+’

Android studio 将提示你同步 gradle，点击 Sync Now 等待同步完成。

到这一步项目就创建完成了。

在你的移动 App 上执行推理

在用代码执行推理前，你需要将转化的模式 (squeezenet.pb) 添加到你的应用的资源文件夹里。

在 Android Studio 中右击你的项目，鼠标移到「添加文件夹」选项，然后选择「资源文件夹」。这时会在你的 app 目录下创建一个资源文件夹。然后，拷贝你的模式到此目录下。

点击 here 下载标签类，并拷贝文件到资源目录。

现在你的项目包含了分类图像的所有工具。

添加一个新的 Java 类到你的项目的主包中，取名为 ImageUtils , 然后将以下代码拷贝到其中。

package com.specpal.mobileai;
import android.content.res.AssetManager;
import android.graphics.Bitmap;
import android.graphics.Canvas;
import android.graphics.Matrix;
import android.os.Environment;
import java.io.File;
import java.io.FileOutputStream;
import java.io.InputStream;
import org.json.*;

/**
* Utility class for manipulating images.
**/
public class ImageUtils {
/**
* Returns a transformation matrix from one reference frame into another.
* Handles cropping (if maintaining aspect ratio is desired) and rotation.
*
* @param srcWidth Width of source frame.
* @param srcHeight Height of source frame.
* @param dstWidth Width of destination frame.
* @param dstHeight Height of destination frame.
* @param applyRotation Amount of rotation to apply from one frame to another.
* Must be a multiple of 90.
* @param maintainAspectRatio If true, will ensure that scaling in x and y remains constant,
* cropping the image if necessary.
* @return The transformation fulfilling the desired requirements.
*/
public static Matrix getTransformationMatrix(
final int srcWidth,
final int srcHeight,
final int dstWidth,
final int dstHeight,
final int applyRotation,
final boolean maintainAspectRatio) {
final Matrix matrix = new Matrix();

if (applyRotation != 0) {
// Translate so center of image is at origin.
matrix.postTranslate(-srcWidth / 2.0f, -srcHeight / 2.0f);

// Rotate around origin.
matrix.postRotate(applyRotation);
}

// Account for the already applied rotation, if any, and then determine how
// much scaling is needed for each axis.
final boolean transpose = (Math.abs(applyRotation) + 90) % 180 == 0;

final int inWidth = transpose ? srcHeight : srcWidth;
final int inHeight = transpose ? srcWidth : srcHeight;

// Apply scaling if necessary.
if (inWidth != dstWidth || inHeight != dstHeight) {
final float scaleFactorX = dstWidth / (float) inWidth;
final float scaleFactorY = dstHeight / (float) inHeight;

if (maintainAspectRatio) {
// Scale by minimum factor so that dst is filled completely while
// maintaining the aspect ratio. Some image may fall off the edge.
final float scaleFactor = Math.max(scaleFactorX, scaleFactorY);
matrix.postScale(scaleFactor, scaleFactor);
} else {
// Scale exactly to fill dst from src.
matrix.postScale(scaleFactorX, scaleFactorY);
}
}

if (applyRotation != 0) {
// Translate back from origin centered reference to destination frame.
matrix.postTranslate(dstWidth / 2.0f, dstHeight / 2.0f);
}

return matrix;
}

public static Bitmap processBitmap(Bitmap source,int size){

int image_height = source.getHeight();
int image_width = source.getWidth();

Bitmap croppedBitmap = Bitmap.createBitmap(size, size, Bitmap.Config.ARGB_8888);

Matrix frameToCropTransformations = getTransformationMatrix(image_width,image_height,size,size,0,false);
Matrix cropToFrameTransformations = new Matrix();
frameToCropTransformations.invert(cropToFrameTransformations);

final Canvas canvas = new Canvas(croppedBitmap);
canvas.drawBitmap(source, frameToCropTransformations, );

return croppedBitmap;

}

public static float[] normalizeBitmap(Bitmap source,int size,float mean,float std){

float[] output = new float[size * size * 3];

int[] intValues = new int[source.getHeight() * source.getWidth()];

source.getPixels(intValues, 0, source.getWidth(), 0, 0, source.getWidth(), source.getHeight());
for (int i = 0; i < intValues.length; ++i) {
final int val = intValues[i];
output[i * 3] = (((val >> 16) & 0xFF) - mean)/std;
output[i * 3 + 1] = (((val >> 8) & 0xFF) - mean)/std;
output[i * 3 + 2] = ((val & 0xFF) - mean)/std;
}

return output;

}

public static Object[] argmax(float[] array){

int best = -1;
float best_confidence = 0.0f;

for(int i = 0;i < array.length;i++){

float value = array[i];

if (value > best_confidence){

best_confidence = value;
best = i;
}
}

return new Object[]{best,best_confidence};

}

public static String getLabel( InputStream jsonStream,int index){
String label = "";
try {

byte[] jsonData = new byte[jsonStream.available()];
jsonStream.read(jsonData);
jsonStream.close();

String jsonString = new String(jsonData,"utf-8");

JSONObject object = new JSONObject(jsonString);

label = object.getString(String.valueOf(index));

}
catch (Exception e){

}
return label;
}
}

如果不理解上面的代码也没关系，这是一些未在核心 TensorFlow-Mobile 库中实现的功能。因此，在参考了一些官方样例后，我写了这些代码以方便后续工作。

在你的主活动中，创建一个 ImageView 和一个 TextView ，这将被用来显示图像和其预测结果。

在你的主活动中，你需要加载 TensorFlow-inference 库和初始化一些类变量。在你的 onCreate 方法前添加以下内容：

//Load the tensorflow inference library
static {
System.loadLibrary("tensorflow_inference");
}

//PATH TO OUR MODEL FILE AND NAMES OF THE INPUT AND OUTPUT NODES
private String MODEL_PATH = "file:///android_asset/squeezenet.pb";
private String INPUT_NAME = "input_1";
private String OUTPUT_NAME = "output_1";
private TensorFlowInferenceInterface tf;

//ARRAY TO HOLD THE PREDICTIONS AND FLOAT VALUES TO HOLD THE IMAGE DATA
float[] PREDICTIONS = new float[1000];
private float[] floatValues;
private int[] INPUT_SIZE = {224,224,3};

ImageView imageView;
TextView resultView;
Snackbar progressBar;

添加一个计算预测类的函数：

//FUNCTION TO COMPUTE THE MAXIMUM PREDICTION AND ITS CONFIDENCE
public Object[] argmax(float[] array){

int best = -1;
float best_confidence = 0.0f;

for(int i = 0;i < array.length;i++){

float value = array[i];

if (value > best_confidence){

best_confidence = value;
best = i;
}
}

return new Object[]{best,best_confidence};

}

添加函数来接收 Image Bitmap 并在其上执行推理：

public void predict(final Bitmap bitmap){

//Runs inference in background thread
new AsyncTask(){

@Override

protected Integer doInBackground(Integer ...params){

//Resize the image into 224 x 224
Bitmap resized_image = ImageUtils.processBitmap(bitmap,224);

//Normalize the pixels
floatValues = ImageUtils.normalizeBitmap(resized_image,224,127.5f,1.0f);

//Pass input into the tensorflow
tf.feed(INPUT_NAME,floatValues,1,224,224,3);

//compute predictions
tf.run(new String[]{OUTPUT_NAME});

//copy the output into the PREDICTIONS array
tf.fetch(OUTPUT_NAME,PREDICTIONS);

//Obtained highest prediction
Object[] results = argmax(PREDICTIONS);

int class_index = (Integer) results[0];
float confidence = (Float) results[1];

try{

final String conf = String.valueOf(confidence * 100).substring(0,5);

//Convert predicted class index into actual label name
final String label = ImageUtils.getLabel(getAssets().open("labels.json"),class_index);

//Display result on UI
runOnUiThread(new Runnable() {
@Override
public void run() {

progressBar.dismiss();
resultView.setText(label + " : " + conf + "%");

}
});

}

catch (Exception e){

}

return 0;
}

}.execute(0);

}

以上代码在后台线程中运行预测，并将预测的类和它的评估得分写到我们之前定义的 TextView 中。

注意在主 UI 线程运行推理时可能会挂起。记住一个原则：“永远在你的后台线程运行推理！”

本教程的重点是图像识别，为此我在资源文件夹中添加了一只小鸟的图像。在标准应用程序中，你要用代码从文件系统加载图像。

添加任何你想做预测的图像到资源文件夹中。为了方便的运行算法，在下列的代码中，我们在一个按钮上添加了一个点击监听。该监听可以加载该图像并调用预测功能。

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

Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
setSupportActionBar(toolbar);

//initialize tensorflow with the AssetManager and the Model
tf = new TensorFlowInferenceInterface(getAssets(),MODEL_PATH);

imageView = (ImageView) findViewById(R.id.imageview);
resultView = (TextView) findViewById(R.id.results);

progressBar = Snackbar.make(imageView,"PROCESSING IMAGE",Snackbar.LENGTH_INDEFINITE);

final FloatingActionButton predict = (FloatingActionButton) findViewById(R.id.predict);
predict.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {

try{

//READ THE IMAGE FROM ASSETS FOLDER
InputStream imageStream = getAssets().open("testimage.jpg");

Bitmap bitmap = BitmapFactory.decodeStream(imageStream);

imageView.setImageBitmap(bitmap);

progressBar.show();

predict(bitmap);
}
catch (Exception e){

}

}
});
}

很好！所有步骤都已完成！双击检验一下，如果都没有问题。点击「Bulid APK.」按钮

APK很快就创建完成了，之后在设备上安装并运行App.

结果如下图所示：

为了得到更新奇的体验，你的 App 应当从安卓文件系统加载图像或用摄像头抓取图像，而不是从资源文件夹加载。

总结

移动端的深度学习框架将最终转变我们开发和使用 app 的方式。使用上述代码，你能轻松导出你训练的 PyTorch 和 Keras 模型到 TensorFlow。运用 TensorFlow Mobile 和这篇文章中介绍的步骤，你可以将卓越的 AI 功能完美的植入到你的移动端应用中。

安卓项目的完整代码和模型转换工具在我的 GitHub 上可以找到：

https://github.com/johnolafenwa/Pytorch-Keras-ToAndroid

中国移动业务支撑系统简介（BOSS、BASS、BOMC、4A及VGOP）_李晓杰的博客

Sat, 14 Jul 2018 21:22:34 CST

文章目录

业务支撑系统（Business Support Systems，简称BSS）主要应用于通信行业，通过该系统对用户执行相应业务操作。它采用省中心/全国中心两级系统架构，两级系统相辅相成，共同构建全网服务/全网运营的运营支撑能力。

省中心将侧重于省内业务的运营，在满足个性化、本地化的业务需求的基础上，提供标准化的接口以满足全网运营的要求，通过业务支撑系统提供全网共享、一致的业务和服务能力，实现面向客户的全业务支撑融合，包括全网业务和本地业务的融合、自有产品和合作伙伴产品的融合等。全国中心将成为全网运营的核心和枢纽，提供全网运营的核心能力，并将重点建立对全网运营的管理与监控功能。

大的业务支撑系统可分为多种业务，如BOSS、BASS、BOMC、4A及VGOP等。

移动BOSS系统

BOSS是业务运营支撑系统（Business Operation Support System）的简称，它包含客户管理（CBOSS）、产品管理（PBOSS）、资源管理、客户服务、渠道管理、计费、账务、结算、合作伙伴管理等多方面的功能。它对各种业务功能进行集中、统一的规划和整合，是一体化得、信息资源充分共享的支撑系统。

BOSS系统实现对分期账单、语音及GPRS欠费风险控制、欠费提醒等计费业务的支撑，旨在构建了一个支持多业务、离线/在线计费统一的融合计费系统，根据客户对业务的需求以及业务特点，提升在线计费能力。通过对融合计费、账务处理、账务管理、综合结算和统计分析等功能的改造，实现对分散账期业务模式的支撑；支撑新账单、详单规范，实现账单、详单在各渠道的服务及用户体验一致；加强集团客户欠费管理能力，建立精细化的欠费管理视图，强化分级信用控制，打通与各集团业务平台的停开机接口；通过两级系统的配合，实现集团客户产品一点支付，并完善集团成员代付功能。

有具体业务中我们经常见NGBOSS类似字样，其全称为Next Generation Business Operation Support System，NG即表示“下一代”。NGBOSS系统与BOSS系统略有不同，NGBOSS和BOSS建设思路完全不一样，BOSS先建省级系统，然后再逐渐完善和补充，是打补丁方式建设，虽然BOSS很大，但是周边的系统不小，外挂系统也不小，是逐渐整合的系统。NGBOSS是自顶向下重构业务支撑网，这个不仅包括BOSS、CRM客服、包括网管，甚至包括DSMP。

目前的BOSS系统是一个大而全、完全紧耦合的系统，可以说是牵一发而动全身，风险非常大，所以NGBOSS从业务上主要关注：(1)将CRM从BOSS系统中分离出来，解决系统藕合问题，降低BOSS系统整体风险;(2)在CRM中彻底解决管理流程的问题;(3)解决业务服务重用的问题。

中国移动BOSS系统采用“两级三层”的结构（两级系统、三层结构）。

BOSS的两级

一级业务支撑系统（集团）：具有管理、实体和枢纽功能，为有限公司进行全网业务管理和业务运营提供支撑和保障，实现全网信息的交换和管理。

二级业务支撑系统（省级）：具有管理和实体功能，为省公司进行省内业务管理和业务运营提供支撑和保障。

一级业务支撑系统与二级业务支撑系统共同支撑业务的运营与协作。

BOSS的三层

接入层：是BOSS系统与外部进行数据交换的平台，由接入逻辑构成。

业务层：是BOSS系统业务处理的逻辑平台，它通过对数据访问子层的调用访问业务数据，实现不同的功能模块，满足不同的业务需求。

数据层：是BOSS系统对业务数据进行统一组织、集中管理的平台，它通过数据访问子层为业务层提供规范、高效的数据服务，实现业务数据的充分共享，是整个BOSS系统的基础。

BOSS的核心“三户模型”

客户：客户是与使用移动服务有关的个人或实体，由用户和潜在用户组成。

用户：运行商所提供服务的实际消费实体，跟服务提供者有商业上的契约关系，可以理解为个或设备。

账户：是客户使用服务的一个付费实体，便于用户一张账单可以缴纳定义的多种服务的费用。

账目：是组成账单的基本单位，比如语音通话费就是一个账目，长途漫游费是一个账目，基本月租也是一个账目。

规制关系：

一个客户可以是运营商的用户，也可以是其潜在的用户，每一个客户在BOSS系统中有唯一的标识，同时客户与客户之间存在从属关系。

一个客户可以包含一个或多个用户，一个用户对应于一项主体服务，订购多个主体服务则为多个用户。

一个帐户可以为多个用户对应的帐目付费，一个用户对应的所有帐目可以由多个帐户付费。

BOSS系统的目标

BOSS系统要实现“三个特征、两个能力、一个综合”。其中，“三个特征”以提供“个性化、社会化、信息化”服务为重要特征；“两个能力”指具有“满足未来业务发展需要”和“满足实时处理”；“一个综合”指提供一个综合性的业务处理平台。

移动BASS系统

BASS是经营分析系统（Business Analysis Support System）的简称。

BASS系统应用框架可分为四大区域和九大功能：

BASS系统四大区域

BASS系统四大区域包括：客户管理域、市场营销与产品管理域、供应商/合作伙伴管理域、资源管理域。

客户管理域主要是以客户为分析目标，分析客户的发展、客户的业务及收益等信息，为提升客户服务水平，增强客户维系能力，提升客户价值，提供决策分析依据的专业功能域。

市场营销与产品管理域是面向市场运营、营销与服务、产品管理，服务于企业市场经营和服务部门的专业功能域。

供应商/ 合作伙伴管理域是建立和完善中国移动产业链管理的专业功能域。它有效管理、评价供应商/合作伙伴，协助加强供应商/合作伙伴合作能力，丰富合作方式，巩固产业链，为逐步建立牢固的、多赢的产业链提供专门服务。

资源管理域是支撑市场运营、营销管理、产品管理等市场经营活动资源，及部分资源调度功能的专业功能域。

BASS系统九大功能

功能一：客户发展及总体收益分析

是对客户发展、业务收益、市场竞争等方面提供综合性分析，向各级管理层提供全省范围内企业经营、业务发展、市场竞争等信息，为移动公司制定企业经营规划、业务发展策略提供支持，进一步提高移动公司业务管理水平和市场竞争力。

功能二：语言业务

对基础语音业务提供专项分析，通过对客户各种呼叫行为进行分析，为语音产品的开发、市场推广计划和客户挽留计划的制定提供依据，并提供国际业务的专项分析。

功能三：增值业务

增值业务是移动公司的重点发展业务，也是企业发展的重要驱动力之一。为适应业务发展新形势，本规范针对增值业务提供客户发展、业务分析、业务营销分析、营销渠道分析、门户运营支撑、数据业务排行分析以及SP监控与管理等应用，以满足增值业务新产品的快速高效支撑、深度运营和精确营销需求，从而实现产品、管理及商务模式的创新和新业务的运营管理，从传统的技术驱动向市场驱动转变。

功能四：集团客户业务

集团客户是实现企业利润和可持续发展的重要保障之一。通过对集团客户的分析，加强集团客户营销和服务工作，发展集团客户，提高集团客户的忠诚度。集团客户分析可从集团客户稳定性、集团客户产品、集团客户行业应用、VPMN集团、集团客户异动、集团成员构成等方面为移动公司集团客户的发展和相关政策的制定提供有力的分析支持，以解决集团客户业务发展和运营管理的热点问题（如：离网预警、精细化营销和双跨客户信息支撑等），深化集团客户业务的管理分析功能，加强对合作伙伴的精细化管理，提升集团客户业务运营管理的信息化水平。

功能五：客户服务与管理

随着移动通信业务和市场竞争不断发展，中国移动的客户规模和客户质量进一步地提升，对客户服务水平提出了更高要求。客户服务与管理针对客户服务的服务质量、服务内容、服务效率和服务流程提供各项分析应用，并提供外呼管理支撑，为进一步提高客户服务水平，提升客户满意度和忠诚度提供支持。

功能六：资源管理

资源包括各类渠道资源和销售资源。通过实体渠道运营分析、电子渠道分析、新业务体验营销、终端管理、卡号资源管理以及资费营销案等分析应用，为构建高效的渠道运营管理分析体系、提升渠道精准化营销和精细化管理能力、提高资源的利用率和管理水平提供支持。

功能七：网络分析

通过网络系统获取客户位置信息和行为数据，加强对网络承载特征和客户行为特征的分析，为优化网络资源、支持精细化营销等工作提供支持。

功能八：财务分析

财务分析是企业运营管理的重要组成部分，其内容主要包括公司内部结算、与其他电信运营商结算、与银行结算、与代销商结算的分析，为掌握各项结算费用信息提供支持。

功能九：基本功能

基础功能是为经营分析系统前端各项应用提供分析数据和业务处理逻辑的模块，可划分为以下四大类：基础信息库、基础应用、业务应用知识库、其他部分。

移动BOMC系统

BOMC（Business Operation Management Center）是中国移动业务支撑网运营管理系统的简称。BOMC定位于为中国移动业务支撑网的运营管理水平提供有效支撑，不但实现在业务支撑网生产运行过程中对平台部件和应用软件等进行“集中监控、集中维护、集中管理”，并且在此基础上进行业务服务管理，同时对BOSS（含客服）系统、经分系统以及BOMC系统进行4A系统改造和统一平台建设。BOMC实现的系统功能有：

监控管理中心：集中提供了平台应用监控、告警管理、预警管理、故障诊断管理、操作控制等监控功能。

运营分析中心：监控分析、告警分析、性能分析管理、系统运行日报、周报、月报管理、业务运营分析管理等。

资源管理：对存储在配置管理数据库（CMDB）的资源模型管理及资源数据管理功能。本期BOMC系统需要实现统一的CMDB和统一的资源管理平台，作为支撑四大管理中心的基础资源信息平台。

统一运营门户：作为BOMC的工作门户，为运营管理人员、业务管理人员、维护人员、监控人员、外部用户等内外部用户提供的统一工作平台。

业务管理中心：以提升业务服务的可用性、服务水平、健康度为目标，通过业务建模构建业务服务支撑网络，与底层IT平台部件和系统应用关联起来，提供一个以业务为中心的IT运营管理平台。

运维服务中心：充分考虑流程角色与实际组织的映射、流程环节与实际工作的对应、ITIL术语与各省习惯用语的翻译，在保证流程实用性的前提下借鉴ITIL3.0、ISO20000理念，保证规范的先进性。另外，服务管理平台还应该满足高可靠性、开放性、可扩展性和性能、安全方面的要求。

指标管理：目前在日常运营工作中，根据不同管理目标的要求，存在着各类指标，包括IT基础设施的KPI指标、应用的KPI指标、KQI、BAM指标、CAPES指标等多类指标，各类指标存在互相重复和定义不唯一的情况，本期规范将对以上指标进行梳理，合理地合并部分指标，统一定义，从而简化和校正现有的指标体系。

采集平台：是运营管理系统中各种数据采集的重要入口。需要支持各种数据采集功能实现和丰富的采集协议。

控制平台：控制的范围根据安全管理和当前的管理需求主要包括部分平台类设备和部分应用类对象。

系统自管理：业务支撑网运营管理系统自身管理是指对整个业务支撑网运营管理系统自身进行管理。包括自告警、自身性能监控、系统管理。

4A系统

4A系统是统一安全管理平台解决方案，指认证Authentication、账号Account、授权Authorization、审计Audit，中文名称为统一安全管理平台解决方案。即将身份认证、授权、审计和账号（即不可否认性及数据完整性）定义为网络安全的四大组成部分，从而确立了身份认证在整个网络安全系统中的地位与作用。

4A平台的管理功能包括：集中认证管理、集中账号管理、集中权限管理和集中审计管理，具体如下：

集中认证(authentication) 管理：可以根据用户应用的实际需要，为用户提供不同强度的认证方式，既可以保持原有的静态口令方式，又可以提供具有双因子认证方式的高强度认证（一次性口令、数字证书、动态口令），而且还能够集成现有其它如生物特征等新型的认证方式。不仅可以实现用户认证的统一管理，并且能够为用户提供统一的认证门户，实现企业信息资源访问的单点登录。

集中帐号(account) 管理：为用户提供统一集中的帐号管理，支持管理的资源包括主流的操作系统、网络设备和应用系统；不仅能够实现被管理资源帐号的创建、删除及同步等帐号管理生命周期所包含的基本功能，而且也可以通过平台进行帐号密码策略，密码强度、生存周期的设定。

集中权限(authorization) 管理：可以对用户的资源访问权限进行集中控制。它既可以实现对B/S、C/S应用系统资源的访问权限控制，也可以实现对数据库、主机及网络设备的操作的权限控制，资源控制类型既包括B/S的URL、C/S的功能模块，也包括数据库的数据、记录及主机、网络设备的操作命令、IP地址及端口。

集中审计(audit) 管理：将用户所有的操作日志集中记录管理和分析，不仅可以对用户行为进行监控，并且可以通过集中的审计数据进行数据挖掘，以便于事后的安全事故责任的认定。

VGOP系统

VGOP（Value-added Service General Operation Platform）是中国移动的增值业务综合运营平台的简称，它从流程、功能、数据、接口四个方面全方位推动数据业务建设和运营从孤立走向整合，实现业务系统的规范化和水平化，加强数据业务以客户为中心的竞争力，沉淀业务综合运营的“软实力”。初期实现三大核心功能：业务能力互通和调度；客户行为诊断和分析；业务质量持续监控和优化。

中国移动的增值业务综合运营平台(VGOP)由一级VGOP、省级(或称为二级)VGOP两级组成。两级VGOP互联，相互协作与配合，共同支撑增值业务的运营、管理和调度:

一级VGOP为有限公司进行全网增值业务营销、管理和运营提供支撑和保障，包括调度功能、运营功能和管理功能，同时是一类业务的管理者，调度者和运营者；

省级VGOP是二、三类自有业务的运营、管理中心，为省内增值业务管理、运营和调度提供支撑和保障。它面向本省客户提供包括一类自有业务在内的完整的运营支撑功能，包括调度功能、运营功能和管理功能。

两级VGOP都主要包括能力管理、能力控制与调度、业务开通管理、数据管理、客户信息分析、业务监控、业务稽核、业务优化、营销支撑、基础管理、管理门户等功能模块。

击败阿里、腾讯中标中国移动世界杯专项公有云采购华为让人意外在哪？

Mon, 11 Jun 2018 23:31:00 CST

近日华为中标中国移动“2018年咪咕视讯公有云采购项目”引起业界关注，作为后来者的华为云能够击败阿里云和腾讯云着实令人意外，阿里云和腾讯云的市场份额排在国内前二，尤其是阿里云，一家就占据了国内IaaS市场近一半的市场份额，如此理解，华为在公有云招标上击败阿里云和腾讯云这件事吸引如此多关注也就说得通了。

那么，华为在这次招标的表现和以往有何不同？

雷锋网了解到，本次“2018年咪咕视讯公有云”租赁服务是为了满足世界杯比赛期间的视频流量需求，租赁内容包括云主机、公网带宽和网络存储三项，预计租赁时间为6月14日至8月13日，最终拟采供应商为一家。

具体租赁内容为：

1、云主机：1000台/月，其中：

（1）配置为8核CPU，32G内存，160G SSD云硬盘的云主机911台；

（2）配置为8核CPU，64G内存，100G SSD云硬盘的云主机44台；

（3）配置为8核CPU，32G内存，4TB SSD云硬盘的云主机45台。

2、公网带宽：50G/月；

3、网络存储：50TB/月；

从云主机采购规格上看，第一类常规规格的采购数量最多，第二类注重大内存。第三类注重大存储，都是公有云厂商的基础产品，从技术角度上没有特别显著的差异。

其实除了对外公开比选的采购，咪咕视讯世界杯专有云项目还有一个“移动网内”采购项目，采购规模还有所上升，云主机需求达到了2000台，对应到三类云主机规模分别翻倍，公网带宽和网络存储也分别提高了采购规模。

中国移动公有云业务由中国移动政企分公司运作，前些日子还顺着阿里云、腾讯云的降价潮也进行了降价，显示出其不是“玩票”性质，中国移动集团和各子公司本身就是中国移动政企分公司的客户，移动云自有客户优势。

既然云主机等产品层面无甚区别，那么价格就是决定性因素了。雷锋网获悉，在招标采购的公开比选中，价格绝对要占据最主要因素，在各项硬性资质都满足的情况下，出价最低的厂商基本能够最终中标，如果选了非最低价中标，采购方可能要面临审计的“麻烦”，最低价中标基本成为行业“潜规则”。

IDC圈报道指出，与订单本身相比，各云厂商看中的不是钱，而是此次招标带来的影响力。这可能促使云厂商进一步降低成本，而在阿里云、腾讯云和华为三家中，最需要树立范本的要数华为了。

华为云作为公有云市场的后来者，雷锋网了解到，2017年华为云实现了用户数增长3倍，收入增长7倍，ARPU值翻倍的成绩，华为私有云+政务云+公有云的外部客户服务的销售收入达到了5亿美金。

但是这建立在华为此前公有云规模不大的基础之上，与阿里云、腾讯云相比，华为做公有云这种类互联网服务，需要学习新的销售方式、商务方式和服务方式等，在华为之前，阿里云和腾讯云已经趟过一遍坑了。

另外华为中标中国移动公有云还有一个先天优势，就是华为作为电信设备商和中国移动的良好关系，在公有云业务之前，华为凭借卖“盒子”成为全球最大电信设备商，公有云对华为相当于另一种模式卖“盒子”。

当中国移动这类政企客户逐渐成为公有云厂商眼中的高价值目标用户群，阿里云、腾讯云和华为云以及其他公有云厂商在保护地盘和抢夺地盘的争斗中更加卖力，市场掀起了另一股竞价和竞争风潮。

CAS统一认证中心，针对移动客户端的认证过程设计（APP视角）

Mon, 11 Jun 2018 19:49:09 CST

CAS统一认证中心，针对移动客户端的认证过程设计（APP视角）

业务场景
- 统一认证中心CAS，用员工工号密码登录。
- 有个通讯录server系统
- 通讯录APP接入两个服务，即登录接CAS，业务接通讯录server
- 通讯录APP在用户登录的情况下允许查询其他员工信息
简单例子
- 通讯录server系统有两个接口，用户信息接口，员工信息查询接口

设计过程（未认证）

APP启动调用通讯录server的接口getUserInfo，用来获取当前用户的基本信息。
通讯录server后台发现没有登录，返回报文

     {     "code": "0030",     "errorMessage": "未登录",     "result": null }

APP解析返回报文，code==0030，即跳转native登录页面
登录页面调用cas提供的登录接口

     https://cas.domain.com/login.do?userName=66647&password=12345&jsonView=true&rememberMe=true  userName:工号 password:密码 jsonView:是否返回json，因为大多情况下，CAS被设计成支持web鉴权 rememberMe:是否开启记住会话

如果登陆成功，CAS会返回一些cookies

     <NSHTTPCookie   version:0   name:TGC   value:TGTCF84007422EAD5E7CED12D9658AF05D1716F52B9   expiresDate:'(null)'   created:'2018-05-28 12:23:04 +0000'   sessionOnly:TRUE   domain:cas.domain.com   partition:none   path:/ids/   isSecure:FALSE   isHTTPOnly: YES  path:"/ids/" isSecure:FALSE isHTTPOnly: YES>

如果开启了rememberMe，则会多一条cookie

     <NSHTTPCookie   version:0   name:cas_r_me   value:MTcxMjAwNTFfQlJPV1NFUl8xNTI3NTA2MTQyMDkyXzE1Mjc1MTAxODQ5NzBfMl9iNjgzNTM1N2I5%0D%0AZTZlZGE0NjZjOWI1ODFkMDVmMDAxYw%3D%3D%0D%0A   expiresDate:'2018-06-07 11:23:04 +0000'   created:'2018-05-28 12:23:04 +0000'   sessionOnly:FALSE   domain:cas.domain.com   partition:none   path:/   isSecure:FALSE   isHTTPOnly: YES  path:"/" isSecure:FALSE isHTTPOnly: YES>

APP重新调用server的getUserInfo接口，如果有机制能自动重掉当然更好，类似于web的302
后台正常返回数据
app进入首页

防止恶意破解(认证过程)

调用CAS登陆接口失败多次，服务器一般会锁定当前IP或者其他策略，手段就是让用户人工介入输入动态图形验证码。

CAS会告知，请求需要验证码

       {     "needVerifyCode": true,     "errorCode": "badVerifyCode",     "tgtTimeoutOrKickoff": false,     "res_code": 1,     "res_message": "errorCode" }

获取验证码，根据”errorCode”: “badVerifyCode”,

       https://passport.csdn.net/ajax/verifyhandler.ashx?uuid=xxxxxx

登陆过程改造

       https://cas.domain.com/login.do?userName=66647&password=12345&jsonView=true&rememberMe=true&verifyCode=8562&uuid=9DLCN-DL8CL3  userName:工号 password:密码 jsonView:是否返回json，因为大多情况下，CAS被设计成支持web鉴权 rememberMe:是否开启记住会话 verifyCode:验证码，在某些情况下，服务器认为用户恶意尝试登陆，会有保护策略。 uuid:用来确定验证码的uuid 注：如果后台服务端强大，对验证码的管理不是通过uuid，而是通过会话识别对应，那么登录接口就无需uuid，生成图形验证码的时候也无需uuid

设计过程(已认证)
- APP启动调用server接口getUserInfo
- 获取得到用户信息
- 进入首页
持久化会话
- 保存cookie
  
  保存name为cas_r_me的cookie，如何保存cookie，具体方法不累赘。
- logout需要清空保存的cookie
  
  删除本地缓存的所有cookie，具体方法不累赘。
- 更新cookie
  
  在每一次APP启动，获取用户信息接口之后，更新保存的cookie，因为cookie有expiresDate，如果一直用第一次登录的那个，就算每天都登录，迟早会失效，这是我们不希望看到的。
- 使用cookie
  
  每次打开app，加载本地保存的cookie到会话管理器，并激活生效。

Oracle 移动数据文件的操作方法 - CSDN博客

Sat, 14 Apr 2018 16:26:19 CST

将表空间和数据文件从一个位置移动到另一个位置的操作方法

一． OFFLINE

OFFLINE 分为ALTER DATABASE 与 ALTER TABLESPACE OFFLINE，

他们的区别参看blog： http://www.cndba.cn/Dave/article/1226

按数据文件来：

1.先将相应的数据文件 offline

ALTER DATABASE DATAFILE 'D:/ORACLE/ORADATA/DBA/TEST01.DBF' OFFLINE;
2.把数据文件 copy 到新位置
3. alter database rename file 'D:/ORACLE/ORADATA/DBA/TEST01.DBF' to 'D:/TEST01.DBF';

4. 介质恢复(offline 数据文件必须要介质恢复)

recover datafile 'D:/TEST01.DBF'
5. 将相应的数据文件 online

SQL>ALTER DATABASE DATAFILE 'D:/TEST01.DBF' ONLINE;

按表空间来：

1.先将相应的表空间 offline

SQL>alter tablespace test offline;

2.把数据文件 copy 到新位置
3. alter tablespace TEST rename datafile 'D:/TEST01.DBF' to 'D:/ORACLE/ORADATA/DBA/TEST01.DBF'

4. 将表空间 online

SQL>alter tablespace test online;

二． Shutdown 数据库

1. 关闭数据库

C:>set ORACLE_SID=DBA

C:>sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on 星期日 11月 29 11:14:02 2009

SQL> conn sys/admin as sysdba

已连接。

SQL> shutdown immediate

数据库已经关闭。

已经卸载数据库。

ORACLE 例程已经关闭。

SQL>

2. 把数据文件 copy 到新位置

3. rename datafile

SQL> startup mount

ORACLE 例程已经启动。

Total System Global Area 289406976 bytes

Fixed Size 1248576 bytes

Variable Size 71303872 bytes

Database Buffers 209715200 bytes

Redo Buffers 7139328 bytes

数据库装载完毕。

SQL> alter database rename file 'D:/ORACLE/ORADATA/DBA/TEST01.DBF' to 'D:/TEST01

.DBF';

数据库已更改。

SQL> alter database open;

数据库已更改。

SQL> select file#,name,status from v$datafile;

FILE# NAME STATUS

-------- ------------------------------------------------------- ---------------

1 D:/ORACLE/ORADATA/DBA/SYSTEM01 SYSTEM

2 D:/ORACLE/ORADATA/DBA/UNDOTBS0 ONLINE

3 D:/ORACLE/ORADATA/DBA/SYSAUX01 ONLINE

4 D:/ORACLE/ORADATA/DBA/USERS01. ONLINE

5 D:/TEST01.DBF ONLINE

腾讯开源：微信和移动开发的 10 大项目

Thu, 29 Mar 2018 20:26:39 CST

腾讯开源了许多非常有价值的项目，下面我们一起来看看腾讯10大开源项目有哪些？

1、Android 热修复框架 Tinker

Tinker 是微信官方的 Android 热补丁解决方案，它支持动态下发代码、So 库以及资源，让应用能够在不需要重新安装的情况下实现更新。当然，你也可以使用 Tinker 来更新你的插件。

它主要包括以下几个部分：

● gradle编译插件: tinker-patch-gradle-plugin

● 核心sdk库: tinker-android-lib

● 非gradle编译用户的命令行版本: tinker-patch-cli.jar（详情：https://github.com/Tencent/tinker）

2、微信客户端跨平台组件 Mars

Mars 是微信官方的终端基础组件，目前已接入微信 Android、iOS、Mac、Windows、WP 等客户端。主要包括以下几个部分：

● comm：可以独立使用的公共库，包括 socket，线程，消息队列，协程等;

● Xlog软件：日志组件，可靠性高，高性能

● SDT：网络诊断组件

● STN：信令分发网络模块，也是Mars最主要的部分。图。（详情：https://github.com/Tencent/mars）

3、小程序组件化开发框架 wepy

WePY 是一款让小程序支持组件化开发的框架，通过预编译的手段让开发者可以选择自己喜欢的开发风格去开发小程序。框架的细节优化，Promise，Async Functions 的引入都是为了能让开发小程序项目变得更加简单，高效。

同时 WePY 也是一款成长中的框架，大量吸收借鉴了一些优化前端工具以及框架的设计理念和思想。如果 WePY 有不足地方，或者你有更好的想法，欢迎提交 ISSUE 或者 PR。

特性：

● 类Vue开发风格

● 支持自定义组件开发

● 支持引入NPM包

● 支持Promise

● 支持ES2015+特性，如Async Functions

● 支持多种编译器，Less/Sass/Stylus、Babel/Typescript、Pug

● 支持多种插件处理，文件压缩，图片压缩，内容替换等

● 支持 Sourcemap，ESLint等

● 小程序细节优化，如请求列队，事件优化等（详情：https://github.com/Tencent/wepy）

4、轻量级高性能的 Hybrid 框架 VasSonic

使用前

使用后

VasSonic 是腾讯QQ会员 VAS团队研发的一个轻量级的高性能的 Hybrid框架，专注于提升页面首屏加载速度，完美支持静态直出页面和动态直出页面，兼容离线包等方案。

接入 VasSonic 后首次打开可以在初始化 APP 的时候并行请求页面资源，并且具备边加载边渲染的能力。非首次打开时，APP 可以快速加载上次打开动态缓存在本地的页面资源，然后动态刷新页面。腾讯手机QQ通过VasSonic 框架使得页面首屏耗时平均低于1S以下。（源码：https://github.com/Tencent/VasSonic 文档：https://github.com/Tencent/VasSonic/wiki）

5、微信团队前端开发工具 WeFlow

这是一个高效、强大、跨平台（macOS & Win）的前端工具，核心基于 tmt-workflow 工作流.（详情：https://github.com/weixin/WeFlow）

6、移动数据库框架 WCDB

WCDB 是一个高效、完整、易用的移动数据库框架，基于 SQLCipher，支持 iOS, macOS 和 Android。

基本特性：

● 易用，WCDB支持一句代码即可将数据取出并组合为object。

● 高效，WCDB通过框架层和sqlcipher源码优化，使其更高效的表现。

● 完整，WCDB覆盖了数据库相关各种场景的所需功能。（详情：https://github.com/Tencent/wcdb）

7、基于参数服务器理念的机器学习框架 Angel

Angel 是一个基于参数服务器（Parameter Server）理念开发的高性能分布式机器学习平台，它基于腾讯内部的海量数据进行了反复的调优，并具有广泛的适用性和稳定性，模型维度越高，优势越明显。 Angel 由腾讯和北京大学联合开发，兼顾了工业界的高可用性和学术界的创新性。

Angel 基于 Java 和 Scala 开发，能在社区的 Yarn 上直接调度运行，并基于 PS Service，支持 Spark on Angel，未来将会支持图计算和深度学习框架集成。（详情：https://github.com/Tencent/angel）

8、自动内存泄漏检测工具 MLeaksFinder

MLeaksFinder 是腾讯开源的 iOS 平台的自动内存泄漏检测工具，引进 MLeaksFinder 后，就可以在日常的开发，调试业务逻辑的过程中自动地发现并警告内存泄漏。具有如下特性：

● 自动检测内存泄漏和释放不及时的场景

● 构建泄漏对象相对于 ViewContrller 的引用链以帮助开发者定位问题

● 不侵入业务逻辑，引入即生效，无需修改任何代码或引入头文件（详情：https://github.com/Tencent/MLeaksFinder）

9、UI 库 WeUI

WeUI 是由微信官方设计团队专为微信移动 Web 应用设计的 UI 库。WeUI 是一套同微信原生视觉体验一致的基础样式库，为微信 Web 开发量身设计，可以令用户的使用感知更加统一。包含button、cell、dialog、toast、article、icon等各式元素。（详情：https://github.com/weixin/WeUI）

10、分布式后台服务引擎 MSEC

毫秒服务引擎（MSEC）由腾讯 QQ 团队开源。它是一个后端 DEV＆OPS 引擎，包括RPC，名称查找，负载平衡，监控，发布和容量管理。毫秒服务引擎特性：

● 模块间访问采用 RPC 的方式，开发者不用关注网络与报文格式，像写单机程序一样开发分布式服务。

● 负载自动均衡与容错，对于单机故障、局部网络波动等状况自动应对，服务高可用性。

● 支持 C/C++/java/PHP 语言，如果选择 C/C++ 语言，支持协程，兼具开发和运行效率。

● Web 化的管理界面

● 简易部署，需要复杂部署的服务器都采用 docker 镜像的方式安装

● 相比使用其他开源组件拼凑起来的解决方案，毫秒服务引擎更加的体系化，对团队的规范更加到位

快讯：Google 正式推出移动优先索引（ Mobile-First Indexing）

Tue, 27 Mar 2018 20:30:00 CST

通过一年半时间的测试，Google 今天在 Webmaster Central Blog 和 Twitter 宣布，正式推出 Mobile-First Indexing。
该策略将对 Google SEO 产生影响非常大，本人第一时间整理资料，整理了相关的几个要点。

为什么要推出 Mobile-First Indexing

众所周知，Google 的抓取、索引和排名系统都是基于 PC 端网页建立，移动端的排名和权重主要继承自 PC 端。
那在 WAP 流量远超 PC 的今天，这种机制就会出现各种各样的问题。

很多网站的 PC 端页面展示所有内容，而WAP 只展示部分内容。
- 举个极端的例子，移动端用户通过搜索达到某页面，发现并没有对应的内容（这个内容只在 PC 呈现，在 WAP 不呈现）
很多网站重点优化 PC 站，而 WAP 站功能缺失体验严重落后，移动搜索用户体验极差
- 我目前的项目就有这个问题
因为移动端用户较多，部分网站重点建设 WAP 站，而忽视了 PC 站的建设，导致无法获取到该有的排名和流量
- 这种情况比较少

根据目前流量趋势，Google 急需调整策略，保证 PC 和 WAP 端的搜索体验。

什么是 Mobile-First Indexing

Mobile-First Indexing，就是 Google 会使用移动端页面的内容来建立索引和排名，以提升移动搜索体验。简单来说，

之前，Google 是拿 PC 站的内容来建立索引，判断链接关系，决定最终排名
现在，Google 开始拿 WAP 的内容

有几点要注意的：

Google 只有一套索引，并不存在单独的一套 Mobile-First Index，所以，Mobile-First Indexing 只是替换掉之前的 PC 站索引。
Mobile-First Indexing 的比例会逐步增加，而不是一下子全切

针对 Mobile-First Indexing 我需要做什么

Google 会在 Search Console 中分批通知站长，进行 Mobile-First Indexing 的改造。

要针对 Mobile-First Indexing 做改造

以下是目前几种网站类型以及对应的改造方式。

单独的网址和动态提供内容的网站具体做什么

WAP 页面的内容，需要跟 PC 页面保持一致。
结构化数据在 PC 和 WAP 端都要添加。
Meta 数据在 PC 和 WAP 端都要添加。

对于单独网址的网站，还有几点建议：

WAP 和 PC 站都在 Search Console 进行验证
确保 PC 和 WAP 页面有 hreflang 标签，并且指向对应版本
确保 WAP 站服务器能承受足够的抓取压力
确认 robots.txt 规则是否正确
确保 PC 和 WAP 页的 rel=canonical 和 rel=alternate 无误

我在移动端还可以做什么

虽然 Google 没有承认 Mobile-First Indexing 会提升网页排名，不过有 2 个因素 Google 已经承认是对排名有明显帮助。

移动友好性
- 可以使用 Google 的移动友好性工具测试。
网页加载速度
- 可以使用 Google 的 PageSpeed Insights 工具测试。

其他问题

问题1：Mobile-First Indexing 就是基于 WAP 站来决定排名？

答：
Mobile-First Indexing 主要是优先从移动页面获取内容和链接，以此建立索引。
Mobile-First Indexing 更偏向页面中的内容和链接，不过多多少少也会对排名产生影响，但不是 Mobile-First Indexing 的最重要的部分。

问题2：Mobile-First Indexing 会有排名上的优势吗？

答：
采用 Mobile-First Indexing 的页面，并没有在排名上有优势。
至少目前 Google 的文档中是这么说，具体表现还需要线上验证。

IT瘾移动推荐

从Flutter聊聊跨平台移动研发方案

Flutter的特别之处

Flutter的整体架构

Flutter的跨端优势

跨平台方案的比较

NATIVE

REACT NATIVE

XAMARIN

NATIVE+小程序

不再钟情于移动端开发

手机的阴暗面

行业现状

职业发展

So What’s Your Plan?

中国主机托管TOP5：中电信、万国数据、世纪互联、中移动、中联通

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

Cordova

参考资料

Ionic

AppCan

Dcloud

学习路线：

APICloud

React Native

总结

Flutter 2 来了：专为 Web、移动与台式机环境构建

Flutter 为 Web 应用添助力

Flutter 2 登陆台式机、折叠式设备与嵌入式设备

不断发展的 Flutter 生态系统

Dart: Flutter 背后的独门绝技

Flutter 2：现已发布

对话中国移动：支撑数亿用户的基础设施如何实施云原生改造？ | 顶尖技术团队访谈

有赞零售移动 CI/CD 实践

一、背景

二、问题与挑战

三、自动化流程体系

3.1 流程与架构

3.1.1 流程

3.2 打包与分发

3.2.1 打包

3.2.2 分发

3.3 检查体系

3.3.1 编译检查

3.3.2 本地检查

3.4 Code Review

3.5 消息与闭环

3.5.1 方案一

3.5.2 方案二

四、思考与展望

传工信部调整网间结算标准：电联失意，移动摘“帽”

Vue 移动端框架

1. vonic

2. vux

3. Mint UI

4. Muse-UI

5. Vant

6. Cube-UI

7. vue-ydui

8. Mand-Mobile

9. v-charts

10. Vue Carbon

11. Quasar

12. Vue-recyclerview

13. Vue.js modal

14. Vue Baidu Map

15. Onsen UI

相关文章

移动端flex布局实战

兼容性

属性对照

容器的属性

项目的属性

采坑经验

实战

总结

相关资料

Google Glass 企业版第二代发布，支持 Android 移动设备管理

移动跨平台技术方案总结 - xiangzhihong8的专栏 - CSDN博客

React Native

方栗子发自凹非寺
量子位出品 | 公众号 QbitAI

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