记一次360面试总结（Android）

转载

mb5fe94870638be 2021-06-21 15:11:14

文章标签 JAVA 文章分类 Java 后端开发

正文

从大二暑假的时候开始，一直想进腾讯或者阿里，在招实习生的时候，最终遗憾落选。暑假的时候为了好好准备校招，我放弃了去步步高实习的机会，继续在原来的一家公司实习。在暑假的时候找师兄师姐内推了腾讯，阿里，最终都没有通过简历筛选，没有面试。说实话，刚开始内心是挺失落的，挺难受的，但经过一两天的调整，我也意识到自己的错误，以前那种强烈想进bat的欲望渐渐淡了下来，当然并不是说不想进bat，只是不再那么注重结果，更注重这奋斗过程中个人的成长。

360一面

差不多三十五分钟

介绍你做过的项目
手写单例模式
布局优化
有没有用过什么开源框架？
ImagLoader的实现原理
OnTouchEvent事件中 down事件和up事件的传递
hashMap的实现原理
LinkedHashMap的实现原理
内存管理及优化
点九图

点九图

https://isux.tencent.com/android-ui-9-png.html

记一次360面试总结（Android）_JAVA

放大后可以比较明显的看到上下左右分别有一个像素的黑色线段，这里分别标注了序号。简单来说，

序号1和2标识了可以拉伸的区域，

序号3和4标识了内容区域。当设定了按钮实际应用的宽和高之后，横向会拉伸1区域的像素，纵向会拉伸2区域的像素。如下图：

记一次360面试总结（Android）_JAVA_02

这里程序设置的文字垂直居中，水平居左的对齐方式。对齐方式是没有问题的，但是对于这种大圆角同时又有些不规则边框的的图形来说，错误的标注方式会让排版看起来很混乱。所以我们需要修正内容区域的线段位置和长度。

记一次360面试总结（Android）_JAVA_03

有两点需要特别注意下：

1.最外围的一圈像素必须要么是纯黑色，要么是透明，一点点的半透明的像素都不可以有，比如说99%的黑色或者是1%的投影都不可以有;

2.文件的后缀名必须是.9.png，不能是.png或者是.9.png.png，这样的命名都会导致编译失败。

内存管理及优化

我这里答的是内存泄漏和oom
少用static静态变量

1) 珍惜Services资源

我们知道service所在的Activity级别相对后台Activity的级别是比较高的，一般不易被回收。
在service不再使用的时候，及时退出。最好的方法是使用IntentService

2）在UI不可见的时候释放资源

当用户切换到其它应用并且你的应用 UI不再可见时，你应该释放你的应用UI上所占用的所有内存资源。在这个时候释放UI资源可以显著的增加系统缓存进程的能力，它会对用户体验有着很直接的影响。

为了能够接收到用户离开你的UI时的通知，你需要实现Activtiy类里面的onTrimMemory()回调方法。你应该使用这个方法来监听到TRIM_MEMORY_UI_HIDDEN级别的回调，此时意味着你的UI已经隐藏，你应该释放那些仅仅被你的UI使用的资源。

请注意：你的应用仅仅会在所有UI组件的被隐藏的时候接收到onTrimMemory()的回调并带有参数TRIM_MEMORY_UI_HIDDEN。这与onStop()的回调是不同的，onStop会在activity的实例隐藏时会执行，例如当用户从你的app的某个activity跳转到另外一个activity时前面activity的onStop()会被执行。因此你应该实现onStop回调，并且在此回调里面释放activity的资源，例如释放网络连接，注销监听广播接收者。除非接收到onTrimMemory(TRIM_MEMORY_UI_HIDDEN))的回调，否者你不应该释放你的UI资源。这确保了用户从其他activity切回来时，你的UI资源仍然可用，并且可以迅速恢复activity。

3) 当内存紧张时释放部分内存

关于onTrimMemory的介绍

在你的app生命周期的任何阶段，onTrimMemory的回调方法同样可以告诉你整个设备的内存资源已经开始紧张。你应该根据onTrimMemory回调中的内存级别来进一步决定释放哪些资源。

