关于最佳实践:MaxCompute-物化视图智能推荐最佳实践

什么是物化视图MaxCompute物化视图是一种事后计算和存储后果数据的数据对象,也能够称之为“实体化视图”。物化视图能够作为一张虚构表存在于MaxCompute我的项目中,它的内容是一个或多个表的聚合,过滤以及Join组合计算结果。物化视图能够大幅度缩小查询处理工夫以及节俭作业计算资源,基于MaxCompute优化器弱小的主动查问改写能力,当作业能够复用物化视图后果时,优化器主动把一些简单的操作替换成读取物化视图操作,从而晋升作业执行速度、节俭作业计算资源。 什么是物化视图智能举荐物化视图的应用,岂但须要对物化视图的工作原理比拟理解,同时须要理解业务数据行为与业务数据的应用场景,给普通用户应用物化视图带来肯定艰难。 MaxCompute 物化视图智能举荐实现了用户无感知的流程化应用物化视图能力。用户开启物化视图智能举荐后,MaxCompute 能够为用户主动剖析业务数据应用场景,主动举荐物化视图,并且能够可视化展示物化视图的应用成果。为物化视图应用大大降低了门槛,同时也带来更多的物化视图应用场景。 物化视图智能举荐的特点简略易用,用户不须要理解物化视图各个底层工作细节,只需抉择本人的Project开启主动智能剖析。智能,MaxCompute主动对用户历史作业进行剖析,自动识别周期性作业,并智能提取作业汇合中的公共计算逻辑作为物化视图计算逻辑,并最终转换成用户敌对的SQL文本模式,依照举荐水平排序展现给用户。便于管理,MaxCompute控制台提供一站式的性能开明、物化视图治理以及物化视图应用成果展现。物化视图智能举荐的应用场景数据治理随着企业业务倒退,公司的业务数据会越来越多,各部门对数据都存在各种数据分析需要,在日常应用过程中,各个部门对数据的应用会存在肯定的穿插应用,难免会有大量的雷同逻辑的反复计算。 日常用户或者大数据平台管理人员很难发现反复计算,因为反复计算局部可能只是整个计算逻辑中一部分。在发现有反复计算时想批改也比拟艰难,如果从新形象一个反复计算的表,上游的依赖作业都须要更改,而后测试上线。会带来额定的工作量,从而导致数据治理很难推动。 应用物化视图智能举荐性能后,MaxCompute会主动剖析Project中存在哪些公共的计算逻辑,并且举荐进去,让用户去创立物化视图,有了物化视图后,通过弱小的优化器改写能力,可能让作业主动利用上物化视图的计算结果,不须要用户批改原来的逻辑。 示例,在没有物化视图,如下图,Tab4跟Tab5的计算中存在棱形跟圆形局部逻辑是反复计算的,在下图中计算了两遍。 创立物化视图MV1后,菱形跟圆形局部逻辑只计算了一遍,能够节俭计算资源的同时进步计算速度。 智能数据建模传统大数据处理,第一步就是既懂技术又懂业务的数据分析专家搭建数据仓库,对数据仓库进行分层,失常模型都分贴源层,明细层,汇总层,应用层等;传统建模形式有以下弊病: 1)模型建的好坏,间接影响到计算的有效性,重大依赖建模的专家; 2)同时随着业务倒退,数据越来越多后,不免有模型建的不是很适合的状况,如果再改模型对整个现有工作都有影响; 3)资源节约,局部模型建好后,然而应用的人很少或者没有应用,导致整个模型白白浪费计算资源和存储资源。 有了物化视图智能举荐后,用户不须要依赖专家来事后建模。能够做到智能的自动化建模。当用户应用数据后,后端主动剖析,剖析出反复计算逻辑,MaxCompute主动举荐创立物化视图,实现真正的灵便,快捷的自动化建模。让用户不必放心数据存储状况,计算资源应用效率等问题;用户能够把更多精力放在业务倒退上。特地对中小型公司来说,不须要额定要招聘数据建模同学,全副交给MaxCompute物化视图智能举荐即可。 数据报表/看板物化视图智能举荐也能够为用户的BI智能报表/看板提供减速能力。MaxCompute会为用户主动剖析反复刷新的数据,举荐创立物化视图,有了物化视图后能够事后计算好报表/看板须要的数据,在报表/看板须要用的时候间接会主动改写路由去查物化视图,能够大大降低报表/看板的响应工夫。 如何应用物化视图智能举荐物化视图智能举荐应用非常简单,只需以下几个步骤: 1.登录MaxCompute控制台,点击右边菜单“物化视图”; 2.抉择Tab页“设置”,开启智能剖析,并且增加须要剖析的项目名称; 3.T+1天后,查看Tab页“物化视图举荐”,查看零碎依据用户应用行为,举荐进去的公共子查问; 4.抉择对应的子查问创立物化视图; 5.T+1天后,查看Tab页“物化视图治理”,能够看到目前哪些查问计算调用了该物化视图以及调用物化视图前后成果比照。 物化视图智能举荐示例 阿里团体数据中台团队负责建设整个阿里的数仓“公共层”,试图将反复计算的逻辑进行收敛,让多个上游业务拜访同一个后果表,从而达到节俭计算和存储的目标。随着数据量和业务复杂度的几何增长,传统的“公共层”曾经很难达到本来构想的状态,次要起因有: 找数难逻辑存在相似性然而后果表不齐全可用人工发现公共逻辑难度大MaxCompute推出的物化视图智能举荐性能,恰好能很好的解决上述问题。数据中台团队通过将MaxCompute智能举荐后果转变为物化视图,大大降低了上游作业之间的反复计算,节俭了大量计算资源。 一期物化视图智能举荐性能笼罩了4个BU共20个project,命中物化视图的作业,其均匀计算资源节俭率为14%。后续咱们会有更加具体的理论应用案例来开展介绍。 物化视图智能举荐应用阐明物化视图并不能解决所有问题,在绝大部分状况下,总体上看都是能够为用户带来正向收益,包含能够缩小计算资源,进步计算速度,并升高计算成本。然而针对某个查问计算,在小概率下会给用户带来负收益,用户须要关注以下几点: 1.公共子查问被物化成物化视图后的数据是否产生数据收缩,如果产生几倍或者更高的收缩时,不倡议应用物化视图。 2.应用后付费的用户,须要留神目前物化视图节俭的是计算资源和计算复杂度,但并不一定会缩小数据扫描量,因为在数据物化过程中如果产生数据收缩后,可能扫描量会减少。 作者 夏俊伟 阿里云高级产品专家 / 郑君正 阿里云高级技术专家 原文链接 本文为阿里云原创内容,未经容许不得转载。

