搜索[全栈管理]结果-低调大师优秀个人博客

大麦 Android 选座场景性能优化全解析

选座场景提供了BaseLoader、策略性Cache对全场景进行数据预加载、内存缓存管理，通过对软引用的使用，即保持了静态数据高效可复用，也避免由于内存紧张而出现强未使用态的强引用静态数据无法及时释放的情况

2022-11-15

Ubuntu 官方支持全志 RISC-V SBC

LicheeRV是基于全志D1-H芯片（阿里平头哥C906 RISC-V CPU）设计的SBC，值得一提的是，这款SBC核心板只是比普通硬币大一点，比普通的手表和Airpods耳机仓都要小。

2022-11-07

RustDesk Nightly 发布，全平台远程桌面控制

RustDesk是一款开源远程桌面软件，支持所有主流操作系统。应对广大粉丝的强烈要求，RustDesk 正式发布 Nightly Build，每日格林威治时间零点构建发布。相比上个稳定版本，此版本包含很多变化，尤其是使用 Flutter 重构前端，以及 Wayland 支持。

2022-10-24

研发需求拆分的全流程详解 | 敏捷实践

本期内容将继续揭秘敏捷开发中的需求拆分全流程，建议收藏⭐先码后看。需求拆分第二招：用户故事切分流程图听上去似乎与「如何把大象🐘放进冰箱里」有异曲同工之妙，但它并不是什么「废话文学」。

2022-07-22

Open Harmony移植：build lite配置目录全梳理

本文分享自华为云社区《移植案例与原理 - build lite配置目录全梳理》，作者：zhushy 。

2022-05-06

