做人咧，最紧要系开心🥳
npm install xxx 利用 npm 安装xxx依赖到当前命令行所在目录npm install xxx -g 利用npm安装全局依赖xxxnpm install xxx –save 安装并写入package.json的”dependencies”中npm install xxx –save-dev 安装并写入package.json的”devDependencies”中npm uninstall xxx 删除xxx依赖npm uninstall xxx -g 删除全局依赖xxx去年6月份的时候，参加了微信小程序官方举办的《高校微信小程序开发大赛》，做出了《活力健身房》这个小程序。按照初版设计，除了可以检测用户的跑步数据外，还可以测量用户的静止心率。但由于个人除了要准备比赛，还要准备痛苦的概率论补考，所以导致日程太过于紧凑，因此在该情况下，我就只完成了第一个目标而忽略了第二个心率测量的目标没有实现。
在暑假期间，处于追求完美的想法，我花了一部分的时间继续学习并完成了心率检测算法的V1.0版本。而后再在这周，时隔一年的时间，重写了检测算法，推出了V1.1的版本。(至于为什么算是1.1版，在文中会说明的😂)。
今天我写这篇文章的主要目的是跟大家分享以下的三点内容：
光体积变化描记图法 (Photoplethysmography，简称PPG) 是借光电手段在活体组织中检测血液容积变化的一种无创检测方法。当一定波长的光束照射到指端皮肤表面，每次心跳时，血管的收缩和扩张都会影响光的透射 (例如在透射PPG中，通过指尖的光线) 或是光的反射 (例如在反射PPG中，来自手腕表面附近的光线)。当光线透过皮肤组织然后再反射到光敏传感器时，光照会有一定的衰减。像肌肉、骨骼、静脉和其他连接组织对光的吸收是基本不变的 (前提是测量部位没有大幅度的运动)，但是动脉会不同，由于动脉里有血液的脉动，那么对光的吸收自然也会有所变化。[1]
PPG检测的核心是通过心脏跳动影响血管中血液光线的吸收率变化，进而影响血液对光的反射率，估算受测者的心率数据。用人话说，心脏的跳动，会影响血液反射光的强度。反映到图表上，就如下图所示，心脏的舒张和收缩，会影响光强变化，形成下图的波动曲线。而心率的估算，则是通过计算60s内，有多少个波峰或者波谷。比如60s内，图表上产生了60个个波峰，则意味着1s中，心脏收缩和扩张了一次，即跳动了一次，进而可以得出60BPM的心率数据。
根据技术原理可以知道，PPG检测中我们需要做的事情是，计算一段时间内出现了多少个波峰，即可估算出受测者的心率。由此我们需要考虑实现以下的几个功能：
在当今社会中，人人都会有一台的智能手机。而手机上最好的颜色传感器就是摄像头了，因此在小程序端的实现中，对于数据的来源主要是摄像头。
为了实现方便，这次我依旧是使用小程序作为我的开发平台。之所以使用小程序的核心原因是官方提供了摄像头的API，使得我可以通过简单的$API$就可以获取到来自用户摄像头的视频流数据，并且不用考虑兼容性的问题。
在小程序中，我是用的是wx.createCameraContext()API来获取到视频流，同时借助onCameraFrame()来直接获取到每一帧的视频信息，极大的降低了开发的难度。通过前述的API，我们可以直接获取到当前帧Uint8数组，也就是每个像素的RGBA值。
为了避免外部光照影响血管对光线的反射，因此需要受测者的手指完全覆盖摄像头。为了检测摄像头是否覆盖，我们可以通过经验主义设定一个阈值，当每个像素的实际光强小于阈值，则代表传感器完全被覆盖，此时就可以开始测试。
通过API，我们可以获得视频流中特定的一帧的Uint8数据。之所以使用Uint8是因为在该RGBA中，每一个通道的颜色只有256种，而我们仅仅是需要获取该帧中的光强。因此选用Uint8可以大幅度减少运算量，提高运行效率。
通过经验主义的测量以及结合论文[2] [3]的理论支持，我们可知血液在红光和绿光的照射下的吸收率是最大的，也就意味着强度值是最大的。因此可以更好的检测到强度变化，所以在后续的开发当中，我们都将使用单个像素中的红绿通道的强度值，来作为数据的来源。由于只使用了其中两个通道的强度值，我们的运算量就可以几何级数减少。
从原来的232个数据转变为了216个数据
获取光强的方法是：
在1.0版本中我的实现方法是通过经验值测算出一条固定的基线，来判断历史采集的光强值，有多少个跃出基线的数据，就计作多少个波峰。
但这种设计是有问题的，比如最右侧的波峰，因为各种外部原因强度没有达到基线，导致丢失。当通过人眼的辨识，这个波峰不属于噪声，应该是要被记录的。
另外通过测试我们可以很容易的发现下图的假波峰和假波谷的噪声信号，这种变化幅度过大的数据也应该是被丢弃的。
因此在1.1版本中，基线的计算方法做了改进。通过动态基线可以适应复杂环境光线的变化，提高测量的效率和准确性。
通过动态基线，判断有多少多少次实际的跃出，进而换算出有多少个波峰。
仅仅记录波峰个数是远远不够的，我们还要计算一次跃出所消耗的时间(从波谷到跃出基线到波峰所消耗的时间)。因为受测者的光线环境如果不稳定，含有频繁的光线变化，则可能导致光强变化幅度过大，造成数据的计算误差。因此我们还需要将跃出时间作为计算的一个因素，计算平均的跃出时间。最后计算出每分钟的心率次数：
到目前为止，小程序端最大的难点不在于测量算法的开发上。反而是在优雅的展示上画了大量的时间。
1.FrameData大小。通过Camera组件，我们可以直接获取到手机的视频流。由于我们这个算法中仅仅需要计算帧的光强，所以仅仅需要最低质量的FrameData即可。即降低了资源的消耗也提升了算法运行的效率。通过frame-data属性，修改为small即可启用最低质量的FrameData。
2.Canvas绘图效率低。在去年小程序退出了Canvas 2D的绘图API，可以实现同层渲染。为了更高的渲染效率，我自然就是选择并使用了最新的API进行曲线的绘制。在电脑模拟器上的表现确实印证了效率更好的这一说法。但诡异的是在Android端上，Canvas2D的运行效率非常低，导致经常性假死，不知道怎么修复。因此只能暂时被搁置，待到日后有能力后再做修复。
这次的开发通过学习更多前人的研究结论来帮助我将算法优化出来，收获满满。感觉到非常的振奋人心。期待后面能继续搞点好玩的DEMO。
最近看到Tensorflow的BlazeFace。可以用很小的体积的模型来识别人脸，感觉可以借此，结合PPG算法，实现rPPG式的检测算法，日后有时间可以继续搞一下，感觉会非常的好玩。同时Canvas的问题也需要被修复，或许能够通过WebGL来修复?但是我还不肯定，需要后续的实验才能证明，待到后面再修吧。
由于本人不是电子工程专业，所以上文中可能会涉及到部分不规范的说明和解释。如果您能够在评论中帮助我指出来并帮助我改正，我将十分感激您，谢谢。
[1] ECG/PPG量测解决方案
[3] 血液成分对光吸收规律的实验研究
执行命令 Xcode-select --install
访问 Homebrew 官网，点击访问官网
按照指引，安装Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install 包名
brew uninstall 包名
brew info 包名
sudo brew update
brew search 包名
brew list
sudo brew install nginx
nginx
安装&启动完成后，从浏览器中输入localhost:8080即可访问到Nginx服务器的欢迎页面
nginx -s sotp
nginx -s reload
nginx -v
我作为一个从5.5时代就开始做php开发的开发者，也是第一次使用8.0的稳定版。直接一步到位的原因是：更好的语法&JIT的支持，希望能够在8.0时代获得更好的性能。因此本教程，将会采用8.0版本的PHP进行安装。
brew install php
如果需要特定版本的php则包名改为`php@指定的版本号`即可
php-fpm
php-fpmsudo pkill -INT -o php-fpm
通过brew info找到php配置文件的位置brew info php
vim php.ini
默认安装的PHP仅仅会在前台运行，如果此时我们关闭命令窗口的话，php-fpm将会自动关闭，无法继续处理我们的php请求。
开启 `守护模式` 即可解决这一问题
1. 配置php-fpm.confvim php-fpm.conf
2. 查找 daemonize
直接键入/daemonize
3. 修改值为yes并且保存daemonize = yes
虽然注释处，写了默认值应该为yes，但是不知道是什么原因，导致了默认值是no。
通过Homebrew安装的php，自带了pecl。这是一个php拓展的包管理器，后续的拓展安装，仅仅需要通过该管理器安装即可。一般开发用不到，主要是用于实现加密或者网络的时候，可能需要通过该tab来安装
pecl version 查看版本信息
pecl help 可以查看命令帮助
pecl search xdebug 搜索可以安装的扩展信息
pecl install xdebug 安装扩展
pecl install http://pecl.php.net/get/redis-4.2.0.tgz 安装指定版本扩展
brew info找到Nginx的配置目录vim nginx.conf
1. 修改启动端口为80
listen关键词server{
listen 8080; // Nginx需要监听的接口
server_name localhost;
...
}
server{
listen 80; // Nginx需要监听的接口
server_name localhost;
...
}
2. 修改默认入口文件
在index这一行中，加入index.php，将其也作为入口文件。
location / {
root html;
index index.html index.htm index.php;
}
3. 启用php流量转发
找到location ~.php$关键词，将注释删掉(删掉代码前面的’#’)，启用php流量转发
location ~ .php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}
4. 配置php流量转发规则
修改location ~.php$中的fastcgi_param配置项
将其从SCRIPT_FILENAME /scripts$fastcgi_script_name
修改为SCRIPT_FILENAME $document_root$fastcgi_script_name
nginx -V
nginx version: nginx/1.19.10 built by clang 12.0.0 (clang-1200.0.32.29) built with OpenSSL 1.1.1k 25 Mar 2021 TLS SNI support enabled configure arguments: ... --error-log-path=/opt/homebrew/var/log/nginx/error.log ...
找到error-log-path关键字，后面的值即为错误报告的地址。
使用tail -f 文件名查看即可。
nginx -t
ps -aux | grep nginx
Nginx服务器php-fpm服务brew info nginx查询网页根目录index.phpindex.php代码:
<?php phpinfo(); ?>
http://localhost/index.php若出现PHP Version + 版本号 以及 php相关的信息则安装完成
dmg安装包,点击访问我当前的系统版本是BigSur，如果你是Catalina也是兼容的，下载最新版就好了。
系统偏好设置的MySQL即可管理MySQL服务
mysql -v
mysql -u 用户名 -p
出现`Enter password`后输入你的密码回车，即可登录MySQL服务器。
exit
http://localhost/phpmyadmin即可command not found: mysql这是由于没有将mysql指令加入到命令行窗口中的原因
解决方法：
cd ～ 切换到用户目录vim .bash_profile 打开命令行配置文件export PATH=$PATH:/usr/local/mysql/binsource ~/.bash_profile加载配置文件这篇教程主要目的是为了帮助我记录下Mac系统中配置环境的流程而写。方便我日后如果需要重装或者更换电脑的时候可以快速将环境搭建完成。希望这篇教程也能帮助到你，谢谢。
由于最近在准备🐧厂的面试，被问及是否知道为什么url-loader将图片转换成Base64后，会有增加33%的数据量。因此，我开始从晚上搜集这方面的资料，但遗憾的是，大多的博文的关注点基本都是在实际应用(Webpack,前端优化…)或者是Base64如何进行编码，没有很清晰的阐述为什么会多出33%的数据量的过程和原因。因此，我希望可以通过这篇博文补充这方面的讯息。
当我们把3个Byte的数据转换成为Base64的字符时，根据Base64的规则，3个Byte的字符会转换成24个二进制位。Base64一位只有6个位二进制位，因此会产生4个Byte的字符。
但是现代计算机系统当中，一个字符要有8个二进制位来存储因此，4个字符对应的6个二进制位都要补充2个0，来转换成8个二进制位的字符存储到计算机当中。因此3个Byte(24位二进制位)的数据要用4个Byte(32位二进制位)来存储。并且32位中只有24位是用来存储数据的，剩下8位都是无用的补充位。
因此我们可以很简单的计算出输出:输入 = 4:3 (33% 数据冗余). 与此同时，我们同样可以总结出，输入n Bytes，输出就有(下图)那么长。
核心思路，原来三个Byte的数据，转换成Base64后，要用四个Byte来存储。多了1/3(33%)的数据要存储，所以数据量会增多。
把照片打包进bundle.js中，看来还是要因地制宜的。url-loader默认数值应该是8192bit(1024 byte)，增大33%后就是增加了300byte。因此，url-loader主要还是用于打包只有几个像素的小文件比较适合。不会对整体的加载速度有过多的影响。
今天闲逛”小程序开发社区”，无意中看到有一个同行贴出了以下的一段代码。
https://developers.weixin.qq.com/s/mqa4fHme7ZnX
从A页面当中跳转到B页面，点击按钮后，再返回上一页就不能触发按钮对应的事件了。
第一次渲染成功时，用户点击setData测试，按钮能正常触发事件(按钮内容变成setData成功)，点击”点击另外打开当前页面”按钮之后，跳转到新的页面。
此时nodeid发生变化，证实跳转到了新的页面。此时点击左上角的返回按钮后，原来的setData按钮无法触发事件。
从代码中我们很容易就能分析出，第一次渲染成功时，that和this指向的页面nodeid应该是acf9ce91,当我们跳转到第二个页面时，此时的that和this就变成了bd622626。
此时神奇的事情就发生了，当我们点击返回按钮回到上一个页面，我们就能看到that的输出值依然是 bd622626 ，但this的输出值就变回了 acf9ce91.
由此我的一个想法是,跳转页面只会初始化一个新的页面实例,而不是重新运行这个JS文件.
为了证明跳转页面后不是重新运行这个JS文件的想法,我在Page构造器的外部增加了如下的代码.
但我重新渲染页面时,console页面成功输出了2
证明第一次渲染时,小程序是运行过这个JS文件的。但当我们点击跳转到新的页面时，2没有继续出现，此时我认为小程序在新的页面当中，小程序是没有运行过这个JS文件的。
小程序为了实现对视图层标签的管控，开发了一套内置的框架”Exparser框架”。在该框架当中，页面的渲染是基于Exparser框架提供的Page和Component构造器的注入的数据的。
按照我的个人理解,启动的时候,小程序就已经提前把页面的模板注册好了。如果后面再次访问该页面时，仅仅是会基于页面模板创建出新的页面实例。也就是只有Page()构造器里面定义的data，在同一个页面下，实例与实例之间是独立的，但是Page外部定义的变量是共用的。
如果未来有能力的话，希望可以反编译一下小程序的基础库，从源码正向来理解小程序页面渲染的流程。
《操作系统》课程最近布置了一个大作业，要求我们每人实现一个非抢占式多级反馈队列调度算法的模拟程序，作为期末考核的一部分。(u1s1，真的是爽到，老师开心，我们也写的开心!)
//Powered By 7gugu
//每一级队列的可运行时间
let timeSlice = [1, 2, 3];
//准备运行的队列
let preRunQueue = [];
//3级运行队列
let runQueue = [
[],
[],
[]
];
//准备运行的程序[开始时间, 运行时间]
let progs = [
[0, 8],
[1, 4],
[5, 1],
[3, 7],
[4, 2]
];
for (let i = 0; i < progs.length; i++) {
let prog = {};
prog.id = "P" + i;
prog.startTime = progs[i][0];
prog.runTime = progs[i][1];
prog.priority = 0; //设置最高优先级
preRunQueue.push(prog); //把待运行的程序导入运行序列
}
//总运行时间
let totalTime = 0;
while (true) {
//如果待运行队列中仍然有程序 & 程序已到达开始时间
if (preRunQueue.length > 0) {
let prog = preRunQueue[0];
if (prog.startTime <= totalTime) {
preRunQueue.shift(); //直接弹出队头的元素
runQueue[0].push(prog); //把程序加入0级运行队列中
console.log(prog.id + "开始运行,开始时间为:" + totalTime);
}
}
for (let i = 0; i < runQueue.length; i++) {
//如果各级队列还有程序的话,就继续运行
if (runQueue[i].length > 0) {
let prog = runQueue[i].shift(); //获取各级队列中第一个程序
if (prog.runTime > timeSlice[i]) {
//程序运行时间比时间片大
totalTime = totalTime + timeSlice[i]; //总运行时间累加
prog.runTime = prog.runTime - timeSlice[i]; //减去每一次运行的时间
if (i != runQueue.length - 1) {
//如果未处于最低优先级,则把程序放在下一个优先级队列中
runQueue[i + 1].push(prog);
} else {
//如果处于最低优先级,则把程序放回最低优先级中运行
runQueue[i].push(prog);
}
} else {
//程序运行时间比时间片小
totalTime = totalTime + prog.runTime;
console.log(prog.id + "运行完成,目前时间为:" + totalTime);
}
break;
}
}
}
计算机操作系统(第四版) 西安电子科技出版社
//function
function x(a, b){
return a + b;
}
//箭头函数
const x = (a, b)=>{
return a + b;
}
使用function定义的函数，this的指向随着调用环境的变化而变化的，而箭头函数中的this指向是固定不变的，一直指向的是定义函数的环境。
function x(a, b){
console.log(this);
}
const obj = ()=>{
test: 7gugu,
}
x(); //Window
obj.test(); //obj { test: 7gugu }
使用function定义的函数中this指向是随着调用环境的变化而变化的
//使用箭头函数定义函数
var foo = () => { console.log(this) };
var obj = { aa:foo };
foo(); //Window
obj.aa(); //Window
明显使用箭头函数的时候，this的指向是没有发生变化的。
//使用function方法定义构造函数
function Person(name, age){
this.name = name;
this.age = age;
}
var lenhart = new Person(lenhart, 25);
console.log(lenhart); //{name: 'lenhart', age: 25}
//尝试使用箭头函数
var Person = (name, age) =>{
this.name = name;
this.age = age;
};
var lenhart = new Person('lenhart', 25); //Uncaught TypeError: Person is not a constructor
function是可以定义构造函数的，而箭头函数是不行的。
由于js的内存机制，function的级别最高，而用箭头函数定义函数的时候，需要var(let const定义的时候更不必说)关键词，而var所定义的变量不能得到变量提升，故箭头函数一定要定义于调用之前！
foo(); //123
function foo(){
console.log('123');
}
arrowFn(); //Uncaught TypeError: arrowFn is not a function
var arrowFn = () => {
console.log('456');
};
转载自:https://blog.csdn.net/github_38851471/article/details/79446722
最近上线Vue项目到服务器,上传之后就出现了,代理404的问题。Dev环境中的代理是工作正常的,这点让我很疑惑,但这恰巧是我的一个误解,下面是这次的解决思路。
一开始,我以为vue.config.js中的,devServer中的proxy是在路由(Router)层面做的数据转发,所以在这上面花了一些时间进行研究。后续通过查阅官方文档发现,devServer配置的是一个nodejs的测试服务器参数,而不是路由参数后,恍然大悟。(这就是我的误解所在）
解决这个proxy的方向,应该是关注于配置自身的HTTP服务器的代理上面,如果是Nginx,就要配置Nginx的路由转发;我这里用的是Apache作为我的HTTP服务器,所以应该配置的是对应的代理参数。
1.打开Apache的httpd.conf,开启以下两个proxy拓展,保存
LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so
2.在https.conf中配置监听接口,保存
3.打开httpd-vhost.conf如下图配置即可
4.此时HTTP服务器部分就配置完成了,此时仅需重启Apache服务器即可生效。
因为是使用了History模式的路由,所以为了正确路由到相关的页面,还需要配置相关的PathRewrite才能正确路由。
1.在vue生成生产环境文件的文件夹中,添加.htaccess文件(我使用的是默认参数,所以就在dist文件夹中)
2.配置以下参数即可。(参数参考官方文档进行配置)
3.至此Vue部分配置完成,重新访问404的问题就消除了。
最近在给工作室打工的时候,Vue做了个静态路由懒加载。
然后编译的时候死活不认这个import,截图如下,完全没有解决的思路。
