1. 程式人生 > >版本迭代更新—增量更新你的應用

版本迭代更新—增量更新你的應用

App的時候升級提醒有兩種方式獲得:

一種是通過App Store獲取

這裡寫圖片描述

另一種是開啟應用之後提醒使用者更新升級

這裡寫圖片描述

而更新操作一般是在使用者點選了更新按鈕之後開始執行的,這裡的升級操作也分為兩種形式:(一般升級,強制升級)

1.App Store升級
在App Store中升級需要為App Store上傳新版App,我們在新版本完成之後都會上傳到App Store中,不同的應用市場稽核的時間不同,一般除了第一次上傳時間較長之外,其餘的稽核都是挺快的,一般不會超過半天(不排除例外情況奧),在稽核完成之後就相當於完成了這個應用市場的釋出了,也就是釋出上線了。這時候如果使用者安裝了這個應用市場,那麼就能看到我們的App有新版本的升級提醒了。

2.應用內升級
在應用內升級主要是通過呼叫伺服器端介面獲取應用的升級資訊,然後通過獲取的伺服器升級應用資訊與本地的App版本比對,若伺服器下發的最新的App版本高於本地的版本號,則說明有新版本釋出,那麼我們就可以執行更新操作了,否則忽略掉即可。

呼叫伺服器介面案例

1.伺服器端:
服務端提供一個介面,或者網址(不是真的):

http://192.168.191.1:8081/update

獲得json資料

