大家好，我是小牛，今天跟聊一下 BAT 面试 C++ 开发工程师必问的一个考点：智能指针。 小艾：你昨晚面 C++ 去了？ 小牛：对啊，不是这个厂主要技术栈都是 C++ 嘛，我就面去了。 小艾：问了点啥啊？ 小牛：BAT 这 C++ 问的都差不多，又问智能指针了。 小艾：那来讲讲呗。 小牛：来。 智能指针的引入 大家都知道，指针是 C++ 中非常重要的一部分，大家在初期学习 C++ 的时候一定学过类似这样的指针方式。 int *ptr; 这种指针也被称为裸指针。但是使用裸指针会存在一些不足： 如果使用裸指针分配内存后，忘记手动释放资源，会出现内存泄漏。 如果使用多个裸指针指向同一资源，其中一个指针对资源进行释放，其它指针成为空悬指针，如果再次释放会存在不可预测的错误。上图中当 sp1 把资源释放后，sp2 成了空悬指针。空悬指针指的是指针所指向的对象已经释放的时候自身却没有被置为 nullptr。sp1 通过 free/delete释放资源的内存时，内存不会立刻被系统回收，而是状态改变为可被其它地方申请的状态。这时当再次操作 sp2，这块内存可能被其它地方申请了，而具体被谁申请了是不确定的，因此可能导致的错误也是不可预测的。 如果程序异常退出时，裸指针的释放资源的代码未能执行，也会造成内存泄漏。 为了改善裸指针的不足，确保资源的分配和释放是配对的，开发者提出了智能指针。智能指针主要是对裸指针进行了一次面向对象的封装，在构造函数中初始化资源地址，在析构函数中释放资源。 当资源应该被释放时，指向它的智能指针可以确保自动地释放它。 C++ 库中，为智能指针提供了不带引用计数和带引用计数的两种方案。 引用计数用于表示有多少智能指针引用同一资源。不带引用计数的智能指针采用独占资源的方式，而带引用计数的智能指针则可以同时多个指向同一资源。下面介绍一下它们的主要特点和区别。 智能指针的分类 不带引用计数的智能指针 不带引用计数的智能指针包括 auto_ptr、scoped_ptr和 unique_ptr三种指针。 不带引用计数的智能指针 1. auto_ptr: 我们先来看个例子： #include int main() { auto_ptr<int> ptr(new int(6));//定义auto_ptr指针ptr auto_ptr<int> ptr1(ptr); //拷贝构造ptr定义ptr1 *ptr=8;//对空指针ptr赋值会产生不可预料的错误 return 0; } 开始时 ptr 指向资源，一个整型数字6，当用 ptr1 拷贝构造 ptr 时，ptr1 指向资源，而 ptr 则指向 nullptr。下一行程序中如果对空指针 ptr 赋值 8，将会产生不可预料的错误。 下图表示 auto_ptr指针对资源的指向过程。 auto_ptr 使用拷贝构造时，如果只有最后一个 auto_ptr持有资源，其余 auto_ptr持有的资源会被置为 nullptr。 因此需要注意，不能在容器中使用 auto_ptr，当容器发生拷贝时，原容器中 auto_ptr持有的资源会置 nullptr。 下面我们再来看一下 auto_ptr的部分源码和部分解析： template<class _Ty> class auto_ptr { public: typedef _Ty element_type; explicit auto_ptr(_Ty * _Ptr=nullptr) noexcept : _Myptr(_Ptr)//初始化列表 { //构造函数 } auto_ptr(auto_ptr& _Right) noexcept : _Myptr(_Right.release())   { //拷贝构造函数，会调用release()函数 } _Ty * release() noexcept { /*使用拷贝构造时，最后一个auto_ptr持有资源，    其余被置为nullptr*/ _Ty * _Tmp = _Myptr;…

