android分包方案
⑴ 關於android studio開發中布局文件分包問題
沒問題的，你改完如果引用不成功就點擊build選項卡clean一下project
⑵ android熱更新框架哪個好
一.基礎知識
1.阿里的熱更新框架已經開源 了。但已經很久沒有更新過新版本了。當前的版本只支持到了 Android 4.4。由於 5.0 起新的 ART 虛擬機、更嚴格的 SELinux 策略以及對 64 位的支持之類的事，使得 Xposed 都在開發上做了很多調整。我不知道 Dexposed 現在是否支持，但至少阿里沒有開源。
2.在本地動態執行遠端下發的代碼是極度危險的行為。利用此方法執行非法代碼等或用於繞過 Google Play 等市場的審查是違反相關協議的，也是對用戶極度不負責任的行為。
3.在一些訪問非常密集的地方使用熱更新可能會對效率產生相對比較大的影響，應該避免使用.
4.我們可以對 java 的 ScriptEngine 進行一些封裝成為一個 HotPatch 類使得它更適合做熱更新的工作。
5.首先,檢查熱更新補丁的管道一定要建立在 https 上，因為下發代碼是極其危險的，如果被劫持，後果是無法想像的。其次,請求時最好自動帶上 Android 版本、手機型號、地區、版本號等信息，以方便更精確地下發，千萬不能下發錯。
6.Java在運行時載入對應的類是通過ClassLoader來實現的，ClassLoader本身是一個抽象來，Android中使用PathClassLoader類作為Android的默認的類載入器
7.我們的如果想做hotpatch，一定要保證我們的hotpacth dex文件出現在dexElements列表的前面。
二.常用的熱更新技術框架:
基於QQ空間的HotFix →→ 要使用到android dex分包方案→拆分dex的項目的話，可以參考一下谷歌的multidex方案實現.
大眾點評的NuWa←項目補丁自動化做的很完整
alibaba/AndFix
阿里巴巴的DexPosed
dalvik_patch實現multidex
使用React-Native實現app熱部署的一次實踐
alibaba/AndFix
三、常用的熱更新技術框架比較
Advantage
disadavantage
NuWa
1，可以新增類和欄位，
2，兼容到6.0系統
1，基本原理是classloader,類載入器
2，不能修改資源文件，如圖片布局等（可通過動態布局實現）
AndFix
1， 支持Android2.3到6.0版本
2， 支持arm與x86系統架構
3， 支持dalvik和ART的runtime
4， 不需要重啟App即可應用補丁
1，不能新增類和欄位，
2，不能修改資源文件,
3，不能修改manifest文件
4，不能新增成員變數
5，不能使用加固後的apk製作pacth文件
四、github地址
網路的同學的實現 HotFix
點評的同學的實現 Nuwa
阿里的同學的實現 AndFix
另：AndFix對static的支持不太好，下面是試驗的Demo:
添加了一個靜態的欄位addString：
通過AndFix來製作patch會直接報錯：
⑶ android消息推送GCM、XMPP、MQTT三種方案的優劣是什麼
android消息推送GCM、XMPP、MQTT三種方案的優劣如下：1、GCM
（1）優點：提供的服務、原生、簡單，無需實現和部署的服務端。
（2）缺點：Android版本限制（必須大於2.2版本），該服務在國內不夠穩定、需要用戶綁定相關的Google帳號，而且只受限於Google。
2、XMPP
（1）優點：成熟、強大、可擴展也性強、目前主要應用於聊天系統中，且已有開源的Java版的開發實例androidpn。
（2）缺點：協議較復雜、冗餘（基於XML）、也比較費流量和費電，部署硬體成本高。
3、MQTT
（1）優點：簡潔、小巧、可擴展性強、是比較省流量、省電。目前已有C++版的服務端組件rsmb。
（2）缺點：不夠成熟、實現起來較復雜、服務端組件rsmb不開源，也是部署硬體成本較高。
消息推送軟體可以使用深圳極光的。極光成立於2011年；憑借領先的人工智慧及機器學習技術，極光將在APP消息推送、用戶增長與活躍等方面為客戶提供服務。
⑷ android studio怎麼分包
這里只做Android Studio分包配置簡單的介紹。
第一步：
在Gradle build文件中做如下配置：
android {
compileSdkVersion 21
buildToolsVersion "21.1.0"
defaultConfig {
...
minSdkVersion 14
targetSdkVersion 21
...
// Enabling multidex support.
multiDexEnabled true
}
...
}
dependencies {
compile 'com.android.support:multidex:1.0.0'
}
添加兩句代碼：
（1）multiDexEnable true
（2）compile 'com.android.support:multidex:1.0.0'
第二步：
在AndroidManifest.xml文件中做如下配置：
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.android.multidex.myapplication">
<application
...
android:name="android.support.multidex.MultiDexApplication">
...
</application>
</manifest>123456789123456789
如果你要定義自己的Application，或者已經有了自定義Application，那麼不需要在application節點中用android.support.multidex.MultiDexApplication，而是用自己的Application類的全名即可，而且自定義的Application也不需要繼承MultiDexApplicatoin。
第三步：
如果有自定義的Application，那麼在自定義的Application類中，重寫attachBaseContext()，並且在其中調用super.attachBaseContext()，然後調用MultiDex.install(this) ，然後在該方法上加上@Override註解，既然是重寫方法，最好加上這個註解，不過Android Studio會自動加上。
有兩點可以注意：
attachBaseContext()是在ContextWrapper類中的。而MultiDexApplication繼承Application，就是如第二步一樣重寫了attachBaseContext()方法。
不需要另外在libs中添加android-support-multidex.jar，否則會報異常。
⑸ android樂變分包技術 怎麼實現的
Intent intent = new Intent(); intent.setClass(**.this, **.activity); startActivity(intent); (**.this, **.activity) 第一個為當前activity，第二個為想要跳轉的activity
⑹ Android開發有MVC的框架嗎Android 開發該怎麼分包
現在都使用mvp進行android開發。
詳細例子請參考android學習手冊，360手機助手中可以下載，裡面有108個android例子，源碼文檔都可在裡面看，裡面有詳細介紹這個的框架。
MVP模式是什麼？MVP 是從經典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負責邏輯的處理，Model提供數據，View負責顯示。
MVC和MVP的區別？
為什麼會出現MVP模式呢？這是因為原有的MVC模式有一些短板。比如在android開發中，activity充當著MVC中Controller的角色，但是在實際開發中處理view的邏輯和角色。當業務界面復雜時我的activity會顯得很龐大。於是出現了MVP模式，它新增了一個Presenter角色用於處理數據和界面的模型以及邏輯，Activity僅僅用於展示界面和用戶交互，這樣就解決了MVC中角色不清的局面。
所以，MVP與MVC的重大區別：在MVP中View並不直接使用Model，它們之間的通信是通過Presenter (MVC中的Controller)來進行的，所有的交互都發生在Presenter內部，而在MVC中View會直接從Model中讀取數據而不是通過 Controller。
在MVC里，View是可以直接訪問Model的！從而，View里會包含Model信息，不可避免的還要包括一些業務邏輯。 在MVC模型里，更關注的Model的不變，而同時有多個對Model的不同顯示，即View。所以，在MVC模型里，Model不依賴於View，但是View是依賴於Model的。不僅如此，因為有一些業務邏輯在View里實現了，導致要更改View也是比較困難的，至少那些業務邏輯是無法重用的。
MVC模式結構
Model 業務邏輯和實體模型
Controller 對應Activity
View 視圖以及布局文件
MVP模式結構
Model： 業務邏輯和實體模型
View：用戶交互和視圖顯示，在android中對應activity
Presenter： 負責完成View於Model間的邏輯和交互
小節：MVP模式相當於在MVC模式中又加了一個Presenter用於處理模型和邏輯，將View和Model完全獨立開，在android開發中的體現就是activity僅用於顯示界面和交互，activity不參與模型結構和邏輯，
####實戰
谷歌官網給了我們一個MVP模式實戰的例子，它是一個類似記事本的app，源碼地址在：https://github.com/googlesamples/android-architecture
官方案例的框架圖如下：
⑺ Android 開發中，有哪些坑需要注意
1、不要排斥新技術和新工具。 Android Studio 1.0 之後的版本，基本已經穩定到可以支持正常的工作開發的程度了。單純就書寫效率而言，Android Studio 帶來的好處絕對大於它和Gradle的學習成本。JetBrains的IDE，用過都說好。還有就是適當的提升targetSdkVer… 顯示全部
1、不要排斥新技術和新工具。
Android Studio 1.0 之後的版本，基本已經穩定到可以支持正常的工作開發的程度了。單純就書寫效率而言，Android Studio 帶來的好處絕對大於它和Gradle的學習成本。JetBrains的IDE，用過都說好。
還有就是適當的提升targetSdkVersion到新版本。
2、代碼設計方面的問題，大部分都能在Android系統源碼里找到解決方案。
當自己想設計一個新模塊，或者實現一個新ui組件的時候，應該採用哪些設計模式、應該以哪種形式給外界提供介面之類的問題，大部分都可以參考Android系統的源碼，找到實現方式。Google為安卓程序員提供了一座現成的寶庫。
3、理解Android和Java內存管理方式，至少要理解垃圾回收和Java的引用。
就好比學OC就要先理解黃金法則一樣，而java的內存管理，其實比OC要好理解多了。
這可能會幫助大大減少程序非同步操作產生的空指針崩潰。也會幫助理解為什麼濫用單例模式會導致內存的臃腫。還會幫助養成不用「+」去連接超大字元串的好習慣。
4、ContentProvider並不是只有在跨進程共享數據的才有用，把資料庫表映射到一個獨立的uri是Google鼓勵的實現方式。
從設計上講，用uri（統一資源標識符）去描述數據，肯定比sql語句要理想。
從效果上講，用CursorLoader讀取數據是讓iOS程序員都羨慕不已的事情，作為android程序員，何苦不用呢。
5、理解Activity任務棧。
非Activity的Context對象如果直接啟動Activity會報錯，這只是一個表面現象，真正起作用的其實是Activity任務棧機制。
理解Activity任務棧機制以及Activity的各種啟動方式，會幫助解決大部分頁面關系錯亂問題，以及應用互相掉起、任務欄進入應用、後台彈窗引起的各種問題。
6、對於一些奇葩的第三方ROM，調用其非主流api的時候，可以使用反射。
在適配一些第三方ROM的的時候，調用一些在開發環境中沒有，但在運行環境中有的方法時，可以使用反射。比方說，華為雙卡手機可能會提供獲取第二塊SIM卡信息的api，如果直接調用，在開發環境可能無法通過正常編譯，用反射就沒問題。這屬於不得已而用反射的一種情況。
7、SQLite的鎖，是資料庫級別的鎖，也就是說同一個資料庫的寫操作無法並發執行。
所以，在資料庫設計的時候，如果表太多，盡量將沒有關聯的表拆到多個資料庫文件中。
8、Bitmap的內存佔用問題。
這是一個困擾2.X時代android程序員的問題。
2.X時代Bitmap對象雖然存儲在堆內存中，但是用了一個byte數組存儲其像素信息。通過計數器來記錄該像素信息被引用的個數。有人認為這個byte數組在native堆中，但事實上它也在堆中。
只有在使用者調用recycle()後，Bitmap對象才會釋放像素信息，才會在失去引用後，被垃圾回收機制銷毀。再加上DVM的heap size有嚴格的閥值，所以在使用大量圖片資源的時候，及其容易發生OOM。
解決辦法一般都是，用一個哈希表存儲Bitmap對象的軟引用，作為內存緩存，並在適當時機掉用其recycle()。
3.0以上版本Bitmap對象可以通過垃圾回收機制完全銷毀，理論上不用再調用recycle()。
⑻ android應用程序結構xml文件按功能分包
如下圖所示，animhi動畫文件，drawable用來放圖片，形狀，選擇器文件，drawable-hdpi-v4到drawable-xxxhdi-v4都是放置大小不同的圖片，為了適配更多的手機，layout是界面布局文件，menu是菜單文件
⑼ Android 幾種消息推送方案總結
Android 幾種消息推送方案總結:一、使用GCM(Google Cloude Messaging) Android自帶的推送GCM可以幫助開發人員給他們的Android應用程序發送數據。它是一個輕量級的消息，告訴Android應用程序有新的數據要從伺服器獲取，或者是一個消息，其中包含了4KB的payload data（像即時通訊這類應用程序可以直接使用該payload消息）。
GCM服務處理排隊的消息，並把消息傳遞到目標設備上運行的Android應用程序。
二、使用XMPP協議（Openfire+Spark+Smark） XMPP是一種基於XML的協議，它繼承了在XML環境中靈活的發展性，有很強的可擴展性。包括上面講的GCM伺服器底層也是採用XMPP協議封裝的。
三、使用MQTT協議（想了解更多可以看http://mqtt.org/）輕量級的、基於代理的「發布/訂閱」模式的消息傳輸協議。
四、HTTP輪循方式。定時向HTTP服務端介面（Web Service API）獲取最新消息。
五、採用第三方服務。客戶端只需要導入第三方提供的lib庫，有第三方管理長連接，負責消息的接收/發送。同時對消息都有比較詳細的報表數據，可以用於做數據分析、挖掘，改善用戶體驗。
中合對比還是採用第三方服務簡捷高效。比如極光推送就很好用，極光推送搭建起一個高度穩定、可擴展的雲端架構，極大地幫助移動應用開發者節約開發和維護的成本，輕松實現毫秒級的精準推送。
⑽ Android的APP，是怎麼做渠道統計的
安卓渠道統計方案
方法1：通常傳統的做法是對不同渠道進行分包發布，每個渠道打一個標識唯一的渠道id的安裝包，再收集渠道安裝數據。這種方式有些弊端，如果渠道很多的話比如說有100個渠道要推廣，就得手工打100個渠道包，這樣做的話技術人員就比較辛苦了。另一個弊端就是應用市場會存在抓包的情況，這樣就會造成數據不準的情況。
方法2：用渠道鏈接替代渠道安裝包做渠道統計，這種方案就可以免去手工打渠道包，而且統計數據會更精確。具體實現請參考openinstall的官網 www.openinstall.io