May 24, 2023 · 1 min · jiezi

关于最佳实践:8款最佳实践保护你的-IaC-安全

基础设施即代码(IaC) 是一种疾速倒退的技术,利用软件开发准则和实际,用软件配置基础设施。与传统的 IT 基础架构相比,IaC 能够更高效地交付软件。自动化还解锁了弹性配置的能力,该性能可在不同的负载下无效地分配资源。 只管 IaC 有很多劣势,但配置不当的 IaC 也会在整个零碎中迅速流传谬误配置。IaC 的自动化配置可能提高效率,也能够放大谬误,而这些谬误通常会对平安产生不利影响。保持 IaC 最佳实际是升高胜利供应链网络攻击和破绽危险的无效办法,思考以下8个 IaC 最佳实际,为企业平安保驾护航。 扫描 IaC 代码,排查谬误配置IaC 是一个功能强大的工具,但同时也存在肯定平安危险,例如在整个云基础设施中流传小的配置谬误。谬误配置可能的模式有:不平安的默认配置,可公开拜访的 S3 buckets 或未加密的数据库。 SAST 和 SCA 扫描是特色代码的最佳形式,然而很少有企业优先思考用此类形式爱护 IaC。对 IaC 代码进行平安扫描能够无效缩小因为配置谬误导致的裸露和破绽。此外,能够通过扫描新的 commit 以查找对云部署的更改,来检测和更正与其原始模板匹配的根底构造。 将自动化 IaC 平安扫描嵌入开发工作流程在破绽进入生产环境之前发现并修复比后置的补救伎俩更无效。因而通过将对 IaC 谬误配置的查看嵌入到开发人员工作流中,开发人员可能提前发现并纠正问题。能够采纳pre-commit的模式,以便在开发人员保留其工作时测试代码,也能够应用拉取申请主动执行的分支爱护规定,或者作为在CI中运行的平安构建规定。在开发人员的工作流中运行平安扫描还能够确保开发人员及时取得精确信息,并修复谬误配置,进步修复效率。 辨认并纠正环境偏移环境偏移检测(不同部署环境的配置与其模板不同步的状况)和修复谬误配置是 IaC 的最佳实际之一。配置中的偏差通常产生在保护期间,并可能导致环境(如测试和生产)变动。随着工夫的推移,这会导致配置偏离平安状态。 环境偏移可能是由大意的谬误引起的,而由此造成的问题修复难度高并且可能导致业务宕机,造成巨大损失。通过将 IaC 与理论生产配置进行比拟来辨认偏移,但手动实现此操作既繁琐又耗时。因而,偏移检测是 IaC 平安扫描工具的不错抉择。 避免硬编码密钥渗透到 IaC 中IaC 最宽泛认可的最佳实际之一是防止部署蕴含凭证的代码。硬编码密钥能够在特色代码或 IaC 代码中被引入,而进入 IaC 代码的密钥有可能对组织的安全性造成毁灭性的影响。硬编码密钥的存在也使得因为明码破解而导致相干帐户泄露,让歹意攻击者无隙可乘。因而如果硬编码密钥保留在程序中,会导致身份验证措施失败,因为任何有权拜访我的项目的人都能够查看这些硬编码密钥。与扫描 IaC 平安配置谬误十分类似,初始评估应在主分支和版本历史记录中的 IaC 代码中查找硬编码密钥。最好的办法是通过扫描 commit 来避免这些硬编码密钥进入版本控制系统。 缩小代码透露的工夫和影响无心泄露源代码可能导致知识产权偷盗、硬编码密钥的裸露等等。源代码和 IaC 代码通常位于同一存储库中,裸露 IaC 代码的危险泛滥,其中包含攻击者通过解析代码找到对应的破绽、配置谬误和破解密钥的危险。 建设协定以防止代码透露,同时制订应急打算,以防产生透露。应考察潜在的可疑用户流动,例如应用 IaC 下载、克隆或分叉存储库。强制施行最小特权策略有助于缩小代码透露危险。此外执行定期检查,避免源代码持续公布到公共存储库或代码共享站点,并确保疾速解决任何源代码透露。公开专有 IaC 代码的工夫越长,歹意攻击者就越有可能借此进行发动攻打。因而,设置警报机制,可能尽可能升高代码透露产生的危险。 ...

