源：《JavaScript设计模式与开发实践》

模式和重构之间有着一种与生俱来的关系。从某种角度来看，设计模式的目的就是为许多重构行为提供目标。

1.提炼函数

在JavaScript开发中，我们大部分时间都在与函数打交道，所以我们希望这些函数有着良好的命名，函数体内包含的逻辑清晰明了。如果一个函数过长，不得不加上若干注释才能让这个函数显得易读一些，那这些函数就很有必要进行重构。

如果在函数中有一段代码可以被独立出来，那我们最好把这些代码放进另外一个独立的函数中。这是一种很常见的优化工作，这样做的好处主要有以下几点。

• 避免出现超大函数。
• 独立出来的函数有助于代码复用。
• 独立出来的函数更容易被覆写。
• 独立出来的函数如果拥有一个良好的命名，它本身就起到了注释的作用。

比如在一个负责取得用户信息的函数里面，我们还需要打印跟用户信息有关的log，那么打印log的语句就可以被封装在一个独立的函数里：

var getUserInfo = function(){
    ajax( 'http:// xxx.com/userInfo', function( data ){
        console.log( 'userId: ' + data.userId );
        console.log( 'userName: ' + data.userName );
        console.log( 'nickName: ' + data.nickName );
    });
};

改成：

var getUserInfo = function(){
    ajax( 'http:// xxx.com/userInfo', function( data ){
        printDetails( data );
    });
};

var printDetails = function( data ){
    console.log( 'userId: ' + data.userId );
    console.log( 'userName: ' + data.userName );
    console.log( 'nickName: ' + data.nickName );
};

2.合并重复的条件片段

如果一个函数体内有一些条件分支语句，而这些条件分支语句内部散布了一些重复的代码，那么就有必要进行合并去重工作。假如我们有一个分页函数paging，该函数接收一个参数currPage，currPage表示即将跳转的页码。在跳转之前，为防止currPage传入过小或者过大的数字，我们要手动对它的值进行修正，详见如下伪代码：

var paging = function( currPage ){
    if ( currPage <= 0 ){
        currPage = 0;
        jump( currPage );    // 跳转
    }else if ( currPage >= totalPage ){
        currPage = totalPage;
        jump( currPage );    // 跳转
    }else{
        jump( currPage );    // 跳转
    }
};

可以看到，负责跳转的代码jump( currPage )在每个条件分支内都出现了，所以完全可以把这句代码独立出来：

var paging = function( currPage ){
    if ( currPage <= 0 ){
        currPage = 0;
    }else if ( currPage >= totalPage ){
        currPage = totalPage;
    }
    jump( currPage );    // 把jump函数独立出来
};

3.把条件分支语句提炼成函数

在程序设计中，复杂的条件分支语句是导致程序难以阅读和理解的重要原因，而且容易导致一个庞大的函数。假设现在有一个需求是编写一个计算商品价格的getPrice函数，商品的计算只有一个规则：如果当前正处于夏季，那么全部商品将以8折出售。代码如下：

var getPrice = function( price ){
    var date = new Date();
    if ( date.getMonth() >= 6 && date.getMonth() <= 9 ){    // 夏天
        return price * 0.8;
    }
    return price;
};

观察这句代码：

if ( date.getMonth() >= 6 && date.getMonth() <= 9 ){
    // ...
}

这句代码要表达的意思很简单，就是判断当前是否正处于夏天（7~10月）。尽管这句代码很短小，但代码表达的意图和代码自身还存在一些距离，阅读代码的人必须要多花一些精力才能明白它传达的意图。其实可以把这句代码提炼成一个单独的函数，既能更准确地表达代码的意思，函数名本身又能起到注释的作用。代码如下：

var isSummer = function(){
    var date = new Date();
    return date.getMonth() >= 6 && date.getMonth() <= 9;
};

var getPrice = function( price ){
    if ( isSummer() ){    // 夏天
        return price * 0.8;
    }
    return price;
};

