目前主流的兩個(gè)種apk更新方式：
通過(guò)市場(chǎng)更新通過(guò)app內(nèi)部下載更新?????? 不過(guò)，根據(jù)隨著android系統(tǒng)的發(fā)展，apk的體積變得越來(lái)越龐大，這種更新方式的時(shí)間成本和流量成本不斷增加。Google顯然也發(fā)現(xiàn)了這個(gè)問(wèn)題，提供了Smart App update，即差分升級(jí)方式。通過(guò)提供不同版本apk間的差異檔來(lái)減小需要下載的數(shù)據(jù)量。
?????? 可惜的是，到目前為止，差分升級(jí)也沒(méi)有成為主流，主要是對(duì)于差分檔的管理太過(guò)復(fù)雜，新版本推出以后，需要對(duì)之前的每一個(gè)版本制作差分檔，對(duì)開(kāi)發(fā)者來(lái)說(shuō)，也是個(gè)不小的負(fù)擔(dān)。
??????
??????? 相比較起來(lái)，PC端的程序更新做的更加完善，比較成熟的解決方案是，通過(guò)更新部分dll庫(kù)和圖片/音頻等其他資源來(lái)實(shí)現(xiàn)增量更新。原則上來(lái)說(shuō)，Android應(yīng)用也可以移植這樣的更新方案。但是，需要解決兩個(gè)問(wèn)題： 需要自定義ClassLoader來(lái)加載下載的jar文件需要基于事先約定的接口，或者反射等方式來(lái)調(diào)用下載的jar文件中的類(lèi)
原則上，這種方案有以下優(yōu)勢(shì)： 增量更新，減少數(shù)據(jù)下載量，減少更新所需時(shí)間，提升了用戶(hù)體驗(yàn)無(wú)需再向市場(chǎng)上傳更新包，減少了繁瑣的審核，可以自由的控制應(yīng)用更新
當(dāng)然，也有一定的劣勢(shì)： 下載的jar檔以應(yīng)用數(shù)據(jù)的方式存在，容易被刪除（Setting中的清空應(yīng)用數(shù)據(jù)功能）服務(wù)器端和客戶(hù)端要提供更加復(fù)雜的版本檢查機(jī)能最后的，應(yīng)該也是最困難的，在已經(jīng)成型的產(chǎn)品上，使用這種更新方式，需要重構(gòu)整個(gè)框架，約定高可擴(kuò)展性的接口，大部分廠(chǎng)商應(yīng)該都是不樂(lè)意接受這個(gè)成本的。
目前來(lái)看，一些大型游戲程序（>100MB)經(jīng)常會(huì)用類(lèi)似的方式更新資源包（主要是圖片音頻視頻），還沒(méi)有發(fā)現(xiàn)能夠動(dòng)態(tài)更新jar檔的應(yīng)用。希望以后隨著Android的發(fā)展，能夠在A(yíng)ndroid應(yīng)用上看到這種更新方式。

??? PS：暫不確定通過(guò)網(wǎng)絡(luò)更新so文件的可行性

? ? 對(duì)于差異化更新的進(jìn)一步分析：
1. 最容易實(shí)現(xiàn)的方案：
整個(gè)app只包含一個(gè)Activity，所有的內(nèi)容通過(guò)Fragment來(lái)展現(xiàn)，每一個(gè)fragment編譯為.class文件，實(shí)現(xiàn)動(dòng)態(tài)更新。 缺點(diǎn)： 對(duì)于原先就使用了Fragment的app，會(huì)出現(xiàn)fragment套fragment的情形，需要進(jìn)一步研究。 如果需要更新Service/Receiver/ContentProvider等組件，還是需要更新apk才能實(shí)現(xiàn)。
2.最佳的實(shí)現(xiàn)方案： 實(shí)現(xiàn)四大組件的動(dòng)態(tài)注冊(cè)（注冊(cè)到PackageManager），這樣，四大組件的實(shí)現(xiàn)都可以編譯為.class文件，實(shí)現(xiàn)動(dòng)態(tài)更新。 缺點(diǎn)： 動(dòng)態(tài)注冊(cè)的可行性待研究 如果apk試圖更新權(quán)限（permission），應(yīng)該還是需要更新APK，才能實(shí)現(xiàn)。