一引起操控性难题其原因？

引起操控性难题的其原因一般来说不是断然因由，特别是小型控制系统插值十多年后，长年劳累过度导致，所以他们要必要性分析找出症结，并按困局错误率逐一击溃，拿他们工程项目为例，约莫分两个方面：

1 天然资源耶莱贝大

通过Chrome DevTools的Network条码，他们可以领到网页前述拉取的天然资源大小不一（如右图）：

历经后端高速路发展，近些年工程项目预览插值，后端构筑乙醛也在急速减小，即使要销售业务由亚姆，许多老师导入库和标识符过程并没有考量操控性难题，引致构筑的包减至几百MB，这样增添两个明显的难题：

弱(一般)互联网下，首屏天然资源浏览费时长天然资源Cogl导出继续执行慢

对第二个难题，大体上会负面影响大部份终端端使用者，因此会花费大批无谓的使用者频宽，对顾客是一个经济上的显式经济损失和新体验经济损失。

对第三个难题，会负面影响大部份使用者，使用者可能即使等候时间太长而舍弃使用。

右图展现了延后与使用者化学反应：

2 标识符费时长

在程序继续执行微观，工程项目插值中引起的操控性难题两极化是即使开发者标识符产品质量引致，约莫下列两个因由：

无谓的数据流监听

此场景在hooks+redux的场景下会更容易出现，如下表所示标识符：

const FooComponent = () => { constdata = useSelector(state => state.fullData); return <Bar baz={data.bar.baz} />; };

假设fullData是频繁变更的大对象，虽然FooComponent仅依赖其.bar.baz属性，fullData每次变更也会引致Foo重新渲染。

双刃剑cloneDeep

相信许多老师在工程项目中都有cloneDeep的经历，或多或少，特别是插值十多年的工程项目，其中难免有mutable型数据处理逻辑或销售业务微观依赖，需要用到cloneDeep，但此方法本身存在很大操控性陷阱，如下表所示：

// a.tsx export const a = { name: a, };// b.tsx import { a } = b; saveData(_.cloneDeep(a)); // 假设需要克隆后落库到后端数据库

上方标识符正常插值中是没有难题的，但假设哪天 a 需要扩展一个属性，保存一个ReactNode的引用，那么继续执行到b.tsx时，浏览器可能直接崩溃！

Hooks之Memo

hooks的发布，给react开发增添了更高的自由度，同时也增添了容易忽略的产品质量难题，由于不再有类中明码标价的生命周期概念，组件状态需要开发者自由控制，所以开发过程中务必懂得react对hooks组件的渲染机制，如下表所示标识符可强化的地方：

