源：《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

值班編輯：肖冉