这些年我踩过的坑——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毫秒).扩展名。html

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

  • 反射在Android上真的很是慢。ormlite比直接使用sql要慢一倍!

  • Activity.runOnUiThread()使用的Handler尽管是Activity的成员变量。其相应的Looper倒是Looper.myLooper()。所有runOnUiThread的Runnable即便Activity已经被finish仍然会被运行
  • SqliteDatabase.beginTransaction必定要setTransactionSuccessful。不然所有的操做都会取消!!

    android

  • 基本所有使用回调的地方都可以经过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。

    样例git

  • 关于软键盘的问题:github

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

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

  • Activity上的Theme之类的都是给Window的DecorView设置的。生效的面积大于Activity的面积(在键盘动画的状况下)网络

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

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

  • 使用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的计算会受背景的大小影响
相关文章
相关标签/搜索