android保活

㈠ android無線開發的幾種常用技術（阿里巴巴資深

完整的開發一個android移動App需要經過從分解需求、架構設計到開發調試、測試、上線發布等多個階段，在發布後還會有產品功能上的迭代演進，此外還會面對性能、安全、無線網路質量等多方面的問題。
移動App的產品形態各不相同，有的是內容類，有的是工具類，有的是社交類，所以它們的業務邏輯所偏重的核心技術有些差別，但它們都會用到一些常用的技術方案。今天我們就先來簡單介紹一下這些常用技術，以後會專門分專題來詳細介紹這些技術的原理和使用場景。

1. Multidex
在Dalvik虛擬機所使用的dex文件格式中，用原生類型short來索引文件中的方法數，也就是最多隻能有4個位元組65536個method，在打包apk的過程中會把工程所需要的全部class文件都合並壓縮到一個dex文件中，也就是說自己開發的代碼加上外部引用的庫的方法總數不能超過65535。
隨著業務邏輯的不斷增長，很容易就會超過這個限制，在編譯期間就會遇到這樣一個錯誤：

還好google官方給出了一個解決方案Multidex，它會把dex文件拆成兩個或多個，第二個dex文件叫classes2.dex，在Application實例化後會從apk中解壓出classes2.dex並將其拷貝到應用的目錄下，通過反射將其注入到當前的ClassLoader中。但是這個方案非但不能解決一切問題也不能直接拿來用，而要加入自己的一些改造，來解決NoClassDefFoundError、INSTALL_FAILED_DEXOPT等問題，以保證自己的dex被順利的載入流暢的執行。

2. Plugin
Multidex雖然可以解決方法數的限制，但隨著業務邏輯越來越多，apk的大小也變得越來越多，而且有一些功能並非全部用戶都想用的，所以會把一些功能模塊獨立出來做成插件，讓用戶可以按需下載更新，這樣既減小了包大小，又改善了用戶體驗。

插件類似於windows的dll文件，放在某個特定目錄，應用程序主框架會用LoadLibrary載入各dll文件，按插件介面去訪問插件。Android的插件技術也是這樣，利用一個進程可以運行多個apk的機制，用ClassLoader將宿主apk之外的類載入進來，插件的context可以通過createPackageContext方法創建。因為插件中的activity，service等組件如果沒有在AndroidManifest.xml中聲明將不能運行，所以需要預先在AndroidManifest.xml中聲明一個代理類（ProxyActivity），將這個ProxyActivity傳給插件，讓插件的activity也有訪問資源的能力。

3. Hot Patch
有時一些嚴重的crash bug或漏洞需要緊急修復，但有些用戶不會或不願意立即升級，而且頻繁升級，沒有特別的功能更新只是修復bug的升級，對活躍用戶是一種傷害。熱補丁就可以解決這樣的窘境，它是一種可以線上修復的技術方案，有動態改變方法的能力，一般大型的移動應用都會使用熱補丁來處理緊急事件。

Hot Patch可以通過hook來修改java的method，注入自己的代碼，實現非侵入式的runtime修改，或者採用正向編程，通過工具生成patch文件，通過jni bridge指向補丁文件中的方法。還有就是利用ClassLoader，在dex中查找class時，如果找到類則返回，找不到就從下一個dex文件中繼續查找，由此可以想到，在把問題修復後，可以單獨生成一個dex，通過反射插入到dexElements數組的最前面，這樣就能讓dalvik載入補丁里的類了。

4. Push通道
Push是移動App常用的一種無線技術，基礎是基於TCP的心跳機制，和客戶端維持一個長連接。用處是向客戶端推送消息，或者代替客戶端定時去從伺服器pull的策略，改為客戶端接收到push消息後再去pull。
如果每個應用都自己實現push通道的話，cpu就會不定時地經常被喚醒，耗電量達到難以容忍的程度，而且自己搭建push平台的成本也很大，實時性和效率也存在問題，一般都直接使用一些服務商提供的push方案，這些push平台一般都經過了優化設計，在跨平台和網路穿透性、長連接心跳包、多客戶端App鏈路復用、服務和連接保活等技術上做了優化。比如Agoo最初是淘寶無線事業部開發的push服務，在逐漸完善和支撐淘系其他app後，通過服務端容量、通訊協議優化、業務和開放能力的拓展改進後，與友盟等合作，開始向第三方提供推送服務。

