今天登录公众号后台看了一下，上一篇文章已经是 2 个月前写的了。 其他平台也基本属于停更状态，这段时间一直在忙毕业设计和论文的事情，属实有些耽搁了，不过今天刚好把毕业论文提交了，毕业的倒计时也开始了。想着从下周开始，我就准备恢复更新了。今天就先水一篇，讲讲最近停更期间发生的一些事情吧。 毕业设计和论文 熟悉我的读者应该知道我现在还没毕业，今年 6 月份才能拿到我的硕士毕业证。总体上来看，我读研的这两年还是比较快乐的，科研的压力虽然有一些，但因为是推免的进实验室比较早所以也就提前适应了。研一的课程虽然比较多但是难度适中，再加上去年碰到了疫情，很多时间都是在家中度过，之后暑期去实习了几个月就回学校了，研二因为实验室已经来新人了相对就轻松了些，等之后找个时间写一篇文章专门聊聊这几年读研的生活。 其实读研期间我没有做出什么成果，主要还是因为自己的想法就是找工作，不想花那么多时间浪费在一些无关紧要的事情上，所以这个毕设可以算是我读研期间为数不多的成果之一了。大体框架如下： 和大多数软件系学生类似，我的毕设也是一个 XXX App，用的技术也是很常见的一些技术，Flutter、Spring Cloud、Docker、MQ 这些，但是涉及的领域是我比较喜欢也比较看好的智能家居领域。 我自己是一个智能家居的爱好者，也爱好捣鼓，所以在家里也购买了一些小米智能家居和苹果智能家居的设备，读研的时候恰好学长就给我安排了一些和智能家居有关的活，虽然活不是很多，难度也还好，但因为自己喜欢也就坚持着做了，所以毕设也就恰好选择了这个方向。做下来这段时间，总体感受还是很不错的，如果有学弟学妹读研之后不知道选什么方向的，这个领域可以涉及下，还是挺好玩的。 多平台短视频发布工具 MediaPub 其实这两个月里，除了在忙活毕业设计和毕业论文，我还在捣鼓另一个东西，也就是一个多平台短视频发布工具 MeidaPub，做这个工具的初衷就是实现一个可以一键将短视频发布到多个平台的工具，提高一些视频制作者的发布效率，其实已经开始内测了，之前也贴出了官网地址和使用说明，目前看来用户不是很多，可能是跟宣传有关吧，不过好在还是收集到了一些测试反馈，之后我也将会持续更新这个软件。 其实最近也在忙活着给他来一个大版本的更新，未来可能也会把图文多平台发布也加进去，有兴趣的小伙伴也可以联系我一起搞点事情。 最后 简单聊了聊最近停更期间做的一些事，接下来要忙活的应该就是准备毕业答辩和旅行了，公众号文章我也会持续更新下去，还有就是之前一直说的要写的 Spring Boot 入门教程，虽然中途写到了第二章就停更了，不过近期也会慢慢拾起的，最后希望接下来这段时间可以顺利的从科研狗 🐶 过渡到打工人 👨‍🔧。