July 22, 2022 · 1 min · jiezi

关于最佳实践:Oracle-11204最佳实践参数

11.2.0.4序号 参数名称 参数值 参数形容1 _awr_mmon_deep_purge_all_expired FALSE Allows deep purge to purge AWR data for all expired snapshots2 _cursor_obsolete_threshold 200 _cursor_obsolete_threshold3 _index_partition_large_extents FALSE Enables large extent allocation for partitioned indices4 _optimizer_adaptive_cursor_sharing FALSE _optimizer_adaptive_cursor_sharing5 _optimizer_cartesian_enabled FALSE _optimizer_cartesian_enabled6 _optimizer_extended_cursor_sharing NONE _optimizer_extended_cursor_sharing7 _optimizer_extended_cursor_sharing_rel NONE _optimizer_extended_cursor_sharing_rel8 _optimizer_use_feedback FALSE _optimizer_use_feedback9 _partition_large_extents FALSE Enables large extent allocation for partitioned tables10 archive_lag_target 600 Maximum number of seconds of redos the standby could lose11 audit_trail os enable system auditing12 control_file_record_keep_time 31 control file record keep time in days13 db_block_checking MEDIUM header checking and data and index block checking14 db_block_checksum FULL store checksum in db blocks and check during reads15 db_cache_advice OFF Buffer cache sizing advisory16 db_files 2000 max allowable # db files17 db_lost_write_protect TYPICAL enable lost write detection18 deferred_segment_creation FALSE defer segment creation to first insert19 enable_ddl_logging TRUE enable ddl logging21 filesystemio_options setall IO operations on filesystem files22 job_queue_processes 100 maximum number of job queue slave processes23 max_shared_servers 0 max number of shared servers24 open_cursors 1000 max # cursors per session25 pga_aggregate_target 0.2 * #OSMEMORY# Target size for the aggregate PGA memory consumed by the instance26 processes 1000 user processes27 recyclebin OFF recyclebin processing28 remote_login_passwordfile EXCLUSIVE password file usage parameter29 resource_limit TRUE master switch for resource limit30 resource_manager_plan 'force:' resource mgr top plan31 result_cache_max_size 0 maximum amount of memory to be used by the cache32 sec_max_failed_login_attempts 100 maximum number of failed login attempts on a connection33 session_cached_cursors 200 number of session cursors to cache34 sga_max_size 0.5 * #OSMEMORY# max total SGA size35 sga_target 0.5 * #OSMEMORY# Target size of SGA36 shared_servers 0 number of shared servers to start up37 standby_file_management AUTO if auto then files are created/dropped automatically on standby38 undo_retention 10800 undo retention in seconds39 _memory_imm_mode_without_autosga FALSE Allow immediate mode without sga/memory target40 _use_adaptive_log_file_sync FALSE Adaptively switch between post/wait and polling41 _gc_undo_affinity FALSE if TRUE, enable dynamic undo affinity42 _gc_policy_time 0 how often to make object policy decisions in minutes43 _px_use_large_pool TRUE Use Large Pool as source of PX buffers44 _clusterwide_global_transactions FALSE enable/disable clusterwide global transactions45 parallel_force_local TRUE force single instance execution46 _undo_autotune FALSE enable auto tuning of undo_retention47 _datafile_write_errors_crash_instance FALSE datafile write errors crash instance48 _keep_remote_column_size TRUE remote column size does not get modified49 _shared_pool_reserved_pct 20 percentage memory of the shared pool allocated for the reserved area50 db_cache_size 0.34 * #OSMEMORY# Size of DEFAULT buffer pool for standard block size buffers51 shared_pool_size 0.07* #OSMEMORY# Target size of shared_pool_size (kb)52 java_pool_size 131072 Target size of java_pool_size (kb)53 large_pool_size 524288 Target size of large_pool_size (kb)54 streams_pool_size 524288 Target size of streams_pool_size (kb)55 _cleanup_rollback_entries 20000 no. of undo entries to apply per transaction cleanup56 _rollback_segment_count 2000 number of undo segments20 event '10949 trace name context forever:28401 trace name context forever, level 1:10849 trace name context forever, level 1:19823 trace name context forever, level 90' debug event control - default null string