4.合理使用循环

在函数体内，如果有些代码实际上负责的是一些重复性的工作，那么合理利用循环不仅可以完成同样的功能，还可以使代码量更少。下面有一段创建XHR对象的代码，为了简化示例，我们只考虑版本9以下的IE浏览器，代码如下：

var createXHR = function(){
    var xhr;
    try{
        xhr = new ActiveXObject( 'MSXML2.XMLHttp.6.0' );
    }catch(e){
        try{
            xhr = new ActiveXObject( 'MSXML2.XMLHttp.3.0' );
        }catch(e){
            xhr = new ActiveXObject( 'MSXML2.XMLHttp' );
        }
    }
    return xhr;
};

var xhr = createXHR();

下面我们灵活地运用循环，可以得到跟上面代码一样的效果：

var createXHR = function(){
var versions= [ 'MSXML2.XMLHttp.6.0ddd', 'MSXML2.XMLHttp.3.0', 'MSXML2.XMLHttp' ];
    for ( var i = 0, version; version = versions[ i++ ]; ){
        try{
            return new ActiveXObject( version );
        }catch(e){

        }
    }
};

var xhr = createXHR();

5.提前让函数退出代替嵌套条件分支

许多程序员都有这样一种观念：“每个函数只能有一个入口和一个出口。”现代编程语言都会限制函数只有一个入口。但关于“函数只有一个出口”，往往会有一些不同的看法。

下面这段伪代码是遵守“函数只有一个出口的”的典型代码：

var del = function( obj ){
    var ret;
    if ( !obj.isReadOnly ){    // 不为只读的才能被删除
        if ( obj.isFolder ){    // 如果是文件夹
            ret = deleteFolder( obj );
        }else if ( obj.isFile ){    // 如果是文件
            ret = deleteFile( obj );
        }
    }
    return ret;
};

嵌套的条件分支语句绝对是代码维护者的噩梦，对于阅读代码的人来说，嵌套的if、else语句相比平铺的if、else，在阅读和理解上更加困难，有时候一个外层if分支的左括号和右括号之间相隔500米之远。用《重构》里的话说，嵌套的条件分支往往是由一些深信“每个函数只能有一个出口的”程序员写出的。但实际上，如果对函数的剩余部分不感兴趣，那就应该立即退出。引导阅读者去看一些没有用的else片段，只会妨碍他们对程序的理解。

于是我们可以挑选一些条件分支，在进入这些条件分支之后，就立即让这个函数退出。要做到这一点，有一个常见的技巧，即在面对一个嵌套的if分支时，我们可以把外层if表达式进行反转。重构后的del函数如下：

var del = function( obj ){
    if ( obj.isReadOnly ){    // 反转if表达式
        return;
    }
    if ( obj.isFolder ){
        return deleteFolder( obj );
    }
    if ( obj.isFile ){
        return deleteFile( obj );
    }
};

6.传递对象参数代替过长的参数列表

有时候一个函数有可能接收多个参数，而参数的数量越多，函数就越难理解和使用。使用该函数的人首先得搞明白全部参数的含义，在使用的时候，还要小心翼翼，以免少传了某个参数或者把两个参数搞反了位置。如果我们想在第3个参数和第4个参数之中增加一个新的参数，就会涉及许多代码的修改，代码如下：

var setUserInfo = function( id, name, address, sex, mobile, qq ){
    console.log( 'id= ' + id );
    console.log( 'name= ' +name );
    console.log( 'address= ' + address );
    console.log( 'sex= ' + sex );
    console.log( 'mobile= ' + mobile );
    console.log( 'qq= ' + qq );
};

setUserInfo( 1314, 'sven', 'shenzhen', 'male', '137********', 377876679 )

;

这时我们可以把参数都放入一个对象内，然后把该对象传入setUserInfo 函数，setUserInfo函数需要的数据可以自行从该对象里获取。现在不用再关心参数的数量和顺序，只要保证参数对应的key值不变就可以了：