之前在《前端菜鸟的阿里实习百日之旅》一文中，我的好友「承和」分享了一些作为前端开发实习生的感悟，文章发出后，很多人在后台询问能不能谈谈前端的学习路径，以及作为一个萌新如何拿到大厂的前端 offer。的确，秋招已过去大半，下一波待就业的应届生们也可以开始考虑实习和春招了，为此，本文以 Q&A 形式邀请了他来讲述他是如何一步步 get 大厂的前端 offer，希望他的成长经历可以为正在准备的人带来一些启发。 Q：初来乍到，先做个简单的自我介绍吧 「01 二进制」的读者，你们好，我是承和，目前是一名计算机专业的研三学生，就读于杭州电子科技大学，本科就读于马爸爸的母校，也就是杭州师范大学。在此次秋招中，很幸运的拿到了阿里，字节，拼多多等公司的 Offer，希望我的成长经历能对你们有所启发。 Q：能不能简单说说你这些年的前端学习经历呢？ 说起前端，其实我最早接触的是 iOS 客户端开发。在我大二的时候，苹果发布了最新的开发语言 Swift，恰巧在当时，我在编程上的启蒙老师所在的实验室正在招新，听说加入还会分配 MacBook，于是我马上联系了他。就这样我顺理成章的白嫖到了一台 MacBook Air 笔记本，而当时分配到的任务是开发一款 App，也正是从这个任务开始，我走上了软件开发这条不归路。 后来实验室为了减少开发和维护的成本，导师让我学习有关跨平台应用开发技术，也正是从那时起，我逐渐接触到前端开发。在学习过程中，我发现，相对于客户端，前端开发有更广的发展空间，再加上当时客户端的就业形势是**“49 年入国军”**，因此，毅然决然地选择了前端开发。 再后来，读研期间，学习了点深度学习的相关知识，发现这玩意儿极其烧脑，加上国内学术圈又相当浮躁，多数研究生基本都是为了发论文而发论文，很少有能实际落地应用到工程之中的。加之现在算法岗 hc 非常少，大厂的算法岗几乎是神仙打架，想着肯定是没办法靠算法吃饭了，所以又重新投入到了前端的怀抱中，从 0 开始学起，好好沉淀自己的前端技术。 Q：你这也算是有了几年开发经验的老鸟了，要不简单谈谈你是如何学习前端技术的？ 我个人认为，学习编程就和练武一样，学习任何一门技术都是修炼内功和学习招式的过程。内功指的就是基础，就前端领域而言，也就是我们常说的前端三板斧：HTML、CSS 和 JS。我们可以根据网上较流行的知识图谱或者一个面试宝典，进行初步的学习。若想要深刻了解的话，便要通过阅读大量相关的专业书籍来加强理解（后面我也会推荐一些，此处没有广告，可放心食用）。 招式指的便是各种前端框架，这些框架帮助我们封装了底层对于 dom 的操作等，使我们能够专注于业务代码的编写。现如今国内 Vue 和 React 大行其道，但是作为 JS 革命性的框架之一，jQuery 我们自然不能忘记，该框架非常适合前端入门者进行学习。 对于框架的学习大致可以分为以下 3 个步骤 👇： 第一步，学会**招式的使用，**你要学会怎么用它，知道这个框架究竟解决了哪些问题，这些资料最好的获取方式便是官网，例如 React 官网，便清楚的说明了 React 的用途，在开发中大多数遇到的问题也能在 React 官网上找到解决方法。 第二步便是用框架做一个项目，在编写项目的过程中，你会遇到很多"稀奇古怪"的问题，通过解决这些问题，可以加深你对框架的理解。 第三步要做到知其然知其所以然，在熟练掌握框架的使用后，去学习它的源码，去看一些源码解析或者大佬的直播课，最好是自己手动实现一个类似于 React 的 diff 算法。 Q：在学习的过程中，有什么需要注意的呢？ 在学习过程中你会接触到非常多的知识点，难免会产生焦虑，这时候要做的就是定义一个边界，做到对另一个知识点的探索适可而止。 例如，在利用 React 脚手架的开发过程当中，我们会接触到 Webpack，我们可以先用脚手架中 Webpack 默认配置来进行项目开发，去了解 Webpack 的功能和大致打包流程，来做到对 Webpack 的整体认识，在后续进行项目优化时，可以尝试对默认配置进行修改，通过熟读 Webpack 官网，了解针对 Webpack，我们有哪些优化手段，并且付诸于实践，在工程当中加深自己对于框架和工具的理解。...