简介： 电子器件是一个非常复杂的系统，其封装过程的缺陷和失效也是非常复杂的。因此，研究封装缺陷和失效需要对封装过程有一个系统性的了解，这样才能从多个角度去分析缺陷产生的原因。 1. 封装缺陷与失效的研究方法论 封装的失效机理可以分为两类：过应力和磨损。过应力失效往往是瞬时的、灾难性的；磨损失效是长期的累积损坏，往往首先表示为性能退化，接着才是器件失效。失效的负载类型又可以分为机械、热、电气、辐射和化学负载等。 影响封装缺陷和失效的因素是多种多样的， 材料成分和属性、封装设计、环境条件和工艺参数等都会有所影响。确定影响因素和预防封装缺陷和失效的基本前提。影响因素可以通过试验或者模拟仿真的方法来确定，一般多采用物理模型法和数值参数法。对于更复杂的缺陷和失效机理，常常采用试差法确定关键的影响因素，但是这个方法需要较长的试验时间和设备修正，效率低、花费高。 在分析失效机理的过程中， 采用鱼骨图（因果图）展示影响因素是行业通用的方法。鱼骨图可以说明复杂的原因及影响因素和封装缺陷之间的关系，也可以区分多种原因并将其分门别类。生产应用中，有一类鱼骨图被称为6Ms：从机器、方法、材料、量度、人力和自然力等六个维度分析影响因素。 这一张图所示的是展示塑封芯片分层原因的鱼骨图，从设计、工艺、环境和材料四个方面进行了分析。通过鱼骨图，清晰地展现了所有的影响因素，为失效分析奠定了良好基础。 2. 引发失效的负载类型 如上一节所述，封装的负载类型可以分为机械、热、电气、辐射和化学负载。 失效机理的分类 机械载荷：包括物理冲击、振动、填充颗粒在硅芯片上施加的应力（如收缩应力）和惯性力（如宇宙飞船的巨大加速度）等。材料对这些载荷的响应可能表现为弹性形变、塑性形变、翘曲、脆性或柔性断裂、界面分层、疲劳裂缝产生和扩展、蠕变以及蠕变开裂等等。 热载荷：包括芯片黏结剂固化时的高温、引线键合前的预加热、成型工艺、后固化、邻近元器件的再加工、浸焊、气相焊接和回流焊接等等。外部热载荷会使材料因热膨胀而发生尺寸变化，同时也会改变蠕变速率等物理属性。如发生热膨胀系数失配（CTE失配）进而引发局部应力，并最终导致封装结构失效。过大的热载荷甚至可能会导致器件内易燃材料发生燃烧。 电载荷：包括突然的电冲击、电压不稳或电流传输时突然的振荡（如接地不良）而引起的电流波动、静电放电、过电应力等。这些外部电载荷可能导致介质击穿、电压表面击穿、电能的热损耗或电迁移。也可能增加电解腐蚀、树枝状结晶生长，引起漏电流、热致退化等。 化学载荷：包括化学使用环境导致的腐蚀、氧化和离子表面枝晶生长。由于湿气能通过塑封料渗透，因此在潮湿环境下湿气是影响塑封器件的主要问题。被塑封料吸收的湿气能将塑封料中的催化剂残留萃取出来，形成副产物进入芯片粘接的金属底座、半导体材料和各种界面，诱发导致器件性能退化甚至失效。例如，组装后残留在器件上的助焊剂会通过塑封料迁移到芯片表面。在高频电路中，介质属性的细微变化（如吸潮后的介电常数、耗散因子等的变化）都非常关键。在高电压转换器等器件中，封装体击穿电压的变化非常关键。此外，一些环氧聚酰胺和聚氨酯如若长期暴露在高温高湿环境中也会引起降解（有时也称为“逆转”）。通常采用加速试验来鉴定塑封料是否易发生该种失效。 需要注意的是，当施加不同类型载荷的时候，各种失效机理可能同时在塑封器件上产生交互作用。例如，热载荷会使封装体结构内相邻材料间发生热膨胀系数失配，从而引起机械失效。其他的交互作用，包括应力辅助腐蚀、应力腐蚀裂纹、场致金属迁移、钝化层和电解质层裂缝、湿热导致的封装体开裂以及温度导致的化学反应加速等等。在这些情况下，失效机理的综合影响并不一定等于个体影响的总和。 3. 封装缺陷的分类 封装缺陷主要包括引线变形、底座偏移、翘曲、芯片破裂、分层、空洞、不均匀封装、毛边、外来颗粒和不完全固化等。 3.1 引线变形 引线变形通常指塑封料流动过程中引起的引线位移或者变形，通常采用引线最大横向位移x与引线长度L之间的比值x/L来表示。引线弯曲可能会导致电器短路（特别是在高密度I/O器件封装中）。有时，弯曲产生的应力会导致键合点开裂或键合强度下降。 影响引线键合的因素包括封装设计、引线布局、引线材料与尺寸、模塑料属性、引线键合工艺和封装工艺等。影响引线弯曲的引线参数包括引线直径、引线长度、引线断裂载荷和引线密度等等。 3.2 底座偏移 底座偏移指的是支撑芯片的载体（芯片底座）出现变形和偏移 如图所示为塑封料导致的底座偏移，此时，上下层模塑腔体内不均匀的塑封料流动会导致底座偏移。 影响底座偏移的因素包括塑封料的流动性、引线框架的组装设计以及塑封料和引线框架的材料属性。薄型小尺寸封装（TSOP）和薄型方形扁平封装（TQFP）等封装器件由于引线框架较薄，容易发生底座偏移和引脚变形。 3.3 翘曲 翘曲是指封装器件在平面外的弯曲和变形。因塑封工艺而引起的翘曲会导致如分层和芯片开裂等一系列的可靠性问题。 翘曲也会导致一系列的制造问题，如在塑封球栅阵列（PBGA）器件中，翘曲会导致焊料球共面性差，使器件在组装到印刷电路板的回流焊过程中发生贴装问题。 翘曲模式包括内凹、外凸和组合模式三种。在半导体公司中，有时候会把内凹称为“笑脸”，外凸称为“哭脸”。 导致翘曲的原因主要包括CTE失配和固化/压缩收缩。后者一开始并没有受到太多的关注，深入研究发现，模塑料的化学收缩在IC器件的翘曲中也扮演着重要角色，尤其是在芯片上下两侧厚度不同的封装器件上。在固化和后固化的过程中，塑封料在高固化温度下将发生化学收缩，被称为“热化学收缩”。通过提高玻璃化转变温度和降低Tg附近的热膨胀系数变化，可以减小固化过程中发生的化学收缩。 导致翘曲的因素还包括诸如塑封料成分、模塑料湿气、封装的几何结构等等。通过对塑封材料和成分、工艺参数、封装结构和封装前环境的把控，可以将封装翘曲降低到最小。在某些情况下，可以通过封装电子组件的背面来进行翘曲的补偿。例如，大陶瓷电路板或多层板的外部连接位于同一侧，对他们进行背面封装可以减小翘曲。 3.4 芯片破裂 封装工艺中产生的应力会导致芯片破裂。封装工艺通常会加重前道组装工艺中形成的微裂缝。晶圆或芯片减薄、背面研磨以及芯片粘结都是可能导致芯片裂缝萌生的步骤。 破裂的、机械失效的芯片不一定会发生电气失效。芯片破裂是否会导致器件的瞬间电气失效还取决于裂缝的生长路径。例如，若裂缝出现在芯片的背面，可能不会影响到任何敏感结构。 因为硅晶圆比较薄且脆，晶圆级封装更容易发生芯片破裂。因此，必须严格控制转移成型工艺中的夹持压力和成型转换压力等工艺参数，以防止芯片破裂。3D堆叠封装中因叠层工艺而容易出现芯片破裂。在3D封装中影响芯片破裂的设计因素包括芯片叠层结构、基板厚度、模塑体积和模套厚度等。 3.5 分层 分层或粘结不牢指的是在塑封料和其相邻材料界面之间的分离。分层位置可能发生在塑封微电子器件中的任何区域；同时也可能发生在封装工艺、后封装制造阶段或者器件使用阶段。 封装工艺导致的不良粘接界面是引起分层的主要因素。界面空洞、封装时的表面污染和固化不完全都会导致粘接不良。其他影响因素还包括固化和冷却时收缩应力与翘曲。在冷却过程中，塑封料和相邻材料之间的CTE不匹配也会导致热-机械应力，从而导致分层。 可以根据界面类型对分层进行分类 3.6 空洞 封装工艺中，气泡嵌入环氧材料中形成了空洞，空洞可以发生在封装工艺过程中的任意阶段，包括转移成型、填充、灌封和塑封料至于空气环境下的印刷。通过最小化空气量，如排空或者抽真空，可以减少空洞。有报道采用的真空压力范围为1~300Torr（一个大气压为760Torr）。 填模仿真分析认为，是底部熔体前沿与芯片接触，导致了流动性受到阻碍。部分熔体前沿向上流动并通过芯片外围的大开口区域填充半模顶部。新形成的熔体前沿和吸附的熔体前沿进入半模顶部区域，从而形成起泡。 3.7 不均匀封装 非均匀的塑封体厚度会导致翘曲和分层。传统的封装技术，诸如转移成型、压力成型和灌注封装技术等，不易产生厚度不均匀的封装缺陷。晶圆级封装因其工艺特点，而特别容易导致不均匀的塑封厚度。 为了确保获得均匀的塑封层厚度，应固定晶圆载体使其倾斜度最小以便于刮刀安装。此外，需要进行刮刀位置控制以确保刮刀压力稳定，从而得到均匀的塑封层厚度。 在硬化前，当填充粒子在塑封料中的局部区域聚集并形成不均匀分布时，会导致不同质或不均匀的材料组成。塑封料的不充分混合将会导致封装灌封过程中不同质现象的发生。 3.8 毛边 毛边是指在塑封成型工艺中通过分型线并沉积在器件引脚上的模塑料。 夹持压力不足是产生毛边的主要原因。如果引脚上的模料残留没有及时清除，将导致组装阶段产生各种问题。例如，在下一个封装阶段中键合或者黏附不充分。树脂泄漏是较稀疏的毛边形式。 3.9 外来颗粒 在封装工艺中，封装材料若暴露在污染的环境、设备或者材料中，外来粒子就会在封装中扩散并聚集在封装内的金属部位上（如IC芯片和引线键合点），从而导致腐蚀和其他的后续可靠性问题。 3.10 不完全固化 固化时间不足或者固化温度偏低都会导致不完全固化。另外，在两种封装料的灌注中，混合比例的轻微偏移都将导致不完全固化。为了最大化实现封装材料的特性，必须确保封装材料完全固化。在很多封装方法中，允许采用后固化的方法确保封装材料的完全固化。而且要注意保证封装料比例的精确配比。 4. 封装失效的分类 在封装组装阶段或者器件使用阶段，都会发生封装失效。特别是当封装微电子器件组装到印刷电路板上时更容易发生，该阶段器件需要承受高的回流温度，会导致塑封料界面分层或者破裂。 4.1 分层 如上一节所述，分层是指塑封材料在粘接界面处与相邻的材料分离。可能导致分层的外部载荷和应力包括水汽、湿气、温度以及它们的共同作用。 在组装阶段常常发生的一类分层被称为水汽诱导（或蒸汽诱导）分层，其失效机理主要是相对高温下的水汽压力。在封装器件被组装到印刷电路板上的时候，为使焊料融化温度需要达到220℃甚至更高，这远高于模塑料的玻璃化转变温度（约110~200℃）。在回流高温下，塑封料与金属界面之间存在的水汽蒸发形成水蒸气，产生的蒸汽压与材料间热失配、吸湿膨胀引起的应力等因素共同作用，最终导致界面粘接不牢或分层，甚至导致封装体的破裂。无铅焊料相比传统铅基焊料，其回流温度更高，更容易发生分层问题。 吸湿膨胀系数（CHE），又称湿气膨胀系数（CME） 湿气扩散到封装界面的失效机理是水汽和湿气引起分层的重要因素。湿气可通过封装体扩散，或者沿着引线框架和模塑料的界面扩散。研究发现，当模塑料和引线框架界面之间具有良好粘接时，湿气主要通过塑封体进入封装内部。但是，当这个粘结界面因封装工艺不良（如键合温度引起的氧化、应力释放不充分引起的引线框架翘曲或者过度修剪和形式应力等）而退化时，在封装轮廓上会形成分层和微裂缝，并且湿气或者水汽将易于沿这一路径扩散。更糟糕的是，湿气会导致极性环氧黏结剂的水合作用，从而弱化和降低界面的化学键合。 表面清洁是实现良好粘结的关键要求。表面氧化常常导致分层的发生（如上一篇中所提到的例子），如铜合金引线框架暴露在高温下就常常导致分层。氮气或其他合成气体的存在，有利于避免氧化。 模塑料中的润滑剂和附着力促进剂会促进分层。润滑剂可以帮助模塑料与模具型腔分离，但会增加界面分层的风险。另一方面，附着力促进剂可以确保模塑料和芯片界面之间的良好粘结，但却难以从模具型腔内清除。 分层不仅为水汽扩散提供了路径，也是树脂裂缝的源头。分层界面是裂缝萌生的位置，当承受交大外部载荷的时候，裂缝会通过树脂扩展。研究表明，发生在芯片底座地面和树脂之间的分层最容易引起树脂裂缝，其它位置出现的界面分层对树脂裂缝的影响较小。 4.2 气相诱导裂缝（爆米花现象） 水汽诱导分层进一步发展会导致气相诱导裂缝。当封装体内水汽通过裂缝逃逸时会产生爆裂声，和爆米花的声音非常像，因此又被称为爆米花现象。裂缝常常从芯片底座向塑封底面扩展。在焊接后的电路板中，外观检查难以发现这些裂缝。QFP和TQFP等大而薄的塑封形式最容易产生爆米花现象；此外也容易发生在芯片底座面积与器件面积之比较大、芯片底座面积与最小塑封料厚度之比较大的的器件中。爆米花现象可能会伴随其他问题，包括键合球从键合盘上断裂以及键合球下面的硅凹坑等。 塑封器件内的裂缝通常起源于引线框架上的应力集中区（如边缘和毛边），并且在最薄塑封区域内扩展。毛边是引线框架表面在冲压工艺中产生的小尺寸变形，改变冲压方向使毛边位于引线框架顶部，或者刻蚀引线框架（模压）都可以减少裂缝。 减少塑封器件内的湿气是降低爆米花现象的关键。常采用高温烘烤的方法减少塑封器件内的湿气。前人研究发现，封装内允许的安全湿气含量约为1100×10^-6（0.11 wt.%)。在125℃下烘烤24h，可以充分去除封装内吸收的湿气。 4.3 脆性断裂 脆性断裂经常发生在低屈服强度和非弹性材料中（如硅芯片）。到材料受到过应力作用时，突然的、灾难性的裂缝扩展会起源于如空洞、夹杂物或不连续等微小缺陷。 4.4 韧性断裂 塑封材料容易发生脆性和韧性两种断裂模式，主要取决于环境和材料因素，包括温度、聚合树脂的黏塑特性和填充载荷。即使在含有脆性硅填料的高加载塑封材料中，因聚合树脂的黏塑特性，仍然可能发生韧性断裂。 4.5 疲劳断裂 塑封料遭受到极限强度范围内的周期性应力作用时，会因累积的疲劳断裂而断裂。施加到塑封材料上的湿、热、机械或综合载荷，都会产生循环应力。疲劳失效是一种磨损失效机理，裂缝一般会在间断点或缺陷位置萌生。 疲劳断裂机理包括三个阶段：裂纹萌生（阶段Ⅰ）；稳定的裂缝扩展（阶段Ⅱ）；突发的、不确定的、灾难性失效（阶段Ⅲ）。在周期性应力下，阶段Ⅱ的疲劳裂缝扩展指的是裂缝长度的稳定增长。塑封材料的裂纹扩展速率要远高于金属材料疲劳裂缝扩展的典型值（约3倍）。 5. 加速失效的因素 环境和材料的载荷和应力，如湿气、温度和污染物，会加速塑封器件的失效。塑封工艺正在封装失效中起到了关键作用，如湿气扩散系数、饱和湿气含量、离子扩散速率、热膨胀系数和塑封材料的吸湿膨胀系数等特性会极大地影响失效速率。导致失效加速的因素主要有潮气、温度、污染物和溶剂性环境、残余应力、自然环境应力、制造和组装载荷以及综合载荷应力条件。 潮气 能加速塑封微电子器件的分层、裂缝和腐蚀失效。在塑封器件中， 潮气是一个重要的失效加速因子。与潮气导致失效加速有关的机理包括粘结面退化、吸湿膨胀应力、水汽压力、离子迁移以及塑封料特性改变等等。潮气能够改变塑封料的玻璃化转变温度Tg、弹性模量和体积电阻率等特性。 温度 是另一个关键的失效加速因子，通常利用与模塑料的玻璃化转变温度、各种材料的热膨胀洗漱以及由此引起的热-机械应力相关的温度等级来评估温度对封装失效的影响。温度对封装失效的另一个影响因素表现在会改变与温度相关的封装材料属性、湿气扩散系数和金属间扩散等失效。 污染物和溶剂性环境 污染物为失效的萌生和扩展提供了场所，污染源主要有大气污染物、湿气、助焊剂残留、塑封料中的不洁净例子、热退化产生的腐蚀性元素以及芯片黏结剂中排出的副产物（通常为环氧）。塑料封装体一般不会被腐蚀，但是湿气和污染物会在塑封料中扩散并达到金属部位，引起塑封器件内金属部分的腐蚀。 残余应力 芯片粘结会产生单于应力。应力水平的大小，主要取决于芯片粘接层的特性。由于模塑料的收缩大于其他封装材料， 因此模塑成型时产生的应力是相当大的。可以采用应力测试芯片来测定组装应力。 自然环境应力 在自然环境下，塑封料可能会发生降解。降解的特点是聚合键的断裂，常常是固体聚合物转变成包含单体、二聚体和其他低分子量种类的黏性液体。升高的温度和密闭的环境常常会加速降解。阳光中的紫外线和大气臭氧层是降解的强有力催化剂，可通过切断环氧树脂的分子链导致降解。将塑封器件与易诱发降解的环境隔离、采用具有抗降解能力的聚合物都是防止降解的方法。需要在湿热环境下工作的产品要求采用抗降解聚合物。 制造和组装载荷 制造和组装条件都有可能导致封装失效，包括高温、低温、温度变化、操作载荷以及因塑封料流动而在键合引线和芯片底座上施加的载荷。进行塑封器件组装时出现的爆米花现象就是一个典型的例子。 综合载荷应力条件 在制造、组装或者操作的过程中，诸如温度和湿气等失效加速因子常常是同时存在的。综合载荷和应力条件常常会进一步加速失效。这一特点常被应用于以缺陷部件筛选和易失效封装器件鉴别为目的的加速试验设计。 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

