蘋果應(yīng)用商店的更新是增量更新嗎？

首先回答問題之前我想問一下您是開發(fā)人員還是普通用戶。如果是普通用戶，我很興奮，一個普通用戶能想到這個并提出這個問題，真的很了不起。對，很了不起！very Good！

如果你是普通用戶，我直接在這里簡短回答你一下：蘋果在iOS7之后就已經(jīng)支持增量更新了。但是，回到你的問題，蘋果應(yīng)用商店的更新是增量更新嗎？回答是：有的是，有的不是。蘋果是支持增量更新，但是有的開發(fā)者他么有想去使用這個功能，或者因為技術(shù)原因，放棄了這個功能，所以某些app沒有增量更新這個功能，你每次下載還是得全部重下載。而一些優(yōu)化做的比較好的app是支持增量更新的，例如某寶之類的。

如果你是程序狗，下拉2行，不影響其他用戶閱讀，咱們?nèi)ド钏畢^(qū)探討下，我拋磚引玉，也希望大神來接著給點意見。

關(guān)于iOS應(yīng)用的增量更新，iOS7.0以后就已經(jīng)支持，具體參見文檔

Q: How can I reduce the downloaded size of my app update for users that already have the previous version installed?

A: This document is specific to app updates. See Technical Q&A QA1795: Reducing the size of my App for a collection of techniques to reduce the size of an app when it is downloaded and installed for the first time.

Starting with iOS 6, the app store will automatically produce an update package for all new versions of apps submitted to the store. When generating the update package, the app store compares one or more prior versions of your app to the new version and creates an optimized package for each that contains only the content that has changed between versions of your app, excluding any content that did not change. This comparison looks at everything in the application bundle, including the application executable, nibs, localizations, image files, video files, audio files, text files, and files containing data in a custom format.

Note: The ability to create update packages is not currently available to developers who do not distribute their apps through the app store, such as those distributing enterprise apps.

When used optimally, an update package is significantly smaller to download than the full package of the app and the update will install more quickly. Also, in many cases, this mechanism allows updates to large apps to be downloadable over cellular networks where app downloads are subject to a size limit.

In addition to new content, the update package contains instructions on how to transform the prior version of the app into the new version of the app. New files will be added, modified files will be replaced with their updated counterpart, and deleted files will be removed as part of this transformation. As far as the developer and user are concerned, this process is entirely transparent and the resulting updated app will be indistinguishable from a full download of the corresponding updated version of their app.

To optimize the size of your app updates, you should consider two tips:

Do not make unnecessary modifications to files. Compare the contents of the prior and new versions of your app with or another directory comparison tool and verify that you've only changed what you expect within your app bundle.

Content that you expect to change in an update should be stored in separate files from content that you don't expect to change. This reduces the size of the update package and increases its install speed.

For devices running iOS 6.x and iOS 7.0, the update package will include any file, in its entirety, that has changed in the new version of the app. For example, if you have a 10 MB file in your app and only change 1 KB of content within that file in the new version of the app, the update package for that new version will contain the full 10 MB file.

For devices running iOS 7.1 and later, the update package may include only the differences between the old and new versions of a changed file instead of the full file. This may significantly reduce the size of the update package in the case where only a small part of a large file changes, but will increase the update's installation time on the device. For this reason, the two tips above are still important even for updates on iOS 7.1 and later. Minimizing changed content and localizing it to many smaller files instead of one larger monolithic file will reduce the download size in all cases and will speed up installation on devices running iOS 7.1 and later.

7.1以后就已經(jīng)自動進行增量更新了，但是有很多開發(fā)者發(fā)現(xiàn)自己的應(yīng)用每次更新還是下載了全部大小，并不是文檔里寫的只下載修改的大小，當(dāng)然有的是文檔所寫的所有文件都進行了無必要的修改。大部分是因為對bitcode的修改，直接設(shè)置為disable，所以蘋果不能自動就行增量更新。這里就不解釋為什么很多人為什么要將bitcode設(shè)置為disable了，大部分從xcode7過來的都深有體會。只說一下為什么蘋果為什么從xcode7開始默認(rèn)打開bitcode？為什么蘋果默認(rèn)要求watchOS和tvOS的App要上傳bitcode? 因為把bitcode上傳到他自己的中心服務(wù)器后,他可以為目標(biāo)安裝App的設(shè)備進行優(yōu)化二進制,減小安裝包的下載大小,當(dāng)然iOS開發(fā)者也可以上傳多個版本而不是打包到單個包里,但是這樣會占用更多的存儲空間. 最重要的是允許蘋果可以在后臺服務(wù)器對應(yīng)用程序進行簽名,而不用導(dǎo)出任何密鑰到終端開發(fā)者那。