作者：刘天宇(谦风) 系列文章回顾《向工程腐化开炮 | proguard治理》《向工程腐化开炮 | manifest治理》《向工程腐化开炮：Java代码治理》《向工程腐化开炮｜资源治理》《向工程腐化开炮｜动态链接库so治理》。本文为系列文章最后一篇文章，聚焦于整体治理思路，方案设计，以及背后的思考与取舍。工程质量是任何一个产品，能够快速、高效、稳定地进行业务功能迭代的基础，也是给用户带来良好产品使用体验不可忽视的因素，更是任何一位优秀工程师的期望和卓越追求。而工程腐化，却是任何一个大型工程都不得不面对的问题，其广泛而细碎，隐藏在不易被察觉的“角落”，对工程方方面面均有所影响。工程腐化与工程本身相伴相生，贯穿工程生命周期的每一阶段，时间、人、代码、流程、规则，任一因素的变化都会导致腐化发生，从觉察到修补、系统性分析到应对方案制定、再到坦然接受与常态化可持续治理，本文对此逐一道来。源起在一个工程趋于成熟之前，腐化问题深深隐藏于代码中，一般会明显降低研发效率，但是引发的线上问题却并不频繁，因此很容易当成单点问题进行修复。但是随着腐化程度加剧，同一类型问题出现的频率越来越高，才逐渐嗅到淡淡的“腐化味道”，也因此才有了后续一系列的分析、方案设计、工具&平台研发，以及治理实践。我们来看下面这张图，可能很多研发同学会有切身感受： 1.1 嗅到腐化味道笔者在Android架构领域有多年经验，直接负责或者间接参与了稳定性、启动性能、包瘦身、工程效能、新版本os适配等多个方向，随着各治理项的不断深入以及时间的推移，遇到过各种各样的问题，例如：冲突资源导致即使代码无变化，多次构建后的apk中也会出现资源值不一致，最终引发线上问题；java代码修改导致不兼容调用，最终引发线上java异常；线程随意使用，缺乏统一管控，一方面性能堪忧，另一方面过多线程数量超过某些设备的自定义限制，从而引发OOM异常；无用代码&资源&功能模块，导致包体积持续增加；apk构建耗时越来越长，严重影响研发效率；这样的例子，可以举出几十项，此处不再一一赘述。当尝试以一个整体的视角去看待和思考这些问题时，才发现背后隐藏着的强大敌人——工程腐化。工程腐化，简单来说就是无用/冗余/不合理代码的持续堆积，从而更容易出问题，出了问题更难定位，而且迭代越快腐化越快，即使无任何迭代，随着新版本os上市、隐私合规监管态势日趋严格等等外部环境变化，都会导致存量代码出现问题。接下来，深入到研发迭代过程，看看腐化自何而来。 1.2 分析腐化产生前面讲到有很多因素会导致工程腐化产生，但最源头因素只有两个：时间和人。时间意味着工程外部环境的变化，例如：目标设备中os版本号会不断升级、研发工具链、IDE等迭代更新，一份静止不动的工程代码，会随着时间的推移慢慢腐化。相比时间对工程腐化带来的慢变性影响，由人主导的快速工程迭代，才是工程快速腐化的最大来源。既然如此，我们就重点看看一个app版本迭代&交付过程中，都有哪些角色参与，其核心诉求分别是什么，工程腐化又如何在这样的“土壤”中不断积累。上图是一个典型的移动端app版本迭代&交付过程，对于大型app和研发团队，可能每个角色都有专门的岗位和人来负责，而对于小型app和研发团队，则可能1人分饰多个角色：产品和设计，负责功能、UI、交互设计，关心的是创意和功能给用户带来的价值，以及视觉和交互的流畅炫酷；研发和测试，在接到产品需求以及设计稿后，负责代码开发、实现、效果&质量保障，研发和测试同学，往往希望需求和设计一旦确定后不要总发生变化，此外还希望尽可能复用现有的逻辑和功能，对不断推倒重做式的需求和设计有着天然的“抗拒”，最后还希望能多点时间，再多点时间，来保障代码质量和验收效果； PMO和PTM负责版本节奏、管控发布过程，关心整体的需求吞吐量，以及过程和线上质量；渠道和运营负责将新版本app，通过各种渠道准时交付到用户手中，并通过层出不穷的运营手段，来获取新用户以及用户对app功能使用的全面、快速增长；在前面这个过程中，安全和法务需要保障app的安全漏洞得到及时解决，隐私合规等相关事项不出现风险性问题。最终，用户获取或者升级到最新版本app，其核心诉求是这个新版本app“好用吗？好玩吗？”。随之而来的除了用户，还有各方监管&检测机构，在获取到新版本app后，会检查根据当前法律、法规，仔细检查app使用过程中是否存在“违规”现象。在这样一个app版本交付过程中，可以看到各角色的侧重点并不相同，同时所有角色的诉求最终都要通过代码来承载。工程腐化直接来源于开发者的代码生产活动，开发者本身的意愿、技能和经验，确实会极大影响代码质量，但现代企业级app的功能之复杂，绝不可能所有参与其中的开发者，都能够对app所有代码了如指掌，因此这种对工程或者说代码掌握的局部性，可能是工程腐化产生的更重要因素。 1.3 拆解腐化问题分析完腐化产生，我们再进一步对Android工程腐化项，进行更细粒度的拆解。从Android工程包含所有“代码”的类型来看，可以分为以下五种：其中，工程配置是指在apk构建过程中使用到的相关配置，配置内容本身并不会进入到最终apk，这种工程配置腐化，主要是影响工程本身的复杂度，甚至是构建过程耗时，例如大量的proguard配置项。其它四种类型，manifest、java代码、资源、动态链接库so，也是组成apk的所有可能“元素”，自身或者相互之间都可能存在各种各样的腐化问题，直接导致apk稳定性、性能、包大小、UI&功能异常、隐私合规风险等等，或者提高这些问题出现的可能性。在实际工具开发和治理实践中，也正是按照上述类型实现分而治之。应对方案在完成腐化产生分析，以及按类型拆解后，接下来需要制定有效的应对方案。首先，必须明确并时刻牢记的指导原则是：“用正确的方式，做正确的事，无论简单还是困难”。“正确的事”往往比较容易界定，并达成共识，但是“用正确的方式”却有些困难，因为有时候“不正确的方式”意味着捷径，可以快速取得目标成果，例如：假设我们需要将app中所有线程使用切换到统一线程池实现，有两种方式可以完成，一种是直接使用构建时aop技术对线程调用代码直接进行替换，另一种是建立非统一线程池使用的检测&卡口机制，在保障有效防控增量代码情况下，逐步修改存量代码。显然，第一种方式可以快速达成目标，但是却会增加apk构建耗时，同时如果这个aop处理过程本身，一旦出现问题导致替换不成功，或者替换过程异常终止导致字节码替换不完整，那么又是另一种“工程腐化”。第二种方式无法快速达成目标，但是可以有效止住腐化趋势，并逐步消化存量问题，虽然卡口本身需要日常审批评估，并且存量代码清理也并非一蹴而就，但代码源头上的直接改正，才是解决工程腐化问题的”正确方式“。 2.1 人vs流程工程腐化来自于人在版本迭代流程中，对工程代码进行的不合理变更，因此，工程腐化治理需要围绕“人”和“流程”来进行。对于人这个因素，业界已经有非常成熟有效的做法，例如：进行代码review、制定代码规范、定制IDE的Lint规则、持续进行技术培训等，这些都能够提高开发者的代码设计和编码水平，从而在源头减少腐化代码产生。此外，能够潜移默化的提高研发团队整体工程质量和素养，对工程质量带来更为全面的提升。但是，这种方式有一些问题，也绝不能忽视：参与到一个工程的开发者，其技术认知、水平、理解能力并不一致，这些规范/规则的执行效果难以保障，带来的潜在成本可能也会很高。对于工程腐化来讲，完全依靠这些围绕人的方案，不确定性非常高，而腐化的防治需要一种确定性的机制来“守好这道门”，同时，防治本身需要做到较低的成本，因此，我们将重点放在流程上面。流程具有客观、固定、有保障的特性，一方面以全面的apk检测分析技术为核心，对腐化项精准定位并在流程关键节点部署卡口，及时感知，有问题就地处理，从而实现零新增。另一方面，对于存量腐化项，提供多样化的辅助工具，降低整改风险和成本，提高效率。冰冻三尺，非一日之寒，因此解冻的过程，也不能够搞成大跃进式的清理模式，而是需要在尽量不影响日常研发活动前提下逐步迭代，最终实现存量清零。围绕人和流程的这些应对方案，并不是二选一而应该是相辅相成，前者重在从源头全面减少腐化项产生，后者重在无差别的阻止其中能够有效检测的腐化项进入到最终apk，同时增强开发者防腐化意识，并促进代码Review、代码规范等有效执行，从而形成良性循环。 2.2 分析工具作为核心的apk检测分析技术，到底包含哪些具体的能力呢？来看下面这张图：上图是当前检测分析技术汇总，可以分为冗余冲突、关键配置、引用关系、辅助提效四个类型。前三种类型直接对应具体的腐化项，最后一种则是帮助开发者在日常研发过程中，更好的定位和分析问题。对于每一项检测能力，此处先不详述，在“向工程腐化开炮”系列文章中，分别与具体实践相结合进行了相关讲解。 2.3 卡口体系这些检测能力，是如何与流程相结合的呢，来看下面这个流程卡口示意图：对于开发/测试同学，在提测、集成、灰度/正式版本发布这些关键节点，都需要进行apk构建，同时，会自动触发已经部署好的各项检测分析。如果是本地打包，检测不通过，会直接构建失败，并在失败原因中，给出相关信息；如果是CI/CD平台打包，卡口结果会以平台页面形式呈现；无论哪种模式，都会中断流程，待研发同学修复问题后，再继续进行。这样，就实现了腐化问题的及时感知，就地修改。以平台模式为例，每次提交测试/集成时，apk构建都会触发卡口检测，如果有卡口项未通过则阻断流程。卡口结果示例如下：在具备了这样一套机能力和机制后，我们接下来看看，如何对各类腐化问题进行治理和防控。首先，先明确“模块”这个概念，对工程腐化与治理的影响，以及工具建设和治理实践。模块治理一个完整apk的产生，可以认为是一个“拼积木”的过程；每一块积木，都可能包含java代码/资源、Android资源、AndroidManifest文件、动态链接库so、proguard配置，将这些积木按照一定规则拼接，同类元素混合&压缩，即成为最终的apk文件。上述这些“积木”，用更贴近技术的术语来讲，就是模块。模块为功能复用提供可能，也为并行研发模式提供基础，一般来讲，越大型和复杂的工程，其模块化程度也越高。工程腐化的产生，本质是由功能的复杂度以及代码变更导致，模块化本身虽然会带来一定的腐化问题，但更重要的是，为工程腐化问题治理提供便利。试想一下，一个由上百人划分为十多个团队，共同参与迭代的app，如果都在一个app工程中开发代码，先不说如何解决代码协作，一旦发生腐化问题，如何进行分配本身就是一个极大的挑战。在现实工程领域，模块化程度一般（正常的工程选择）都会随着功能和开发人员的增加而不断提高，在这个前提下，工程腐化治理首先要做的事情，就是要明确知道每一个具体的腐化问题，来自哪几个模块，这是将问题进行分发和处理的前提。接下来，首先会给出模块的分类，然后讲述针对模块开发的几个“辅助分析能力”，以及在此之上的治理实践。 3.1 模块分类 app工程中以外部依赖形式引入的jar/aar，以及与app工程平行的subproject，可能是日常研发过程中接触最多的模块类型，除此之外，Andriod原生还支持其它类型模块。从apk构建视角来看，模块的完整分类图如下：上图展示了5种模块类型，以及几个维度：在apk构建过程中是否需要经历源码编译、是否在maven仓库中存在，以及可能存在的依赖关系。下面分别进行讲解： app-project有且仅有1个，用于生成apk，包含源代码，因此需要源码编译。可以依赖sub-project、local jar、flat aar、external module； sub-project可以有0或多个，一般与app-project平行，同样包含源代码，可以依赖sub-project、local jar、external module； local jar不能单独存在，java代码已经以编译后的class字节码形式存在，不能依赖其它类型模块； flat aar是Android原生提供的一种引入非maven中aar的方式，同样无需源码编译，并且不能依赖其它类型模块； external module，即外部依赖模块，无需源码编译，可以依赖其它外部模块，依赖信息位于maven仓库对应pom文件中。一般来讲，一个app的“出生”，是从一个app-project工程开始的：所有代码、资源都写在此工程中，当然也会以外部模块形式引入（依赖）一些二、三方库；随着app承载功能增加，复杂度随之上升，此时也很可能会有更多的开发者加入进来，持续迭代一段时间后，可能会迎来第一次模块化“变革”：将通用功能拆分为多个sub-project；开发人员的增多，会引发代码协作成本提高，此时可能需要从单个代码仓库拆分为多个，便于并行化开发，此时迎来第二次模块化“变革”：代码仓库拆分，以及更细粒度的模块拆分，研发并行程度继续提高。最终，会演进为模块化的究极形态：app-project成为用于打包apk的一个“壳子”，几乎所有代码全部拆分到单独模块和仓库，在app-project中以外部模块形式对其进行依赖（引入），研发高度并行化。很多大型app，基本都完成了上述这样的演进过程，同时也引发了新的问题。接下来，就来逐一讲述在模块这个维度，研发了哪些工具，进行了哪些治理。 3.2 辅助分析能力辅助分析能力，主要是站在apk完整构建角度，为开发同学提供模块及其依赖信息，用于解决各种日常问题，例如： “我更新了一个模块的版本号，为什么apk中的代码还是旧的？” —— 查看本次apk构建，目标模块最终使用的版本号是多少，如果没有更新，那么肯定会出现这个问题。 “我删除了模块，为什么apk中还有相关代码/资源？” —— 查看本次apk构建，目标模块是否参与到apk构建过程，是app工程直接依赖引入，还是其它模块间接依赖引入，快速定位原因。 “我在一个模块工程中，使用了另一个模块中的方法，但是在apk中却找不到此方法，是什么原因？” —— 查看本次apk构建，依赖的另一个模块版本号是多少，升级目标工程中对此模块依赖的版本号，重新编译目标工程，看是否方法已被删除，转移或者签名有变化。接下来，分别对每项辅助分析能力进行简单介绍。外部依赖模块列表外部依赖模块列表，统一输出所有参与到本次apk构建的外部依赖模块，及其版本号、类型。示例结果： com.youku.arch:testlib:0.1-SNAPSHOT@aar com.youku.arch:testlib2:0.3@aar 被依赖关系检测在apk构建过程中，有一些外部依赖模块是通过间接依赖（没有在app工程中直接声明依赖）引入进来的，这个间接依赖关系，存在于maven仓库中模块对应的POM文件。通过被依赖关系检测功能，可以方便的找到一个模块，被哪些其它模块所直接依赖，用于进行模块下线，或者归属关系判定（根据依赖关系，判断模块属于哪个上层业务）。示例分析结果： com.youku.android:y-core |-- [provided] com.youku.android:ct-ad |-- [compile] com.youku.android:catl |-- [runtime] com.youku.android:MtRec com.tb.android:z_dev |-- [compile] com.tb.android:zcore 注意，这里的分析结果，是被依赖关系。在这个例子中，com.youku.android:ct-ad模块以provided方式，声明了依赖com.youku.android:y-core模块；com.youku.android:catl模块以compile方式，声明了依赖com.youku.android:y-core模块；其它内容以此类推。其中，依赖类型一般包括以下几种： compile。此类型依赖，如果不额外添加exclude设置，会导致模块被打入apk； provided。此类型依赖，不会导致模块被打入apk； runtime。此类型依赖，不会导致模块被打入apk。当然，模块在发布到maven仓库时，可以定制pom文件内容，所以如果模块发布时，并未正确的将工程中对其它模块的依赖关系写入到pom中，那么上述检测结果，也会存在对应的错误信息，例如：漏掉真实依赖模块、依赖类型与实际不符、包含多余依赖模块等。不匹配依赖关系检测在模块化开发模式下，各个模块独立开发，并最终参与apk构建，这会导致很难感知到其依赖的模块进行了升级：模块自己在进行构建时，使用的还是对应依赖模块的旧版本，所以可以编译通过，但是在apk编译时，很可能其所依赖的模块已经进行了版本号升级，从而导致一些不匹配引用情况发生。不匹配依赖关系检测，正是为了便于各模块开发同学，清晰的掌握模块编译时依赖的其它模块版本号，与apk编译时这些模块使用的版本号之间的差异，从而及时在模块工程中进行依赖模块版本号的升级操作。示例分析结果： com.youku.android:YTask |-- com.youku.android:BFra:1.0.0-SNAPSHOT ==> 1.0.0.44 |-- com.youku.android:BUIKit:20190617-SNAPSHOT ==> 1.0.1.66 |-- com.youku.android:YUI:1.4.2.16-SNAPSHOT ==> 1.4.10 在上述示例中，YTask模块在编译时，依赖的BFra模块是1.0.0-SNAPSHOT版本，而在apk构建时使用的BFra模块是1.0.0.44版本，其它以此类推。此外，还提供额外功能，将所有外部依赖模块的pom文件，统一输出到apk构建产物文件中，便于集中查看和定位问题。 3.3 治理实践在上述几项辅助分析能力的基础上，有两种情况会对构建出的apk带来不确定性隐患，因此，也成为模块腐化的直接治理目标。 snapshot版本号在apk构建开始阶段，直接从maven仓库下载外部依赖模块对应版本号的jar/aar文件，参与后续构建过程。其中，SNAPSHOT版本号由于可以随时更新jar/aar到maven仓库，而在app发布版本构建时，并不希望这种情况发生，这会带来各种难以预期的线上风险。因此apk构建过程，是否存在SNAPSHOT版本号的外部依赖模块，需要被严格管控住。为了，研发了snapshot版本号检测功能，筛选出参与到apk构建过程所有版本号为snapshot的外部模块。示例内容如下： com.youku.arch:testlib:0.1-SNAPSHOT com.youku.arch:testlib2:0.2-SNAPSHOT 进一步，在app版本迭代关键节点，例如：集成、灰度/正式版本发布，利用此项检测能力形成卡口。优酷在几年前，就已经以本地卡口形式（apk构建失败）上线此功能，并在2021年将此卡口融入到整个卡口体系，成为其中一个卡口项，累计拦截7次，有效防止snapshot版本模块引入到apk构建过程中。 snapshot依赖开发阶段，为了方便模块间联合调试，通常会将依赖的模块版本修改为SNAPSHOT，在完成联合调试后的正式版本打包过程中，如果没有将依赖模块的SNAPSHOT版本号修改回正式版本，而这个时间窗口内，依赖模块的SNAPSHOT版本一旦有更新，会导致模块正式版本编译时依赖非预期代码，最终导致apk运行时出现各种不兼容问题，例如：API不兼容（类、变量、方法签名不匹配）、常量不一致（常量在模块编译时，会进行常量展开）。 snapshot依赖检测功能，正是为此而生，在检测结果中列出每个模块依赖的snapshot版本号模块，以及apk构建时此模块对应的版本号。示例内容如下： com.youku.android:YHPage:1.9.35.5 |-- com.ali.android:VCommon:20210309-SNAPSHOT ==> 11.1.6.4 |-- com.youku.android:YRes:20210309-SNAPSHOT ==> 1.0.44.2 com.youku.android:OUtil:1.0.4.11 |-- com.youku.android:OService:20210105-SNAPSHOT ==> 1.3.8.2 作为腐化治理项，优酷在2021年初上线此功能，当时有200多个模块在pom文件中存在snapshot模块依赖，当时统一添加到了白名单，在接下来版本迭代过程中逐步清理，截止目前已清理近40%，效果显著。在同一时间于app版本迭代关键节点，形成了对应流程卡口，近一年时间累计拦截25次，有效防止由此导致的线上风险问题发生。其它治理实践上述模块相关腐化治理，只是与工程腐化这场持久战的前哨。针对前面工程腐化的元素级分类拆解，开辟了以下“五大战场”，可以前往查看详情（点击跳转）： proguard配置 manifest java代码资源动态链接库so 还能做些什么在优酷近两年的工程腐化实践中，得到了很多研发同学的支持，他们怀抱匠心、热情与勇气，及时解决出现的新增问题，一点一点的去消化存量技术债，长期的坚持和努力共同换来目前工程腐化问题的全面显著降低。“用正确的方式，做正确的事，无论简单还是困难”，这既是优酷进行工程腐化解决方案设计和治理实践时，所坚定遵循的原则，也是本系列文章想要传达出来的技术理念。目前能够通过工具检测到的具体腐化问题，加起来不过20余项，相对于工程腐化的冰山，毫不夸张的说这真的只是一角儿。况且，这里所给出的应对方案，也仅仅能够解决其中一类问题，面对那些极度复杂，甚至牵一发而动全身的腐化问题，尚缺少有效解决方案。面对工程腐化，还有很长的路要走，还有很多事情可以并且需要去做，向工程腐化开炮，是一种直接而切中要害去解决问题的态度，积跬步行千里，与诸君共勉。关注【阿里巴巴移动技术】微信公众号，每周 3 篇移动技术实践&干货给你思考！

