由于Android系统的开放性，任何用户、开发商、OEM厂商、运营商都可以对Android进行定制，修改成他们想要的样子，导致碎片化严重。Android手机的分辨率和尺寸千奇百怪，同样的软件在不同的手机上UI表现难以达到一致的效果，所以需要进行屏幕适配，针对不同的设备做一个比较统一的方案。先要搞清楚的问题就是什么是屏幕尺寸？什么是屏幕分辨率？什么是屏幕像素密度？还有开发中的各种单位的意义，关于屏幕适配的各种解决方案，布局适配与图片适配，在图片适配方案主要是记述了.9图的使用和制作。



# 基本概念

什么是**屏幕尺寸**？屏幕尺寸指屏幕的对角线的长度，单位是英寸，1英寸=2.54厘米，常见尺寸:2.4，2.8，3.5，3.7，4.2，5.0，5.5，6.0等。

什么是**屏幕分辨率**？屏幕分辨率是指在横纵向上的像素点数，单位是px，1px=1个像素点，一般以纵向像素×横向像素，如：1920×1080。

什么是**屏幕像素密度**？在尺寸一定的情况下分辨率越高则屏幕越清晰，屏幕像素密度越大！屏幕像素密度是指每英寸上的像素点数，单位是dpi，即"dot per inch”的缩写。屏幕像素密度与屏幕尺寸和屏幕分辨率有关。比如对于两个都是5寸的手机来说，A手机是1280×720的分辨率，B手机是1920×1020的分辨率，那么也就意味着B手机可以显示得更清晰，B手机得像素密度也越大。