积分作为一种营销手段，被广泛运用于线上/线下的产品中，以此来增加用户对于产品的粘性。比如天猫积分可以用来兑换商品，京豆可以在下单折扣等，如下图所示。 如今，随着获客成本的增加，如何减少用户的流失，变成了各个产品的核心命题之一。也正因如此，很多业务引入了各式各样的积分系统。为了更好的面对业务带来的变化，对整个积分兑换流程做一个合理的抽象是正确且有必要的。只是，整个积分的兑换是一个非常庞大且复杂的流程，因此，本着一切从简的理念，我们这期先聊一聊如何设计一个积分领取系统。 从具体到抽象 无论是天猫积分/京豆，都会有一个规则说明，笼统的来说，无外乎两个主要的功能点：如何获取积分以及如何消费积分。 获取京东的方式通常有： 每天签到一次，领5个京豆 买100元以上的东西，领20个京豆 发1条20字以上的评论，领10个京豆 …… 从上面的规则中，我们可以看出，基本符合一个格式：xx行为，执行yy次，可以得到zz个ww。 于是我们可以将上述案例抽象成以下三步： 行为感知 任务推进 权益领取 架构设计 本着高内聚与低耦合的理念，我们可以抽象成几个核心模块 行为感知模块 该模块负责对用户的行为进行感知，如果用户的登录行为、点赞行为、下单行为等。通常情况，该模块是异步进行的。 原因也很简单，行为感知作为依附于主链路存在的功能，其存在不应该影响到主链路的运行。 例如“用户每日登录获取一个积分”这样的案例，我们不应该在登录接口同步进行行为感知。通常采取的做法是，开一个子线程调用一下行为感知接口即可。 但是，行为的种类千奇百怪，如何对行为进行一个合理的抽象便是我们要考虑的问题了。一个简易的流程图如下所示： 在上述流程里，行为感知模块可以感知多种数据源（消息），解析不同业务的消息数据后，为了转换成系统内部需要的行为对象，通常还需要有一步数据填充的过程，这一步需要我们和其他的服务进行联动的，在数据填充完成后，外部的行为才真正变成我们整个积分领取系统内部所需要行为对象，这一步可以可以再发出一个行为变更消息出去，以便和其他业务解耦（当然也可以提供一个接口）。 任务推进模块 我们将如何领取积分归到该模块中。 所谓任务推进，便是我们上述案例中提到的例如：下单20元的物品、点赞10条内容、登录1次这样的行为。在该模块中，我们需要维护一张用户行为记录表和一个任务规则表。 行为记录表负责维护用户每天的任务进度状态，例如点赞了多少条内容等信息。 任务规则表负责录入玩法规则，比如点赞10条内容可得一个积分这样的信息。该部分通常会由一个运营后台来承接。 一个简易的流程图如下 在上述流程中，任务的匹配与任务进度的更新是比较核心的部分。如何做好技术选型是比较重要的一点，我们将会在下一章详细介绍。 权益领取模块 出于高内聚低耦合的思想，我们可以将权益系统的职责设置的简单一些，只需要负责增加积分、减少积分，查询积分明细这几个工作。至于从什么渠道加积分、加多少积分，则将职责上移到任务推进模块中进行。 举个例子解释一下。比如，用户通过下订单赚取积分。订单系统通过异步发送消息或者同步调用接口的方式，告知行为感知模块订单交易成功，补全必要的信息后，发送给任务推进模块；任务推进模块根据拿到的订单信息，查询订单对应的积分兑换规则（兑换比例、有效期等），计算得到订单可兑换的积分数量，然后调用权益领取模块的接口给用户增加积分。 这一部分的流程比较简单，就不画图了。但是如何保证积分加的正确，如何保证不重复加或者不漏加则是该模块的难点。 小结一下 简单对上述三个模块进行一个小结。有了上述共识后，我们可以抽象出如下的功能图。 详细设计（数据表设计） 数据库和接口的设计非常重要，一旦设计好并投入使用之后，这两部分都不能轻易改动。 改动数据库表结构，需要涉及数据的迁移和适配。改动接口，需要推动接口的使用者作相应的代码修改。这两种情况，即便是微小的改动，执行起来都会非常麻烦。因此，我们在设计接口和数据库的时候，一定要多花点心思和时间，切不可过于随意。 相反，业务逻辑代码侧重内部实现，不涉及被外部依赖的接口，也不包含持久化的数据，所以对改动的容忍性更大。 在对上述流程进行了一个抽象之后，我们发现有两个非常重要的表：任务规则表和任务进度明细表。 数据字典设计 任务规则表 这张表的设计比较简单，只需要指明相应的活动规则即可，表结构如下。 字段 说明 id 活动ID name 任务名称 description 任务描述 type 任务类型 userAction 用户行为 num 任务次数 rewardCount 任务完成后的奖励数值 rewardType 任务完成后的奖励类型 period 单次任务的周期，本次需求仅支持天级别（DAY）的周期 threshold 每个任务周期内能完成的次数上限 🌰场景举例...