2022-03-29

2.5万字读懂企业DevSecOps全实践

管理结构的建立使开发经理管理开发人员，而不是 IT 运维人员。用于特性跟踪、故障排除和资源分配的管理工具是面向孤岛结构的。

2022-01-24

必了解的 DevOps 工具链集合 2021（全）

项目管理（Plan）这个阶段属于 Agile 的范畴，解决的问题是【如何把工作规划好】。我们主要调研文档系统，项目管理系统，会议系统，即时通讯系统。

2021-11-07

Zoom将以全股票形式收购Five9

7月19日，视频会议巨头Zoom宣布将以全股票形式收购云服务商Five9，该笔交易价值约为147亿美元，预计将于2022年上半年完成。

2021-07-20

Darktable 3.6.0 发布，全平台图像编辑软件

Darktable 是 Adobe Lightroom 的开源替代品，它是一款帮助专业摄影师的进行照片管理及后期处理的图形工具，用户可以通过该软件查看和编辑照片。

2021-07-04

谷歌开源首个通用全同态加密转译器

谷歌宣布开源了用于全同态加密（FHE）的首个通用转译器。该公司称，FHE 将允许开发人员在无法访问个人身份信息的情况下处理加密数据。

2021-06-17

带你梳理Roach全量恢复的整体流程

