11.binder机制
Binder是Android系统中进程间通讯（IPC）的一种方式，也是Android系统中最重要的特性之一。Android中的四大组件Activity，Service，Broadcast，ContentProvider，不同的App等都运行在不同的进程中，它是这些进程间通讯的桥梁。正如其名“粘合剂”一样，它把系统中各个组件粘合到了一起，是各个组件的桥梁。
12.launcher的实现
Manifest 配置launcher，PackageManager、ActivityManager对应包的管理和应用进程的管理。
13.Android 版本特性
6.0需要代码请求权限checkPermissions，7.0应用间文件共享限制，系统广播删除，8.0通知渠道、悬浮窗、透明窗口不允许屏幕旋转，9.0明文流量的网络请求（Https加密）
Android SDK兼容：minSdkVersion必须，targetSdkVersion针对某版本，maxSdkVersion非必需。
详细特性可见转载文档：Android 各版本新特性介绍 - 落叶Ex的博客 - CSDN博客
14.BroadcastReceiver广播
特别注意：动态广播最好在Activity 的 onResume()注册、onPause()注销。
原因：对于动态广播，有注册就必然得有注销，否则会导致内存泄露，重复注册、重复注销也不允许
广播的类型主要分为5类：
普通广播（Normal Broadcast）：开发者自身定义 intent的广播（最常用），sendBroadcast(intent);
系统广播（System Broadcast）：涉及到手机的基本操作（如开机、网络状态变化、拍照等等），都会发出相应的广播，每个广播都有特定的Intent - Filter（包括具体的action）
有序广播（Ordered Broadcast）：发送出去的广播被广播接收者按照先后顺序接收，按照Priority属性值从大-小排序；Priority属性相同者，动态注册的广播优先；
sendOrderedBroadcast(intent);
特点
接收广播按顺序接收
先接收的广播接收者可以对广播进行截断，即后接收的广播接收者不再接收到此广播；
先接收的广播接收者可以对广播进行修改，那么后接收的广播接收者将接收到被修改后的广播
App应用内广播（Local Broadcast）：Android高效安全的本地广播LocalBroadcast完全解析 -
粘性广播（Sticky Broadcast）：由于在Android5.0 & API 21中已经失效，所以不建议使用
15.RecycleView
方法：onCreateViewHolder() 、onBinderViewHolder()、getItemCount()
三种布局：垂直or水平、网格、瀑布流
需要自定义分割线、易于回收、View复用、便于实现添加和删除item动画。
16.各种集合比较
SparseArray稀疏数组与HashMap相比，正序插入快，逆序插入慢，查找慢占用内存少于HashMap；
HashMap和ArrayMap的区别
①查找效率 HashMap依据HashCode查找，效率增加；ArrayMap使用二分法查找，效率下降。数量大时用HashMap
②扩展数量 HashMap初始值16个长度，每次扩容申请双倍的数组空间；A扩容申请空间更少
③扩容效率 ArrayMap更好
④内存消耗 数据量小时，ArrayMap更节省内存
总结：数据量小时，并需要频繁使用map存储时，用ArrayMap，数据量大时，用HashMap。
HashMap由数组+链表组成的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的，如果定位到的数组位置不含链表（当前entry的next指向null）,那么对于查找，添加等操作很快，仅需一次寻址即可；如果定位到的数组包含链表，对于添加操作，其时间复杂度为O(n)，首先遍历链表，存在即覆盖，否则新增；对于查找操作来讲，仍需遍历链表，然后通过key对象的equals方法逐一比对查找。所以，性能考虑，HashMap中的链表出现越少，性能才会越好。
HashMap 的实例有两个参数影响其性能：初始容量和加载因子。容量是哈希表中桶的数量，初始容量只是哈希表在创建时的容量。加载因子 是哈希表在其容量自动增加之前可以达到多满的一种尺度。当哈希表中的条目数超出了加载因子与当前容量的乘积时，则要对该哈希表进行 rehash 操作（即重建内部数据结构），从而哈希表将具有大约两倍的桶数。在Java编程语言中，加载因子默认值为0.75，默认哈希表元为101
hashMap的默认加载因子为0.75，加载因子表示Hsah表中元素的填满的程度。加载因子越大,填满的元素越多,空间利用率越高，但冲突的机会加大了。反之,加载因子越小,填满的元素越少,冲突的机会减小,但空间浪费多了。冲突的机会越大,则查找的成本越高。反之,查找的成本越小。当桶中元素到达8个的时候，概率已经变得非常小，也就是说用0.75作为加载因子，每个碰撞位置的链表长度超过８个是几乎不可能的。
参考文章：为什么java Hashmap 中的加载因子是默认为0.75 -
LinkedList 链表结构，查找慢，插入快；
ArrayList 数组结构，查找快，插入慢。
17.SQLite升级而不影响现有数据，DBHelper单例，在OnUpgrade()方法中判断oldVersion对数据库进行增删改查以实现数据库升级。
18.Bitmap
参考文章：Android Bitmap详解 - 小爷宋 - 博客园
位图包括图片的像素、长宽、颜色等描述，可通过这些信息计算出图像占用内存的大小。作为花架，可对图片做一些处理，位图文件显示效果好，但是非压缩格式，需要占用较大存储空间。
①Config：表示图片像素类型
②三种压缩格式：Bitmap.CompressFormat.JPEG、Bitmap.CompressFormat.PNG、Bitmap.CompressFormat.WEBP
③BitmapFactory提供了四类加载方法：decodeFile、decodeResource、decodeStream、decodeByteArray。巨图加载：BitmapRegionDecoder，可以按照区域进行加载。高效加载：核心其实也很简单，主要是采样压缩、缓存策略、异步加载等
④内存优化：缓存LRU、缩放、Config、Compress选择、内存管理、缓存方式等等方面入手。、内存管理、内存优化、缩放、config、compress
开源框架：ImageLoader、Glide（google）、Fresco（FaceBook）、Picasso（Square）
图片优化：异步加载，压缩处理bitmapFactory.options，设置内存大小，缓存于内存、SD卡，没有内存再从网络取。
Picasso包体积小、清晰，但功能有局限不能加载gif、只能缓存全尺寸；
Glide功能全面，擅长大型图片流，体积较大；
Fresco内存优化，减少oom，体积更大。
如何处理大图：BitmapFactory.Options，把inJustDecodeBounds这个属性设为true，计算inSampleSize。参考文章：官方推荐方法，如何有效率的加载大图Bitmap - 月毛毛的专栏 - CSDN博客
19.Handler机制
主线程不能进行耗时操作，子线程不能更新UI，Handler实现线程间通信，将要发送的消息保存到Message中，Handler调用sendMessage()方法将message发送到MessageQueue，Looper对象不断调用loop()方法，不断从MessageQueue中取出message交给handler处理，从而实现线程间的通信。
主线程handler不需要调用Looper.prepare()，Looper.loop()，通过sendMessage将message添加到messagequeue。
子线程可以new Handler。
总结：当创建Handler时将通过ThreadLocal在当前线程绑定一个Looper对象，而Looper持有MessageQueue对象。执行Handler.sendMessage(Message)方法将一个待处理的Message插入到MessageQueue中，这时候通过Looper.loop()方法获取到队列中Message，然后再交由Handler.handleMessage(Message)来处理。
20.性能优化技巧
启动速度优化，布局优化，内存、电量、APP大小优化、列表滑动优化等等。
性能优化工具：TraceView、Hierarchy Viewer。
上一篇：Android基础知识总结（一）
下一篇：Android基础知识总结（三）
每天进步一点点。。。（2019-05-08 ）