這是正常的增量更新方法了。還有“不正常的”熱更新。這個也是那些每次打開app就進行遠(yuǎn)程檢查版本是否需要跟新的app的套路，比如那農(nóng)藥啊。我個人之前也喜歡搗鼓這個熱更新。因為要睡覺了，先引用下別人寫的，有時間再來優(yōu)化。

iOS主要是使用JSPatch來實現(xiàn)熱補丁修復(fù)，在項目中引入JSPathc，然后在發(fā)現(xiàn)bug時下發(fā)JS腳本補丁，替換原生方法，以此實現(xiàn)無需更新APP即時修復(fù)bug。

主要實現(xiàn)流程：當(dāng)客戶端出現(xiàn)bug時，iOS開發(fā)人員需要開發(fā)一段JS腳本用于修復(fù)bug，腳本開發(fā)完成后，服務(wù)端開發(fā)人員根據(jù)iOS開發(fā)人員提供的JS腳本部進行一定的安全策略部署服務(wù)端腳本，iOS客戶端通過腳本版本檢測接口，判斷是否需要下載JS腳本，下載腳本成功后，進行加載，運行，進而修復(fù)APP的bug。

其中，客戶端與服務(wù)端在獲取JS腳本時會進行安全校驗，防止過程中被攻擊替換代碼，安全校驗的簡單流程：a.服務(wù)端對JS腳本文件生成一個MD5（文件的唯一標(biāo)識）值并加密——b.將加密的MD5值與JS腳本傳給客戶端——c.客戶端對拿到的腳本文件計算MD5值，且對加密的MD5值進行解密——d.客戶端對比計算出的MD5值與解密后的MD5值——e.兩個MD5數(shù)值相等則通過校驗。

熱補丁技術(shù)不僅可以用來修復(fù)bug打補丁，還可以在線更新代碼添加新需求哦！

增量更新技術(shù) 定義

增量更新是指在進行更新操作時，只更新需要改變的地方，不需要更新或者已經(jīng)更新過的地方則不會重復(fù)更新。也就是，只將App中有發(fā)生改變的部分發(fā)送給用戶，而不是每次都重新下載一個完整的安裝包。

原理

生成差異包。將 App 的最新安裝包(V2)與歷史發(fā)布版本的安裝包(V1)進行差分對比，得到一個差異包(V2-V1)。下發(fā)差異包。當(dāng)某個老版本(V1)的 App 開始檢查更新的時候，需要將自己當(dāng)前的版本信息發(fā)送給服務(wù)端，然后服務(wù)端判斷后，選擇對應(yīng)的差異包(V2-V1)下發(fā)。合成新包。校驗完整性。校驗當(dāng)前歷史包的Hash值以及差異包的Hash（哈希值是一段數(shù)據(jù)唯一的數(shù)值表示形式）值，合成新包后，也要校驗新包的Hash值，只有這三個Hash值都與預(yù)期匹配，才可以確認(rèn)新包是完整的。

增量更新的注意點：

增量更新是以兩個應(yīng)用版本之間的差異來生成補丁的，無法保證用戶每次及時升級到最新，所以必須對所發(fā)布的每一個版本都和最新的版本作差分，以使所有版本的用戶都可以差分升級，這樣操作較為繁瑣，不過可以通過腳本批量生成。增量更新成功的前提是，用戶手機端必須有能夠被拷貝出來且與服務(wù)器用于差分的版本一致的APK文件，這樣就會造成一些情況，例如，系統(tǒng)內(nèi)置的APK無法獲取到，則無法進行增量更新。

下面有請大神繼續(xù)補充，我來吃個瓜！