配图来自Canva可画 近年来“农产品上行”、“数字农业”等词语，开始频繁出现在巨头的“双11”购物节上。农业数字化也作为一个重要议题，被越来越多的巨头所提及，在此背景下巨头在数字农业上的动作也越来越频繁了。 去年10月，阿里正式成立阿里数字农业事业部，开始全力推进其数字农业项目；而在此之前，拼多多则举起了“农货上行”大旗，全力推动农产品的产销对接；京东也与多地政府建立了合作关系，推动其数字农业技术落地。从各家的动作来看，对于数字农业各家巨头都是势在必得。但在具体的发力点上，各家却有明显不同。 拼多多全力推动农货上行 在三大电商平台之中，拼多多对推动农产品上行最为热衷，而如今它也是业内最大的农产品上行平台。拼多多能够取得如此成绩，与多方面的因素有关。 首先，我国农村电商的线上流通率非常低。根据艾媒咨询的数据显示，截至2019年，中国农产品流通各渠道占比调查中，农贸市场占比最高达到51.8%，超市占比位列第二位达36.4%，位列第三的是个体商贩占比为8.5%，其次是电商渠道，仅有2.8%。农产品线上渠道占比如此之低，给后来者发力线上创造了机会。 其次，拼多多在农货上行方面拥有先发优势。早在2017年之前，拼多多就开始推动农产品上行，助力农产品产销对接。这种先行一步的布局，让拼多多吃到了下沉市场崛起的巨大电商红利，从而让其迅速在农货上行方面建立了竞争优势。 比如，拼多多构建的体系化、系统化的助农模式，就为其推动农货上行提供了诸多助力。例如，针对传统农产品流通链路长、信息不对称等痛点问题，拼多多推出了“产地直连”的新模式，拉平了产地和销地之间的信息差，很好地保证了供需平衡；针对农村人才不足的问题，推出了多多大学，帮助培养新农人、新农商……正是凭借这一体系化的举措，帮助拼多多奠定了其农货上行第一平台的行业地位。 据拼多多《2019年农产品上行发展报告》显示，拼多多2019年农产品电商销售额达到了1364亿元，同比上涨了109%，据预计2020年，拼多多农产品电商销售总额将会达到2500亿元，仍将继续保持高速增长，其在行业的地位也将愈加稳固。 阿里押注全链路农业数字化改造 与拼多多不同，阿里则提出了全链路农业数字化改造的新设想。所谓“全链路数字化改造”是指通过把控从上游到终端的整个环节，并将每一个环节都进行数字化改造，从而将农业整个从产到销的过程，都纳入到数字化进程之中。阿里之所以选择用这样的方式参与农业改造，背后则有着多方面的考虑。 一方面，我国传统农业各个环节都存在很多的问题，数字化改造的空间很大。比如，我国农业的“小农”形态，使得农业生产的集约化程度很低，这给农业的产业化带来了一些困难；其次，由于缺乏很好的农业供应链，农产品在流通环节耗损严重，这些都严重制约传统农业的进一步发展，而数字化技术则对改善这一问题多有助益。 另一方面，阿里在数字化方面积累了雄厚的技术基础，具备很好的数字化改造的能力。比如，阿里云旗下的数字农业ET大脑，就能够为农业数据的打通提供技术支持，阿里云旗下的AI、区块链技术等，也为农业的智慧化、可溯源追踪提供技术解决方案。 而阿里之所以想要做全链路农业数字化，则与农业的产业链较长不无关系。农业从产地到流通再到销售，中间经历各种环节。而正是因为这个原因，任何单一环节的数字化，对农业数字化改造的效果都不会太理想，这也正是阿里投身全链路农业数字化的原因。 为了达成这个目的，阿里在产源地数字化（基地模式）的基础上，又在全国范围内建立了打通供应链的产地仓，来加速流通环节的数字化。据悉，目前阿里已经在全国范围内建立了5个产地仓和十几个销地仓，进而形成了覆盖全国的仓网群。 由此，阿里已经形成了从田间地头（基地模式），到运输流通（产地仓），再到淘宝、天猫、盒马前端零售的全链路农业数字化闭环生态。从这里不难看出，在做数字农业上，阿里有着全盘的谋划和全方位的布局。 京东侧重技术赋能 与前两者不同，京东的农业数字化主要是从产业端开启的，其农业数字解决方案也主要是聚焦于产业端的，更侧重于通过技术解决方案来给行业赋能。 京东开启数字农业，最早源于此前京东数科旗下的数字农牧。早前京东数科，偶然间获得了一个保险客户的需求：他们想要准确识别不同的死猪，以避免养殖户用同一头猪骗保，京东由此推出了一个“猪脸识别”的数字技术解决方案，并以此为契机切入了智能养殖业务，投了一家山黑猪养殖厂商，开启了数字化养殖的试验。 此后，京东数字农牧依托于大数据、人工智能、IoT、区块链等方面的数字科技能力，自主研发并推出集成“神农大脑（AI）”+“神农物联网设备（IoT）”+“神农系统（SaaS）”的智能养殖解决方案，独创养殖巡检机器人、饲喂机器人、3D农业级摄像头等先进设备，打通养殖全产业链，真正实现了智能化、自动化、精细化生产。 这套技术真正从生产环节，改变了传统农业自动化程度低、生产数据难采集、人工成本大等痛点问题，为数字农牧产业的降本增效和结构化转型，注入了强劲的科技动能。 在数字化养猪试验取得实效之后，京东又将智能养猪，拓展到智能养牛、智能水产养殖等多个养殖领域。之后，京东又以无人机农林植保服务为切入点，整合京东集团物流、金融、生鲜、大数据等能力，搭建智慧农业共同体，同时打造旗下首个农场品牌“京东农场”，由此形成了完整的数字农业版图。 今年以来，京东又与四川地方政府建立了合作，建立农业大数据中心，探索农产品质量安全标准以及数字农业的场景落地。总的来看，京东在数字农业领域涉足甚广，但目前为止京东在农业方面的应用落地，还主要集中在技术赋能方面。 新农业大战即将开打？ 随着三大电商平台，同时汇聚于数字农业领域。外界就不时传出一种声音认为，三家电商企业将会在数字农业领域掀起新的大战。但当前来看，这种情况发生的概率很小。 一方面，目前我国的农业数字化水平还很低，目前整个市场也还处于增量博弈的阶段。据中国信息通信研究院7月3日发布的《中国数字经济发展白皮书（2020年）》显示，2019年，我国数字经济增加值规模为35.8万亿元，占GDP比重达36.2%。而在三大产业中，数字经济在农业中占比7.30%，在工业和服务领域，则已分别占比18.30%和35.90%。这意味着在三大产业中，农业领域的数字化潜力最大。 而农业数字化巨大的市场空间，在短期之内很难被某一家巨头所独享。因此，对于目前各家电商企业来说，其核心的任务还是以拓展市场增量为主，现在相互触碰的可能性还比较小。 另一方面，各家在数字农业的布局上也有差异，开打的动机并不明显。阿里做的是重投入的产业链数字化改造，拼多多目前还主要是聚焦农产品上行、注重的是渠道畅通，而京东农牧则主要是通过输出技术解决方案，来为农牧业发展赋能，相对而言更偏重于技术应用。从三者之间的发展情况来看，各家之间的差异性明显，因此各家目前开打的可能性并不高。 因此，现在谈巨头之间的数字农业大战，还为时过早。不过，随着各家巨头农业数字化的步伐加速，接下来各家之间交叉的点必然会越来越多，而到了那时彼此之间的冲击，也就不可避免了。