Web 发展三部曲 青铜时代 在互联网诞生之初，网页还只是一个承载静态信息的载具，只能显示一些纯静态的文本和图片。这种静态页面不能读取后台数据库中的数据，是一个完全封闭的生态，我们姑且称这是 Web 发展的“青铜时代”。 白银时代 而为了使 Web 更加充满活力，开发者们一次又一次的对动态网页这一高地发起进攻，主要目标是允许网络开发人员快速编写动态页面。这一个阶段，以 PHP、JSP、ASP.NET 为代表的动态页面技术相继诞生。在这些动态页面技术面前，网页不再是静止的，可以根据不同的人，不同的地域，不同的时间段呈现出不同的数据结果，从这时开始，Web 发展进入了其“白银时代”。 黄金时代？？？ 随后，各种各样的网站如雨后春笋般出现，网站的复杂程度也呈爆炸式增长，程序员既绘制页面又控制业务逻辑的难度也越来越大，这时，前后端分离的概念被提出来了。核心理念是**「让专业的人做专业的事」**。于是，程序员的职业发展来到了一个分叉点，是选择专门绘制页面的程序员还是专门控制业务逻辑的程序员成为了一个争论点，直至今日。 在这个阶段，前端是完全不需要参与后台的数据处理，他只需要利用约定好的接口拿到合适的数据，然后渲染页面即可。而且这么做的一个好处是，开发进度不会堵塞，后端开发不需要等待前端完成之后才能继续，只要 Mock 完整数据之后前后端联调即可。 前后端分离的挑战 那这个阶段，是 Web 发展的“黄金时代”吗？ 私以为不是。 前后端分离是一个非常好的思想，让专业的人做专业的事情这一美好愿景，在实际的过程中却受到了很多挑战。 举个例子，前端的接口通常是按照逻辑来展现数据的，有时候为了提高效率，后端会根据前端需要的数据结构做数据封装。这就意味着后端还是做了 view 层的工作，违背了前后端分离的初衷。 Web 系统架构的中间层 为了解决上述问题，有人提议干脆把 Controller 和 View 的工作都转移到前端，后端只负责处理 Model 的数据与底层逻辑。于是 Node 中间层这个解决方案就被提出来了，这种方案好不好我们暂且按下不表，先来说说这一个中间层的职能是什么以及架构是什么样的。 中间层架构 其实中间层要做的事很简单。 原来客户端直接向 Server 发送请求，Server 层收到请求后经过计算处理将结果返回给浏览器。如今浏览器将请求发送给 node 层，node 层经过一轮处理后再向 Server 层发起请求。Server 层处理完毕将响应结果返回给 node 层，node 层最后将数据返回给浏览器。因为 node 层的出现，Server 层可以只用关注业务本身，而不必理会前端对字段的特殊要求。 而且，由于增加了 NodeJS 层，每种前端的界面展示逻辑由 NodeJS 层自己维护。产品经理在中途如果想要改动界面，可以由前端自己维护，无需后端操心。前后端各司其职，后端专注于自己的业务逻辑开发，前端专注于产品效果开发。这样就实现了更彻底的前后端分离。 乍一看是不是觉得这个方案很完美呢？但事实真的是这样吗？ 太阳底下无新事 细心留意文章里的图，就会发现整个系统越来越复杂，系统复杂会带来很多问题，比如人员沟通成本增加，系统整体性能下降，安全隐患增加等等。这些都是老生常谈的，只要是增加系统的层级就一定会出现这些问题，还有什么其他的问题吗？ 我们先思考一个事情，这些东西是不是非 Node 不能做？...

因为想锻炼自己的英文能力，所以开始尝试阅读英文书，第一本便是这本小王子，其实选它的原因很简单，一是自己之前读过，大致情节都还记得些；二是因为小王子里面的词汇比较简单，阅读起来的压力会小一些。 第一次看的时候觉得内容蛮无厘头的，可能是因为自己当初太年轻，经历的事情太少了吧，再读这本书的时候，才渐渐明白小王子、玫瑰和狐狸都扮演着什么角色。曾经我也很好奇为什么小王子明明已经来到了地球，却仍然心心念他那个星球上的玫瑰。直到后来经历了和初恋分手，才渐渐明白，正因为小王子与玫瑰，彼此驯化，彼此需要，小王子和玫瑰对彼此来说才都是独一无二的，哪怕聪明如狐狸，也无法替代。 恋人该是如此，我与千千万万人中遇见你，本是沧海一粟，但正因为为你花过心思，付出真心，彼此陪伴，我们才变成彼此间心目中的独一无二。 扯的有点远了，整本书有很多金句，但是我最喜欢的是下面这句： What is a rite? Those also are actions too often neglected. They are what make one day different from other days, one hour from other hours. 仪式是什么？它就是使某一天与其他日子不同，使某一时刻与其他时刻不同。 生活还是多点仪式感的好，因为它代表你对生活的态度，这种态度，会让你活的更高级。简单说，就是会让你过的更幸福。 就像王小波说的：一个人只拥有此生此世是不够的，他还应该拥有诗意的世界。我们的生活需要一些仪式感，它是一种敬畏，一种美好，一种精致，一种态度，它无需做给别人看，只需要你从内到外的用心，让平凡的生活里充满着独一无二的感动。 希望自己可以以自己喜欢的方式过一生，不愧对别人，亦不辜负自己。

