blink

　　一，主流浏览器及内核 　　Chrome——Webkit/blink 　　IE ——Trident 　　Firfox ——Gecko 　　Safari—— Webkit 　　Opera—— presto 　　二，css权重 　　!importent ——Infinity(正无穷) 　　行间样式 ——1000 　　id ——100 　　class/属性/伪类 ——10 　　标签/为元素 ——1 　　通配符—— 0 　　css的优先级取决于权重，权重间的进制是256. 　　三，行级 块级 行级块 元素 　　行级元素：1内容决定元素大小 2无法通过css改变宽高(span em a strong……) 　　块级元素：1独占一行 2可以改变宽高 (p div ul li form address……) 　　行级块元素：内容决定大小 可以改变宽高 (img) 　　四，定位 　　绝对定位：absolute：脱离原来位置，以最近父级定位，如果没有以文档顶端定位 　　相对定位：relative：保留自己以前的位置，并且以自己以前位置定位 　　五，margin俩bug 　　1，margin-top塌陷：子div在父div中 子div margin-top无效，除非子div margin-top值大于父级的，而且此时还带动父级一起移动。 　　父级div上边框消失了一样，给父级加上一个上边框可以解决

以上均为个人汇总，如有不对欢迎指出！ 小程序个人看法 可能今天在很多人眼中，小程序已经成为别人印象中的app，功能齐全，且可以完成各种功能以及业务。但是个人从小程序的诞生使用至今，在我眼中他依然是个轻量级应用，虽逐步的壮大，一些功能还是有所限制，但是从功能上的角度却无法与app相媲美。以微信小程序为例，也许今天大小限制8M，页面栈已经是15层，大小可开发约50~70个页面，的确已经很好的支持业务的开发以及功能的扩张。但是在小程序开始之初，页面栈仅为5，包大小限制1M，很多业务的确无法扩展。小程序也因业务的扩展，逐步逐渐支持工程化，如当前支持npm包。但我们从小程序的产品整体设计上，还是不能忘记这个限制，无止境的叠加页面以及业务。 小程序的编译原理 简单的借助大神的思路，描述一下小程序的编译原理。 我们都知道，小程序页面由View（视图层）,App Service(逻辑层)组成。它们在两个线程中运行（我们传统的h5,是单线程运行）。他们之间是由系统的JSBridage（常用于原生与h5交互的工具，可自行百度）进行交互的。 视图层使用 WebView 渲染，iOS 中使用自带 WKWebView，在 Android 使用腾讯的 x5 内核（基于 Blink）运行。 逻辑层使用在 iOS 中使用自带的 JSCore 运行，在 Android 中使用腾讯的 x5 内核（基于 Blink

使用Blink SQL+UDAF实现差值聚合计算 介绍了如何使用Blink SQL+UDAF实现实时流上的差值聚合计算，后来在与@付典就业务需求和具体实现方式进行探讨时，付典提出通过 CEP 实现的思路和方法。 本文介绍通过CEP实现实时流上的差值聚合计算。 感谢@付典在实现过程中的指导。笔者水平有限，若有纰漏，请批评指出。 一、客户需求 电网公司每天采集各个用户的电表数据（格式如下表），其中data_date为电表数据上报时间，cons_id为电表id，r1为电表度数，其他字段与计算逻辑无关，可忽略。为了后续演示方便，仅输入cons_id=100000002的数据。 no(string) data_date(string) cons_id(string) org_no(string) r1(double) 101 20190716 100000002 35401 13.76 101 20190717 100000002 35401 14.12 101 20190718 100000002 35401 16.59 101 20190719 100000002 35401 18.89 表1：输入数据 电网公司希望通过实时计算（Blink）对电表数据处理后，每天得到每个电表最近两天（当天和前一天）的差值数据，结果类似如下表： cons_id(string) data_date

QQ音乐 Android 客户端的 Web 页面日均 PV 达到千万量级，然而页面的打开耗时与 Native 页面相距甚远，需要系统性优化。本文将介绍 QQ 音乐 Android 客户端在进行 Web 页面通用性能优化过程中的问题、思路、方案和效果，并尝试对跨端场景的常见瓶颈和对策进行归纳。文章作者：关岳，QQ音乐客户端开发工程师。 一、问题与目标 作为一款注重于内容运营的应用程序，QQ 音乐 Android 客户端的 Web 页面日均 PV 达到千万量级，评论页、MV 页等核心页面均有 Web 页面参与，或完全由 Web 实现。 客户端内 Web 页面的打开耗时与 Native 页面相距甚远，需要系统性优化。然而，现有的前端和跨端优化方案，存在一定局限性。 1. 前端优化的局限 针对 Web 页面的耗时优化，在优化思路、方案、服务、工具链等方面都已经建设得非常详细。然而，在客户端内 Web 页面这一场景，纯前端优化存在以下两个局限： 无法规避 WebView 初始化耗时 受限于 WebView 生命周期范围 从客户端角度，除了思考优化 WebView 初始化耗时之外，还可以从 “扩展前端生命周期” 的角度出发，思考优化方案。 2. 跨端优化的局限 现有跨端优化方案，包括离线包、VasSonic 等，为了达到最好的优化效果，均需要前端终端共同参与改造。这导致存量页面的逻辑改造增加