var setUserInfo = function( obj ){
    console.log( 'id= ' + obj.id );
    console.log( 'name= ' + obj.name );
    console.log( 'address= ' + obj.address );
    console.log( 'sex= ' + obj.sex );
    console.log( 'mobile= ' + obj.mobile );
    console.log( 'qq= ' + obj.qq );
};

setUserInfo({
    id: 1314,
    name: 'sven',
    address: 'shenzhen',
    sex: 'male',
    mobile: '137********',
    qq: 377876679
});

7.尽量减少参数数量

如果调用一个函数时需要传入多个参数，那这个函数是让人望而生畏的，我们必须搞清楚这些参数代表的含义，必须小心翼翼地把它们按照顺序传入该函数。而如果一个函数不需要传入任何参数就可以使用，这种函数是深受人们喜爱的。在实际开发中，向函数传递参数不可避免，但我们应该尽量减少函数接收的参数数量。下面举个非常简单的示例。 有一个画图函数draw，它现在只能绘制正方形，接收了3个参数，分别是图形的width、heigth以及square：

var draw = function( width, height, square ){};

但实际上正方形的面积是可以通过width和height计算出来的，于是我们可以把参数square从draw函数中去掉：

var draw = function( width, height ){
    var square = width * height;
};

假设以后这个draw函数开始支持绘制圆形，我们需要把参数width和height换成半径radius， 但图形的面积square始终不应该由客户传入，而是应该在draw函数内部，由传入的参数加上一定的规则计算得来。此时，我们可以使用策略模式，让draw函数成为一个支持绘制多种图形的函数。

8.少用三目运算符

有一些程序员喜欢大规模地使用三目运算符，来代替传统的if、else。理由是三目运算符性能高，代码量少。不过，这两个理由其实都很难站得住脚。

即使我们假设三目运算符的效率真的比if、else高，这点差距也是完全可以忽略不计的。在实际的开发中，即使把一段代码循环一百万次，使用三目运算符和使用if、else的时间开销处在同一个级别里。

同样，相比损失的代码可读性和可维护性，三目运算符节省的代码量也可以忽略不计。让JS文件加载更快的办法有很多种，如压缩、缓存、使用CDN和分域名等。把注意力只放在使用三目运算符节省的字符数量上，无异于一个300斤重的人把超重的原因归罪于头皮屑。

如果条件分支逻辑简单且清晰，这无碍我们使用三目运算符：

var global = typeof window !== "undefined" ? window : this;

但如果条件分支逻辑非常复杂，如下段代码所示，那我们最好的选择还是按部就班地编写if、else。if、else语句的好处很多，一是阅读相对容易，二是修改的时候比修改三目运算符周围的代码更加方便：

if ( !aup || !bup ) {
    return a === doc ? -1 :
        b === doc ? 1 :
        aup ? -1 :
        bup ? 1 :
        sortInput ?
        ( indexOf.call( sortInput, a ) - indexOf.call( sortInput, b ) ) :
        0;
}

9.合理使用链式调用

经常使用jQuery的程序员相当习惯链式调用方法，在JavaScript中，可以很容易地实现方法的链式调用，即让方法调用结束后返回对象自身，如下代码所示：

var User = function(){
    this.id = null;
    this.name = null;
};

User.prototype.setId = function( id ){
    this.id = id;
    return this;
};

User.prototype.setName = function( name ){
    this.name = name;
    return this;
};

console.log( new User().setId( 1314 ).setName( 'sven' ) );

或者：

var User = {
    id: null,
    name: null,
    setId: function( id ){
        this.id = id;
        return this;
    },
    setName: function( name ){
        this.name = name;
        return this;
    }
};

console.log( User.setId( 1314 ).setName( 'sven' ) );

