安卓开发中常用的一些问题

最新推荐文章于 2022-06-24 11:08:18 发布

fajuary

最新推荐文章于 2022-06-24 11:08:18 发布

阅读量332

点赞数

分类专栏： Android开发

本文链接：https://blog.csdn.net/fajuary/article/details/79729776

版权

Android开发专栏收录该内容

18 篇文章 0 订阅

订阅专栏

1，ListView中图片错位的问题是如何产生的？

2，混合开发有了解吗？

3，知道哪些混合开发的方式？说出它们的优缺点和各自使用场景？（解答：比如RN,weex,H5,小程序，WPA等。做android的了解一些前端js等还是很有好处的）；

4，屏幕适配的处理技巧都有哪些？

5，服务器只提供数据接收接口，在多线程或多进程条件下，如何保证数据的有序到达？

6，动态布局的理解

7，怎么去除重复代码？

答：

代码的去重复技巧

从代码上去除重复的代码就是用通用的重构技巧，比如提炼方法，抽象基类，提炼常量等。但是光是代码还不够，因为Android的页面代码跟布局文件的关联非常大，通常Activity或者Fragment都是为了操作布局页写的，所以要想彻底的减少代码的重复，还必须先减少布局的重复。

用include减少局部布局的重复

标签是减少布局重复的利器，它的作用是把另外一个布局文件全部无修改式的嵌入到标签所在的位置。这与C/C++语言的预处理指令#include是一样的。在WEB框架式开发中，也非常常用HTML模板，其中也有类似的include。目的也是减少代码的重复。

要想把include用的恰到好处，首先要做的就是把整体布局模块化，从整体的布局出发，找出可复用的局部布局或布局组合，把它们放入单独一个布局文件中，然后在其他的地方就可以include了。

用ViewStub减少整体的布局的重复

前面是找出布局中的可复用布局组合，include以减少重复。但有些时候是反过来的，也就是说有几个页面，它们整体的一样的，但是某个局部是不同的，这个时候include就不行了。这个时候就可以使用一样的整体布局+ViewStub来做布局。

ViewStub是一个轻量级别的，不可见的View，当ViewStub被设为visible时，或者显示调用layout()时，才会去把它所指向的布局渲染出来，所以它非常适合处理整体相同，局部不同的情况。关于ViewStub的使用可以参考这篇博客。具体的策略是：

规划整体布局，抽象出共同的布局，把可变的布局识别出来
写整体布局，对于可变的局部布局用ViewStub替代
用一个基Fragment来操作整体布局。
创建基Fragment的子类，每个子类，用真正的布局来替换ViewStub。

多用引用而不是写死

这点是非常重要的，Android的强大之处在于，所有的资源的指定都可以用引用，而非直接写死，直接写死就会出现重复代码，比如颜色，背影，字串，布局，ID，度量(dimen)，风格等等。那么，我们在使用的时候，也尽可能的使用引用，这样非常易于复用，修改和定制，从而也就更方便复用。

分析，分离变与不变

其实代码的去重复的关键都在于要分析出可变与不可变，共性和特性，这是抽象与封装的基础。这个没有直接可操作性的建议，只能靠自己平时多多积累，以及遇到问题时多多思考。

另外，就是对于重复的定义是达到三次及三次以上。如果仅出现二次，并且，无可能出现别一次，这个时候其时，要不要去重复有在商榷，写第二次时，花时间重构，与拷贝或重新实现，其实代码差不多。当发现第三次实现某个东西时，就要考虑好好的重构一下，减少重复。

还有，就是，在项目开始不要考虑的太多，不要过度设计。孤认为，不过过度设计，更不要过早优化，就根据需求和进度和发展状况综合来看。当出现了重复，需要重构时就立马去做，这样就不会出问题。但如果没能及时去做重构，欠了债，那么由于涉及代码，功能和模块都比较多时，再去重构，难度大，风险也大。就好比房屋的维护保养，当出现灰尘时就去打扫，很容易，个把小时就搞定了，但如果一直拖着，一年才打扫一次，可能要十天半个月才能完事。