![](https://img.zouchanglin.cn/20201130211848.png-zouchanglin.cn)

# 常用单位

## dpi（屏幕像素密度）

屏幕像素密度是指每英寸上的像素点数，单位是dpi，即”dot per inch“的缩写。上面已经说过了，不再赘述。

## px（像素点）

pixel的缩写，像素，1px代表屏幕上一个物理的像素点。上面已经说过了，不再赘述。

## dip、dp（密度无关像素）

dip、dp：都是Density Independent Pixels的缩写，即密度无关像素，在像素密度为160dpi的情况下，1dp = 1px，但是在像素密度为320dpi的情况下，1dp = 2px，这就成为了比例关系：

![](https://img.zouchanglin.cn/20201130212339.png-zouchanglin.cn)

所以，1dp = （手机实际像素密度 / 160dpi）× 1px，换算公式则为：

pxValue = （手机实际像素密度 / 160dpi）× dpValue
> **dp的范围划分**


| 名称                 | 像素密度范围  |
| :------------------- | ------------- |
| mdpi（中密度）       | 120dpi~160dpi |
| hdpi（高密度）       | 160dpi~240dpi |
| xhdpi（超高密度）    | 240dpi~320dpi |
| xxhdpi（超超高密度） | 320dpi~480dpi |
| xxxhdpi（最高密度）  | 480dpi~640dpi |


## sp（设置字体大小）

sp：scaled pixels, 与dp类似，用于设置字体大小。

# 屏幕适配

## 布局适配
1、禁用绝对布局
2、少用px
3、使用wrap_content、match_parent、layout_weight
4、重建布局文件

## 图片适配

1、提供不同分辨率的备用位图（美工做的）
2、使用自动拉伸图

自动拉伸图主要是指.9图，它是Android App开发里一种特殊的图片形式，文件的扩展名为：.9.png。.9图片的作用就是在图片拉伸的时候保证其不会失真。所以使用.9图片，让图片在指定的位置拉伸和在指定的位置显示内容，这样图片的边边角角就不会出现失真了。 

![](https://img.zouchanglin.cn/20201201170652.png-zouchanglin.cn)

上面那一部分是原始效果，下面那一部分是使用.9图的效果。

```xml
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    tools:context=".MainActivity">

    <TextView
        android:text="@string/tv_content"
        android:gravity="center"
        android:textSize="30sp"
        android:background="@drawable/other"
        android:layout_width="match_parent"
        android:layout_height="400dp"/>
    
    <TextView
        android:text="@string/tv_content"
        android:gravity="center"
        android:textSize="30sp"
        android:background="@drawable/dialog"
        android:layout_width="match_parent"
        android:layout_height="wrap_content" />

  </LinearLayout>
```

现在有一张图片那么如何制作.9图呢？

![](https://img.zouchanglin.cn/20201201171129.png-zouchanglin.cn)

选择Create 9-Patch file…选项之后，会弹出选择保存位置的对话框，可以自己选择修改位置，一般都直接选择OK即可，然后打开这个.9图：

![](https://img.zouchanglin.cn/20201201171529.png-zouchanglin.cn)

所以关于屏幕适配的问题做一下总结：

![](https://img.zouchanglin.cn/20201201171830.png-zouchanglin.cn)

Android屏幕适配

接着上一篇文章[《手写一个Hexo评论系统（一）》](https://zouchanglin.cn/2020/11/26/16902.html)，本篇文章主要是讲述记述评论系统实现的一些具体的设计方案与技术细节，方便以后修改或者重构。还有项目的部署问题，包括域名解析，Nginx配置代理，云服务器选购的一些问题，选购服务器的坑是真的大，所以还是尽量选择大厂，稳定一点，好用一点就不用在乎多几那块钱嘛，而且根据自己的需要买配置还是比较划算的。



上次总共列出了如下的一些需求，根据这些需求来构想一下如何设计：

**1、无需登录和验证码，直接评论即可**

**2、支持回复评论，且可无限递归回复**

**3、支持评论点赞，按照点赞排序，相同则按照时间排序**

**3、支持文章评分，显示评分人数和评分的平均分数**

**4、支持自己的评论被别人回复后可以邮件通知**

**5、支持评论后台管理系统，可以设置对应属性**

**6、支持评论导出，且高度100%可恢复数据**

# 界面与UI设计

![](https://img.zouchanglin.cn/20201127161834.png-zouchanglin.cn)

第一版得UI就长这样了，整体看起来风格比较简单，这也是我比较喜欢的风格。在文章加载后评论者会获得一个随机的昵称与头像，点击昵称可以切换昵称和头像，不过都是随机的而已。然后就是三个输入框，邮箱输入框、评论内容、文章评分。所以从整体上分成了两部分，一部分是用户信息和评论框，另一部分是具体评论展示区域，只要思考清楚了那么就可以开始了。

反正是做PC的Web端UI嘛，直接上ElementUI了，其实还真的挺适合的，尤其是在展示具体评论的时候按照时间线来展示最合适不过了，而且评分组件也很OK，挺好看的，以后有时间再拿其他的组件库试试！

# 交互流程设计

首先用户要一打开博客就可以获得随机头像和昵称，并且要保持这个用户的状态，所以整体思路如下：

![](https://img.zouchanglin.cn/20201127170329.png-zouchanglin.cn)

首先对于一个从未打开过某篇博客的页面的用户来说，在浏览器端存储的clientID肯定是没有这个字段的，直接可以判定为新用户，所以去请求后台给一个ClientID，并且分配随机的昵称和头像，把这个用户信息给落库，即使用户点击了刷新昵称和头像，但是ClientID并没有变，用户信息就这样得以保存了下来。如果浏览器已经存在了ClientID，那么数据库里面也应该有对应的用户信息，所以就直接请求后台拿到用户数据即可。

第二个问题，后端怎么知道哪些评论是哪些博客的呢？其实这里使用了一个比较简略的方式，那就是直接根据URL来判断，相同的URL肯定是同一篇博客，但是这样做也是有缺陷的，就是在本地调试的时候是localhost:8080开头，但是远程是zouchanglin.cn，这样在本地的测试数据就不会展示在正式的博客评论上。而且zouchanglin.cn和zouchanglin.gitee.io的评论并不相通，其实这是不合理的，应该把域名和剩余部分URL分离出来，这样通用性才会更好，这一点以后有时间了我会进行重构。

第三个问题，用户设置了邮箱那么怎么才能回复的时候相互通知呢？其实对这样的Client端设计，只要在用户填写了邮箱后，进行评论或者回复的操作，都可以设置邮箱，因为这样可以从很大程度上减少业务复杂度，只要你的邮箱出现变更，你的下一次评论想到得到通知的时候肯定会填写新的邮箱，这样就可以直接更新整个用户的邮箱，非常方便。

# 数据库设计

数据库使用MySQL 8.0。首先是设计客户端信息表，也就是代表了用户信息(主要包括了客户端ID、Email、昵称、创建时间、头像、客户端OS等信息，其他字段等有需要再添加就OK)：

![](https://img.zouchanglin.cn/20201127172526.png-zouchanglin.cn)然后是文章信息表（主要字段是文章URL、文章评论数），一条数据对应着一条博客，其中还有博客的评论总计数目，其实完全可以拿URL做主键，但是为了以后改动方便，目前还是决定自定义生成主键比较好一些。

然后是评论表，在这里我把评论分成了两种类型，一种是文章评论（主要字段是文章ID、comment_parent是无效字段、评论客户端ID、评论内容、点赞数、创建时间、文章评分），也就是直接在文章下面的评论；另一种是子评论（主要字段是所在的文章评论ID、评论客户端ID、评论内容、点赞数、回复的客户端ID、创建时间），这个就是文章评论的回复而已，当然无论是文章评论的子评论还是子评论的回复评论都被当作子评论来存储，所有分了两张表。唯一不同之处在于文章评论会存储自己是那一篇文章下的评论，而子评论会存储自己位于哪一条文章评论底下，而且会存储回复的Client是谁，所以还存储了reply_client这个字段。

# 后端系统设计

点击此处直到后端代码仓库：[https://gitee.com/zouchanglin/comment-box](https://gitee.com/zouchanglin/comment-box)

后端系统还是基于SpringBoot搭建的后端服务，其实用的都是比较常见的技术，SpringMVC、SpringDataJPA等，平时用的比较少的就是邮件发送服务，其实使用spring-boot-starter-mail来发送邮件简直不要太容易。需要注意的就是后端的跨域问题，需要配置一个允许跨域的配置类，但是后面部署的时候推荐使用Nginx同域部署，跨域问题也就不存在了，这是我目前最喜欢的方案。

# 项目部署问题

## 1、云服务购买

还是比较推荐腾讯云88/年，百度云太贵、阿里云用过了。腾讯云学生及还是可以买一买的，1核2G的配置，其实完全够用了。刚开始脑子抽搐了买个天翼云，虽然才77元/年，但是难用的要死，而且最高速度也就130K/s，这谁受得了这么慢的速度。还是宁愿多花几块钱买个好一点的呀，毕竟大厂靠谱。**千万别买天翼云呀，千万别买天翼云呀，千万别买天翼云呀**，重要的事情说三遍。

## 2、解决HTTPS问题

整个代码其实都已经写好了，就剩一个部署了，但是由于我的网站全是HTTPS的，所以评论系统也必须是HTTPS的，否则由于浏览器的安全策略会导致评论模块无法加载。于是乎通过域名解析了一个二级域名comment.zouchanglin.cn到服务器上，为这个二级域名申请一个证书，这样就完全OK了。

## 3、Nginx部署

前端项目打包后直接使用Nginx部署一下，顺便把HTTPS证书配置一下，这样前端项目就可以HTTPS访问了，那么后端呢？不可能有`https://comment.zouchanglin.cn:8080`这种URL存在吧，所以还是通过Nginx很轻松的解决了这个问题，只要通过Nginx配置一个代理，100%搞定，而且彻底、一劳永逸地解决了跨域问题，并且共享域名，还利用反向代理隐藏了后端地址，比较方便集中管理。

所以我个人还是非常推荐采用Nginx将前后端同域部署的，Nginx真的帮了大忙！

后端项目application.yml配置如下，其实就是访问路径都变成了`http://127.0.0.1:8080/api/....`

```yml
server:
    port: 8080
    servlet:
        context-path: /api
```

前端项目记得关闭History模式，然后请求的基础URL就写成了：

```
axios.defaults.baseURL = 'https://comment.zouchanglin.cn/api/'
```

Nginx的配置文件如下：

```nginx
user  root;
worker_processes  2;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
	
    sendfile        on;
    keepalive_timeout  65;

    gzip  on;
	
    # HTTPS server
    server {
        listen       443 ssl;
        server_name  comment.zpuchanglin.cn;

        # 配置证书
        ssl_certificate      /opt/ssl_file/cn_chain.crt;
        ssl_certificate_key  /opt/ssl_file/cn_key.key;

        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        location / {           
            root /root/dist;
			try_files $uri $uri/ /index.html;
        }

		location ^~/api/ {
			proxy_pass http://127.0.0.1:8080;
		}
    }
}
```

# 需要改进之处

集思广益，大家也可以评论留言...

- 支持后台管理
- 支持自适应移动端(宽高度需调整)
- 支持Docker一键部署
- ……

原文地址：[《手写一个Hexo评论系统（二）》](https://zouchanglin.cn/2020/11/27/53884.html)

手写一个Hexo评论系统（二）

我的个人博客时使用Hexo构建的，个人觉得使用Hexo非常方便，而且主题也很好看。因为我的Hexo仓库推送地址同时配置了Github和Gitee，所以一个hexo d命令便可以通知部署到 [zouchanglin.cn](https://zouchanglin.cn) 和 [zouchanglin.gitee.io](https://zouchanglin.gitee.io) 两个站点。唯一美中不足的就是Hexo缺少一款我比较满意的评论系统，所以决定自己手撸一个Hexo博客的评论系统，现在已经部署好了，去我的博客站点是可以看到效果的。



## 我的博客经历了什么

我个人比较喜欢用博客来记录很多东西，比如学习笔记、实验报告、心得体会啥的，能写在博客上面的基本上都写在博客上了。所以我的博客一直保持着更新，不断追求完善，直到如今博客才算是比较完美，而且也算是很稳定了，即使是换电脑了，还可以保证迁移成本非常小。

## GithubPages时代

先说说这个博客配置的历程吧，最开始就是单纯的在Github上新建一个GithubPages，个人地址就是username.github.io这种形式的，后来发现其实这种做法问题有很多：

> 1、访问速度慢，毕竟那个时候Github速度实在是太慢了，Push代码有时候都成问题，更别说加载个人主页了。大部分情况下不等待个十来秒是无法全部加载的，不过自从微软收购了Github后情况貌似有所好转。

> 2、图片的问题的，由于我是直接把图片给放在同级文件夹底下的，所以hexo d的时候也必然要把图片给push到Github的仓库，本来推送就很慢了，再来个推送图片结果就更慢了。访问图片也是慢到极点，所以有时间博客里的图片基本上无法加载，这简直是无法忍受的，因为我写博客的原则就是尽量用比较少的语言，尽量用图片来说明。

## 云服务器部署时代

基于GithubPages的种种问题，我打算自己开发一款博客系统，也就是在仓库吃灰的[https://gitee.com/zouchanglin/journey](https://gitee.com/zouchanglin/journey)，这款博客系统是基于SpringBoot + Thymelafe模板引擎开发的，那个时候技术不成熟，其实还是挺好看的，但是由于需要云服务器部署，而且有一些细节问题没有处理，比如区分代码高亮，粘贴插图等，其实虽然能用，但是毕竟数据持久化在云服务器的MySQL中，感觉不是很稳定，还包括WordPress这种直接部署在PHP环境中的带后端的系统， 最终还是选择GithubPages，毕竟Hexo主题还是挺多的，我很喜欢Hexo的主题， Jekyll也不错，但是主题没有Hexo的多。

## 个人域名时代

准备在云服务器上部署我的个人博客系统的时候我还顺便买了10年的域名，并且做了备案，而且发放了免费的HTTPS证书，有效期时一年，证书过期了可以重新免费申请。反正域名都买了，而且暂时也不用所以就直接把GithubPages的主域名改成了我自己的域名。所以我的博客地址就成了[https://zouchanglin.cn](https://zouchanglin.cn)。但是依旧是避免不了的问题，那就是慢，而且慢的主要原因还是图片加载占用了比较大的带宽。所以图片真是不能往Github上面放呀！

## 图床才是正解

因为图片加载比较慢的问题，所以我又找了一个比较好的方案，那就是图床。最开始使用的微博图床，但是总感觉这个东西不是很靠谱，过了大概两周时间果然出现了图片被删除的情况，所以还好我有备份，打算另辟蹊径，最后又陆续尝试了路过图床、又拍云发现都是各有利弊。后来某天邮箱收到了七牛云给发的推广邮件，免费10GB对象存储空间。有个人备案域名的我简直是对七牛云爱了，我解析了一个子域名叫img.zouchanglin.cn，解析到七牛云的存储空间中，因为如果没有个人域名的话七牛云只会提供一个月时长的随机域名，过了一个月随机域名就会失效，意味着图片链接也无法使用了，下面是我的图片仓库：

![](https://img.zouchanglin.cn/20201126104647.png-zouchanglin.cn)

此时需要一个图片上传工具，毕竟不能每次都要依靠手动上传吧！所以给大家安利一个好工具：[ PicGo: 一个用于快速上传图片并获取图片 URL 链接的工具](https://github.com/Molunerfinn/PicGo) ，支持七牛云、腾讯云、又拍云、Github等图床。而且可以直接剪切板上传，由于是Electron-vue开发的，所以Windows、Mac、Linux平台都支持。

七牛云的仓库不仅可以存储图片文件（png、jpg、gif....），而且还可以存储其他任意类型的文件，有时需要在博客里放一些压缩包的下载链接，用七牛云真的再合适不过了。而且以后就算七牛云没了，还可以把图片迁移到自己的服务器上，反正只要二级域名重新解析一下就OK了。

## 全站CDN加速

由于有时候对博客的加载速度还不是很满意，所以用了阿里的全站CDN加速，是免费的，但是如果是HTTPS的话还是需要收费的，但是很便宜按照流量算一个月一块多钱，所以相当于是免费了。

![](https://img.zouchanglin.cn/20201126110440.png-zouchanglin.cn)

自从开启了全站CDN加速，全国访问都是很低的延迟：

![](https://img.zouchanglin.cn/20201126111332.png-zouchanglin.cn)

## 双仓库部署

我的Hexo仓库推送地址同时配置了Github和Gitee，所以一个hexo d命令便可以通知部署到 [zouchanglin.cn](https://zouchanglin.cn) 和 [zouchanglin.gitee.io](https://zouchanglin.gitee.io) 两个站点，但是由于Gitee关闭了GiteePages的高级功能，也就是Pro版本，不支持关联到自定义域名，而且GiteePages需要手动部署更新内容，所以就有了[zouchanglin.cn](https://zouchanglin.cn) 和 [zouchanglin.gitee.io](https://zouchanglin.gitee.io) 两个站点。目前两个站点都是可以低延迟正常访问的。

## 就缺一个评论系统

那么多问题都解决了，现在最主要的问题就是缺少一个方便的评论系统，网上虽然有很多集成评论系统的教程，但是大多都是Hexo集成 Gitment、 Gitalk、来必力、畅言、Leancloud的Valine、Disqus...虽然其中不乏优秀的评论系统，但是都不是我想要的效果，我理想的评论系统应该是哪种呢？。

>**1、无需登录和验证码，直接评论即可**
>
>**2、支持回复评论，且可无限递归回复**
>
>**3、支持评论点赞，按照点赞排序，相同则按照时间排序**
>
>**3、支持文章评分，显示评分人数和评分的平均分数**
>
>**4、支持自己的评论被别人回复后可以邮件通知**
>
>**5、支持评论后台管理系统，可以设置对应属性**
>
>**6、支持评论导出，且高度100%可恢复数据**

评论系统的功能就是这些了，接下来要干的事情就是逐步实现这些功能，不断优化达到一个比较棒的效果！开始构思，请见《手写一个Hexo评论系统（二）》。
原文地址：[《手写一个Hexo评论系统（一）》](https://zouchanglin.cn/2020/11/26/16902.html)