TRIM_MEMORY_RUNNING_MODERATE：你的app正在运行并且不会被列为可杀死的。但是设备此时正运行于低内存状态下，系统开始触发杀死LRU Cache中的Process的机制。
TRIM_MEMORY_RUNNING_LOW：你的app正在运行且没有被列为可杀死的。但是设备正运行于更低内存的状态下，你应该释放不用的资源用来提升系统性能（但是这也会直接影响到你的app的性能）。
TRIM_MEMORY_RUNNING_CRITICAL：你的app仍在运行，但是系统已经把LRU Cache中的大多数进程都已经杀死，因此你应该立即释放所有非必须的资源。如果系统不能回收到足够的RAM数量，系统将会清除所有的LRU缓存中的进程，并且开始杀死那些之前被认为不应该杀死的进程，例如那个包含了一个运行态Service的进程。
同样，当你的app进程正在被cached时，你可能会接受到从onTrimMemory()中返回的下面的值之一:

TRIM_MEMORY_BACKGROUND: 系统正运行于低内存状态并且你的进程正处于LRU缓存名单中最不容易杀掉的位置。尽管你的app进程并不是处于被杀掉的高危险状态，系统可能已经开始杀掉LRU缓存中的其他进程了。你应该释放那些容易恢复的资源，以便于你的进程可以保留下来，这样当用户回退到你的app的时候才能够迅速恢复。
TRIM_MEMORY_MODERATE: 系统正运行于低内存状态并且你的进程已经已经接近LRU名单的中部位置。如果系统开始变得更加内存紧张，你的进程是有可能被杀死的。
TRIM_MEMORY_COMPLETE: 系统正运行与低内存的状态并且你的进程正处于LRU名单中最容易被杀掉的位置。你应该释放任何不影响你的app恢复状态的资源。
因为onTrimMemory()的回调是在API 14才被加进来的，对于老的版本，你可以使用onLowMemory)回调来进行兼容。onLowMemory相当与TRIM_MEMORY_COMPLETE。

Note: 当系统开始清除LRU缓存中的进程时，尽管它首先按照LRU的顺序来操作，但是它同样会考虑进程的内存使用量。因此消耗越少的进程则越容易被留下来。

4) 避免bitmaps的浪费

当你加载一个bitmap时，仅仅需要保留适配当前屏幕设备分辨率的数据即可，如果原图高于你的设备分辨率，需要做缩小的动作。请记住，增加bitmap的尺寸会对内存呈现出2次方的增加，因为X与Y都在增加。

Note:在Android 2.3.x (API level 10)及其以下, bitmap对象的pixel data是存放在native内存中的，它不便于调试。然而，从Android 3.0(API level 11)开始，bitmap pixel data是分配在你的app的Dalvik heap中, 这提升了GC的工作效率并且更加容易Debug。因此如果你的app使用bitmap并在旧的机器上引发了一些内存问题，切换到3.0以上的机器上进行Debug。

5) 使用优化的数据容器

利用Android Framework里面优化过的容器类，例如SparseArray, SparseBooleanArray, 与 LongSparseArray。通常的HashMap的实现方式更加消耗内存，因为它需要一个额外的实例对象来记录Mapping操作。另外，SparseArray更加高效在于他们避免了对key与value的autobox自动装箱，并且避免了装箱后的解箱。

6) 请注意内存开销

对你所使用的语言与库的成本与开销有所了解，从开始到结束，在设计你的app时谨记这些信息。通常，表面上看起来无关痛痒(innocuous)的事情也许实际上会导致大量的开销。例如：

Enums的内存消耗通常是static constants的2倍。你应该尽量避免在Android上使用enums。
在Java中的每一个类(包括匿名内部类)都会使用大概500 bytes。
每一个类的实例花销是12-16 bytes。
往HashMap添加一个entry需要额一个额外占用的32 bytes的entry对象。
7) 请注意代码“抽象”

通常，开发者使用抽象作为”好的编程实践”，因为抽象能够提升代码的灵活性与可维护性。然而，抽象会导致一个显著的开销：通常他们需要同等量的代码用于可执行。那些代码会被map到内存中。因此如果你的抽象没有显著的提升效率，应该尽量避免他们。

8) 使用ProGuard来剔除不需要的代码

ProGuard能够通过移除不需要的代码，重命名类，域与方法等方对代码进行压缩，优化与混淆。使用ProGuard可以使得你的代码更加紧凑，这样能够使用更少mapped代码所需要的RAM。

9) 对最终的APK使用zipalign

在编写完所有代码，并通过编译系统生成APK之后，你需要使用zipalign对APK进行重新校准。如果你不做这个步骤，会导致你的APK需要更多的RAM，因为一些类似图片资源的东西不能被mapped。

Notes: Google Play不接受没有经过zipalign的APK。