8，画出android的大体框架图

9，RecycleView和ListView的区别

答：

一、两者的缓存机制上的区别

先来说一样的地方，ListView与RecyclerView缓存机制原理大致一样，滑动的时候，离开屏幕的ItemView被回收到缓存，新的itemView加在优先获取的缓存中的，这是正常的两种类似的缓存机制。

而不同的地方在于，两者的缓存层级不同，ListView只有两层，RecycleView有四级缓存。

1. mActiveViews和mAttachedScrap功能相似，意义在于快速重用屏幕上可见的列表项ItemView，而不需要重新createView和bindView；

2. mScrapView和mCachedViews + mReyclerViewPool功能相似，意义在于缓存离开屏幕的ItemView，目的是让即将进入屏幕的ItemView重用；

3. RecyclerView的优势在于： a.mCacheViews的使用，可以做到屏幕外的列表项ItemView进入屏幕内时也无须bindView快速重用； b.mRecyclerPool可以供多个RecyclerView共同使用，在特定场景下，如viewpaper+多个列表页下有优势.客观来说，RecyclerView在特定场景下对ListView的缓存机制做了补强和完善。

同时，两者的缓存不同，RecycleView缓存在ViewHolder，可以看作是：View + ViewHolder(避免每次createView时调用findViewById) + flag(标识状态)；

而ListView缓存在View上，获取缓存的方法流程是：

listView的mScrapViews是根据pos获取相应的缓存，但不直接用，是重新getView（这样会重新bindView）。所以ListView中通过pos获取的是View。

RecycleView的流程是：

mRecycleView在获取缓存的时候，是通过匹配pos获得目标的位置的缓存，这么做可以不用重新bindView，所以RecycleVIew中通过pos获取的是viewholder，是pos-->（view，holder，flag），flag是判断view是否需要重新bindView。

二、局部刷新的区别

RecycleView中的notifyItemRemoved（position）方法，最终会调用requestLayout()方法，使整个View重新绘制，为：onMeasure()-->onLayout()-->onDraw()

其中的onLayout分三步：

1.dispathLayoutStep1()：记录RecyclerView刷新前列表项ItemView的各种信息，如Top,Left,Bottom,Right，用于动画的相关计算；

2.dispathLayoutStep2()：真正测量布局大小，位置，核心函数为layoutChildren()；

3.dispathLayoutStep3()：计算布局前后各个ItemView的状态，如Remove，Add，Move，Update等，如有必要执行相应的动画.

其中layoutChildren()方法的流程图：

当调用notifyItemRemoved时，会对屏幕内ItemView做预处理，修改ItemView相应的pos以及flag。当调用fill()中RecyclerView.getViewForPosition(pos)时，RecyclerView通过对pos和flag的预处理，使得bindview只调用一次。

需要指出，ListView和RecyclerView最大的区别在于数据源改变时的缓存的处理逻辑，ListView是"一锅端"，将所有的mActiveViews都移入了二级缓存mScrapViews，而RecyclerView则是更加灵活地对每个View修改标志位，区分是否重新bindView。

10，ListView图片加载错乱的原理和解决方案

11，动态权限适配方案，权限组的概念

12，android系统为什么设计ContentProvider?

13，下拉状态栏会不会影响activity的生命周期

答：Android下拉通知栏不会影响Activity的生命周期方法

14，如果在onStop的时候做了网络请求，onResume的时候怎么恢复？

答：onResume是在启动activity启动之后才能执行的，也就是恢复执行。程序正常启动：onCreate()->onStart()->onResume();
正常退出：onPause()->onStop()->onDestory()
一个Activity启动另一个Activity: onPause()->onStop(), 再返回：onRestart()->onStart()->onResume()
程序按back 退出： onPause()->onStop()->onDestory(),再进入：onCreate()->onStart()->onResume();
程序按home 退出： onPause()->onStop(),再进入：onRestart()->onStart()->onResume();