12月28日晚间，经历多次预告的小米11终于揭开了“面纱”，其中最为让网友关注的几个问题也被逐一披露。 01 还附带充电器吗？ 发布会上，雷军表示，小米11将拥有标准版和套装版两版，前者不包含充电器，后者则附带55W小米GaN充电器，两者定价均为3999元。   雷军强调，为了响应苹果对于环保的响应，小米本决定同样不在包装盒内附带充电器并以4098元定价，但在经过，特将两者定价都定为3999元。   不过，他仍然建议拥有多余充电器的用户继续选购标准版，响应环保的号召。   前几日，在雷军爆料本次小米11将不再包装盒内附带充电器后，引发网友大面积负面评论，实际上当时就有网友猜测小米或将本体和充电器拆分为两者，而本次发布会应验了这一猜想。   02 定价是否会比小米10高？ 定价方面，小米11与小米10的价格持平，有媒体戏称“如此定价，雷军都肉疼了”。具体来说，小米11拥有8+128GB、8+256GB、12+256GB三种可选型号，分别售价3999元、4299元、4699元。   需要注意的是，标准版与55W小米GaN充电器套装版同价，另外12+256GB版还拥有雷军签名版，也与标准版同价。 03 屏幕对比iPhone12如何？ 屏幕上，小米11正面搭载6.81英寸AMOLED屏幕，为四曲面柔性屏，使用E4发光材料，采用2K超视网膜屏，拥有120Hz高刷新率，支持480Hz触控采样率，1500nit峰值亮度，拥有8192细腻调光。   根据雷军的介绍，该屏幕是市售手机最强屏幕，刷新了评价机构DisplayMate 13项新记录，该机构赋予小米11屏幕最高A+级别。   发布会现场，雷军特别展示出一张横向对比iPhone 12 Pro Max屏幕的图片，“很多人认为iPhone 12系列的屏幕非常好，实际上通过参数对比高下立判”。   04 核心配置如何做到超高的性能？ Arm公司全新一代Cortex-X1 高性能CPU正在成为下一代旗舰手机性能争霸战中的秘密武器。12月28日发布上市的小米11手机，搭载了内置Cortex-X1的高通骁龙888处理器。这也是市面上首款使用Cortex-X1的智能手机。为此，小米董事长雷军甚至提前1周在自己的微信公众号中为小米11打call。   为了在下一代竞争激烈的移动处理器市场上保持优势，Arm公司于2020年5月发布了Cortex-X1。这是Arm全新旗舰移动处理器架构中的第一款产品。Cortex-X1在Arm公司内部项目研发代号“赫拉（Hera）”。希腊神话中的天后之名，赋予这一项目足够的优先地位。Arm对其优异性能的期待也可见一斑。   带宽提升两倍，峰值性能拉高三成 与同期发布的Cortex-A78以及其他所有Cortex家族CPU都不同的是，Cortex-X1及其后续产品在设计中以获取最佳峰值性能为目标，没有采用平衡性能、功耗和面积限制三大要素的传统思路，最终造就了这款当下Cortex家族中性能最强的超大核产品。   Cortex-X1在架构设计上与Cortex-A78极为相似，二者共享了许多基础设计改进。同时，基于5nm的先进工艺制程，Cortex-X1在微架构上应用了多项创新。   Cortex-X1包含有四个128位NEON单元及64kB的一级缓存、最大1MB二级缓存和高达8MB的三级缓存。相比之下，常规升级的Cortex-A78有两个128位NEON单元：最高不超过64kB的一级缓存和4MB的三级缓存。Cortex-X1以2倍于Cortex-A78的带宽极大提升了性能输出，在同频情况下性能峰值比Cortex-A78提高了22%，相比上一代Cortex-A77拉高30%。   得益于增加了Neon引擎的计算资源，与Cortex-A77和Cortex-A78相比，Cortex-X1在ML（机器学习）和AI（人工智能）性能上性能提高了2倍。 CXC模式提供深度定制，未来发力高性能市场 Cortex-X1架构支持DynamIQ技术，可以和A78等组成多丛集异构CPU，通过提高峰值性能来实现更大的可扩展性。例如，在基于ARM的高性能移动处理器上可以集成1个Cortex-X1超大核加上3个Cortex-A78大核和4个Cortex-A55小核，从而获得比上一代产品提高30％的性能。   采用类似配置的智能手机在需要处理高性能重载APP时，可以激活X1大核心获取最高性能，提升处理器表现；反之则以中、小核应对一般任务，让X1进入休眠状态，降低能耗。这可以为智能手机带来性能和能耗上的良好平衡，并保持拥有强大的运算能力。   为了更好协调不同客户的设计能力和适配能力， Cortex-X1采取了ARM和厂商协作定制化的“CXC”（Cortex-XCustomprogram）模式。在这一模式下，面向这款旗舰移动处理器的芯片厂商在研发初期就将深度参与进来，将终端厂商的性能需求导入进来，以满足其客户对更高性能的需求。   Cortex-X1在小米11手机之外，已经引起大多数国内5G旗舰手机品牌的兴趣。在移动生态之外，Cortex-X1的应用场景同样丰富多样。搭载多核Cortex-X1的解决方案可以结合于Windows-on-Arm生态系统中，参与未来高性能计算市场中的建设。   2020年，Arm架构在数据中心、超级计算机、边缘计算等应用领域都取得了重大突破，并逐渐发展成唯一的全平台主流架构。随着应用的逐步铺开，Cortex-X1未来将成为Arm巩固移动终端优势，持续向高端市场拓展的一张新王牌。 END 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