这本书是🐔哥送的， 是一本很薄的书， 讲的故事内容也很简单， 就是主人公维特来到了一个小镇， 在一次舞会上他认识了一个叫绿蒂的少女， 她的一颦一笑、 一举一动都让维特倾倒； 绿蒂也喜欢他， 却不能予以爱的回报， 她已与维特的好友订婚。 维特陷入了尴尬和痛苦， 他毅然离开此地， 力图从事业上得到解脱， 有所成就， 然而鄙陋的环境、 污浊的人际关系、 压抑个性窒息自由的现存秩序， 都使他无法忍受， 当他怀才不遇地重返绿蒂身边时， 发现绿蒂已结婚， 决定以死殉情， 于是用一支手枪结束了自己的生命（上述内容摘自豆瓣的内容简介）。 说实话， 我刚读完这本书的感觉就是这本书相当中二， 前半本的抒情真的让我感觉十分尴尬， 就跟小时候写作文老师让我描写一个人时的感觉一样， 类似——啊！ 她的眼睛多单纯啊！ 她真的好迷人啊！ 大自然多美啊！ 之类的。 后半本干脆就是直接在发牢骚了， 之前查资料的时候有说过拿破仑也曾看过这本书， 我真的无法想象他当时看这本书的心情。 我看豆瓣的评论时有人说这是西式的浪漫与伤感， 可能真的是因为我的文学素养不够吧， 我看见的不过是一个发春的中二少年无限的YY和碎碎念。 诚然主人公维特那种从心中涌动出的纯真的感情我们很多人都有过， 可早已不纯真的我们很难再有青春时期的那种细腻， 而且书中所描述的故事太过完美主义， 太过倾向纯洁， 兴许放在当时那个自杀是一种反宗教行为的时代， 会在有着巨大的影响力， 但流传至今后则明显是过誉太多了。 不过我也不是完全否定这本书， 有些字句个人感觉还是不错的， 这里做了一些摘抄。 这儿的人怎么样, 我只能回答： 跟到处一样！ 人类嘛都是一个模子铸出来的。 多数人为了生活, 不得不忙忙碌碌, 花去大部分时间; 剩下一点点余暇却使他们犯起愁来, 非想方设法打发掉不可。 这就是人类的命运啊！ 人从某些探索结果中得到的自慰， 其实只是一种梦幻者的怠惰， 正如一个囚居斗室的人， 把四面墙壁统统画上五彩缤纷的形象与光辉灿烂的景物一般。 我们人呵, 常常抱怨好目子如此少， 坏目子如此多依我想来， 这种抱怨多半都没有道理。 只要我们总是心胸开阔, 享受上每天赏赐给我们的欢乐, 那么, 我们也会有足够的力量承担一且到来的痛苦。 乖僻就跟惰性一样, 要知道它本来就是一种情性呵。 我们生来都是有此惰性的, 可是, 只要我们能有一次鼓起勇气克服了它, 接下去便会顺顺当当, 并在活动中获得真正的愉快。 世界上的一切事情, 说穿了全都无聊。 一个人要是没有热情， 没有需要， 仅仅为了他人的缘故去逐利追名， 苦苦折腾, 这个人便是傻瓜。 人之幸福， 全在于心之幸福。 我们生来就爱拿自己和其他人反反复复比较。 所以， 我们是幸福或是不幸， 全取决于我们与之相比的是些什么人。 所以， 最大最大的危险， 就莫过于孤身独处了。 我们的脑子生就是朝上想的， 加之受到诗里的幻境的激发， 便常常臆造出一些地位无比优越于我们的人来， 好像他们个个都比自己杰出， 个个都比自己完美。 而这似乎理所当然。 世间最纯粹、 最暖人胸怀的乐事， 恐怕莫过于看见一颗伟大的心灵对自己开诚相见吧。 以自己去衡量别人是很愚蠢的。 我们这些有教养的人， 实际上是被教养成了一塌糊涂的人！