5. 應用加固
一款熱門的移動app或游戲發布後會受到很多的關注，經常會遇到二次打包的盜版行為，破解者要麼修改游戲的資源文件、道具、分值甚至直接把訪問的站點指向自己架設的伺服器，損害了開發者的利益；要麼偷偷植入自己的惡意代碼，表面上看起來跟正版的app完全一樣，在後台卻盜取用戶隱私，植入木馬；要麼通過反向工程學習原app的核心技術，打破技術上的競爭壁壘。
為了防止被破解只通過混淆是遠遠不夠的，即使是在native層混淆也還是會被人熟練的反編譯，所以需要一套對apk的保護方案來反調試、防逆向和防篡改。一般的加固方法都是對原apk先進行加密，然後和殼合並生成新的apk。殼是用來解密apk的dex文件。當應用啟動時，殼先解密原apk，准備好自己定義的ClassLoader，然後獲取源程序中的Application名稱，通過反射找到正確的Application對象，運行它的onCreate方法，這樣原apk才能被真正運行。其他一些反調試的方法有針對反編譯工具，在源程序中加入一些無效的指令或無效的指針，引發反編譯工具的崩潰，還有就是加花指令，利用一些跳轉，堆棧操作等指令，讓破解者無法清楚地理解反匯編後的內容。

6. 其他
除了上述幾點外，在服務端還會涉及灰度策略、鏈路流量優化、動態更新配置、防DNS劫持等技術，在客戶端會涉及用戶埋點上報、在線監控、進程保活、H5和native混合開發、注入框架等。

㈡ 求問大神 AndroidDaemon.apk 這個軟體是啥

Android 服務保活/常駐 (Android Service Daemon)
建議只在 App 的核心功能需要保活/常駐時使用。
啟動前台服務而不顯示通知來自於 D-clock 的 AndroidDaemonService，對其他的一些非 native 層保活方法進行了實現。

㈢ android開發 如何像微信一樣，不啟動App也能收到消息

㈣ 安卓8.0以上 怎麼實現保活啊急

對於移動端IM應用和消息推送應用的開發者來說，Android後台保活這件事是再熟悉不過了。

自從Android P（即Android 8.0）出現以後，Android已經從系統層面將後台保活這條路給堵死了（詳見：《Android P正式版即將到來：後台應用保活、消息推送的真正噩夢》），曾今那些層出不窮的保活黑科技能用的也越來越少了（詳見：《全面盤點當前Android後台保活方案的真實運行效果（截止2019年前）》。雖然可以自已對接廠商的ROOM級推送通道，但一方面各廠商的推送介面都不一樣（而且同一廠商不同的系統版本間也存在推送介面的兼容性問題），很不方便。另一方面要一家家引入各自的推送服務SDK包會讓APP變的很大，這讓APP的下載變的很不友好。

總之，Android應用的後台保活在某些場景下，還是有持續的需求。除了之前那些耳熟能詳的保活黑科技以外，在Android 9.0（甚至Android 10）時代，我們還有哪些保活方法可以用？那麼，請跟著本文作者的思路，看看更優雅的後台保活實現方法吧

㈤ app植入保活功能後,會存有惡意軟體嗎

建議用戶提高警覺性，使用軟體請到官網下載。到應用商店進行下載正版軟體，避免從論壇等下載軟體，可以有效的減少該類病毒的侵害。關注」暗影實驗室」公眾號，獲取最新實時移動安全狀態，避免給您造成損失和危害。
為防止病毒變種，用戶發現已經安裝此病毒的，可以請專業人員分析此病毒。
安全需要做到防患於未然，可以使用恆安嘉新公司的APP威脅檢測與態勢分析平台進行分析對Android樣本提取信息並進行關聯分析和檢測；
用戶發現感染手機病毒軟體之後，可以向「12321網路不良與垃圾信息舉報受理中心」或「中國反網路病毒聯盟」進行舉報，使病毒軟體能夠第一時間被查殺和攔截。

㈥ 面試android高級開發工程師具備哪些技能