“ 今天无聊来撩一下MySQL事务，希望你们喜欢~ 目录 概念 隔离性与隔离级别 事务隔离的实现 事务启动方式 MVCC工作原理 总结 一、概念 事务到底是什么东西呢？想必大家学习的时候也是对事务的概念很模糊的。接下来通过一个经典例子讲解事务。 银行在两个账户之间转账，从A账户转入B账户1000元，系统先减少A账户的1000元，然后再为B账号增加1000元。如果全部执行成功，数据库处于一致性； 如果仅执行完A账户金额的修改，而没有增加B账户的金额，则数据库就处于不一致状态，这时就需要取消前面的操作。 这过程中会有一系列的操作，比如余额查询，余额做加减法，更新余额等，这些操作必须保证是一个整体执行，要么全部成功，要么全部失败，不能让A账户钱扣了，但是中途某些操作失败了，导致B账户更新余额失败。这样用户就不乐意了，银行这不是坑我吗？ “ 事务就是要保证一组数据库操作，要么全部成功，要么全部失败。 在MySQL中，事务支持是在引擎层实现的。你现在知道，MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。 比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。 接下来会以InnoDB为例，抽丝剥茧MySQL在事务支持方面的特定实现。 二、隔离性与隔离级别 提到事务，你肯定会想到ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性），接下来我们就要讲解其中的I，也就是隔离性。 当数据库上存在多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题，为了解决这些问题，就有了隔离级别的概念。 我们知道，隔离级别越高，效率就越低，因此我们很多情况下需要在二者之间找到一个平衡点。 SQL标准的事务隔离级别包括： 读未提交（read uncommitted） 读提交（read committed） 可重复读（repeatable read） 串行化（serializable ） 下面我逐一为你解释： 读未提交：事务中的修改，即使没有提交，对其他事务也都是可见的，事务可以读取未提交的数据，也被称为脏读。这个级别会导致很多问题，从性能上来说也不会比其他隔离级别好很多，但却缺乏其他级别的很多好处，一般实际应用中很少用，甚至有些数据库内部根本就没有实现。 读已提交：事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的，这个级别有时候也叫做不可重复读（Nonrepeatable Read）,因为同一事务中两次执行同样的查询，可能会得到不一样的结果 可重复度：同个事务中多次查询结果是一致的，解决了不可重复读的问题。此隔离级别下还是无法解决另外一个幻读（Phantom Read）的问题，幻读是指当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，之前的事务再次读取该范围的记录时，会产生幻行 串行化：顾名思义是对于同一行记录，写会加写锁，读会加读锁。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。 对于上面的概念中，可能 读已提交 和可重复读比较难理解，下面会用一个例子说明这种集中隔离级别。假设数据表T中只有一列，其中一行的值为1，下面是按照时间顺序执行两个事务的行为。 mysql> create table T(c int) engine=InnoDB; insert into T(c) values(1); 接下来讲解不同的隔离级别下，事务A会有哪些不同的返回结果，也就是图里面V1、V2、V3的返回值分别是什么。 若隔离级别是读未提交， 则V1的值就是2。这时候事务B虽然还没有提交，但是结果已经被A看到了。因此，V2、V3也都是2。 若隔离级别是读提交，则V1是1，V2的值是2。事务B的更新在提交后才能被A看到。所以， V3的值也是2。 若隔离级别是可重复读，则V1、V2是1，V3是2。之所以V2还是1，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。 若隔离级别是串行化，则在事务B执行“将1改成2”的时候，会被锁住。直到事务A提交后，事务B才可以继续执行。所以从A的角度看， V1、V2值是1，V3的值是2。 在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在可重复读隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。 在读提交隔离级别下，这个视图是在每个SQL语句开始执行的时候创建的。这里需要注意的是，读未提交隔离级别下直接返回记录上的最新值，没有视图概念；而串行化隔离级别下直接用加锁的方式来避免并行访问。 注意一下，每种数据库的行为会有所不一样，Oracle数据库的默认隔离界别是读提交，因此，当我们需要进行不同数据库种类之间迁移的时候，为了保证数据库隔离级别的一致，切记将MYSQL的隔离级别设置为读提交。 配置的方式是，将启动参数transaction-isolation的值设置成READ-COMMITTED。你可以用show variables来查看当前的值。 每种隔离级别都有它自己的使用场景，你要根据自己的业务情况来定。我想你可能会问那什么时候需要“可重复读”的场景呢？我们来看一个数据校对逻辑的案例。 假设你在管理一个个人银行账户表。一个表存了每个月月底的余额，一个表存了账单明细。这时候你要做数据校对，也就是判断上个月的余额和当前余额的差额，是否与本月的账单明细一致。你一定希望在校对过程中，即使有用户发生了一笔新的交易，也不影响你的校对结果。 这时候使用可重复读隔离级别就很方便。事务启动时的视图可以认为是静态的，不受其他事务更新的影响。 三、事务隔离的实现 接下来以可重复度来展开事务隔离具体是怎么实现的。 在MySQL中，实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。 假设一个值从1被按顺序改成了2、3、4，在回滚日志里面就会有类似下面的记录。 可以看到当前值是4，从图中可以看到在查询的时候，不同时刻启动的事务会有不同的read-view。如图中看到的，在视图A、B、C里面，这一个记录的值分别是1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）。 对于read-view A，要得到1，就必须将当前值依次执行图中所有的回滚操作得到。同时你会发现，即使现在有另外一个事务正在将4改成5，这个事务跟read-view A、B、C对应的事务是不会冲突的。 你一定会问，回滚日志总不能一直保留吧，什么时候删除呢？ 这是肯定不能一直保留的，在不需要的时候才删除。系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志会被删除。 那么什么时候才不需要了呢？就是当系统里没有比这个回滚日志更早的read-view的时候。 基于上面的说明，我们来讨论一下为什么建议你尽量不要使用长事务。 长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。 在MySQL 5.5及以前的版本，回滚日志是跟数据字典一起放在ibdata文件里的，即使长事务最终提交，回滚段被清理，文件也不会变小。我见过数据只有20GB，而回滚段有200GB的库。最终只好为了清理回滚段，重建整个库。 除了对回滚段的影响，长事务还占用锁资源，也可能拖垮整个库，这个我们会在后面讲锁的时候展开。 四、事务启动方式 MySQL的事务启动方式有以下几种： 显式启动事务语句， begin或 start transaction。配套的提交语句是 commit，回滚语句是 rollback。 set autocommit=0，这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个 select语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动执行 commit或 rollback语句，或者断开连接。 有些客户端连接框架会默认连接成功后先执行一个set autocommit=0的命令。这就导致接下来的查询都在事务中，如果是长连接，就导致了意外的长事务。 因此，我会建议你总是使用set autocommit=1, 通过显式语句的方式来启动事务。 但是有的开发同学会纠结多一次交互的问题。对于一个需要频繁使用事务的业务，第二种方式每个事务在开始时都不需要主动执行一次 begin，减少了语句的交互次数。如果你也有这个顾虑，我建议你使用commit work and chain语法。 在autocommit为1的情况下，用begin显式启动的事务，如果执行commit则提交事务。如果执行 commit work and chain，则是提交事务并自动启动下一个事务，这样也省去了再次执行begin语句的开销。同时带来的好处是从程序开发的角度明确地知道每个语句是否处于事务中。 你可以在information_schema库的innodb_trx这个表中查询长事务，比如下面这个语句，用于查找持续时间超过60s的事务。 select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60 五、MVCC工作原理 可重复读隔离级别下，事务在启动的时候就“拍了个快照”。请注意，这个快照是基于整个库的，这时候你肯定觉得不可思议，如果一个库上百G的数据，那么我启动一个事务，那MYSQL岂不是要将上百G的数据拷贝出来，这个过程不是非常慢吗？但是为什么我们平时并没有感觉到它️呢？ 事实上，我们并不需要拷贝出这100G的数据。 我们先来看看这个快照是怎么实现的。InnoDB里面每个事务有一个唯一的事务ID，叫作transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。 每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记为row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。这也说明了，数据表中的一行记录，可能存在多个版本（row）,每个版本有自己的row_trx_id. 下面用一张图说明一个记录被多个事务连续更新后的状态，如下图所示：…