July 17, 2022 · 3 min · jiezi

Blink-有何特别之处菜鸟供应链场景最佳实践

作者:晨笙、缘桥菜鸟供应链业务链路长、节点多、实体多,使得技术团队在建设供应链实时数仓的过程中,面临着诸多挑战,如:如何实现实时变Key统计?如何实现实时超时统计?如何进行有效地资源优化?如何提升多实时流关联效率?如何提升实时作业的开发效率? 而 Blink 能否解决这些问题?下面一起来深入了解。背景菜鸟从2017年4月开始探索 Blink(即 Apache Flink 的阿里内部版本),2017年7月开始在线上环境使用 Blink,作为我们的主流实时计算引擎。 为什么短短几个月的探索之后,我们就选择Blink作为我们主要的实时计算引擎呢? 在效率上,Blink 提供 DataStream、TableAPI、SQL 三种开发模式,强大的 SQL 模式已经满足大部分业务场景,配合半智能资源优化、智能倾斜优化、智能作业压测等功能,可以极大地提升实时作业的开发效率;在性能上,诸如MiniBatch&MicroBatch、维表 Async&Cache、利用 Niagara 进行本地状态管理等内部优化方案,可以极大地提升实时作业的性能;在保障上,Blink 自带的 Failover 恢复机制,能够实现线程级的恢复,可以做到分钟级恢复,配合 Kmonitor 监控平台、烽火台预警平台,可以有效地实现实时作业的数据保障。 接下来,我将结合供应链业务的一些业务场景,简要说明,Blink 如何解决我们遇到的一些实际问题。 回撤机制订单履行是供应链业务中最常见的物流场景。什么是订单履行呢?当商家 ERP 推单给菜鸟之后,菜鸟履行系统会实时计算出每笔订单的出库、揽收、签收等节点的预计时间,配送公司需要按照各节点的预计时间进行订单的配送。为了保证订单的准点履约,我们经常需要统计每家配送公司每天各个节点的预计单量,便于配送公司提前准备产能。 看似很简单的实时统计加工,我们在开发过程中遇到了什么问题呢?履行重算!当物流订单的上游某个节点延迟时,履行系统会自动重算该笔订单下游所有节点的预计时间。比如某个物流订单出库晚点后,其后的预计揽收时间、预计签收时间都会重算。而对于大部分的实时计算引擎来说,并不能很友好的支持这种变 Key 统计的问题。以前,数据量没那么大的时候,还可以通过 OLAP 数据库来解决这类场景,当量上来后, OLAP 方案的成本、性能都是很大的问题。 除了 OLAP 方案,我们提倡采用 Blink 已经内置的 Retraction 机制,来解决这类变 Key 统计的问题,这也是我们在2017年初就开始尝试 Blink 的重要原因。Blink 的Retraction 机制,使用 State 在内存或者外部存储设备中对数据进行统计处理,当上游数据源对某些汇总 Key 的数据做更新时,Blink 会主动给下游下发一个删除消息从而“撤回”之前的那条消息,并用最新下发的消息对表做更新操作。Retraction的实现细节,可以参见:Retraction for Flink Streaming。 下面是一个简化后的案例,供了解Blink Retraction的内部计算过程: 对于上述案例,可以通过 Blink 提供的强大的、灵活的、简易的 SQL 开发模式来实现,只需要几行 SQL 即可完成。 ...

