search.xml

<?xml version="1.0" encoding="utf-8"?>
<search>
  <entry>
    <title>归来后第一篇博客</title>
    <url>/2020/04/16/my-first-blog/</url>
    <content><![CDATA[<p>我的第一篇博客</p>
<h1 id="一级标题"><a href="#一级标题" class="headerlink" title="一级标题"></a>一级标题</h1><h2 id="二级标题"><a href="#二级标题" class="headerlink" title="二级标题"></a>二级标题</h2><h3 id="三级标题"><a href="#三级标题" class="headerlink" title="三级标题"></a>三级标题</h3><h4 id="四级标题"><a href="#四级标题" class="headerlink" title="四级标题"></a>四级标题</h4><h5 id="五级标题"><a href="#五级标题" class="headerlink" title="五级标题"></a>五级标题</h5><h6 id="六级标题"><a href="#六级标题" class="headerlink" title="六级标题"></a>六级标题</h6><p><em>斜体文本</em><br><strong>粗体文本</strong><br><strong><em>粗斜体文本</em></strong></p>
<hr>
<hr>
<hr>
<p><del>文本</del><br><u>这是一个有下划线的文本</u></p>
]]></content>
  </entry>
  <entry>
    <title>vue.js关于mvvm和mvc</title>
    <url>/2019/11/10/vue-js%E5%85%B3%E4%BA%8Emvvm%E5%92%8Cmvc/</url>
    <content><![CDATA[<h1 id="1-在看mvc和mvvm的区别之前我们来看一下前端的发展历史"><a href="#1-在看mvc和mvvm的区别之前我们来看一下前端的发展历史" class="headerlink" title="1.在看mvc和mvvm的区别之前我们来看一下前端的发展历史"></a>1.在看mvc和mvvm的区别之前我们来看一下前端的发展历史</h1><p>最早的HTML页面是完全静态的网页，它们是预先编写好的存放在Web服务器上的html文件。浏览器请求某个URL时，Web服务器把对应的html文件扔给浏览器，就可以显示html文件的内容了。</p>
<p>有了JavaScript后，浏览器就可以运行JavaScript，然后，对页面进行一些修改。JavaScript还可以通过修改HTML的DOM结构和CSS来实现一些动画效果，而这些功能没法通过服务器完成，必须在浏览器实现。</p>
<p>用JavaScript在浏览器中操作HTML，经历了若干发展阶段：<br>第一阶段，直接用JavaScript操作DOM节点，使用浏览器提供的原生API：<br>第二阶段，由于原生API不好用，还要考虑浏览器兼容性，jQuery横空出世，以简洁的API迅速俘获了前端开发者的芳心：<br>第三阶段，MVC模式，需要服务器端配合，JavaScript可以在前端修改服务器渲染后的数据。<br>现在，随着前端页面越来越复杂，用户对于交互性要求也越来越高，想要写出Gmail这样的页面，仅仅用jQuery是远远不够的。MVVM模型应运而生。</p>
<p>MVVM最早由微软提出来，它借鉴了桌面应用程序的MVC思想，在前端页面中，把Model用纯JavaScript对象表示，View负责显示，两者做到了最大限度的分离。</p>
<h1 id="2-现在让我们从MVC开始"><a href="#2-现在让我们从MVC开始" class="headerlink" title="2.现在让我们从MVC开始"></a>2.现在让我们从MVC开始</h1><p>几乎所有的App都只干这么一件事：将数据展示给用户看，并处理用户对界面的操作。<br>MVC的思想：一句话描述就是Controller负责将Model的数据用View显示出来，换句话说就是在Controller里面把Model的数据赋值给View</p>
<h2 id="M、V、C"><a href="#M、V、C" class="headerlink" title="M、V、C"></a>M、V、C</h2><h3 id="Model（模型）：是应用程序中用于处理应用程序数据逻辑的部分。"><a href="#Model（模型）：是应用程序中用于处理应用程序数据逻辑的部分。" class="headerlink" title="Model（模型）：是应用程序中用于处理应用程序数据逻辑的部分。"></a>Model（模型）：是应用程序中用于处理应用程序数据逻辑的部分。</h3><p>　　　　通常模型对象负责在数据库中存取数据。</p>
<figure class="highlight plain"><table><tr><td class="code"><pre><span class="line">在代码中体现为数据管理者，Model负责对数据进行获取及存放。</span><br><span class="line">数据不可能凭空生成的，要么是从服务器上面获取到的数据，要么是本地数据库中的数据，</span><br><span class="line">也有可能是用户在UI上填写的表单即将上传到服务器上面存放，所以需要有数据来源。</span><br><span class="line">既然Model是数据管理者，则自然由它来负责获取数据。</span><br><span class="line">Controller不需要关心Model是如何拿到数据的，只管调用就行了。</span><br><span class="line">数据存放的地方是在Model，而使用数据的地方是在Controller，</span><br><span class="line">所以Model应该提供接口供controller访问其存放的数据（通常通过.h里面的只读属性）</span><br></pre></td></tr></table></figure>


<h3 id="View（视图）：是应用程序中处理数据显示的部分。"><a href="#View（视图）：是应用程序中处理数据显示的部分。" class="headerlink" title="View（视图）：是应用程序中处理数据显示的部分。"></a>View（视图）：是应用程序中处理数据显示的部分。</h3><p>　　　　通常视图是依据模型数据创建的。</p>
<figure class="highlight plain"><table><tr><td class="code"><pre><span class="line">它们有一部分是我们UI定死的，也就是不会根据数据来更新显示的，</span><br><span class="line">比如一些Logo图片啊，这里有个按钮啊，那里有个输入框啊，一些显示特定内容的label啊等等；</span><br><span class="line">有一部分是会根据数据来显示内容的，比如tableView来显示好友列表啊，</span><br><span class="line">这个tableView的显示内容肯定是根据数据来显示的。</span><br><span class="line">我们使用MVC解决问题的时候，通常是解决这些根据数据来显示内容的视图。</span><br></pre></td></tr></table></figure>

<h3 id="Controller（控制器）：是应用程序中处理用户交互的部分。"><a href="#Controller（控制器）：是应用程序中处理用户交互的部分。" class="headerlink" title="Controller（控制器）：是应用程序中处理用户交互的部分。"></a>Controller（控制器）：是应用程序中处理用户交互的部分。</h3><p>　　　　通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。</p>
<figure class="highlight plain"><table><tr><td class="code"><pre><span class="line">也就是在Controller里面把Model的数据赋值给View来显示</span><br><span class="line">（或者是View接收用户输入的数据然后由Controller把这些数据传给Model来保存到本地或者上传到</span><br><span class="line">服务器）。</span><br></pre></td></tr></table></figure>

<h2 id="综合以上内容，实际上你应该可以通过面向对象的基本思想来推导出controller出现的原因：我们所有的App都是界面和数据的交互，所以需要类来进行界面的绘制，于是出现了View，需要类来管理数据于是出现了Model。我们设计的View应该能显示任意的内容比如页面中显示的文字应该是任意的而不只是某个特定Model的内容，所以我们不应该在View的实现中去写和Model相关的任何代码，如果这样做了，那么View的可扩展性就相当低了。而Model只是负责处理数据的，它根本不知道数据到时候会拿去干啥，可能拿去作为算法噼里啪啦去了，可能拿去显示给用户了，它既然无法接收用户的交互，它就不应该去管和视图相关的任何信息，所以Model中不应该写任何View相关代码。然而我们的数据和界面应该同步，也就是一定要有个地方要把Model的数据赋值给View，而Model内部和View的内部都不可能去写这样的代码，所以只能新创造一个类出来了，取名为Controller。"><a href="#综合以上内容，实际上你应该可以通过面向对象的基本思想来推导出controller出现的原因：我们所有的App都是界面和数据的交互，所以需要类来进行界面的绘制，于是出现了View，需要类来管理数据于是出现了Model。我们设计的View应该能显示任意的内容比如页面中显示的文字应该是任意的而不只是某个特定Model的内容，所以我们不应该在View的实现中去写和Model相关的任何代码，如果这样做了，那么View的可扩展性就相当低了。而Model只是负责处理数据的，它根本不知道数据到时候会拿去干啥，可能拿去作为算法噼里啪啦去了，可能拿去显示给用户了，它既然无法接收用户的交互，它就不应该去管和视图相关的任何信息，所以Model中不应该写任何View相关代码。然而我们的数据和界面应该同步，也就是一定要有个地方要把Model的数据赋值给View，而Model内部和View的内部都不可能去写这样的代码，所以只能新创造一个类出来了，取名为Controller。" class="headerlink" title="综合以上内容，实际上你应该可以通过面向对象的基本思想来推导出controller出现的原因：我们所有的App都是界面和数据的交互，所以需要类来进行界面的绘制，于是出现了View，需要类来管理数据于是出现了Model。我们设计的View应该能显示任意的内容比如页面中显示的文字应该是任意的而不只是某个特定Model的内容，所以我们不应该在View的实现中去写和Model相关的任何代码，如果这样做了，那么View的可扩展性就相当低了。而Model只是负责处理数据的，它根本不知道数据到时候会拿去干啥，可能拿去作为算法噼里啪啦去了，可能拿去显示给用户了，它既然无法接收用户的交互，它就不应该去管和视图相关的任何信息，所以Model中不应该写任何View相关代码。然而我们的数据和界面应该同步，也就是一定要有个地方要把Model的数据赋值给View，而Model内部和View的内部都不可能去写这样的代码，所以只能新创造一个类出来了，取名为Controller。"></a>综合以上内容，实际上你应该可以通过面向对象的基本思想来推导出controller出现的原因：我们所有的App都是界面和数据的交互，所以需要类来进行界面的绘制，于是出现了View，需要类来管理数据于是出现了Model。我们设计的View应该能显示任意的内容比如页面中显示的文字应该是任意的而不只是某个特定Model的内容，所以我们不应该在View的实现中去写和Model相关的任何代码，如果这样做了，那么View的可扩展性就相当低了。而Model只是负责处理数据的，它根本不知道数据到时候会拿去干啥，可能拿去作为算法噼里啪啦去了，可能拿去显示给用户了，它既然无法接收用户的交互，它就不应该去管和视图相关的任何信息，所以Model中不应该写任何View相关代码。然而我们的数据和界面应该同步，也就是一定要有个地方要把Model的数据赋值给View，而Model内部和View的内部都不可能去写这样的代码，所以只能新创造一个类出来了，取名为Controller。</h2><p>
<img src="https://upload-images.jianshu.io/upload_images/7770244-f4fc955f1488299a.png?imageMogr2/auto-orient/strip|imageView2/2/w/1127/format/webp">
</p>]]></content>
  </entry>
  <entry>
    <title>配置统计数据出现的问题</title>
    <url>/2019/11/09/%E9%85%8D%E7%BD%AE%E7%BB%9F%E8%AE%A1%E6%95%B0%E6%8D%AE%E5%87%BA%E7%8E%B0%E7%9A%84%E9%97%AE%E9%A2%98/</url>
    <content><![CDATA[<h1 id="hexo配置统计数据出现的问题-不蒜子"><a href="#hexo配置统计数据出现的问题-不蒜子" class="headerlink" title="hexo配置统计数据出现的问题-不蒜子"></a>hexo配置统计数据出现的问题-不蒜子</h1><br>
在引用不蒜子作为静态网站的博客的统计功能的时候发现无法显示，在查阅了相关的资料之后发现，由于域名地址的更换，需要重新配置。
<figure class="highlight plain"><table><tr><td class="code"><pre><span class="line">与客服沟通数次无果，即使我提出为此付费也不行，只能更换域名到『busuanzi.ibruce.info』！</span><br><span class="line">因我是最早的一批七牛用户，为七牛至少带来了数百个邀请用户，很痛心，很无奈！</span><br><span class="line">各位继续使用不蒜子提供的服务，只需把原有的：</span><br><span class="line">&lt;script async src=&quot;

//dn-lbstatics.qbox.me/busuanzi/2.3/busuanzi.pure.mini.js&quot;&gt;&lt;/script&gt;</span><br><span class="line">域名改一下即可：</span><br><span class="line">&lt;script async src=&quot;

//busuanzi.ibruce.info/busuanzi/2.3/busuanzi.pure.mini.js&quot;&gt;&lt;/script&gt;</span><br><span class="line">只需要修改该js域名，其他均未改变。若有疑问，可以加入不蒜子交流QQ群：`419260983`，</span><br><span class="line">对您带来的不便，非常抱歉！！！还是那句话，不蒜子不会中断服务！！！！</span><br></pre></td></tr></table></figure>
<br>
修改NexT的配置的方法如下：
<p>

</p><p><code>&lt;script async src=&quot;https://dn-lbstatics.qbox.me/busuanzi/2.3/busuanzi.pure.mini.js&quot;&gt;&lt;/script&gt;</code></p>
<p>修改为:</p>
<p><code>&lt;script async src=&quot;https://busuanzi.ibruce.info/busuanzi/2.3/busuanzi.pure.mini.js&quot;&gt;&lt;/script&gt;</code></p>
<p>测试效果成功。</p>
]]></content>
      <tags>
        <tag>编程</tag>
        <tag>前端</tag>
      </tags>
  </entry>
  <entry>
    <title>前端面试题</title>
    <url>/2019/11/05/%E5%89%8D%E7%AB%AF%E9%9D%A2%E8%AF%95%E9%A2%98/</url>
    <content><![CDATA[<h1 id="HTML问题"><a href="#HTML问题" class="headerlink" title="HTML问题"></a>HTML问题</h1><h2 id="HTML5语义化"><a href="#HTML5语义化" class="headerlink" title="HTML5语义化"></a>HTML5语义化</h2><p>什么是语义化？就是用合理、正确的标签来展示内容，比如h1~h6定义标题。</p>
<p>好处<br>易于用户阅读，样式丢失的时候能让页面呈现清晰的结构。<br>有利于SEO，搜索引擎根据标签来确定上下文和各个关键字的权重。<br>方便其他设备解析，如盲人阅读器根据语义渲染网页<br>有利于开发和维护，语义化更具可读性，代码更好维护，与CSS3关系更和谐。</p>
<p>在移动端浏览器当中，存在着两种视口，一种是可见视口（也就是我们说的设备大小），另一种是视窗视口（网页的宽度是多少）。 举个例子：如果我们的屏幕是320像素 * 480像素的大小（iPhone4），假设在浏览器中，320像素的屏幕宽度能够展示980像素宽度的内容。那么320像素的宽度就是可见视口的宽度，而能够显示的980像素的宽度就是视窗视口的宽度。</p>
<p>为了显示更多的内容，大多数的浏览器会把自己的视窗视口扩大，简易的理解，就是让原本320像素的屏幕宽度能够容下980像素甚至更宽的内容（将网页等比例缩小）。</p>
<h2 id="Viewport属性值"><a href="#Viewport属性值" class="headerlink" title="Viewport属性值"></a>Viewport属性值</h2><ul>
<li>width 设置layout viewport 的宽度，为一个正整数，或字符串”width-device”</li>
<li>initial-scale 设置页面的初始缩放值，为一个数字，可以带小数</li>
<li>minimum-scale 允许用户的最小缩放值，为一个数字，可以带小数</li>
<li>maximum-scale 允许用户的最大缩放值，为一个数字，可以带小数</li>
<li>height 设置layout viewport 的高度，这个属性对我们并不重要，很少使用</li>
<li>user-scalable 是否允许用户进行缩放，值为”no”或”yes”, no 代表不允许，yes代表允许这些属性可以同时使用，也可以单独使用或混合使用，多个属性同时使用时用逗号隔开就行了。</li>
</ul>
<h2 id="Reflow和Repaint"><a href="#Reflow和Repaint" class="headerlink" title="Reflow和Repaint"></a>Reflow和Repaint</h2><p>Reflow<br>当涉及到DOM节点的布局属性发生变化时，就会重新计算该属性，浏览器会重新描绘相应的元素，此过程叫Reflow（回流或重排）。</p>
<p>Repaint<br>当影响DOM元素可见性的属性发生变化 (如 color) 时, 浏览器会重新描绘相应的元素, 此过程称为Repaint（重绘）。因此重排必然会引起重绘。</p>
<p>引起Repaint和Reflow的一些操作</p>
<ul>
<li>调整窗口大小</li>
<li>字体大小</li>
<li>样式表变动</li>
<li>元素内容变化，尤其是输入控件</li>
<li>CSS伪类激活，在用户交互过程中发生</li>
<li>DOM操作，DOM元素增删、修改</li>
<li>width, clientWidth, scrollTop等布局宽高的计算</li>
<li>Repaint和Reflow是不可避免的，只能说对性能的影响减到最小，给出下面几条建议：</li>
<li>避免逐条更改样式。建议集中修改样式，例如操作className。</li>
<li>避免频繁操作DOM。创建一个documentFragment或div，在它上面应用所有DOM操作，最后添加到文档里。设置display:none的元素上操作，最后显示出来。</li>
<li>避免频繁读取元素几何属性（例如scrollTop）。绝对定位具有复杂动画的元素。</li>
<li>绝对定位使它脱离文档流，避免引起父元素及后续元素大量的回流<br></li>
</ul>
]]></content>
      <tags>
        <tag>编程</tag>
        <tag>前端</tag>
      </tags>
  </entry>
  <entry>
    <title>第一篇博客</title>
    <url>/2019/11/05/%E7%AC%AC%E4%B8%80%E7%AF%87%E5%8D%9A%E5%AE%A2/</url>
    <content><![CDATA[<br>
序言
希望未来能够不断建设好这个博客，把自己的知识和见解，分享到博客上。

<p>计划<br>目前打内容的方向还没有确定，前期可能会以教程、日记为主，后期可能会转型成视频。github的功能还没有全部掌握，hexo框架还有许多一些功能未开发，比如留言板、搜索栏、子页面栏目。但我相信只要每天能够进步一点点，日后就会是很大的进步。</p>
<p>感谢身边帮助我的小伙伴！</p>
]]></content>
  </entry>
</search>