Android黑科技保活实现原理揭秘,聪明人已经收藏了!

Android黑科技保活实现原理揭秘,聪明人已经收藏了!,第1张

概述背景首先我是个菜鸡,工资也低的一笔。刚毕业时候在一家国企上班干app开发,干了快两年的时候,跳槽到了一家伪大厂干安全。投了不少简历都没有回音,只有这加伪大厂要我就来了。当时说好了会接触一些底层的东西,然而平时也就写python脚本,逆向,android上写了一些风控的东西,感觉 背景

首先我是个菜鸡,工资也低的一笔。

刚毕业时候在一家国企上班干 app 开发,干了快两年的时候,跳槽到了一家伪大厂干安全。投了不少简历都没有回音,只有这加伪大厂要我就来了。当时说好了会接触一些底层的东西,然而平时也就写 python 脚本,逆向,androID 上写了一些风控的东西,感觉有点 low,工资也不高,当初没敢多要,hr 给的比我要的还高。刚刚 leader 谈了谈明年的规划,现在想跳槽。

现在也是很尴尬,原来 app 开发的东西也忘了不少,然后其实我想干 framework 开发,自己对 ams,pms 还算挺了解的,平时也根据他们原创了一点微小的解决方案。最近开始 fork 一个 aosp,买个 pixel 改改刷刷练习一下。

理想毕竟是理想,AndroID 低端不好混,没什么经验跳到 framework 上去感觉也是挺难的,跳回 app 开发又不甘心,现在的状态貌似是干了快 3 年没有特别精通的东西。最近闹的裁员,我司也是其中之一。加薪怕是没戏了,然而生活还要继续,跳槽避无可避。

这是我印象深刻的一道题,很明显它是我的第一次,那时我去一家公司(暂时叫它T公司吧)面试外派到韩国三星的工作机会。T公司的面试官是一个叫Bely架构师,显然那个时候AndroID开发是稀缺资源,知道Service那都不得了了,当然Bely也没打算为难我(必竟也工作4年多了,人长得也不错),我轻松对答:

Service是一个专门在后台处理长时间任务的AndroID组件,它没有UI。它有两种启动方式,startService和bindService。

你猜得没错,Bely紧接着问我:这两种启动方式的区别。

startService只是启动Service,启动它的组件(如Activity)和Service并没有关联,只有当Service调用stopSelf或者其他组件调用stopService服务才会终止。
bindService方法启动Service,其他组件可以通过回调获取Service的代理对象和Service交互,而这两方也进行了绑定,当启动方销毁时,Service也会自动进行unBind *** 作,当发现所有绑定都进行了unBind时才会销毁Service。

这应该是比较关键的区别了,在面试前我刚刚用Serivce做过一个音乐播放器。几年后,我在深圳面试过很多人,他们中有60-70%的人没有使用Service的经验,让我一度感觉得深圳这座城市做AndroID开发的比较浮躁。因为这儿工作机会太多了,初级的开发者都比较急功近利,不需要在自己身上下太多的功夫也可以找到工作(当然这是片面的认识)。

当然还有其他的区别,如两种调用对Service生命周期函数影响,面试官也可以就这个问题展开一下。

当我遇到面试者知道怎么使用Service,也如多年前的我可以自如的答出startService和bindService的区别时,我一般会多问一句:

Service的onCreate回调函数可以做耗时的 *** 作吗?

很多人都会说:可以。

原形毕露,他前面的回答只是在面试前预习了一下面试题而已。如果知道Service的onCreate是在主线程(ActivityThread)中调用的,耗时 *** 作会阻塞UI,我一般再接着问:

如果需要做耗时的 *** 作,你会怎么做?

问题便这样展开了,一个人是否真正懂得原理会灵活运用,一下子便能看出来。 当面试者回答到线程和Handler方式时,我会再问一下对方:

是否知道IntentService,在什么场景下使用IntentService?