博客网站哪家强，CSDN找小强。 大家好，我是打不死的小强，素小暖！ 码龄三年，访问量依旧稳如狗！ 为了提高访问量，早日成为博客专家，我也是想尽了办法，吸引眼球的狗血名字，唯美的动态网图，blink的无耻推荐，去评论其他人的博客来换取他人的访问，还去老东家开源中国发热门动弹。 得不到的永远是最好的，我很喜欢现在的状态，虽然有些无耻，但是，很有成效，一个懒惰的我，变成了一个为了发博客可以学习总结到凌晨的人。 写博客是一种乐趣，一种需要培养的乐趣 我之前是混开源中国的，因为那里的动弹很吸引我，很有美女照片，小色段子，蛋疼的起名字动弹（王富贵永远会被推荐，开源中国的大bug）。 1、可以记录每日的学习情况 参考其它大神的博客，然后收录到自己的博客中，一种“都到碗里来”的感觉，不，应该是万剑归宗的感觉； 2、可以敦促你学习 这个是我写博客最重要的原因，惰性十足的我，怎样才能努力学习呢，怎样才能压制住内心的小寂寞呢？开一局王者荣耀，看韩国煽情电影，欧美大片，不爽吗？学习是孤寂的，需要一些偏执，比如写博客，提高访问量； 3、可以和大家进行交流，这个还是挺有意思的 这个篇《为什么很多人不愿意用hibernate了?》是我最火的文章，但，已成往事，在谩骂中成长，在博弈中进步，这就是博客的乐趣，这才是互联网最重要的分享精神，这才是互联网最可贵的互助精神。 4、共享的自豪感 当有人因为一个问题

简介 在今年2月初， SLS 已经发布针对新冠病毒肺炎疫情国内动态展示分析 APP，目前该能力全面开放给政府、社区、第三方平台和开放者进行广泛应用， 完全免费开放 。还没有关注过的同学可以通过以下链接了解背景： 新冠病毒疫情分析 APP 官方文档 云栖博文、直播 最近，随着新冠病毒肺炎疫情在全球爆发， SLS 又推出了跟踪关注全球范围疫情动态的分析大盘。与国内大盘主要关注国内疫情（数据来源于央视新闻、人民日报、各省市卫健委公告）相比，国际疫情大盘则是跟踪关注全球范围的疫情动态，数据来源是被国际上广泛引用的 约翰·霍普金斯大学开源数据集 。 SLS 阿里云日志服务（SLS）是针对日志类数据的一站式服务，无需开发就能快捷完成海量日志数据的采集、消费、投递以及查询分析等功能，提升运维、运营效率。日志服务主要包括实时采集与消费、数据投递、查询与实时分析等功能，适用于从实时监控到数据仓库的各种开发、运维、运营与安全场景。 作为日志分析中台，日志服务提供了一站式的数据采集、加工、查询分析、AI计算、可视化，并支持互联互通。 亮点 1. 提供规整的疫情数据，并每天定时同步更新 SLS 已经将疫情相关数据进行收集和规整，每天定时更新，并形成可视化平台覆盖全球各个国家/地区、省份/州的疫情信息。你只需要专注在数据的分析和展示，其它繁琐的细节 SLS 都已经处理好。 2. 预定义丰富数据大盘

作者：宋辛童（五藏） 整理：王文杰（Flink 社区志愿者） 摘要：本文根据 Apache Flink 系列直播整理而成，由阿里巴巴高级开发工程师宋辛童分享。文章主要从基本概念、当前机制与策略、未来发展方向等三个方面帮助开发者深入理解 Flink 的资源管理机制。 基本概念 当前机制与策略 未来发展方向 Tips： 点击「下方链接」可查看更多数仓系列视频～ https://ververica.cn/developers/flink-training-course-data-warehouse/ 1. 基本概念 1.1 相关组件 我们今天介绍的主要是与 Flink 资源管理相关的组件，我们知道一个 Flink Cluster 是由一个 Flink Master 和多个 Task Manager 组成的，Flink Master 和 Task Manager 是进程级组件，其他的组件都是进程内的组件。 图1. Flink 资源管理相关组件 如图1所示，一个 Flink Master 中有一个 Resource Manager 和多个 Job Manager ，Flink Master 中每一个 Job Manager 单独管理一个具体的 Job ，Job Manager 中的 Scheduler 组件负责调度执行该 Job 的 DAG 中所有 Task ，发出资源请求