官网：www.ytools.xyz 我个人对软件开发是有一定偏爱的，我的梦想就是能做出一款让所有人都用上的软件，「开挂Lite」就是这个大梦想的一次简单尝试。 保研结束后，时间相对充裕起来了，再加上毕业设计是要做一个风格迁移的小工具，所以干脆就想把这个工具的功能拓宽一点，于是便有了「开挂Lite」。 其实这个小程序的功能非常简单，就是提供一些日常生活中可能会使用到的工具，例如车辆识别、食物卡路里识别、QQ音乐下载等功能。 功能介绍什么的我就不多说了，直接看上面的图片吧。 名字和logo的由来 其实这个小程序刚做出来的时候想名字我也想了好久，但是总感觉哪里怪怪的，毕竟ios端有「捷径」，android端有「一个木函」，我这个小程序怎么也该有个能记住的名字啊，后来在和同学打游戏的时候遇到了几个开挂的，当时便想到既然游戏能靠程序开挂，生活为什么不能靠着程序开挂呢？ 相比名字，logo的由来就很简单了，灵感来自雷神1中索尔重新举起雷神之锤的场景，因为锤子代表的是工具，锤哥又是我最喜欢的超级英雄之一，所以干脆就借鉴了这个画面。这里说句题外话，logo的制作网站是https://www.designevo.com/， 下面简单说说这个小程序的架构吧 平台：微信 能力来源：百度AI，自己训练的模型 前端：html+css+js（官网）、微信小程序 后台：Flask,Nginx,Gunicorn,MySQL… 因为不是第一次做小程序了，遇到的坑还是比较少的，代码我就不公开了，有兴趣的可以加我微信和我交流，觉得好玩的可以点下小程序里面的广告，就当是给我支持了哈。 再谈点其他的 caoz在《你凭什么做好互联网》一书中提到了创业的四种冷启动方式：单点启动，单边启动，双边启动，多边启动，其难度和成本依次递增，而一旦启动成功，其竞争门槛则从低到高。 单点启动，简单说就是，一个人，一个客户，也能用起来。这种项目的特征非常明显，个体用户使用你的产品和服务时不会受到其他人、其他服务商的影响。因此对于一个穷学生/个人开发者，在没有资金注入、时间相对充裕的情况下，单点启动可以说是最好的选择了。因为这样的产品 ，启动推广可以慢慢来，不用担心说，我没有很多的用户，就会导致大量的流失，可以慢慢磨产品，针对每一个用户，客户的反馈去调整优化，直到产品打磨成熟，然后逐步推广做大。最常见的就是各种单机游戏、各种工具类应用。 很明显，「开挂Lite」就属于单点启动。不过就像开头说的，我只是把它当作是一次简单的尝试，并没有想着他能走多远，只要它真的可以为我、为周围人的生活带来一点点便捷，「开挂Lite」在我心中就已经成功了。

临近毕业，慢慢的也感伤起来，回想大学这几年，除了技术的成长，最值得庆幸的就是结交了一帮志同道合的好友。后期自己做了公众号，微信好友的数量也越来越多，身边人所扮演的角色也越来越丰富，有早已结婚生子为人父母的同学，有沉迷科研学术的教师，当然也少不了一众还在 996 的程序猿。事实上，你所处圈子的质量很大程度上就决定了你的人生质量，那么今天我们就来看看当 Python 遇到了你的微信好友后能擦出怎样的火花。 完整代码可在公众号：「01 二进制」后台回复：「微信好友」获取_ 前言 这次我们直奔主题，本文要做的是以下几件事： 分析微信好友的总人数、男生数、女生数、男女比 分析好友的地域分布 利用 自然语言处理 的方法分析出你好友的情感倾向 获取微信好友的头像并拼接成指定图片 准备 还是老样子，做实验前，先做好准备工作，实验环境如下： Python 3.6 （虚拟环境的管理为 Pipenv） Pycharm 主要使用到的包有： itchat pyecharts baidu-aip photomosaic pillow 对 Pipenv 这个虚拟环境管理工具不熟悉的可以去看我之前的文章：《Python 管理哪家强？》，里面对于 Pipenv 这个虚拟环境管理工具有一些介绍。 itchat 是一个开源的微信个人号接口，可以让我们使用 python 来调用微信 pyecharts 是 python+echarts 的结合，用于进行数据的可视化 baidu-aip 是百度推出的一个 nlp 的包 photomosaic 是用来生成蒙太奇马赛克图片的 大家获取到源码之后只需要将 Pipfile 复制到你们的项目根路径下，然后再终端执行 pipenv install 即可创建一个安装好所有包的虚拟环境了（前提是你的电脑上已经安装了 pipenv 了）...