使用链式调用的方式并不会造成太多阅读上的困难，也确实能省下一些字符和中间变量，但节省下来的字符数量同样是微不足道的。链式调用带来的坏处就是在调试的时候非常不方便，如果我们知道一条链中有错误出现，必须得先把这条链拆开才能加上一些调试log或者增加断点，这样才能定位错误出现的地方。

如果该链条的结构相对稳定，后期不易发生修改，那么使用链式调用无可厚非。但如果该链条很容易发生变化，导致调试和维护困难，那么还是建议使用普通调用的形式：

var user = new User();

user.setId( 1314 );
user.setName( 'sven' );

10.分解大型类

在HTML5版“街头霸王”的第一版代码中，负责创建游戏人物的Spirit 类非常庞大，不仅要负责创建人物精灵，还包括了人物的攻击、防御等动作方法，代码如下：

var Spirit = function( name ){
    this.name = name;
};

Spirit.prototype.attack = function( type ){    // 攻击
    if ( type === 'waveBoxing' ){
        console.log( this.name + ': 使用波动拳' );
    }else if( type === 'whirlKick' ){
        console.log( this.name + ': 使用旋风腿' );
    }
};

var spirit = new Spirit( 'RYU' );

spirit.attack( 'waveBoxing' );      // 输出：RYU: 使用波动拳
spirit.attack( 'whirlKick' );    // 输出：RYU: 使用旋风腿

后来发现，Spirit.prototype.attack这个方法实现是太庞大了，实际上它完全有必要作为一个单独的类存在。面向对象设计鼓励将行为分布在合理数量的更小对象之中：

var Attack = function( spirit ){
    this.spirit = spirit;
};

Attack.prototype.start = function( type ){
    return this.list[ type ].call( this );
};

Attack.prototype.list = {
    waveBoxing: function(){
        console.log( this.spirit.name + ': 使用波动拳' );
    },
    whirlKick: function(){
        console.log( this.spirit.name + ': 使用旋风腿' );
    }
};

现在的Spirit类变得精简了很多，不再包括各种各样的攻击方法，而是把攻击动作委托给Attack类的对象来执行，这段代码也是策略模式的运用之一：

var Spirit = function( name ){
    this.name = name;
    this.attackObj = new Attack( this );
};

Spirit.prototype.attack = function( type ){    // 攻击
    this.attackObj.start( type );
};

var spirit = new Spirit( 'RYU' );

spirit.attack( 'waveBoxing' );    // 输出：RYU: 使用波动拳
spirit.attack( 'whirlKick' );    // 输出：RYU: 使用旋风

11.用return退出多重循环

假设在函数体内有一个两重循环语句，我们需要在内层循环中判断，当达到某个临界条件时退出外层的循环。我们大多数时候会引入一个控制标记变量：

var func = function(){
    var flag = false;
    for ( var i = 0; i < 10; i++ ){
        for ( var j = 0; j < 10; j++ ){
            if ( i * j >30 ){
                flag = true;
                break;
            }
        }
        if ( flag === true ){
            break;
        }
    }
};

第二种做法是设置循环标记：

var func = function(){
    outerloop:
    for ( var i = 0; i < 10; i++ ){
        innerloop:
        for ( var j = 0; j < 10; j++ ){
            if ( i * j >30 ){
                break outerloop;
            }
        }
    }
};

这两种做法无疑都让人头晕目眩，更简单的做法是在需要中止循环的时候直接退出整个方法：

var func = function(){
    for ( var i = 0; i < 10; i++ ){
        for ( var j = 0; j < 10; j++ ){
            if ( i * j >30 ){
                return;
            }
        }
    }
};

当然用return直接退出方法会带来一个问题，如果在循环之后还有一些将被执行的代码呢？如果我们提前退出了整个方法，这些代码就得不到被执行的机会：

var func = function(){
    for ( var i = 0; i < 10; i++ ){
        for ( var j = 0; j < 10; j++ ){
            if ( i * j >30 ){
                return;
            }
        }
    }
    console.log( i );    // 这句代码没有机会被执行
};