摘要：本文将梳理Roach全量恢复的整体流程，描述Roach集群全量备份场景的运转机制。数据备份恢复是保护数据安全的重要手段之一。

2021-03-03

darktable 3.4.1 发布，全平台图像编辑软件

Darktable 是 Adobe Lightroom 的开源替代品，它是一款帮助专业摄影师的进行照片管理及后期处理的图形工具，用户可以通过该软件查看和编辑照片。

2021-02-06

Python搭建新冠肺炎预测模型全解读

新冠病毒疫后复工成为当务之急，然而病毒尚未消散，风险权衡面临不确定因素，如果可以准确预测未来的疫情走势，将会为复工计划的制定提供有效辅助。传统机器学习模型虽然可以精确拟合历史数据，但由于脱离疾病传播机理，外推预测的可靠性低。另一方面，传染病学领域提出的传播模型则恰好相反，主要依赖疾病传播机理进行推演，但对历史数据的拟合能力弱，不同疾病会得到相似的结论，特异性不足。近日，南栖仙策通过强化学习融合传染病传播机理与数据拟合，使用其自主研发的Universe平台构建传播模型，并基于横琴先进智能计算平台提供人工智能计算资源，实现新冠病毒疫情长达60天的预测，可为疫情防控提供决策辅助。在线预览预测结果：http://ncov.polixir.ai 值得注意的是，目前AI领域常用的深度学习模型是黑盒模式，内部运算过程难以被人们理解，同时也难以将人