深色模式（Dark Mode），也被称为暗黑模式，是一种高对比度，或者反色模式的显示模式，开启之后在夜间可以缓解疲劳，更易于阅读，同时也能在一定程度上达到省电的效果。iOS 和安卓分别从 iOS 13 和 Android 10（不同厂商不尽相同，部分 Android 9 也支持） 开始加入深色模式的支持，各大浏览器纷纷开始支持深色模式，强如微信也终于在 iOS 客户端 7.0.12、Android 客户端 7.0.13 支持了深色模式，等网页端适配深色模式后将更进一步提高用户体验的一致性。 Flutter 作为一个先进的跨平台框架，自然也考虑到了深色模式的使用，我在上一篇文章《Flutter 主题切换——让你的 APP 也能一键换肤》的结尾提到了Brightness brightness属性可用于适配跟随系统的 DarkMode，我们可以直接在MaterialApp的darkTheme选项中使用 MaterialApp( theme: ThemeData( brightness: Brightness.light, primaryColor: Colors.blue, ), darkTheme: ThemeData( brightness: Brightness.dark, ), ); 也可以写成： darkTheme: ThemeData.dark() 这样写的好处是，用户无需单独设置深/浅色模式，完全根据系统设置来切换。 但白天不懂夜的黑，有的人就是喜欢一套深色主题用一天，这时就需要用户可以手动开启深色模式了。 我们先来看下实现的效果： 手动开启深色模式 其实思路和上一篇文章类似，通过shared_preferences保存用户设置，通过Provider实现状态管理，这两个依赖的使用我在上一篇文章中已经介绍了，这里就不多说了。详情点击 👉Flutter 主题切换——让你的 APP 也能一键换肤。 添加依赖 我们在pubspec.yaml文件中添加如下内容： provider:^4.0.5flustars:^0.2.6+1深色模式状态管理类 import 'package:flustars/flustars.dart'; import 'package:flutter/material.dart'; import 'package:flutterchallenge/constant.dart'; class DarkModeProvider with ChangeNotifier { /// 深色模式 0: 关闭 1: 开启 2: 随系统 int _darkMode; int get darkMode => _darkMode; void changeMode(int darkMode) async { _darkMode = darkMode; notifyListeners(); SpUtil....

如果你希望你的 APP 走出海外，那么就需要你在编写代码时考虑支持不同的语言环境，设置一些“本地化”的值，例如文本/布局。Flutter 本身是具备国际化的，在适配方面也较为简单，今天我将会介绍一个名为Flutter Intl的插件快速实现 Flutter 的语言国际化。 Flutter Intl 之前在学习适配国际化的时候，出现最多的一个组件叫做flutter_i18n，不过由于一些原因，这个插件已经停止维护了，后来无意中发现了一个名为Flutter Intl的插件，我们只需要在 VSCode/Android Studio 中安装他即可。 添加依赖 默认情况下，Flutter 仅提供美国英语本地化。要添加对其他语言的支持，应用程序必须指定其他 MaterialApp 属性，并包含一个名为的单独包-“flutter_localizations”。 在pubspec.yaml中添加flutter_localizations依赖并执行packages get # 国际化 flutter_localizations: sdk: flutter 如下图所示： 初始化项目 接下来我们选择Tools -> Flutter Intl -> Initialize for the Project就会对项目进行初始化 初始化结束后，pubspec.yaml中会自动增加以下字段 flutter_intl: enabled: true 表示国际化已经开启。与此同时，lib目录下会新增generated和l10n两个目录。 l10n目录下为 arb 文件 generated目录下为根据 arb 文件自动生成以下 dart 代码 ARB 文件 ARB 文件扩展名为：Application Resource Bundle 意为应用程序资源包，并得到 Google 的支持，每个.arb文件都包含一个 JSON 表，该表从资源 ID 映射到本地化值，文件名包含已为其转换值的语言环境。 所以，如果我们想新增一门语言支持的话，只需要通过插件添加相应的 arb 文件即可。...