为了解决这个问题，我们可以把循环后面的代码放到return后面，如果代码比较多，就应该把它们提炼成一个单独的函数：

var print = function( i ){
    console.log( i );
};

var func = function(){
    for ( var i = 0; i < 10; i++ ){
        for ( var j = 0; j < 10; j++ ){
            if ( i * j >30 ){
                return print( i );
            }
        }
    }
};

func();

- END -

创 石若萧 中国新闻周刊

不可逆的历史进程

提到4399、7K7K、2144等小游戏网站，大部分90后或许还保有记忆，这种记忆大部分和种种场景交织在一起：电话线拨号上网、臃肿肥胖的台式机、windows 98/XP的开机音乐，蓝天白云的经典屏保，穿鞋套才能进入的学校机房……《火柴人》《摩尔庄园》《黄金矿工》《闪客快打》《狂扁小朋友》，这些耳熟能详的小游戏，陪伴90后度过了那个娱乐产品相对匮乏的童年。

4399小游戏网站截图

如今，随着软硬件技术不断推陈出新，各种崭新的娱乐活动占据了人们的业余时间。越来越少的人会再打开网页浏览器，输入一个特定网址，靠简单的小游戏满足自己的娱乐需求。

4399的日薄西山，就好比BBS论坛、分类导航网站的衰落一样，属于不可逆的历史进程。在移动互联网的浪潮下，入局者但凡转身慢了一步，便都成了时代的眼泪。

逐步败退的4399

小游戏聚合网站的起家，和20世纪末、21世纪初兴起的互联网浪潮密不可分。彼时，我国个人电脑才刚刚开始普及，上网费用较为高昂，流行的大部分是《雷电》《大富翁》《街头霸王》《仙剑奇侠传》《三国群英传》《抢滩登陆战》等大小在数十M乃至数百M的单机游戏。因为储存工具（软盘、U盘、光盘）的容量限制，外加病毒横行，盗版或拷贝都是一个极麻烦的问题——“虚拟光驱”大约是当年众多电脑小白装机时的心理阴影。

同安装麻烦、配置要求高的单机相比，网络游戏正处在爆发的前夜，唯一要解决的只是载入、运行的速度问题。2004年，4399小游戏平台上线，正赶上了这一波浪潮。其采用Flash技术为基础，域名简单好记，游戏无需安装，载入速度快，不少游戏还分为单双人模式，能满足小朋友们的初级社交需求。

但如今，网页游戏市占率越来越小，已不复当年盛景。梳理起4399的衰落，不难总结出三个原因：质量跟不上，消费者习惯的改变（流量入口变化），以及版权问题。

首当其冲的，自然是游戏质量问题。

随着电脑配置的日新月异，Steam等分销平台的流行，单机游戏的下载安装越来越方便，大小也从数百M，到动辄破G，再到今天随便一个普通品相的游戏都破10G。玩家的口味越来越叼，而以省流量、小体积为卖点的网页游戏自然再难以满足玩家的需求。

当然，总有一部分玩家对游戏质量的要求不太高，只求消磨时间。但随着智能手机的普及，这批玩家的注意力也转移到了《水果忍者》《神庙逃亡》《刀塔传奇》等手游上。

毕竟，在移动互联网时代，流量入口也变了。PC时代，浏览器几乎是唯一的流量入口。但如今，流量入口变成了如微信、淘宝、头条，甚至打车、导航、视频、应用商店等巨型APP。

4399也试图在APP时代找到自己的新路子，2013年10月，其推出了针对移动端的“4399游戏盒子”。截至2017年，累计下载量超过1亿，日活突破350万。

但随着线上红利日渐见顶，流量话语权也逐步从第三方应用商店转移到了超级APP上。华为等各个安卓手机厂商也相继推出了自家的游戏分发平台，并不约而同在应用商店中将4399游戏盒屏蔽，其面临的竞争环境愈发严酷。

