这些年我踩过的坑——Android

• PD假设常常要求改入口，使用Adapter + ViewHolder来实现解耦：
  
  • 这两个配合模拟FragmentManager + Fragment的逻辑
  • Adapter只负责管理View、对ViewHolder中的生命周期函数进行回调
  • ViewHolder不仅保存View的引用。还完整包含与该View有关的全部逻辑，对外暴露同样的生命周期回调函数，比如onViewCreated、onBindView等
  • 调整入口只须要在Activity中调整Adapter的Data
  • 切记要将ViewHolder与View绑定，假设不绑定就不要复用之前的View，否则空指针
• Json是弱类型。子类Json串填充父类对象将会出现Member丢失的情况
• getSystemService获得Inflater的时候，一定要用Activity的Context。不能用Application Context
• ListView跳转到item的某个位置。须要用setSelectoinFromTop，不能setSelection再scroll。ListView直接scroll会导致跳动和空白item
• ListView中传递的全部关于Position的数据都是包含Header、Footer的，算数要小心
• 在Inflate时，一定要传入parent參数。否则一些依赖父节点的layout參数是不能解析的。详见：这里
• merge节点在inflate时，必须attachToRoot传true。否则crash
• LaunchMode以及ApplicationContext+ActivityContext引发的Task栈混乱问题
• Android/Linux系统是不保存文件创建时间的，假设想拿到文件创建时间，须要用比較tricky的办法。

  文件名称由两部分组成：原始文件名称+分隔符+创建时间（1970毫秒）.扩展名。

  原始文件名称开头比較easy写Filter

• 反射在Android上真的非常慢。ormlite比直接使用sql要慢一倍！

• Activity.runOnUiThread()使用的Handler尽管是Activity的成员变量。其相应的Looper却是Looper.myLooper()。全部runOnUiThread的Runnable即使Activity已经被finish仍然会被运行
• SqliteDatabase.beginTransaction一定要setTransactionSuccessful。否则全部的操作都会取消！！

  ！

• 基本全部使用回调的地方都能够通过KVO来实现，并且直接使用LocalBroadcast能够避免非常多内存泄露啊、监听器管理之类的麻烦。
• 应对软键盘遮挡的问题，能够处理四个不同的事件，事件和调用顺序例如以下：
  
  1. onSizeChanged（Activity须要是AdjustResize的）
  2. onLayout（不用监听onMeasure，回调的位置太多了）
  3. addOnLayoutChangeListener监听layout的回调事件
  4. getViewTreeObserver().addOnGlobalLayoutListener监听全局的layout事件
• 据说在App被卸载/停止的时候。jni里fork出来的子线程是不会被停止的。这样就能够干非常多流氓的事情了，比方保活之类的
• 有一个非常赞的hook，LayoutInflater.Factory提供在原生View的xml里添加新的attribute。

  样例

• 关于软键盘的问题：

  • 调起来讲，((InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE)).
showSoftInput(view, 0);tag为0是默认。SHOW_FORCED在某些rom上会要求用户主动点back才干收起键盘。使用不论什么一种代码上的hide都不生效，压后台也不生效。理论上是tag越大。show的动作越强

  • 收起来讲，((InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE)).
hideSoftInputFromWindow(editText.getWindowToken(), 0);tag为0是默认的，最强的是HIDE_NOT_ALWAYS，却仍然不能hide用SHOW_FORCED调起的键盘

• Activity上的Theme之类的都是给Window的DecorView设置的。生效的面积大于Activity的面积（在键盘动画的情况下）

• 设计的时候，各种码、状态类型要统一，尽量使用int，打印也别非转换一下。

  码类型转换、字符串拼接这样的非常耗内存也会添加apk大小

• 使用ValueAnimator做颜色动画时，一定要用ValueAnimator.ofObject(new ArgbEvaluator(), colors)，不能用ValueAnimator.ofInt(colors);。后者会闪，各种闪

• Fragment由于在切换过程中会有各种post，会有不可解的crash。能够自己实现简单的fragment
• View的Animation和setXXX是不一样的，Animation都是作用在Transform上的。所以全部的结果不能通过setXXX恢复
• View在add到Window之前post的runnable可能会在add之后不被运行（由于相应的消息队列变了）
• 获取当前进程名，反射调用android.ddm.DdmHandleAppName.getAppName()。或者使用pid反查
• 进程的启动原因会在MainLooper中Message的obj中存储，对象不同区分原因
• SP每次get的时候都会读文件，假设SP数据不大的话，还是在内存中保存一份效率高
• 一个设计合理的埋点应该包含这几方面。当中的大部分信息都是固定的。能够參考Android中xml压缩的方法，在多个埋点中重用同样内容：
  
  • 固定上下文：用户信息、设备信息、时间、App信息
  • 交互上下文：Session、网络
  • 当前用户操作的信息：类型。所在的模块、页面、View，referer（http_referer），url
  • 其它：数据分析串连埋点用的埋点session、埋点起止标识位
• 能够通过WindowFocus推断Activity是否在前台（isResumed）。包含了是否有弹框、是否被其它view遮挡了。toast这样的不能获取焦点的window不会影响。非常敞亮的方法
• 据说.9做selector的时候，padding会失效。源代码上看，padding的计算会受背景的大小影响