移动站方案设计

2014-08-06

背景

本文档是对[荆楚网移动站建设说明]的细化，进一步分析系统的需求，并对
系统的实施方案做出初步设计。

本文档主要侧重于移动站的后台流程，即从采页面 到 发布的过程。

前置文档

• 荆楚网移动站建设说明

系统用户

• 移动站编辑（后台用户）
• 荆楚网移动端用户（前台用户）

系统流程

后台流程

前台流程

系统交互

后台交互

前台交互

需求列表

功能性需求

1. 文件存储(文章,视频,图片等)
2. 页面转换
3. 组图操作(左右滑动翻页)
4. 视频正常浏览
5. 额外模块(广告等)
6. 后台管理
7. 评论(预留)

非功能型需求

1. 用户体验
2. 执行效率
3. 误操作
4. 安全性
5. 可拓展性(如采集规则的动态配置)

方案设计

本部分对于主要的功能性需求给出解决方案，并进行可行性分析。

总体方案

为了保证PC端和移动端都有良好的显示效果,可能的方案如下：

综合考虑五种总体的方案，依照目前的技术可行性可以排除S1，S4。S2，S3，S5的区别在于，移动端和PC端是否使用相同的URL，以及是否采用动态页面。

目前确定的方法是S2，并采取生成静态页面方式实现。

在确定了总体方案的基础上，再对需求进行考量。依照功能性需求列表，分析软件的进一步设计方案。

文件存储方案(8月7日修改)

页面存储方案

依照系统流程的总体方案，要依照PC端页面来生成静态的移动端页面。需要从网页上采集相应的HTML页面，将该页面转换成静态的移动端页面，依照某种文件存储方案来存储在文件系统中。对此，我将所获取的PC端URL做如下解析：

http://[X].cnhubei.com/[A]/[B]/[C].....

• X为子域名（如存在三级域名，如jm.news.cnhubei.com）,则解析出X = jm.news
• A为一级子目录
• B为二级子目录
• C为三级子目录及后续所有部分
• C为三级子目录(可能存在后续部分，即DEFGH等)

假定生成的所有移动端页面均储存在/wap文件夹下，则上述URL在经过系统转码后，文件位置则是:

/wap/[X]/[A]/[B]/[C]....   注意，如果X包含三级域名如X = jm.news，则会将X处理成news.jm

关于为何在此仅做到二级子目录精确解析，是依据荆楚网网站模板实际情况，不会在同一个二级子目录下存在不同的模板。

这里假定不存在 4级域名的情况。即不存在形如xyz.jm.news.cnhubei.com的域名。

关于页面存储的目录，目前存在几种考量。假定存在一个比较长的URL：

http：//jm.news.cnhubei.com/zt/2014zt/jj/t0000001.shtml

存在几种存储的方式:

下面详述S3

对于上面规则给出的地址，按照上述方式进行解析的流程：

给出具体的代码:

//funtion
//@name: get_output_dir
//@param: $url: the page's url
//@return: $output_dir: the output directory
function get_output_dir($url)
{
    $s = explode("/",$url);
    $s[2] = str_replace(".cnhubei.com", "", $s[2]);//$s[2]:jm.news.cnhubei.com -> jm.news
    if(strstr($s[2],".")
    {
        $temp = explode(".", $s[2]);
        $s[2] = $temp[1].".".$temp[0];//jm.news -> news.jm
    }
    $dir = $s[2];
    for($i = 3; $i < sizeof($s); $i++)
        $dir .= "/".$s[$i];//news.jm/..../t0000001.html
    return $dir;
}

资源文件存储方案

文件存储还有另一种情况，资源文件的存储。

资源文件是指文章中引用的图片，视频等资源。对于图片而言，需要将其转换成适合手机端显示的图片，并存储在文件系统中。在将PC端HTML转换为移动端页面时，会将对应的PC端的图片链接到转换后的图片地址。

由于在PC端，图片是与HTML页面共目录。比如：http://news.cnhubei.com/xw/yl/201408/t3005874_1.shtml
中引用了图片W020140805549496102554.jpg，则该张图片的位置就是

http://news.cnhubei.com/xw/yl/201408/W020140805549496102554.jpg

那么我们就可以直接使用在移动端一样。将该图片转换成移动端适用的图片后，重命名为W020140805549496102554_small.jpg，再存储于

/wap/images/news/xw/yl/201408/W020140805549496102554_small.jpg

在转换HTML页面时，只需将图片地址后加上_small，然后沿用其相对地址即可。
将所有图片存储于images文件夹下，再根据目录细化。相对地址也要转换成绝对地址。

页面转换方案

页面转换是将PC端页面转换成相应的移动端页面的流程。（可参见管理员流程图）包括两个步骤：

• 确定采集规则
• 采集并转换成移动端页面

由于PC端网页由不同模板生成，需要以不同的规则来采集网页信息。在存在多个可能匹配的采集规则时，如何确定应该依照哪条规则来采集网页。

初步的想法是采用逐步递减的匹配策略。假如提供如下的URL，对其进行解析：

http://[X].[Y]cnhubei.com/[A]/[B]/[C]/[D]/t0000001.shtml

注意这里不一定只到D，可能后面还有EFGH...

那么我们采取如下的匹配策略:

• 是否存在匹配http://[X].[Y].cnhubei.com/[A]/[B]/[C]/[D]
• 是否存在匹配http://[X].[Y].cnhubei.com/[A]/[B]/[C]
• 是否存在匹配http://[X].[Y].cnhubei.com/[A]/[B]
• 是否存在匹配http://[X].[Y].cnhubei.com/[A]
• 是否存在匹配http://[X].[Y].cnhubei.com
• 是否存在匹配http://[Y].cnhubei.com
• 是否存在匹配http://cnhubei.com

具体流程如下：

JS插件自动生成的图，部分内容有点重合。

下面给出代码

//funtion
//@name: get_match_rule
//@param: $url: the page's url
//@return: $match_rule: the best fit url rule
function get_match_rule($url)
{
    ...//cut the 'http://' if exist
    if(perfect_fit($url))
        return $url;
    else if(strstr($url, "/"))
    {
        $url = substr($url, 0, strrpos($url, "/"));//cut the last dir
        return get_match_rule($url);//recursive
    }
    else if(strstr(str_replace(".cnhubei.com", "", $url), "."))
    {
        $url = substr(strstr($url, "."), 1);//cut the first domain name
        return get_match_rule($url);//recursive
    }
    else
        return "cnhubei.com";
}

对某一页面，在确定了采集的规则之后，就可以依照规则进行转换。页面转换的具体流程包括：

图片转换方案

图片转换是将PC端图片转换成便于移动端显示的图片。图片转换主要考虑两个因素：

• 显示效果
• 体积

理想情况是，在显示效果不变的情况下，将图片尽可能压缩至比较小的体积。

采用PHP GD库，在页面转换的同时，抓取页面内容中的图片，对图片进行转换，把结果直接保存在文件系统中。

目前可以做到将图片体积压缩80-90%，而图片显示效果几乎不变。在压缩至将近90-95%时，图片在小分辨率的移动设备上显示几乎不受影响。

下面给出测试用例。原图拷贝自荆楚网新闻页面。在压缩过程中，图片的原始尺寸保持不变。

• 原图309KB:
  

• 压缩至40KB，压缩质量参数设置为75:
  

• 压缩至20KB，压缩质量参数设置为20:
  

• 压缩至15KB，压缩质量参数设置为10:
  

结论：
可以将图片压缩质量参数设置为20%，此时图片会体积压缩90%以上，而显示效果变化不大。
新增：后续测试表明，以上所用测试图由于是在夜间，颜色较少，会造成体积上的压缩比例虚高。在后续的测试中，采用色域较广的图片，使用20的质量参数，图片体积会压缩70-80%。

执行效率：php GD库执行效率问题。这一点需要压力测试来进行检验。
对于上面的图片，用一段小程序在本机上执行压力测试，做400次图片转换，耗时在24s左右。图片转换本身的效率大约是20次转换/秒。考虑到在实际使用中，图片是从其它服务器上获取，做转换，再写回其它服务器。还需要加上服务器的IO时间。对于性能的优化尚需再做考量

#

2014/8/7 11:44 unfinished