1、關於團隊：對內：能提升團隊內聚力和執行力，注重個人成長，能快速提高團隊戰鬥力；對外：能住區更多的資源，使項目和組內成員獲得更好的成長和發展。
2、關於技術：領導項目優化，架構變更、核心模塊的修改，也能不斷引入新技術、對標競品，不但技術上領先，也能做出更優秀的作品。
一、了解系統核心機制
1. 了解SystemServer的啟動過程
2. 了解主線程的消息循環模型
3. 了解AMS和PMS的工作原理
4. 能夠回答問題」一個應用存在多少個Window？「
5. 了解四大組件的大概工作流程
二、基本知識點的細節
1. Activity的啟動模式以及異常情況下不同Activity的表現
2. Service的onBind和onReBind的關聯
3. onServiceDisconnected(ComponentName className)和binderDied()的區別
4. AsyncTask在不同版本上的表現細節
5. 線程池的細節和參數配置
6.熟悉設計模式，有架構意識
三、技術要求
1.稍微深入的知識點
2.系統核心機制
3.基本知識點的細節
4.設計模式和架構
當然，除了上面的知識點和技能外，你還要能玩轉RxJava、掌握自定義view 、要會進程間通信與進程保活、熱修復等知識點。

㈦ 怎麼讓 Android 程序一直後台運行，像 QQ 一樣不被殺死

1. 提高進程優先順序，降低進程被殺死的概率

2. 防止鎖屏清理，1像素Activity

3. 將Service 設置為前台 Service（會常駐一條通知，比如安全軟體和一些手機助手）

4. 注冊系統廣播

5. 集成推送功能（推送自帶喚醒）

6. JobScheler，AlarmManager

7. 廠商白名單
   

只能做到不那麼容易被殺。

關鍵字： 不死 保活 拉活

㈧ Android 7.0 和8.0 如何保活

1.控制onStartCommand函數的返回值。

我對這個函數的理解是：當服務被異常終止時，是否重啟服務?

有些文章裡面在用這個做保活時，修改的是flag，在我實際測試中是無效。有效的做法是直接返回參數。另外默認的flags值為0，是START_STICKY_COMPATIBILITY。如下：

[java]view plain

• @Override

• publicintonStartCommand(Intentintent,intflags,intstartId){

• //TODOAuto-generatedmethodstub

• returnSTART_STICKY;

• //returnsuper.onStartCommand(intent,flags,startId);

• }

測試結果：

魅族的機子：無效，不管默認還是修改參數，在DDMS裡面直接結束進程後都不會重啟服務。

其它三台機子（9100沒測）：默認參數的情況下就會重啟服務，return START_STICKY 會重啟，return START_NOT_STICKY 不會重啟。

其它：1.用360一鍵清理，或者360超級ROOT的手機優化，會殺死進程，過會兒還是會重啟，只是會慢很多，大概是在排隊重啟服務。

2.一次測試完後確保服務重啟後，執行了onStartCommand函數。

2.在service 的onDestory裡面重啟服務

這個在所有能觸發onDestory的情況下都是有效的。4台測試機都測試過。直接startService 或者發送廣播重啟都可以 。

但能觸發onDestory的情況，我不知道內存回收會不會觸發。另外兩種情況（2，3）是不觸發的。我的測試方法是在「設置」-》應用管理-》正在運行-》停止服務。（這個是正常停止服務，會觸發onDestory，所以上面的onStartCommand效果不會觸發。）

3.提高服務的優先順序

這個主要是針對第一種kill服務的情況，內存回收機制。由於這個測試比較難搭建。360清理什麼把後台的進程都殺的，體現不出優先順序這樣的概念。我的建議是能提高就提高。下面例幾種。

通知--前台service

創建一個通知使自己成為前台service

測試結果：

360一鍵清理和手機優化，不會把該service結束掉。

對於後台保護：華為G730不結束service，魅族和華為TL00H都會結束service。

通知欄的保活效果還是可以的，一般的應用要求基本能滿足了。

若有root許可權：

android:persistent="true",並放入system/app中

測試結果：效果一般，三星9100上用360等清理工具殺不掉進程，在華為G730上沒什麼效果.（這個測試跟onStartCommand有點干擾）