还有版权问题。

游戏本质上也属于内容产业，对创意有强烈需求。但早年的4399，大部分小游戏来源其实都是盗版。除了使用死神、火影、龙珠这些知名IP的未授权素材外，据传说，4399在千禧年之初曾有一支专业的“破解铁军”，专门盯着海外几个著名Flash游戏站，只要有新游戏上线，就在第一时间进行破解换皮改名。因为投诉流程故意设计得极为繁琐，海外开发者又鞭长莫及，许多主创只得选择不去理会。

但近年来，随着人均收入的提高，在线支付手段的普及，以及知识产权相关法律的完善，人们对盗版的容忍度越来越低。4399已经数次陷入纠纷之中。

2017年，广州天河区人民法院就4399侵害“地下城与勇士”、“DNF”商标权及不正当竞争纠纷一案做出一审判决。法院经审理认定4399利用搜索引擎关键词的行为属于商标性使用，构成侵权。最终裁定4399赔偿腾讯公司500万元；

无独有偶，2017年，网易发表声明，称4399旗下手游《仙语》侵犯了《梦幻西游》手游著作权及不正当竞争行为。法院经过审判后判处网易胜诉，判令4399等二被告连带赔偿网易游戏共计人民币1500万元；

2019年年底，暴雪与4399长达两年的抄袭诉讼完结，法院判定，4399公司旗下的两款手游《英雄枪战》及《枪战前线》游戏素材抄袭了暴雪旗下射击游戏《守望先锋》，需分别赔付300万和97万。

破解+搜索重新定向的玩法，在如今极为强调版权的时代，显然玩不转了。

停止服务的Flash

2020年，许多互联网用户在打开电脑浏览器时都会看到这样一句话：“Flash Player 将于2020年12月31日停止支持。”

因此，前段不少流言传出，认为如4399，7k7k这般以Flash为基础架构的游戏网站失去了技术支持，将会面临倒闭的命运——这自然言重了。且不说如今各个小游戏网站都有H5的备选方案，即便坚持用Flash版本运行，也总会有一些浏览器，如360、搜狗等坚持提供插件服务。

4399小游戏网站截图

不过，受影响也是难免的。例如部分以Flash为基础的页游开发团队受影响较大，不得不整体进行转型。

Flash的特点在于省流量、体积小、创作自由度高，顺应了互联网发展初期“一切从简”的原则，因此在21世纪前十年，一度支配了页游、在线视频以及大量在线交互程序，并围绕建立了一套强大的生态。

但当网速不断提升、主机性能越来越强，Flash的优势不再明显，劣势反而愈发突出：效率和表现力均不足，只要图片像素、视频清晰度、游戏分辨率等要求稍微高些，便无法进一步处理。

而当智能手机时代来临后，Flash更是因为几乎完全不兼容移动端，正式开始淡出时代。

据公众号“极客公园”梳理，2010年，乔布斯发表文章“我对于 Flash 的思考”：直指 Flash 封闭，坚持作为独立的第三方插件，不兼容触控屏，用户体验还停留在 PC 端，可靠性、安全性均成问题。且因为Flash易于开发，相关产品庞杂泛滥，漏洞多、补丁多、耗电高，导致 Mac 经常崩溃。基于以上种种原因，很快，Flash便被IOS系统排除在了生态之外。

随着乔布斯“一声令下”，各个主流互联网公司，包括Adobe自己，都开始了“去Flash化”的历史进程。

2012年，Adobe正式宣布，将停止在安卓平台上继续更新移动版Flash插件，转为推进开发HTML5；

2015 年，谷歌浏览器Chrome 发表一则声明，称：“2014 年，80% 的桌面 Chrome 用户每天访问至少一个含有 Flash 内容的网站，2017 年这一数字下跌到 17%，并且还在持续下跌”；

