代码混淆加密面试补充

1、面试中一些常问的问题的补充 陈俊波邮箱: 数据版本和软件版本的问题软件版本:服务端用于判断客户端是否可以继续使用的版本,这个版本一般都是数字自增的数字,我们在所有的请求接口或者是一个软件启动时候的固定接口中 请求服务端,将这个版本号发给对应的接口,服务端进行判断,如果发现这个版本已经停用,就返回停止的信息,客户端收到返回的停用信息,就给用户弹出提示,当前版本已停用,需要升级到最新版本,这个版本和我们配置文件中的版本不一样,这个版本需要和 ios 以及服务端进行商讨每次迭代后都需要增加版本号,因为 ios 端可能上线比较慢,会出现这样的问题, ios 端客户端没有停用, android 端停用了

2、,怎么判断, 在这个对应的接口中,我们需要将软件平台也一起发过去,数据版本: 指的同一个接口返回数据可能不同的情况,因为新版本中增加了一部分功能,可能会在某个接口中改变返回数据的结构,一旦改变之后,老的软件可能就解析不了新数据了,会崩溃,这个时候 就应该考虑 数据版本在每个接口中都添加一个额外的字段,用于标记当前数据版本是多少,服务端根据数据版本号的不同返回不同的数据这样老版本的用户就不会出现崩溃了,但是这个版本号不一定会增加,什么情况下增加呢,只有同一个接口发生数据变化的时候,新版本增加了新功能 但是用的是新接口,那么就没有必要增加版本号,登陆信息 收藏等保存登陆信息是怎么保存,不能每次打开

3、软件都要求用户登陆,每个用户基本上都应该有一个唯一的标识,每个用户都不一样我们将用户的标识保存起来,每次去获取有没有对应的标识就行用户登陆信息的时效性,可以要求服务端返回一个 sessionid 给你,你打开软件的时候 将 sessionid 发给服务端进行校验,如果服务端发现 session 已经过时了,就返回过时,客户端收到后提示用户 过时了 重新登陆,否则就进入,这个可以放在每次启动的闪屏页面执行收藏啊,购物车 是放在了本地数据库呢还是网络服务器,这个问题没有固定答案,你可以说,这个产品 是在服务端,那个产品是在本地,为什么这么放,产品原型的要求就是这么要求一些不对的问题不对的问题:就是

4、根本没有的问题,比如 listview 和 gridview 的优化中, UI 虚拟化这个问题这个其实是 windows phone 中的 listview 和 gridview 的优化,和 android 没有任何关系,你不要被问呆了觉得我完全不知道这个是什么,没法说了,你可以说 这个是 windows phone 的,和 android 没关系,我大体也看了下其实和我们的复用差不多,因为它上面说 为每个 item 创建 ui 太耗费资源,要复用,这样说完以后,还可以堵住一个问题,叫 你既然看过 你能在 android 中实现以下这个方案吗Android 进程间通讯 android 本身的四

5、大组件其实也可以是进程间通讯的一部分,比如 activity, 可以启动其他程序的 activity, 也可以被其他程序的 activity 启动,并且传递数据过来服务 service: 我们知道可以用个 bind 方式绑定远程服务 用 aidl 或者是 messenger 信使进行数据传递内容提供者:本身就是进程间通讯的一部分广播:这个本身也是进程间通讯的一部分Socket 通讯Messenger 内部是用 aidl 实现, aidl 内部是通过 binder 传递数据, binder 传递的都是可序列化的数据Binder 传递出去的数据和另外一边接受到的数据对象不是同一个对象首先证据一:

6、两个独立的进程 有独立的堆内存空间,不可能出现一个程序中的变量指向另外一个程序的堆内存序列化对象跨进程传递的时候 首先要先序列化对象,写入到一片公共区域内,一般是内存,然后另外一方读取公共区域,重新反序列化对象后复制给自己程序内部的变量,只不过内容一致罢了版本控制 svn或者 git 冲突怎么办出现冲突就解决冲突, 我们比较一下两个内容,看看哪部分内容需要保留,需要保留的就留下,重复或者是不需要的就删除,编辑完毕后 标记为解决,然后再提交就可以Svn 是集中式管理,所有用户操作的都是同一份代码Git 分布式管理,每个用户都可以单独 clone 一份代码,然后自己编辑,提交后也只是提交到自己的分