2020-02-19

Apache ShardingSphere数据脱敏全解决方案详解

Apache ShardingSphere数据脱敏全解决方案详解作者简介潘娟，京东数科高级DBA，主要负责京东数科数据库中间件开发、数据库运维自动化平台开发、生产数据库运维工作。

2019-08-12

用阿里云产品搭建个人网站全教程

申明：这是整体流程，看完这个你至少知道搭建网站怎么个流程了，相当于一个说明书，具体操作时，阿里会给你提示的，很人性化.建站的三个核心关键步骤1注册域名建议直接在阿里云注册，方便快捷，管理也方便，还有优惠呦

2019-04-27

安卓平台Flutter启动过程全解析

前言今天主要带大家一起分析下flutter是如何启动、初始化和加载dart代码的。这里有几点需要提前告知：由于篇幅的问题，关于flutter界面创建、绘制过程将略过；由于相关的c++代码比较多，而且较为复杂，建议先下载flutter engine的完整开发环境代码，阅读本文更方便；本文只分析启动过程，参考的项目是基于android studio创建的一个默认flutter项目，以下简称demo。（文章干货很长请耐心看完文末有福利！）正文 java层启动过程熟悉android的朋友都知道，一个APP启动会先执行Application再执行Activity(AndroidManifest.xml中配置的启动Activity)，结合这个，我们先看看Application里做了什么，在分析过程中我们将挑取一些关键的native方法作为