2017年，Adobe正式宣布在2020年末放弃对Flash的更新与维护；

2019年，微软宣布计划从所有的浏览器中移除Flash，同时Windows 10加入了一个补丁，强制全面删除系统中的Flash插件。苹果也宣布将在2020年从Safari中移除Flash。Adobe 自己更是通过弹窗提醒用户永久删除该软件。

一代“王者”，终于到了谢幕的时候。

页游市场的未来

用户量收缩，供应量不足，连基础设施运行都成了问题。为了在云谲波诡的时代中生存下去，小游戏网站们只好和各种“一刀暴击999”的氪金页游抱团取暖，共享本就局促的流量入口，甚或亲自参与页游的开发和入股。

7k7k小游戏网站截图

但这个市场，也在以肉眼可见的速度缩小。

据2007年及2008年中国游戏产业报告，2007年，中国网页游戏市场规模为1亿元，2008年达到3.5亿，2009年达到9.9亿，三年里，市场规模翻了近10倍。

4399的高光期与这段时间正好重合，并于2010年前后到达峰顶。相关数据显示，2011年，4399净利润破亿；2012年，净利润翻番，并占据了近10%的市场份额；2013年营收14.9亿，净利润2.49亿，增长率30.91%。

而到了2013年，随着移动互联网的爆发式发展，页游发展进入了停滞期。4399不得不抓紧开拓手游业务，于当年推出了4399游戏盒。产品开发、发行渠道投入陡增。为了引入更多资金，公司开始寻求上市。

相关招股书显示，2014的前半年，4399实现了净利润1.58亿元，全年净利有望达到3亿。但营收相比2013年没有明显增长，有分析称，其净利增长全靠裁员来压缩成本。随后，因未能如期将2014年下半年及全年财报交齐，上市进程被证监会叫停。

随后几年，随着市场大盘下滑速度也越来越快，4399更加找不到合适的上市时机。根据2015年及2016年中国游戏产业报告，2015年，中国移动游戏市场规模达到514.6亿元，网页游戏规模为219.6亿，达到顶峰，此后一路下滑。2016年，网页游戏的市场规模下降到180多亿，较上一年度下滑超过10%。

而到了近两年，这一下滑趋势越发明显。《2019年中国游戏产业报告》数据显示，2019年的中国游戏市场，移动游戏以62.5%市占率遥遥领先，端游紧随其后，占比28.9%。而页游占比仅有5.9%。

据《2020年1-6月中国游戏产业报告》，去年上半年，我国页游市场实际销售收入为40.02亿元，同比下降21.43%，连续五年下降，且只占到了所有游戏收入的2.87%。为了寻找盈利点，各个昔日的页游大厂都在加速布局手游，小厂也不得不寻求转型。

中国页游市场销售收入数据。来源：伽马数据

在2020年11月30举办的第四届中国文创产业大会·天河峰会上，4399董事长骆海坚就提出了转型的想法。其宣布，要“掌握3A主机级的制作能力”，“通过深度积累，再结合大兵团的运作协调和制作开发能力，真正提高我们的游戏制作水平”。此言一出，招来的却更多是业内的怀疑声音。大部分从业者认为，4399从最初的基因上就不具备3A的制作能力，与其贸然转型，不如坚守阵地。毕竟，就像市占率愈发缩小，但一直没有消亡的分类导航网站和BBS论坛一样，虽然网页游戏前景不佳，但只要网页浏览器还存在，没有完全终结。只要能够找准用户需求，创作出优秀的作品，依然能够抓住一部分用户。

究竟哪条路是对的？恐怕只能等待时间来验证了。

参考资料：

4399上市喊停, 不仅是财报未交这么简单. 爆料汇. 2015-03-11

多端融合，3D画面，未来的页游市场到底应该怎么闯？游戏茶馆. 2020-09-14

永别了，Flash. 极客公园. 2020-12-31

值班编辑：肖冉