7、支,当然可以所有的用户都只操作一份分支,这种模式就和 svn 一样了,如果使用第一种方式 每个人操作自己的,最后可以在自己这边申请合并代码, master 分支收到后可以去通过合并你的代码,如果有冲突 解决即可取消网络请求频繁切换页面或者是不小心打开了某个页面,发起了网络请求,如果不需要了 应该及时取消请求, asynctask 调用Cancel 方法, urlconnection 调用 disconnect 方法断开,为什么,因为网络请求会占用资源,返回数据会被解析成对象,对象是占用资源的,而且会接着变成垃圾对象,在页面的销毁或者是某个生命周期内,应该取消网络请求Handler 问题总是刻意

8、强调线程问题, 比如在主线程中创建 handler 在子线程中发送消息因为 handler 可以在任何线程中创建,也可以在任何线程中发送消息只不过在非主线程中创建 handler 的时候需要给它一个 looper, 调用 Lopper.prepar();获取一个 Lopper. 然后在代码最后下面 调用 Lopper.loop() 方法开启无限循环 获取Asynctask 的原理主线程开启-new 线程 执行 doinbackground- 执行完毕后 通过 handler 将结果发出去, handler 是获取主线程的 looper之后创建的,那么这个 handler 就在主线程中, han

9、dlemessage 中执行 finish(),这个方法内部 通过判断是否取消来决定执行什么,没有取消的话 就制定 onPostExecute(),这样这个方法就回到了主线程广播接收者的内部原理: 它其实就是一个观察者模式,应该了解的模式 观察者 单例 ,工厂, 代理, 适配器,Eventbus 的内部其实也是观察者 xutils 内部 封装网络请求, 返回流之后 通过传递的回调,反射获取回调上面的泛型,将返回的流解析成对应的泛型数据对象,然后调用回调的 onsucess 方法,将对象传递进去,比如内部也和 async 一样有子线程,怎么将数据发回主线程呢, 一样也是通过 handler 将数

10、据返回到主线程中之后传递到回调中,最终由用户决定怎么接受怎么处理OOM 和二次采样OOM 我们一般在图片较大的情况下出现, 一般处理措施是对图片进行二次采样,获取元数据,比如分辨率,然后与期望的分辨率,进行除法运算, 宽高都进行运算,得到的结果 以较大值为准,设置为缩放比进行缩放为什么二次采样后能避免 OOM ,二次采样一般最大就是屏幕大小,android 系统屏幕上显示的内容其实是系统通过绘制一张 bitmap 显示出来,既然和屏幕分辨率一样大的 bitmap 可以显示,那么我们自己缩放的也肯定可以显示,这就是为什么可以理论上避免 OOM但是也不一定 “ 一定能避免 OOM”, 为什么呢,因

11、为 bitmap 最终绘制的时候是占用我们自己程序的内存,虽然系统一开始分配的内存足够显示一张与屏幕分辨率大小一致的图片,但是我们程序内部毕竟还有其他的内容在占用内存最终仍然可能会导致剩余的内存不足显示 图片,最终导致 OOM加载一张很大的图片,不允许缩放,因为缩放会导致失真,同时可能会说缩放后仍然很大怎么办切割显示照片, bitmap 在加载的时候只显示一部分,比如我就切割出屏幕大小的那部分显示 从中间切割切割完成后显示对应的部分,然后监听手势的滑动,重新切割显示对应的内容开发中的问题UI 给几套图 一般普通的图片给5套,.9图只要给一套即可你们上一家公司在哪,附近有什么地标性建筑物你住哪,你住什么路,什么小区你抽烟吗?你有男女朋友吗?你男女朋友在什么地方工作,你为什么离职,你离职了,年终奖都没了,来我们公司也没有年终奖, 我上一家公司没有年终奖,所以不在乎离职 没有年终奖你离职的时候 你们的项目到了什么版本了, 或者让你演示项目的时候直接拿起来问你 ,你当初写的是什么版本,如果你是刚离职,会问你, 你现在写的这个是什么版本应该注意看看演示项目或者所有项目上的版本信息,可以搜