15，Bitmap使用时候注意什么？

答：

一、 问题的背景和意义

在Android移动应用开发中，对Bitmap的不小心处理，很容易引起程序内存空间耗尽而导致的程序崩溃问题。比如我们常遇到的问题：

java.lang.OutofMemoryError: bitmap size exceeds VM budget.

导致该问题的出现，一般由以下几方面原因导致：引动设备一般存储空间非常有限。当然不同设备分配给应用的内存空间是不同的。但相对不但提高的设备分辨率而言，内存的分配仍然是相对紧张的。


Bitmap对象常常占用大量的内存空间，比如：对于2592*1936的设备，如果采用ARGB_8888的格式加载图像，内存占用将达到19MB空间。

在Anroid App中经常用到ListView，ViewPager等控件，这些控件常会包含较大数量的图片资源。
二、 问题及场景分析
1 高效地加载大图片。
BitmapFactory类提供了一些加载图片的方法：decodeByteArray(), decodeFile(), decodeResource(), 等等。
为了避免占用较大内存，经常使用BitmapFactory.Options 类，设置inJustDecodeBounds属性为true。
BitmapFactory.Options options = new BitmapFactory.Options();

options.inJustDecodeBounds =true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
为了避免java.lang.OutOfMemory 的异常，我们在真正decode图片之前检查它的尺寸，除非你确定这个数据源提供了准确无误的图片且不会导致占用过多的内存。
加载一个按比例缩小的版本到内存中。例如，如果把一个原图是1024*768 pixel的图片显示到ImageView为128*96 pixel的缩略图就没有必要把整张图片都加载到内存中。为了告诉解码器去加载一个较小的图片到内存，需要在你的BitmapFactory.Options 中设置 inSampleSize 为true 。例如, 一个分辨率为2048x1536 的图片，如果设置inSampleSize 为4，那么会产出一个大概为512x384的图片。加载这张小的图片仅仅使用大概0.75MB，如果是加载全图那么大概要花费12MB(假设bitmap的配置是ARGB_8888).
2 不要在主线程处理图片。

注意两点：1. 为了保证使用的资源能被回收，建议使用WeakReference, 以应用内存内存紧张时，回收部分资源，保证程序进程不被杀死。

2. 避免异步任务的长时间耗时操作，在任务执行结束后，及时释放资源。
3 管理Bitmap内存。
在Android开发中，加载一个图片到界面很容易，但如果一次加载大量图片就复杂多了。在很多情况下（比如：ListView,GridView或ViewPager），能够滚动的组件需要加载的图片几乎是无限多的。
有些组件的child view在不显示时会回收，并循环使用，如果没有任何对bitmap的持久引用的话，垃圾回收器会释放你加载的bitmap。这没什么问题，但当这些图片再次显示的时候，要想避免重复处理这些图片，从而达到加载流畅的效果，就要使用内存缓存和本地缓存了，这些缓存可以让你快速加载处理过的图片。
3.1 内存缓存
内存缓存以牺牲内存的代价，带来快速的图片访问。LruCache类（API Level 4之前可以使用Support Library）非常适合图片缓存任务，在一个LinkedHashMap中保存着对Bitmap的强引用，当缓存数量超过容器容量时，删除最近最少使用的成员（LRU）。
注意：在过去，非常流行用SoftReference或WeakReference来实现图片的内存缓存，但现在不再推荐使用这个方法了。因为从Android 2.3 （API Level 9）之后，垃圾回收器会更积极的回收soft/weak的引用，这将导致使用soft/weak引用的缓存几乎没有缓存效果。顺带一提，在Android3.0（API Level 11）以前，bitmap是储存在native 内存中的，所以系统以不可预见的方式来释放bitmap，这可能会导致短时间超过内存限制从而造成崩溃。