const Foo = () => { // 1. Foo可用React.memo，避免无props变更时渲染 const result = calc(); // 2. 组件内不可使用直接继续执行的逻辑，需要用useEffect等封装 return <Bar result={result} />; // 3.render处可用React.useMemo，仅对必要性的数据依赖作渲染 };

Immutable Deep Set

在使用数据流的过程中，很大程度他们会依赖lodash/fp的函数来实现immutable变更，但fp.defaultsDeep系列函数有个弊端，其实现逻辑相当于对原对象作深度克隆后继续执行fp.set，可能增添一些操控性难题，因此引致原对象大部份层级属性都被变更，如下表所示：

const a = { b: { c: { d: 123 }, c2: { d2: 321 } } }; const merged = fp.defaultsDeep({ b: { c3: 3 } }, a); console.log(merged.b.c === a.b.c); // 打印 false

3 排查路径

程各个环节的费时和卡顿点（如右图）：

当他们锁定一个费时较长的环节，就可以再通过矩阵树图往下深入（右图），找出具体费时较长的函数。

诚然，一般来说他们不会直接找出某个单点函数占用费时非常长，而基本是每个N毫秒函数叠加继续执行成百上千次引致卡顿。所以这块结合react调试插件的Profile可以很好地帮助定位渲染难题所在：

如图react组件被渲染的次数以及其渲染时长一目了然。

二如何解决操控性难题？

1 天然资源包分析

作为一名有操控性sense的开发者，有必要性对自己构筑的乙醛内容保持敏感，这里他们使用到webpack提供的stats来作乙醛分析。

首先继续执行 webpack –profile –json > ./build/stats.json 得到 webpack的包依赖分析数据，接着使用 webpack-bundle-analyzer ./build/stats.json 即可在浏览器看到一张构筑大图（不同项目乙醛不同，右图仅作举例）：

当然，还有一种直观的方式，可以采用Chrome的Coverage功能来辅助判定哪些标识符被使用（如右图）：

最佳构筑方式

一般来说来讲，他们组织构筑包的基本思路是：

按entry入口构建。一个或多个共享包供多entry使用。

而基于复杂销售业务场景的思路是：

entry入口轻量化。共享标识符以chunk方式自动生成，并建立依赖关系。大天然资源包动态导入（异步import）。

webpack 4中提供了新的插件 splitChunks 来解决标识符分离强化的难题，它的默认配置如下表所示：

module.exports = { //… optimization: { splitChunks: { chunks: async, minSize: 20000, minRemainingSize: 0, maxSize: 0, minChunks: 1, maxAsyncRequests: 30, maxInitialRequests: 30, automaticNameDelimiter: ~, enforceSizeThreshold: 50000, cacheGroups: { defaultVendors: { test: /[\\/]node_modules[\\/]/, priority: -10 }, default: { minChunks: 2, priority: -20, reuseExistingChunk: true } } } } };

根据上述配置，其分离chunk的依据有下列几点：

模块被共享或模块来自于node_modules。chunk必须大于20kb。同一时间并行加载的chunk或初始包不得超过30。

理论上webpack默认的标识符分离配置已经是最佳方式，但如果工程项目复杂或耦合程度较深，仍然需要他们根据前述构筑乙醛大图情况，调整他们的chunk split配置。

解决TreeShaking失效

“你工程项目中有60%以上的标识符并没有被使用到！”

treeshaking的初衷便是解决上面一句话中的难题，将未使用的标识符移除。

webpack默认生产模式下会开启treeshaking，通过上述的构筑配置，理论上应该达到一种效果“没有被使用到的标识符不应该被打入包中”，而现实是“你认为没有被使用的标识符，全部被打入Initial包中”，这个难题一般来说会在复杂工程项目中出现，其因由就是标识符副作用（code effects）。由于webpack无法判定某些标识符是否“需要产生副作用”，所以会将此类标识符打入包中（如右图）：

所以，你需要明确知道你的标识符是否有副作用，通过这句话判定：“关于‘副作用’的定义是，在导入时会继续执行特殊行为的标识符（修改全局对象、立即继续执行的标识符等），而不是仅仅暴露一个 export 或多个 export。举例说明，例如 polyfill，它负面影响全局作用域，因此一般来说不提供 export。”

对此，解决方法就是告诉webpack我的标识符没有副作用，没有被导入的情况下可以直接移除，告知的方式即：

在package.json中标记sideEffects为false。

或在webpack配置中 module.rules 添加sideEffects过滤。

模块规范

由此，要使得构筑乙醛达到最佳效果，他们在标识符过程中约定了下列几点模块规范：

[必须] 模块务必es6 module化（即export 和 import）。[必须] 三方包或数据文件（如地图数据、demo数据）超过 400KB 必须动态按需加载（异步import）。[禁止] 禁止使用export * as方式输出（可能引致tree-shaking失效因此难以追溯）。[推荐] 尽可能导入包中具体文件，避免直接导入整个包（如：import { Toolbar } from @alife/foo/bar）。[必须] 依赖的三方包必须在package.json中标记为sideEffects: false（或在webpack配置中标记）。

2 Mutable数据

大体上通过Performance和React插件提供的调试能力，他们基本可以定位难题所在。但对mutable型的数据变更，我这里也结合实践给出一些非标准调试方式：

冻结定位法

众所周知，数据流思想的产生因由之一就是避免mutable数据无法追溯的难题（即使你无法知道是哪段标识符改了数据），而许多工程项目中避免不了mutable数据更改，此方法就是为了解决一个棘手的mutable数据变更难题而想出的方法，这里我暂时命名为“冻结定位法”，即使原理就是使用冻结方式定位mutable变更难题，使用相当tricky：

constob j= { prop: 42 }; Object.freeze(obj); obj.prop=33; // Throws an error in strict mode

Mutable追溯

此方法也是为了解决mutable变更引起数据不确定性变更难题，用于实现排查的两个目的：

属性在什么地方被读取。属性在什么地方被变更。属性对应的访问链路是什么。

如下表所示示例，对一个对象的深度变更或访问，使用 watchObject 之后，不管在哪里设置其属性的任何层级，都可以输出变更相关的信息（stack内容、变更内容等）：

const a = { b: { c: { d: 123 } } }; watchObject(a); const c=a.b.c; c.d =0; // Print: Modify: “a.b.c.d”

watchObject 的原理即对一个对象进行深度 Proxy 封装，从而拦截get/set权限，详细可参考:

https://gist.github.com/wilsoncook/68d0b540a0fea24495d83fc284da9f4b

避免Mutable

一般来说像react这种技术栈，都会配套使用相应的数据流方案，其与mutable是天然对立的，所以在标识符过程中应该尽可能避免mutable数据，或者将两者从设计上分离（不同store），否则出现不可预料难题且难以调试

3 计算&渲染

最小化数据依赖

在工程项目组件爆炸式增长的情况下，数据流store内容层级也逐渐变深，许多组件依赖某个属性触发渲染，这个依赖项需要尽可能在设计时遵循最小化原则，避免像上方所述，依赖一个大的属性引致频繁渲染。

合理利用缓存

（1）计算结果

在一些必要性的cpu密集型计算逻辑中，务必采用 WeakMap 等缓存机制，存储当前计算终态结果或中间状态。

（2）组件状态

对像hooks型组件，有必要性遵循下列两个原则：

尽可能memo费时逻辑。无多余memo依赖项。

避免cpu密集型函数

某些工具类函数，其复杂度跟随入参的量级上升，而另外一些本身就会花费大批cpu时间。针对这类型的工具，要尽量避免使用，若无法避免，也可通过 “控制入参内容（白名单）” 及 “异步线程（webworker等）”方式做到严控。

比如针对 _.cloneDeep ，若无法避免，则要控制其入参属性中不得有引用之类的小型数据。

另外像最上面描述的immutable数据深度merge的问题，也应该尽可能控制入参，或者也可参考使用自研的immutable实现：

https://gist.github.com/wilsoncook/fcc830e5fa87afbf876696bf7a7f6bb1const a = { b: { c: { d: 123 }, c2: { d2: 321 } } }; const merged = immutableDefaultsDeep(a, { b: { c3: 3 } }); console.log(merged === a); // 打印 false console.log(merged.b.c === a.b.c); // 打印 true