编排 | strongerHuang 微信公众号 | 嵌入式专栏 不知道大家写程序、画板子时，版本号是怎么命名的？ 最常见的就是V1.0.0这种简单的形式命名，复杂一点就是带有日期、后缀等版本信息。 当然，版本号命名规范就像代码规范一样，不同公司、不同岗位的规范不同。 下面就来简单说下关于版本号命名的常见规范。 1、通用版本命名规范 这里分享一种通用的版本命名规范，格式： 主版本号.子版本号.修订版本号.日期_版本阶段 比如：V1.2.3.20201228_rc 说明： 第一位（1）：主版本号。 当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。 第二位（2）：子版本号。 当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。 第三位（3）：修订版本号。 一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。 日期版本号（20201228）： 用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。 希腊字母版本号(rc)： 此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。 软件版本阶段说明： Base版: 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。 Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。 Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。 RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。 Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。 阶段名称 阶段标识 阶段名称 阶段标识 需求控制 a 设计阶段 b 编码阶段 c 单元测试 d 单元测试修改 e 集成测试 f 集成测试修改 g 系统测试 h 系统测试修改 i 验收测试 j 验收测试修改 k 2、其他版本命名规范 不同的软件，其版本命名会不同，比如我前几天分享的《Keil MDK 和 IAR EARM发展历程及历史版本下载》你就会发现： Keil MDK版本命名为：V5.33 （只有主版本和次版本） 而IAR EWARM版本命名为：V8.50.9.33462（通过序列号代替日期） 其实，绝大部分软件的主版本和次版本才是关键，其它修订版本、日期版本这些因软件而已。 像微信、QQ、支付宝、抖音这些大家常用的APP软件版本号，你会发现，也是类似方法命名。 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