June 17, 2019 · 2 min · jiezi

渐进式React

可以说 React 为Web开发者带来了全新的开发模式,而在各类新功能下,如何达到性能最优仍是我们需要关心的。今天做一次精读尝试,原文地址在文末,话不多说,先呈上一份性能清单:1. 测量组件级渲染性能Chrome DevTools Performance 面板React DevTools profiler 面板2. 避免非必要的组件重复渲染尽量使用shouldComponentUpdateClass 组件使用PureComponent功能组件使用React.memo记住 Redux selectors(比如使用reselect)虚拟化超长列表(比如使用react-window)3. 使用 Lighthouse 测量App级性能4. 提升APP级性能如果没有使用服务端渲染,则使用React.lazy分割组件如果使用了服务端渲染,则使用loadable-components之类的库来分割组件使用 service worker 来缓存需要的文件,Workbox 可以帮到你如果使用了服务端渲染,使用流式传输(使用renderToNodeStream或renderToStaticNodeStream)无法使用 SSR?使用react-snap等方案进行预渲染(Pre-render)如果用到 CSS-in-JS 库,将关键路径样式解析出来保障应用可用性,考虑使用React A11y或react-axe等库如果用户需要通过设备主屏幕访问站点,增加 web app manifest对于 React 应用,我们主要关注两个性能维度:组件渲染性能 与 页面加载性能,由于 React 的核心在于组件设计,那先从组件性能讲起。测量组件级性能React 熟为人知的“Virtual DOM”,是建立在高效调和(reconciliation)算法基础上的,其基于一定约定假设,将虚拟 DOM Diff 时间复杂度从O(n3)降为O(n)。虽然这些 React 内部实现不要求大家都理解,在小型应用中性能也不足以成为瓶颈,但性能优化本来就是量变到质变的过程,因此让我们从测量组件性能工具做起。使用 Chrome 开发者工具测量性能React 使用 User Timing API 收集各生命周期耗时,为避免测量本身带来的性能影响,性能采集仅在开发模式有效。说实话,这类火焰图在视觉上有很强直观性,但缺少的有效调试信息,因此 React Devtools 提供了更为强大的能力。使用 React DevTools Profiler 分析性能React 16.5 开始使用 Profiler API 收集组件渲染耗时,以独立Tab形式呈现在 React DevTools 中。它的使用类似于 Chrome DevTools Performance,通过录制来决定收集数据范围。React DevTools Profiler 示例相比 Chrome DevTools Performance 中呈现的 Timing 信息,React DevTools Profiler 提供了更多辅助定位性能瓶颈的组件级信息,这里简单说下几个亮点:以 commit 维度记录信息。熟悉 React 内部原理的同学知道,React 生命周期中有个 Commit 阶段,React DevTools Profiler 会以每次 commit 维度记录渲染相关信息,在右侧进行展示。具体组件状态信息。左侧的火焰图对应了组件层级结构,以不同颜色区分组件渲染次数,高亮重复渲染的组件。点击组件后,右侧会展示组件具体渲染次数,以及当时的 state 与 props。简单的统计能力。除了火焰图,工具还有排名(Ranked)和交互(Interactions)两个维度统计,帮助更快的定位组件瓶颈。总体上 Profiler 工具使用简单,没什么门槛,接下来介绍优化组件渲染的相关技术。避免非必要的组件重复渲染去除无用的重复渲染,方案因场景各异:使用 shouldComponentUpdateshouldComponentUpdate(nextProps, nextState) { // 仅在确定条件下返回 true}Class 组件使用 PureComponentimport React, { PureComponent } from ‘react’;class AvatarComponent extends PureComponent {}功能组件使用 memoimport React, { memo } from ‘react’;const AvatarComponent = memo(props => {});记住 Redux selectors(比如使用 reselect)虚拟化超长列表(比如使用 react-window)测量 App 级性能除了 DOM 级的渲染性能,还有更高层面的应用加载性能需要关注。这方面的性能工具属 Lighthouse 最有名了,我们可以通过 Node CLI、Chrome 扩展和 Chrome DevTools 的 Audits 面板用到它。Lighthouse 根据一系列性能规则,对目标页面进行检查,最终生成一份性能报告,给出未达标指标的改进建议。在 React 项目中,随着路由和组件的膨胀,很容易触发 Lighthouse 对 JavaScript 传输体积的检查规则(Avoid enormous network payloads)。在实践中,已有成熟的方案供我们使用——代码分割。代码分割进行代码分割的一个方法是动态导入(dynamic imports): import(’lodash.sortby’) .then(module => module.default) .then(module => doSomethingCool(module))这里的 import 语法像是函数调用,允许异步加载模块并通过 Promise 返回。上面代码动态获取了 lodash sortby 方法,紧接着被后续代码使用。虽然动态导入目前仍处于 stage 3 阶段,Chrome and Safari 已经率先支持了,Webpack、Rollup 和 Parcel 也做好了支持。回到 React,组件级别的代码分割已经被良好地抽象,比如React.lazy:import React, { lazy } from ‘react’;const AvatarComponent = lazy(() => import(’./AvatarComponent’));然而这么做可能会导致用户可感知的加载延迟。对此,可以将Suspense组件配合React.lazy一起使用,“暂停”部分组件的渲染,通过渲染 Loading 组件,对仍在加载的组件进行降级处理:import React, { lazy, Suspense } from ‘react’;import LoadingComponent from ‘./LoadingComponent’;const AvatarComponent = lazy(() => import(’./AvatarComponent’));const PageComponent = () => ( <Suspense fallback={LoadingComponent}> <AvatarComponent /> </Suspense>)Suspense 还不支持 SSR,如果要在服务端渲染使用代码分割,可以使用loadable-components这样的库。另外如果需要在滚动场景做异步加载的同学,可以了解下 react-loadable-visibility。缓存Service Worker 就不重新介绍了,概括起来就是一个运行在浏览器后台的可编程代理,让我们对网络缓存更加可控。一个具体的使用场景是,通过控制缓存策略,来提升用户二次访问时的页面加载体验。这里主要是安利 Workbox 这个工具包,它能让我们更简单地使用 Service Worker,具体细节不做展开,在 PWA 的浪潮中,你的站点值得拥有。流式 SSR为了加快页面呈现,服务端渲染概念已经被大家接受和使用。为了最大限度复用服务端返回的 HTML,React 还提供了 hydrate() API。这时优化的目光投向了 TTI,流式渲染也应运而生,相对之前的renderToString API 返回 HTML 字符串,renderToNodeStream会返回 NodeReadable字节流。这样浏览器就能源源不断地获取到页面块,hydrate API 也很好地支持了流式处理,真的很强大。关于 SSR 更多信息,可以查看本专栏的《Web渲染那些事儿》。SSR 不行?预渲染来顶其实服务端渲染是个笼统的概念,由于现代页面大多都是动态的,因此每个请求可能都要在服务器上处理一遍。然而纯服务端渲染与纯客户端渲染之间,是存在中间地带的。虽然页面是通过组件模式进行开发,但页面内容可能是静态的,只要生成一次就行,这就是预渲染(Prerendering)或静态渲染的由来。这里介绍一个基于 Puppeteer 的预渲染方案 react-snap,它能让你更简单地进行预渲染页面。提取关键 CSS-in-JS 样式出于各种原因,有些开发者会使用 emotion 及 styled-components 等 CSS-in-JS 库,但如果不注意,会导致样式都在运行时解析,也就是导致页面会闪过无样式的瞬间。如果在移动设备或弱网络场景下,体验就很糟糕。上面提到的 SSR 更是如此,因为在客户端JS加载之前,SSR 返回的无样式 DOM 已经开始渲染了。优化的做法就是将这些关键样式提取出来,好在 emotion 和 styled-components 都原生支持将样式提取到可读流中,流式 SSR 也不用担心闪屏情况了。杂项接下几项关于提升开发者体验,并助于减少繁琐的编码。编写更少代码 = 传输更少代码 = 更快的网页加载原子 CSS原子样式的理念是定义单一作用的 class,以达到灵活组合样式的目的。看个简单的例子:<button class=“bg-blue”>Click Me</button>bg-blue 定义了蓝色背景色,作用在 button 上可令其应用这条规则。如果要给它加个 padding,可以设置单独负责 padding 的 class:<button class=“bg-blue pa2”>Click Me</button>虽然会多写几个 css class,但可以不用再去编辑复杂的 CSS 文件了,如果你不想自己维护一套样式规范,可以直接用开源的 Tachyons 方案。组件级别还有 tachyons-components 这样的方案,个人觉得还不太成熟,这里不做展开。整体来看原子 CSS 比较适用于样式风格简单统一的场景,让开发者聚焦 JS 部分,随时修改样式而不用关心样式继承方面的影响,另一个好处是 CSS 可以长期缓存,基本不需要更新。出于性能考虑,页面首次加载会被统一样式的 CSS 阻塞,看了下gzip后有10KB大小,还是看场景应用吧。HooksHooks 允许以功能组件实现以前只有class组件才能实现的功能,比如对state的操作:import { useState } from ‘react’;function AvatarComponent() { const [name, setName] = useState(‘Houssein’); return ( <React.Fragment> <div> <p>This is a picture of {name}</p> <img src=“avatar.png” /> </div> <button onClick={() => setName(‘a banana’)}> Fix name </button> </React.Fragment> );}除了 React 提供的 useState 和 useEffect,可以自定义 hooks 来复用跨组件的逻辑。在此之前要实现该功能,会用到 recompose 这个库,Hooks 出现后就可以退出历史舞台了。(真实情况是 recompose 的作者加入了 React Team,并推出了 Hooks)虽然 Hooks 的定位是解决代码架构问题,但确实也在加载性能方面做出了贡献。虽然 Hooks 功能相关代码为 React 增加了1.5KB(gzip后),但 Hooks 代码比 class 组件代码更易压缩,因此可以减小一些 JS 包大小。总结像 React 这样拥有广泛开发者的开源项目,有两样事可以期待:优化其 API,令构建应用更加容易开源社区贡献第三方库,令构建应用更加容易“令构建应用更加容易”可以指很多方面,让开发者做的更少、页面性能更高是其中之一。延伸阅读progressive reactReact as a UI Runtime Debugging React performance with React 16 and Chrome Devtools Introducing the React Profiler make loadable-components work with SSR 《Web渲染那些事儿》 ...

April 1, 2019 · 2 min · jiezi