huazidev

LruCache 是最近最少使用算法的一种实现，主要用于内存缓存。 LruCache 内部使用 LinkedHashMap 来实现最近最少使用的核心逻辑。通过构造函数初始化最大的cache 大小，其单位要和 sizeOf 大小一致。还会初始化一个有序的 LinkedHashMap，这个 LinkedHashMap 是个有序的双向链表，根据进入顺序进行排序，新进入或最新使用的放在链表尾部，这样表头就是最少使用的。当超过给定的大小时就会移除表头的数据，知道大小小于给定大小为止。 **注意**：LruCache 是强引用，LruCache 本身并没有释放内存存，它只是把 LinkedHashMap 中的数据移除，如果数据还在其他地方引用，还是无法释放内存，可以手动释放；

Context 也叫上下文，是有关应用程序环境的全局信息的接口。这是一个抽象类, 它允许访问特定于应用程序的资源和类，以及对应用程序级操作的调用，比如启动活动，发送广播和接收意图等； Activity, Service, Application 都是 Context 的子类。 Context 的具体实现类是 ContextImpl, 还有一个包装类 ContextWrapper, ContextWrapper 的子类有 Service，Application，ContextThemeWrapper, Activity 又是 ContextThemeWrapper 的子类，ContextThemeWrapper 也可以叫 UI Context，跟UI 操作相关的最好使用此类 Context。 ContextWrapper 中有个 mBase，这个 mBase...

楼上都说的很清楚了，这里补充一个问题， SharedPreferences优化建议： 来源：[http://gityuan.com/2017/06/18/SharedPreferences/#%E4%BA%94-%E6%80%BB%E7%BB%93](http://gityuan.com/2017/06/18/SharedPreferences/#%E4%BA%94-%E6%80%BB%E7%BB%93) 1. 强烈建议不要在sp里面存储特别大的key/value, 有助于减少卡顿/anr 2. 请不要高频地使用apply, 尽可能地批量提交;commit直接在主线程操作, 更要注意了 3. 不要使用MODE_MULTI_PROCESS; 4. 高频写操作的key与高频读操作的key可以适当地拆分文件, 由于减少同步锁竞争; 5. 不要一上来就执行getSharedPreferences().edit(), 应该分成两大步骤来做, 中间可以执行其他代码. 6. 不要连续多次edit(), 应该获取一次获取edit(),然后多次执行putxxx(), 减少内存波动; 经常看到大家喜欢封装方法, 结果就导致这种情况的出现. 7. 每次commit时会把全部的数据更新的文件, 所以整个文件是不应该过大的, 影响整体性能;

推荐看下官方 ANR 文档： https://developer.android.com/topic/performance/vitals/anr?hl=zh-cn ## ANR 出现的场景 1. 应用在主线程上非常缓慢地执行涉及 I/O 的操作。 2. 应用在主线程上进行长时间的计算。 3. 主线程在对另一个进程进行同步 binder 调用，而后者需要很长时间才能返回。 4. 主线程处于阻塞状态，为发生在另一个线程上的长操作等待同步的块。 5. 主线程在进程中或通过 binder 调用与另一个线程之间发生死锁。主线程不只是在等待长操作执行完毕，而且处于死锁状态。 6. 执行速度缓慢的广播接收器。 ## 解决方式： ### 首先，通过各种方式定位问题 -...

App 启动流程（基于Android8.0）： - 点击桌面 App 图标，Launcher 进程采用 Binder IPC（具体为ActivityManager.getService 获取 AMS 实例） 向 system_server 的 AMS 发起 startActivity 请求 - system_server 进程收到请求后，向 Zygote 进程发送创建进程的请求； - Zygote 进程 fork 出新的子进程，即 App...

HandlerThread 继承自 Thread , 它是一种可以使用 handler 的 Thread, 就是 在run 方法中通过 Looper.prepare 来创建消息队列，并通过 Looper.loop() 来开启消息循环。 普通 Thread 主要用于在 run 方法中执行一个耗时任务，而 HandlerThread 内部创建了消息队列，外界需要通过 Handler 的消息方式来通知 HandlerThread 执行具体任务。HandlerThread 的具体使用场景是 IntentService。IntentService 封装了 HandlerThread...

#### 先说结论： 有大小限制 #### 再说原因： Intent 是消息传递对象，用于各组件间通信。各组件以及个程序间通信都用到了进程间通信。因此 Intent 的数据传递是基于 Binder 的，Intent 中的数据会存储在 Bundle 中，然后 IPC 过程中会将各个数据以 Parcel 的形式存储在 Binder 的事物缓冲区（Binder transaction buffer）进程传递，而 Binder 的事物缓冲区有个固定的大小，大小在 1M 附近。因为这 1M 大小是当前进程共享的，Intent 中也会带有其他相关的必要信息，所以实际使用中比这个数字要小很多。 ####...

先说下问题的考点： 首先，在 view 测量过后就可以获得 view 的测量宽高，另外系统可能需要多次 measure 才能确定最终的测量宽高。 其次，由于 view 的测量过程和 Activity 的生命周期不是同步，所以无法保证在 onCreate，onStart， onResume 时已经测量完毕，如果没有测量完毕获取的宽高都是0。 能获取真实 view 宽高的方法： - Activity/View 的 onWindowFocusChanged 方法: 方法含义是 View 已经初始完毕，宽高已经准备好了, 得到焦点和失去焦点会被多次调用 - view.post：将...