摘要:4.在APP端軟件更新之後,我們不能強制的讓用戶必須更新,要做到更新後可以使用,同時未更新的版本也能正常使用,這就需要我們針對不同的版本進行不同的處理。3.當我們軟件設置了強制更新,每當用戶操作APP時,都會檢測軟件當前的版本與最新的版本,如果發現不一致則會提醒用戶進行更新,如不更新則無法使用。

[個人理解]軟件版本是隨着項目的不斷研發,在不同階段產生的一個重要里程碑記錄。針對不同的階段,存在軟件功能的更新或軟件問題的修復而出現的一種軟件設計模式。

爲什麼會存在不同的APP軟件版本

  1. 業務不斷的迭代更新。

一個好的產品總是在不斷的迭代開發、不斷的增加一些新的功能。我們在軟件發佈新功能時, 要儘可能的讓用戶被動的知道軟件功能進行了更新 ,這時候就需要我們將新的軟件功能告知用戶,讓用戶去使用新功能。

例如,我們第一次APP只發布了一個文章閱讀的功能,後來我們在APP上增加了一個視頻播放的功能。這時候需要用戶進行更新APP纔可以查看,但是存在部分用戶不願意更新到最新版本,我們要做到新版本的發佈不影響舊版本的使用。保證多個版本同時能夠使用。

2.現有軟件版本的bug。

在當前我們發佈的APP軟件中,如果我們發現了軟件存在的bug,此時需要修復bug,重新發布版本,就需要用戶在使用時強制更新到最新的版本。

APP軟件版本與Web網頁版本之間的區別

1.APP是使用實在用戶的移動設備上進行的,我們運行的代碼也是在用戶的移動設備上。服務器端是無法讓用戶每次進來都是加載最新的軟件功能。

2.Web網頁是運行在瀏覽器中,用戶使用是通過一個網頁地址(網頁鏈接),服務器端是可以保證用戶每次讓問鏈接都是加載的最新功能。

3.因此APP軟件版本的更新,需要用戶主動的去下載最新的APP軟件。每次下載的APP軟件都是一個新的版本。

4.在APP端軟件更新之後,我們不能強制的讓用戶必須更新,要做到更新後可以使用,同時未更新的版本也能正常使用,這就需要我們針對不同的版本進行不同的處理。

APP軟件版本流程圖

通過上圖,我們將用戶使用的設備成爲客戶端。每個用戶手中的軟件版本存在不同的情況,我們要讓用戶無感知的情況下,針對不同的用戶的不同版本請求不同的數據。

例如,上圖安卓設備用戶,用戶1使用的APP版本是版本2,用戶2使用的版本比用戶1的版本要低一些,使用的是版本1,用戶3使用的是版本3,爲最新的APP軟件。雖然我們APP軟件的最新版本是版本3,但我們要做到每個用戶使用的軟件版本都能正常使用。

APP軟件版本控制實現原理分析

1.這裏的客戶端1、客戶端2和客戶端3分別對應上圖的用戶1、用戶2和用戶3。

2.客戶端1使用的是版本2,在請求服務端時,服務端根據當前請求地址中的參數,來判斷用戶當前的版本號,根據不同的版本好轉發到後端不同的接口地址。其他的客戶端同理進行。

3.當我們軟件設置了強制更新,每當用戶操作APP時,都會檢測軟件當前的版本與最新的版本,如果發現不一致則會提醒用戶進行更新,如不更新則無法使用。

APP軟件版本更新的模式

1.強制更新

強制更新指的是,用戶使用的版本與當前最新版本不一致,則會提示用戶更新否則無法使用。一般不推薦使用強制更新,如發現舊版本存在重大bug時,才強制用戶進行強制更新。

2.多版本兼容

多版本兼容指的是,不管APP更新了多少個版本並且用戶使用的是某一個版本,都能正常操作。對用戶的體驗性更好。

APP軟件版本控制需要考慮些什麼

1.數據庫設計

數據庫中我們需要考慮到不同的用戶設備,不同的版本號等信息。

字段 類型 描述 示例值
id int(10) 主鍵 1
device_type varchar(32) 設備類型 Android
device_model varchar(32) 設備機型 vivo x6
in_version varchar(32) 內部版本號 v1.0.1
out_version varchar(32) 外部版本號 v1.0.1
version_url varchar(255) 更新包地址 https://www.xxx.com/v1
is_force tinyint(10) 是否強更 1
update_msg varchar(32) 更新提示信息 增加視頻播放功能
is_latest tyintint(10) 是否爲最新版本 1

2.監控內容

一般的軟件設計都會針對APP使用情況進行檢測,比如設備類型、使用時間、啓動次數、瀏覽時間等情況進行檢測,後臺做一些數據分析使用。

字段 類型 描述 示例值
id int(10) 主鍵 1
device_type varchar(32) 設備類型 Android
device_model varchar(32) 設備機型 vivo x6
version varchar(32) 版本號 v1.0.1
open_time datetime(0) 啓動時間 2019-02-02 12:09:09

3.代碼設計

代碼一般是通過分層設計,降低代碼的耦合度、同時也能提高代碼的擴展性。如上圖,我們所有的業務邏輯一般都是在controller層進行處理,我們v1版本請求controller下面v1,v2版本請求controller下面v2,同理後面的版本也按照這種模式進行處理。針對一些不需要版本控制的邏輯則單獨設置爲公共的控制器進行處理。

4.路由地址

上面代碼設計中,我們將不同的版本分爲不同的模塊,路由地址主要是爲了區分不同的版本請求不同的模塊。v1的路由地址則請求v1控制器,v2的路由地址則請求v2控制器。

APP軟件版本具體實現

這裏使用PHP中的ThinkPHP5.1進行部分代碼演示

1.數據庫設計

// 數據庫直接根據上面表的結構進行設計,創建一些模擬數據。

2.路由定義

use think\facde\Route;

// 新聞列表路由地址
Route::get('news/list/:ver', 'index/:ver.News/list');
// 文章列表路由地址
Route::get('article/list/:ver', 'index/:ver.Article/list');

上面的:ver是一個url必填變量,客戶端APP在請求服務端時,請求的url中攜帶着該變量,我們根據定義好的路由就會自動的轉發到對應版本下面的控制器中。如下url示例格式:

// 請求版本1中的新聞接口
https://www.xxx.com/news/list/v1
// 請求版本2中的新聞接口
https://www.xxx.com/news/list/v2

3.業務控制器

// v1版本的新聞接口
namespace app\index\v1\News;

class News 
{
    public function list()
    {
        // 這裏返回v1版本的數據格式
    }
}
// v2版本的新聞接口
namespace app\index\v2\News;

class News 
{
    public function list()
    {
        // 這裏返回v2版本的數據格式
    }
}

當我們部分接口存在小變動,也可以不用單獨增加一個版本接口,只需要在原來的版本上增加我們需要的字段接口,如下示例數據格式。

// v1版本,新聞模塊返回的數據格式
[
    'id' => 1,
    'title' => 'APP軟件版本控制',
    'created_at' => '2019-02-12'
];
// v2版本,新聞模塊返回的數據格式
[
    'id' => 1,
    'title' => 'APP軟件版本控制',
    'created_at' => '2019-02-12',
    'author' => '卡二條'
];
相關文章