4.守護進程

雙服務

360會同時殺掉兩個服務，分兩個apk也一樣。

native守護進程

360不會殺掉native的守護進程，但在魅族和華為TL00H中待機一段時間後還是會被殺掉。

結論和待續

1.一般的應用添加到後台保護進程後，改個onStartCommand返回值，再加個通知。基本上大部分都能保活了。

2.雙服務我覺得沒有native守護進程來的好，雖然360，微信什麼的都有幾個進程服務，但如果不添加到後台保活的話，效果一樣不能保活，也會進入停止狀態。

3.但是.360手機助手會創建雙natice守護進程做相互的看守。存活的效果會高一點點。「沒添加到後台保活」一般只會殺一次，（魅族是屏幕關閉後5分鍾，華為TL00H是屏幕關閉時）

㈨ Android N 是什麼

一、 性能改善
Doze超級省電模式
手機在關屏同時沒有充電的情況，會進入打盹狀態，這時候app的位置服務，訪問網路，cpu background-running 等後台服務會被停止，不允許定時任務，忽略wake locks，停止wifi scanner。
會影響app的保活，尤其對那些需要接受消息類的app。Google 推薦使用GCM。
後台優化
廣播：
靜態注冊CONNECTIVITY_ACTION 廣播將失效，只有動態注冊才行。Android 5.0上可以使用JobScheler在指定的網路條件運行你的任務，還可以通過ConnectivityManager registerNetworkCallback()來監聽網路狀態。
ACTION_NEW_PICTURE，ACTION_NEW_VIDEO廣播已經去除，當然應用可以通過ContentResolver來監聽。Android N上面可以JobScheler來監聽
二、 NDK 試用改變
限制只能試用平台公共api，否則你的應用會crash，最好只使用NDK中包含的api，否則系統被定製了可能會找不到你要鏈接的so，其次使用第三方so的時候也要注意對方有木有試用非法的so.
如圖：

三、 Screen Zoom

用戶最低可以改變到屏幕寬度為320dp，所以app最好能適配sw320dp，當你的 compile target < android N 時，當用戶改變屏幕顯示大小時，會殺掉後台進程(你的app會被幹掉哦)
四、 Language and Locale
支持多用戶多語言環境，提供新的API： LocaleList.GetDefault()，可以獲取所有用戶的語言環境。
同時app多語言查找策略改變，當你的app中不在當前語言環境的resources時，會找最接近的語言代替，而不是直接使用默認語言代替。如：你的app的Resources中只包含 es，和zh_cn，當用戶的環境是zh_tw時，會用zh_cn代替。並且還支持自定義語言目錄。

五、 Multi-Window Support
Android N機器上默認就支持Multi-Window,同一個屏幕可以運行多個app窗口。有兩種模式，split-screen mode和picture-in-picture mode。app開啟和關閉這兩個模式很方便，在AndroidManifest.xml配置一下即可。
android:resizeableActivity=["true" | "false"]
android:supportsPictureInPicture=["true" | "false"]
這種模式在平板電腦上面很合適。

六、Notifications
Android N提供一些新的關於Notifications的API。
RemoteInput.Builder：使得用戶可以在通知欄直接回復，這個很適合社交類app和簡訊app,以及可以應用到用戶反饋中。

NotificationCompat.Builder.setGroup()：可以使同一個app通知放在同一個分組。

NotificationManager：能讓你知道你目前發了多少條通知，怎樣通知進行分組。
七、Data Saver
當用戶開啟流量節省後，會禁止app在後台使用收費網路流量數據。甚至在前台使用流量時也會發出警告。
ConnectivityManager.isActiveNetworkMetered()，
ConnectivityManager.isActiveNetworkMetered()，
查詢是否開啟流量節省模式，自己是否在用戶白名單中（對自己例外）
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
監聽用戶開啟流量節省模式
八、Network Security Configuration
能讓app定製網路安全設置：
Debug-only overrides（自定義信用的CA）。
Debug-only overrides（自定義能調試你app信用的CA）
Cleartext traffic opt-out（防止網路請求明文交互）
Certificate pinning（自定義只信用包含特定公鑰CA）

㈩ android 友盟消息推送 如何保活