作者：贺小令（晓令） 本文由阿里巴巴技术专家贺小令分享，社区志愿者郑仲尼整理。文章基于 Flink 1.9 版本，从用户的角度来讲解 Flink 1.9 版本中 SQL 相关原理及部分功能变更，希望对大家有所帮助。主要内容分享以下三个部分: TableEnvironment 的设计与使用场景 Catalog 的设计以及 DDL 实践 Blink Planner 的几点重要改进及优化 TableEnvironment FLIP-32 中提出，将 Blink 完全开源，合并到 Flink 主分支中。合并后在 Flink 1.9 中会存在两个 Planner：Flink Planner 和 Blink Planner。 在之前的版本中，Flink Table 在整个 Flink 中是一个二等公民。而 Flink SQL 具备的易用性、使用门槛低等特点深受用户好评，越来越被重视，Flink Table 模块也因此被提升为一等公民。而 Blink 在设计之初就考虑到流和批的统一，批只是流的一种特殊形式，所以可以用同一个TableEnvironment来表述流和批。 TableEnvironment 整体设计 图1 新 Table Environment 整体设计 从图 1 中，可以看出，TableEnvironment 组成部分如下： flink-table-common

有不少读者反馈，参考上篇文章《 Hive 终于等来了 Flink 》部署 Flink 并集成 Hive 时，出现一些 bug 以及兼容性等问题。虽已等来，却未可用。所以笔者增加了这一篇文章，作为姊妹篇。 回顾 在上篇文章中，笔者使用的 CDH 版本为 5.16.2，其中 Hive 版本为 1.1.0（CDH 5.x 系列 Hive 版本都不高于 1.1.0，是不是不可理解），Flink 源代码本身对 Hive 1.1.0 版本兼容性不好，存在不少问题。为了兼容目前版本，笔者基于 CDH 5.16.2 环境，对 Flink 代码进行了修改，重新打包并部署。 其实经过很多开源项目的实战，比如 Apache Atlas，Apache Spark 等，Hive 1.2.x 和 Hive 1.1.x 在大部分情况下，替换一些 Jar 包，是可以解决兼容性的问题。对于笔者的环境来说，可以使用 Hive 1.2.1 版本的一些 Jar 包来代替 Hive 1.1.0 版本的 Jar 包。在本篇文章的开始部分，笔者会解决这个问题，然后再补充上篇文章缺少的实战内容。 剪不断理还乱的问题 根据读者的反馈，笔者将所有的问题总结为三类： Flink 如何连接 Hive 除了 API 外，有没有类似 spark-sql 命令 识别不到 Hadoop 环境或配置文件找不到 依赖包、类或方法找不到 1.

前言 见解有限，如有描述不当之处，还请大家指出，如有错误，会及时修正。（Doge保命） 这是本系列的第一篇文章，主要讲浏览器的架构知识。 目的：对浏览器架构有初步的认知。 阅读本文的注意事项 文章难度由浅入深，大致可以分为四个模式： 简单模式：《浏览器的前世今生》 普通模式：《进程与线程》到《多进程架构简介》 困难模式：《多进程架构详解》到《核心原则》 地狱模式：《拓展资料》 小声BB： 阅读本系列文章，只需要阅读完《浏览器的前世今生》到《多进程架构简介》即可。 如有身体不适，请及时下车。 我从找资料，翻译，到分析资料，到困难难度已经吐血 。 文章内容存在大量的引用，在本人粗浅理解下整理了其中的内容，引用的链接放置在子标题下方，如有需要，可以进入原文深入了解。如有侵，给我留言，立马删。 大纲 开篇 前言 浏览器的占有率 chrome的核心原则的简单描述 浏览器和渲染引擎的前世今生 进程与线程 浏览器架构的演变 单进程架构 多进程架构 面向服务的架构 多进程架构简介 多进程架构详解 浏览器进程 进程模型 渲染进程 组件通信 渲染进程与视图管理 信息流如何通过各种组件和连接器 鼠标点击 光标事件 沙箱 插件架构 网络栈 GPU 架构分析 多流程体系结构采用什么主导的体系结构风格？ 多进程架构会产生哪些品质或者属性 多进程体系架构的是如何影响软件的修改能力 核心原则 拓展资料 小结