作者 | strongerHuang 微信公众号 | 嵌入式专栏 STM32Cube HAL出来六七年了，还是有很多初学者没有适应，今天就分享一个读者问到的关于中断处理的问题。 很多人都知道STM32CubeMX这套工具的一个目的：减少开发者对STM32底层驱动的开发时间，把重心放在应用代码上。 但是，STM32CubeMX只是生成了底层驱动的初始化代码。所以，我们还需要掌握：应用层代码如何调用HAL库函数（API接口），以及HAL库中断处理机制等相关知识。 HAL库牵涉的内容较多，下面简单描述一下HAL库中断处理，以及相关的回调函数。 1HAL库中断处理机制 之前使用标准外设库开发时，中断程序（函数）由我们自己实现。 而HAL库的中断处理函数是按照HAL处理机制来实现，如USART1，统一由HAL_UART_IRQHandler来进行处理，如下图： 其它大部分外设（TIM、SPI、CAN…）中断都类似，HAL进行统一处理。 也就是说，HAL已经帮我们把中断处理函数写好了，我们只需要调用相应函数来编写应用程序就行了。 HAL_xxx_IRQHandler里面做了哪些处理？ 我们以STM32F1的HAL_UART_IRQHandler为例： void HAL_UART_IRQHandler(UART_HandleTypeDef *huart){ uint32_t isrflags = READ_REG(huart->Instance->SR); uint32_t cr1its = READ_REG(huart->Instance->CR1); uint32_t cr3its = READ_REG(huart->Instance->CR3); uint32_t errorflags = 0x00U; uint32_t dmarequest = 0x00U; /* If no error occurs */ errorflags = (isrflags & (uint32_t)(USART_SR_PE | USART_SR_FE | USART_SR_ORE | USART_SR_NE)); if(errorflags == RESET) { /* UART in mode Receiver -------------------------------------------------*/ if(((isrflags & USART_SR_RXNE) != RESET) && ((cr1its & USART_CR1_RXNEIE) != RESET)) { UART_Receive_IT(huart); return; } } /* If some errors occur */ if((errorflags != RESET) && (((cr3its & USART_CR3_EIE) != RESET) || ((cr1its & (USART_CR1_RXNEIE | USART_CR1_PEIE)) != RESET))) { /* · ·删减了部分代码 · */ } /* End if some error occurs */ /* UART…

本项目基于前面开源的快速的将项目里的RTOS替换为RT-Thread(RT-Thread甲醛测试仪)。在软件上只改动了核心检测部分以及部分界面，在操作逻辑风格上与前面这个项目基本相同，这就体现了软件代码复用价值的威力了，上一个开源项目文章链接如下： 快速的将项目里的RTOS替换为RT-Thread(RT-Thread甲醛测试仪) 项目视频操作展示效果：(Powe by RT-Thread nano) 项目图片展示效果： 项目开源仓库 个人 07.rtt_smart_farming https://gitee.com/morixinguan/rt-thred-demo 1、硬件平台(小熊派) 2、支持的RT-Thread版本 目前仅支持RT-Thread Nano，后续计划适配RT-Thread完整版。 RT-Thread Nano架构 RT-Thread完整版架构 3、软件组成 3.1、软件框架图 4、功能说明 等等可拓展会在后续持续维护和加入。 5、软件版本 发布版本 描述 [V1.0.0] 初次发布，完成基本功能及相关功能和稳定性验证 6、问题反馈 欢迎提Issues的形式向我的个人仓提交问题和BUG报告，本项目会持续进行维护和升级。 7、版权和许可 本项目遵循Apache License v2.0开源协议。鼓励代码共享和尊重原作者的著作权，可以自由的使用、修改源代码，也可以将修改后的代码作为开源或闭源软件发布。 8、结尾 本节代码已同步到码云的代码仓库中, 项目开源仓库： 个人 git clone OLED液晶显示 支持灵敏度三档可调 支持用户密码权限管理功能 支持外部串口Finsh命令行调试 支持用户自由设置设备运行时间 支持SD卡剩余存储容量提示功能 支持核心设备参数SD卡INI文件存储功能 主页面实时显示传感器数值与UI交互逻辑 支持WIFI、4G、NBIOT无线数据上传(待完成) 支持声光报警，可通过配置实现(由于平台限制,目前仅支持LED报警) 具有数据存储及查询功能，可以存储数据超过100万条或以上(仅完成存储) 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

前言 随着互联网的快速发展，越来越多的云建站平台快速崛起，不可避免的就是自定义可视化设计，如何不通过开发就能够简单快速的搭出一个可用的页面就成了大家头痛的问题，但是从零开始开发设计一套可视化设计功能并不是一个简单的事情，还好有很多开源的可视化设计项目/组件可以供我们使用，今天我们就来看看这些开源可视化设计项目。 易用的跨组件体系的表单渲染引擎 – 通过 JSON Schema 快速生成自定义表单配置界面 Github Star 数 1938 ， Github 地址：https://github.com/alibaba/form-render/stargazers 官方文档地址：https://x-render.gitee.io/form-render协议： 遵循 MIT 协议 请自由地享受和参与开源 如上图，使用 Schema 编辑器 快速生成可实现低上手成本、快速搭建 支持 Ant Design 和 Fusion Design 主流的视觉主题 使用 JSON Schema 标准协议描述表单配置，并搭配丰富类型且可扩展的组件 支持 1 排 N、横纵排、支持对象无限嵌套、自定义正则校验、自定义样式组件、列表拖拽等特性 已在阿里云、淘宝、天猫、飞猪、亚博科技、安全智能、新零售行业工作台、人工智能实验室等多 BU 多场景使用，简单使用同时支持复杂场景使用 使用上有详细文档，维护上有专人支持 Element UI表单设计及代码生成器，可将生成的代码直接运行在基于Element的vue项目中；也可导出JSON表单，使用配套的解析器将JSON解析成真实的表单。 GiteeStar 数 1.3K， Gitee地址：https://gitee.com/mrhj/form-generator?_from=gitee_search 演示地址：https://mrhj.gitee.io/form-generator/#/协议： 遵循 MIT 协议 f-render 是基于 vue-ele-form 开发的可视化表单设计工具, 适用于 各种流程引擎和动态表单项目，大大节省你的开发时间； GiteeStar 数 1.1K， Gitee地址：https://gitee.com/dream2023/f-render?_from=gitee_search 演示地址：https://dream2023.gitee.io/f-render/协议： 未声明 基于VUE+JsPlumb的流程设计器 Gitee Star 数 1938 ， Gitee地址：https://gitee.com/xiaoka2017/easy-flow 演示地址：http://xiaoka2017.gitee.io/easy-flow/#协议： 符合项目package.json中使用的插件中规定的协议即可 功能介绍 支持拖拽添加节点 点击线进行设置条件 支持给定数据加载流程图 支持画布拖拽 支持连线样式、锚点、类型自定义覆盖 支持力导图 免责声明：本文内容由21ic获得授权后发布，版权归原作者所有，本平台仅提供信息存储服务。文章仅代表作者个人观点，不代表本平台立场，如有问题，请联系我们，谢谢！

你好，我是 yes。 在之前的文章已经提到了 RPC 的核心，想必一个 RPC 通信大致的流程和基本原理已经清晰了。 这篇文章借着 Dubbo 来说说微内核这种设计思想，不会扯到 Dubbo 某个具体细节实现上，和 Dubbo 强相关的内容会在之后的文章写到。 所以今天的重点在微内核，而这个概念我最早是从操作系统那里得知，不过操作系统的微内核和 Dubbo 相关的微内核又不太一样。 Dubbo 的微内核广义上的微内核，而操作系统只是针对内核实现。 这么说你肯定不清楚，别急，听我慢慢道来。 我们先看看操作系统的微内核。 操作系统中的微内核 在维基百科上搜索微内核出现的就是： 在计算机科学中，微内核（英语：Microkernel，μ-kernel），是一种内核的设计架构，由尽可能精简的程序所组成，以实现一个操作系统所需要的最基本功能，包括了底层的寻址空间管理、线程管理、与进程间通信。 这个词条归类在操作系统技术下，所以这里的微内核指的就是操作系统的内核设计，与之对应的是宏内核架构。 Linux 就是宏内核架构。 操作系统我们都知道它是一个中间层，为我们管理底层的硬件资源，为上层服务提供接口。 提供进程管理、内存管理、文件系统、进程通信等功能。 像 Linux 这样的宏内核设计是把这些功能都作为内核来实现，而微内核则仅保留最基础的功能。 比如就留下进程的管理、内存管理等，把文件管理等功能剥离出去，变成用户空间的独立进程来提供服务。 来看下这个维基百科上的这个图应该就很清晰了。 宏内核中的一些功能在微内核架构上都被独立到用户态中，这样内核代码量就少了。 代码少了潜在的 bug 就少，出了问题也更容易排查。 系统也就更加稳定，不易奔溃，因为那些服务从内核中移除，在用户空间运行着，如果出了故障，内核重启这个服务就好了，不会像之前那样整个内核 GG。 拿显卡驱动来说，出问题就蓝屏，这要是微内核设计就可以重启显卡驱动。 听起来好像微内核很好啊？并不是，接下来就说说微内核的缺点。 首先是性能问题。 因为很多功能作为独立进程放到用户空间运行了，所以宏内核时的函数调用就变成了进程间调用，涉及进程间的通信，还会伴随着内核态和用户态的来回切换，我们知道这种上下文切换时比较耗时的。 这性能的问题就有点大了。 然后微内核设计没那么简单，想要灵巧、减少耦合、提高可移植性就需要好好的设计，按照林纳斯的话来说：“如果 GNU 内核(微内核架构)早在去年春天完成了，我压根不会开始我的项目(Lniux)。” GNU Hurd 采用微内核架构，设计过于精巧，研发速度缓慢，性能长期无法提升。 当年林纳斯还和 Minix 的作者安德鲁，对操作系统的宏内核和微内核的好坏进行了一波网络口水战。 我们来回顾一下那段历史，挺有意思的。 因为 AT&T 把 Unix 商业化了，大学不能免费使用 Unix，身为大学教授的安德鲁为了教学自己搞了个操作系统，即 Minix。 安德鲁 当时的学术风潮是微内核架构，把核心功能模块化，划分为几个独立的进程，运行在不同的地址空间提高了代码的可移植和系统的安全性。 所以 Minix 就是按微内核架构编写的，当然还有上述提到的 GNU Hurd。 而林纳斯那时候读大学，他祖父送了他一台 Intel 80386，林纳斯也看到了安德鲁的教科书，根据书上的内容写出了 Linux。 林纳斯 不过没有按照微内核的设计，而是跟 Unix 一样采用了宏内核架构。 安德鲁教授看到了 Linux ，然后在 comp.os.Minix 上批评道：宏内核的设计是有害的。 Linux 内核耦合度太高，完全是为了 Intel 80386 而设计的，处理器架构进化很快的，操作系统应该都具备可移植性。 安德鲁还提到：都1991年了还用宏内核来设计操作系统，这是一种巨大的退步。 林纳斯在一天之后进行了反击，他说 Minix 设计上有缺陷，从哲学和美学角度来看微内核确实好，但是你看 GUN Hurd 到现在还没开发出来。 然后操作系统本来就依靠硬件的特性，所以内核本身不需要过度具备可移植性，应用程序的可移植性才重要，Linux 比 Minix 好移植多了。 而且 Linux 本来就是为我自己做的，所以契合 80386，如果要移植到别的平台，代码都是开源的(Minix 源码当时得买)，想要的人自己做咯。 安德鲁也做了一波回应：Minix 有局限性是因为我是教授，因为大部分学生都只能在低配的机器上使用，所以系统的硬件需求得足够低，虽然你 Linux 是免费的，但是需要的硬件贵呀。 其实可以看到，两者并没有对宏内核和微内核的技术细节的进行深入探讨，而是抓住对方的：你这 Minix 代码还要收费，你这 Linux 需要的硬件这么贵来进行“攻击”，所以称之为口水战。 反正口水战之后双方都没有改变各自的设计，不过林纳斯有引进微内核的思想来改进代码，也改善了可移植性。 微内核市面上设计成功的有 QNX，黑莓手机就是用这个操作系统，车用市场也几乎都用 QNX 系统。 黑莓手机 这手机很多年前我用过，当时觉得有点东西的。 宏内核的话就提个…