2019-04-01

一铲子下去，服务器全瘫痪......

【大咖・来了第7期】10月24日晚8点观看《智能导购对话机器人实践》昨日（3月24日）下午三点前后，大量用户反馈腾讯旗下诸多服务出现服务器未响应问题。受影响的腾讯服务包括腾讯微云、腾讯游戏、QQ安全中心等。事实上，并不是腾讯一家公司的游戏产品受到了断网影响、今天下午同样也有网民和业内人士注意到其他公司游戏产品也出现了类似故障，只是因为腾讯断网游戏实在太多、多达几十款，影响用户太多，网民更多讨论的是腾讯罢了。根据网友描述，通过腾讯登录相关游戏界面会出现登录超时问题。另外，还有网友反馈腾讯微云网盘服务也出现异常。有用户通过QQ安全中心修改密码也提示失败。此外，有网友发现QQ空间也不显示昵称只显示QQ号。就当日网络故障，腾讯公司也发出了正式公告，“23日下午16时左右，因上海当地网络运营商光纤线路大面积故障，腾讯多个产品业务使用受到影响。目前运营商正在紧急抢修中，我们也正在积极做容灾处理，业务陆续恢复中。” 腾讯公告等于确认事故原因确实是施工队挖断了光纤。随后，腾讯官方微博证实了这一说法。昨日晚上8点，腾讯公关总监张军则表示，正在恢复正常，而玩家也发现游戏开始逐步可登陆。据腾讯内部人士的说法，此次故障是由于上海机房主光缆断裂造成，目前影响腾讯94款游戏。腾讯游戏也同时发布公告说明此次服务器异常情况。目前，运营商和腾讯方面都在加紧抢修，恢复相关业务。躲不开的赔偿关于赔偿，王者荣耀表示，将在网络恢复后补偿玩家100钻石+100铭文碎片。在断网的这近8个小时中，腾讯损失了多少呢?有好事者根据前天腾讯发布的财报进行了如下估算：腾讯2018年全年营收为3127亿元、其中游戏收入为1284亿元，平均算下来，腾讯每天营收8.56亿元、其中每天游戏收入为3.5亿元。仅估算游戏断网8小时的损失，今日腾讯就损失过亿。无独有偶，据圈圈回忆，去年 7月24日上午，腾讯云因广州运营商光缆物理中断宕机。据微博用户@卢松松爆料，腾讯云此次宕机影响较大，已导致腾讯云广州区域全面断网，包括腾讯云主页、控制台、DNSPod等。难怪有腾讯员工在朋友圈开玩笑说，再高明的互联网科技，也抵不过蓝翔挖掘机的一铲子。然而，圈圈好奇地想问一句：都9102年了，还木有听说过物理双路由吗?

