㈠ 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也能收到消息
常见的方法是借助第三方推送工具实现APP保活,第三方推送一般都会用“长连互保”功能来保证消息的到达,长连互保的意思是,用户设备中任何一个集成过该推送的app是打开的状态,即使这个app没打开也能启动push service,收到推送。㈣ 安卓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像素Activity
将Service 设置为前台 Service(会常驻一条通知,比如安全软件和一些手机助手)
注册系统广播
集成推送功能(推送自带唤醒)
JobScheler,AlarmManager
厂商白名单
只能做到不那么容易被杀。
关键字: 不死 保活 拉活
㈧ 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 友盟消息推送 如何保活
其实这个很简单,第三方推送一般都会用“长连护保”功能来保证消息的到达,以下是该平台推送对长连护保的解释:长连互保,用户设备中任何一个集成过友盟推送的app打开,即使他的app没打开也能启动push service,收到推送。