这也是面试官要看的点,真正的项目需要一个开发人员对某个问题有一定的深度,也需要对整个AndroID的知识点有一定的广度。深度代表这个人对问题认真对待有钻研的精神,广度代表这个人在面对同一个问题时,会更容易从多种可行的方案中选出最合适的一种。

Service的实际项目中一直被很多人忽略,为什么我一再强调Service很重要,我们来看看,如果对Service完全无知会在工作中遇到什么问题。

场景:如果一个应用要从网络上下载MP3文件,并在Activity上展示进度条,这个Activity要求是可以转屏的。那么在转屏时Actvitiy会重启,如何保证下载的进度条能正确展示进度呢?

没有Service概念的人,一般想出来的方案如下:

在转屏前将进度缓存,转屏后再读出来。使用androID:configChanges设置,让转屏时Activity不销毁和重建。

针对第1个方案,我会继续问他将进度值存在哪里? 转屏的过程中,我们知道Activity的重建算是比较耗时的,会可能会有几百毫秒以上,那么这时候下载线程仍然在工作,进度肯定和保存时的进度不一致了,如何处理这个问题呢?

第2个方案,大家可以自己展开思考,实际的项目中可能会需要额外做一些事情来处理ContentVIEw的横竖布局的问题。

如果使用Service来解决这个问题,看似是比较完美的,不过就会涉及Activity(UI)和Service的交互问题,这个我们以后再讨论。

《设计思想解读开源框架》

第一章、 热修复设计

第一节、 AOT/JIT & dexopt 与 dex2oat

第二节、 热修复设计之 CLASS_ISPREVERIFIED 问题

第三节、热修复设计之热修复原理

第四节、Tinker 的集成与使用(自动补丁包生成)

第二章、 插件化框架设计

第一节、 Class 文件与 Dex 文件的结构解读

第二节、 AndroID 资源加载机制详解

第三节、 四大组件调用原理

第四节、 so 文件加载机制

第五节、 AndroID 系统服务实现原理

第三章、 组件化框架设计

第一节、阿里巴巴开源路由框——ARouter 原理分析

第二节、APT 编译时期自动生成代码&动态类加载

第三节、 Java SPI 机制

第四节、 AOP&IOC

第五节、 手写组件化架构

第四章、图片加载框架

第一节、图片加载框架选型

第二节、GlIDe 原理分析

第三节、手写图片加载框架实战

第五章、网络访问框架设计

第一节、网络通信必备基础

第二节、Okhttp 源码解读

第三节、Retrofit 源码解析

第六章、 RXJava 响应式编程框架设计

第一节、链式调用

第二节、 扩展的观察者模式

第三节、事件变换设计

第四节、Scheduler 线程控制

第七章、 IOC 架构设计

第一节、 依赖注入与控制反转

第二节、ButterKnife 原理上篇、中篇、下篇

第三节、Dagger 架构设计核心解密

第八章、 AndroID 架构组件 Jetpack

第一节、 liveData 原理

第二节、 Navigation 如何解决 tabLayout 问题

第三节、 viewmodel 如何感知 VIEw 生命周期及内核原理

第四节、 Room 架构方式方法

第五节、 dataBinding 为什么能够支持 MVVM

第六节、 WorkManager 内核揭秘

第七节、 lifecycles 生命周期


本文包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等,资源持续更新中…

如果需要八份神级学习进阶资料,赶紧戳这里免费领取!
包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等,资源持续更新中…**
[外链图片转存中…(img-ZpuAWHhh-1623141303400)]

如果需要八份神级学习进阶资料,赶紧戳这里免费领取!

总结

以上是内存溢出为你收集整理的Android黑科技保活实现原理揭秘,聪明人已经收藏了!全部内容,希望文章能够帮你解决Android黑科技保活实现原理揭秘,聪明人已经收藏了!所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/web/998872.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-21
下一篇 2022-05-21

发表评论

登录后才能评论

评论列表(0条)

保存