2019-03-25

全平台硬件解码渲染方法与优化实践

接下来我将围绕以下几个话题，为大家分享有关全平台硬件解码的渲染与优化的实践经验。解码后的视频数据需经过纹理加载后才会进行下一步的OpenGL ES渲染操作，其关键在于如何将解码后的数据填充到纹理中。

2018-11-04

网络唤醒（WOL）全解指南：原理篇

什么是网络唤醒网络唤醒（Wake-on-LAN，WOL）是一种计算机局域网唤醒技术，使局域网内处于关机或休眠状态的计算机，将状态转换成引导（Boot Loader）或运行状态。无线唤醒（Wake-on-Wireless-LAN，WoWLAN）作为 WOL 的补充技术，使用无线网卡去唤醒计算机。网络唤醒在一般的局域网环境里使用有限广播地址（255.255.255.255）即可，由于路由器都不转发目的地址为有限广播地址的数据报，因此在复杂网络情况下通常使用子网定向广播地址。在局域网外唤醒局域网内特定计算机，可以使用路由器的 DDNS 与端口转发。在1996年10月，英特尔和 IBM 成立了 Advanced Manageability Alliance。1997年4月，联盟提出了 WOL 技术。这是 WOL 技术的起源，随后各大厂商纷纷推出了自己的 WOL 技术标准。本文所讨论的 WOL 技术是由 AMD 公司提出的 Magic Packet（幻数据包，魔术包）唤醒方式，这里给出 AMD 关于此技术的白皮书。幻数据包（Magic Packet）幻数据包是一个广播帧，包含目标计算机的MAC地址。由于 MAC 地址的唯一性，使数据包可以在网络中被唯一的识别。幻数据包发送通常使用无连接的传输协议，如 UDP ，发送端口为 7 或 9 ，这只是通常做法，没有限制。 WOL 技术被提出了将近20年，绝大多数的现代网卡都支持在超低功耗下监听特定的报文，如 ARP。如果设备网卡接收到一个与自己 MAC 地址相同的幻数据包，则网卡会向计算机的电源或主板发出信号以唤醒计算机。大部分的幻数据包在数据链路层（OSI模型第2层）上发送，当发送时，使用广播地址广播到给定的网络上，不使用IP地址（OSI模型第3层）。当然这是绝大部分情况，幻数据包也可以使用特定的 IP 地址进行发送。幻数据包最简单的构成是6字节的255（FF FF FF FF FF FF FF），紧接着为目标计算机的48位MAC地址，重复16次，数据包共计102字节。有时数据包内还会紧接着4-6字节的密码信息。这个帧片段可以包含在任何协议中，最常见的是包含在 UDP 中。例如 MAC 地址为 11 22 33 44 55 66 的目标计算机，幻数据包的格式为： FFFFFFFFFFFF 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 112233445566 [ABABABABABAB（这里为6个字节的密码）] 幻数据包还有一些基本限制条件：需要知道目标计算机 MAC 地址不提供送达确认可能无法在局域网之外工作需要硬件进行支持创建幻数据包项目地址：https://github.com/ZhangGaoxing/wake-on-lan 该项目为 Xamarin 跨平台项目，包含 Xamarin.Android 与 UWP 。支持自动扫描添加局域网设备。关于 MAC 地址的扫描获取，这里只说一下思路，详细请查阅代码。第一种方式，也是我最开始想到的方式，使用 Ping 来 Ping 整个网段。开了四个线程，1-255大概需要30多秒，稍微有点慢，而且 .NET 的 Ping 类在 Android 上无法限制秒数。第二种方式，百度到的，直接向整个网段发送 UDP 消息，2秒解决战斗。扫描完成后获取 ARP 表就行。下面给出的是发送幻数据包的方法： public static async void Wake(string broadcast, int port, byte[] mac) { using (UdpClient udp = new UdpClient()) { udp.EnableBroadcast = true; byte[] packet = new byte[6 + 16 * 6]; for (int i = 0; i < 6; i++) { packet[i] = 0xFF; } for (int i = 0; i < 16; i++) { for (int j = 0; j < 6; j++) { packet[6 + i * 6 + j] = mac[j]; } } await udp.SendAsync(packet, packet.Length, broadcast, port); } }

2018-09-16

精选列表