{"data":{
  "appname": "hoolay.apk",
  "serverVersion": "1.0.2",
  "serverFlag": "1",
  "lastForce
" : "1", "updateurl": "http://releases.b0.upaiyun.com/hoolay.apk", "upgradeinfo": "更新功能添加了掃描支付、重力感應重新整理、修改一些Bug" }
, "error_code":"300","error_msg" :"蛋疼的認識"}

2.客戶端需要實現:

兩種方式:app內部下載還是通知欄更新:

app內下載更新
這時我們必須等下載安裝完全後才能進行操作,效果是這樣的:

這裡寫圖片描述

通知欄下載更新
這種情況是不在應用內更新,放在通知欄並不會影響當前app的使用,效果是這樣的:

這裡寫圖片描述

app更新分3種:強制更新,推薦更新,無需更新

強制更新
這裡寫圖片描述

推薦更新
這裡寫圖片描述

無需更新
這裡寫圖片描述

具體思路:

1.實現bean用於對接後端介面實現app的更新(不寫網路請求模擬本地資料也需要這個模型)
2.使用retrofit來請求版本更新介面
3.下載apk我們分別使用DownloadManager和普通的httpurlconnection
4.通過BroadcastReceiver來監聽是否下載完成
實現步驟

應用增量升級

增量升級的原理
服務端通過新版本APK和舊版本APK生成patch補丁(也成為差分包),客戶端更新的時候只需要下載差分包到本地,然後從system/app取出舊版本APK,通過差分包來合成新版本的APK,這個過程實際上就是打補丁。

這裡寫圖片描述

步驟地址

增量升級並非完美無缺的升級方式,至少存在以下兩點不足:
1.增量升級是以兩個應用版本之間的差異來生成補丁的,你無法保證使用者每次的及時升級到最新,所以你必須對你所釋出的每一個版本都和最新的版本作差分,以便使所有版本的使用者都可以差分升級,這樣操作相對於原來的整包升級較為繁瑣,不過可以通過自動化的指令碼批量生成。
2.增量升級成功的前提是,使用者手機端必須有能夠讓你拷貝出來且與你伺服器用於差分的版本一致的apk,這樣就存在,例如,系統內建的apk無法獲取到,無法進行增量升級;對於某些與你差分版本一致,但是內容有過修改的(比如破解版apk),這樣也是無法進行增量升級的,為了防止合成補丁錯誤,最好在補丁合成前對舊版本的apk進行sha1sum校驗,保證基礎包的一致性。

相關推薦

版本更新增量更新應用

App的時候升級提醒有兩種方式獲得: 一種是通過App Store獲取 另一種是開啟應用之後提醒使用者更新升級 而更新操作一般是在使用者點選了更新按鈕之後開始執行的,這裡的升級操作也分為兩種形式:(一般升級,強制升級) 1.App Store升級

iOS開發:2017 蘋果APP上架更新應用版本注意事項及APP版本步驟方法

前幾天蘋果剛出臺新的政策協議,警告禁止使用APP熱更新,然後就收到蘋果發的警告郵件,然後並沒有在意,直到今天需要更新之前上架應用版本,才發現了問題。如果你的開發者賬號已經同意了蘋果開發者官網的最新協議

Android SDK 代理更新版本

啟動 Android SDK Manager ,開啟主介面,依次選擇「Tools」、「Options...」,彈出『Android SDK Manager - Settings』視窗; 在『Android SDK Manager - Settings』視窗中,在

Android app版本升級

在我們進行App開發的時候,免不了進行進行版本迭代,所以就將自己的版本迭代進行整理,以便大家使用,也對自己以後的開發更方便 首先是請求後臺資料,獲取當前後臺版本號,然後和自己客戶端的版本號進行比對,如果高於當前版本,就進行升級   //versionCode 是當前App的版本號

設計模式 | 器模式及典型應用

本文的主要內容: 介紹迭代器模式 原始碼分析迭代器模式的典型應用 Java集合中的迭代器模式 Mybatis中的迭代器模式 更多內容可訪問我的個人部落格:laijianfeng.org 關注【小旋鋒】微信公眾號,及時接收博文推送

官網TensorFlow 版本展示

網址https://pypi.org/project/tensorflow/1.12.0/#history 列出TensorFlow版本名稱,釋出時間等 還可以根據電腦環境,下載對應版本   GitHub中對版本迭代,API更新,修改,變化的記錄https://gith

Alpha版本

前言 小組名:沒有bug! 專案:短視訊APP 思考總結 設想與目標  我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述? 我們軟體主要是實現一個創新型的短視訊APP,在以往的短視訊APP的基礎上增加了一些新

敏捷需要增量 - Why Scrum Process is Iterative and Incremental?

[Source: 由邁克·科恩] 與所有敏捷流程一樣, scrum 既是迭代的, 也是增量的。由於這些詞在沒有定義的情況下經常使用, 讓我們定義它們。 開發團隊首先在系統中進行切割,知道在一些(可能很多)區域中它是不完整或弱的。然後,團隊反覆精煉這些區域,直到產品令人滿意為止。通過

時間序列預測系統α版本總結

第一次迭代已經結束,總的來說收穫很大。a版本主要進行了網站的開發,從最開始的第一個頁面到最後一個頁面,開發速度越來越快,效率越來越高,html、css、js也運用的越來越熟練,但還是需要更加深入的學習。 設想與目標 我們的軟體要解決什麼問題?是否定義得很清楚?是否對典型使用者和典型場景有清晰的描述?

敏捷開發之Scrum(增量軟體開發)

敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方法。 怎麼理解呢?首先,我們要理解它不是一門技術,它是一種開發方法,也就是一種軟體開發的流程,它會指導我們用規定的環節去一步一步完成專案的開發;而這種開發方式的主要驅動核心是人;它採用的是迭代式開發; 為什麼說是以

如何制定版本的需求清單?

 需求要從哪裡來 從使用者來 C端來說使用者畫像是個好東西,你能清楚的知道你的使用者定位,心理,偏好,基於資料可以分析出下一步的需求;B端來說使用者池是個好東西,需求反饋和客戶拜訪帶來的需求往往的是需要探尋背後業務深度的;需求從使用者來是需求構成的一部分。 從競品來 別

產品的版本機制是這樣的

一款網際網路產品的版本迭代不是在最開始就規劃好的,也不應該規劃好,甚至不用做很長遠的規劃,因為你的長遠規劃真的只是停留在規劃。 一款新產品推出市場,死了或者火了的處理方法比較簡單,可如果是不慍不火呢?迭代,該怎麼讓產品火起來? 一、產品的迭代的唯一依據————目標使用者

移動App雙週版本實戰

        對於移動網際網路產品來說,迭代的速度就是生命。我創業時做移動App時是一週一版,而現在是2周1版。相比起小公司,大公司迭代時間雖長,卻更為不易,因為大公司流程更多,參與人數更多,需求更多,實現這樣的快速迭代存在許多挑戰,也有一定風險,管理者控制起來更困難。 

Unity3D版本

版本與版本之間有差異,其中資源的更新是AssetBundle(Zip),程式碼的更新是Lua Zip01 Zip02 Zip03  本地版本 1.0.1 伺服器版本 1.0.2 因此需要在本地上去載入伺服器的Zip01包 如果伺服器現在是 1.04 則需要載入&

版本控制(Not Git/svn)

說到版本控制,大多數人的大腦中都一定會立刻想到 git 和 svn 吧,只可惜,這次的主角可不是他們 雖說 git 和 svn 雖好,對於一些專案也能夠進行很好的開發,但是呢,對於某些場景,還是有些 hold 不住的 比如,我們來舉一個場景: 現在我

敏捷開發一千零一問系列之三十六:如何做小版本的程式碼管理

本文是敏捷開發一千零一問的第三十五篇。(欄目總目錄)問題若要實現敏捷式的開發,對產品進行迭代式的小版本的釋出,在程式碼管理方面應該怎麼樣管理呢?我們目前的管理是在一個大的版本上不斷的遞增新的需求……但是要是有個需求做到一半,領導又要求做更重要的需求的情況,就很難將開發一半的程

PHP各版本

php5.3 改動: 1、realpath() 現在是完全與平臺無關的. 結果是非法的相對路徑比如FILE. "/../x" 將不會工作. 2、call_user_func() 系列函式即使被呼叫者是一個父類也使用 $this. 3、陣列函式 natsort(), natcasesort(), usor

iOS版本

當前執行版本資訊可以通過info.plist檔案中的bundle version中獲取: [cpp] view plaincopy NSDictionary *infoDic = [[NSBundle mainBundle] infoDictionary];

前端採用SeaJs模組化程式設計,處理web專案版本每次都清空瀏覽器快取問題

1.首先定製規則,業務程式碼開發的js我的在app0資料夾下,第三方的js在common資料夾下  2.引入seaJs相關的js檔案,實現模組化程式設計 <script language="ja

記錄版本_20180709

記錄這個千瘡百孔的專案迭代過程!!!! 樂店雲通用版v1.5 1、店鋪管理文案修改:“店鋪管理/店鋪裝修”文字改為“店鋪管理/微站裝修”; 2、裝修選單層級關係優化:目前的版塊命名和提示,導致層級關係很不清晰。“模板市場”可以改為“建立頁面”,“萬能頁面”可以改為