解决Android自定义键盘与系统键盘交替出现会出现弹跳闪烁问题

在Android应用的某个界面上,配置出现使用自定义键盘,系统键盘的相邻的两个独立的输入框,当用户在两个输入框之间来回切换的时候,会出现弹跳闪烁问题。

这个问题发生的原因是,系统键盘的关闭是异步的,我们需要等待系统键盘关闭后再显示我们的键盘,否则会出现系统键盘关闭的过程中,我们自定义键盘同时出现,出现两者叠加的瞬间状态。

解决方法参考下面的代码:

注意,在继承实现自定义的密码键盘弹窗的时候,可以参考Android源代码中的PopWindow的处理逻辑。如果是使用WindowManager.addView 的方式添加到窗口,那么在关闭View的时候需要使用 WindowManager.removeViewImmediate来移除,否则一样会出现与输入法弹窗冲突。 代码同样参考PopWindow。

另外,如果自定义输入法的View增加了 FLAG_NOT_TOUCH_MODAL 属性,那么会导致事件穿透到输入法窗口下面的Window,如果点击区域恰好有个 EditText,则可能诱发系统输入法的弹出。如果自定义键盘通过监听 ACTION_OUTSIDE来关闭窗口,那么会出现系统键盘先弹出,输入法的View再关闭的奇怪流程。因此这种情况下,我们需要参考PopWindow来监听ACTION_DOWN事件。

如下图:

监测系统键盘是否已经关闭,参考代码如下:

上面的代码依赖

参考链接


Android扩大View点击范围

Android4.0设计规定的有效可触摸的UI元素标准是48dp,转化为一个物理尺寸约为9毫米。7~10毫米,这是一个用户手指能准确并且舒适触摸的区域。

如下图所示,你的UI元素可能小于48dp,图标仅有32dp,按钮仅有40dp,但是他们的实际可操作焦点区域最好都应达到48dp的大小。

1 触屏手机点击区域的小秘密

为使小的UI区域获得良好的触摸交互,根据View的特性,目前碰到了两种情况:

1.如ImageView,设置其padding值,可触摸区域将向外扩展;

2.如Button,设置其padding值,可触摸区域不变,其内内容显示区域向内压缩;

情况1的控件,可直接设置其padding值达到目的,如 android:padding="10dp"  

情况2的控件,可使用TouchDelegate动态修改其触摸区域,达到扩大点击范围的效果

采取此种方法的两点注意:

1、若View的自定义触摸范围超出Parent的大小,则超出的那部分无效。
2、一个Parent只能设置一个View的TouchDelegate,设置多个时只有最后设置的生效。

若需要恢复该View的触摸范围:

使用TouchDelegate扩大View的触摸响应范围是一种比较灵活的方法,有时可与设置padding的方式结合使用。

更新

======

后期实际开发中发现,使用post runnable的方式去设置Delegate区域大小的原因是,如该View师在Activity的OnCreate()或Fragment的OnCreateView()中绘制,此时UI界面尚未开始绘制,无法获得正确的坐标;

若将此法应用在ListView的getView()中绘制每个ItemView时,则Delegate的设置将部分失效,原因是ListView的绘制较特殊,可能无法获取到部分还未绘制出的View的正确坐标。解决方案具体可参考以下参考阅读所列。

 

参考阅读:通过自定义View的方式,及某些其他情况的处理:

1.《Android使用TouchDelegate增加View的触摸范围》 http://blog.csdn.net/sgwhp/article/details/10963383

2.《ListView Tips & Tricks #5: Enlarged Touchable Areas》 http://cyrilmottier.com/2012/02/16/listview-tips-tricks-5-enlarged-touchable-areas/

3.《Extend touchable areas #Android》 https://plus.google.com/u/0/+JulienDodokal/posts/8zoV3RQvReS

参考链接


aapt/aapt2命令获取apk详细信息(包名、版本号、版本名称、兼容api级别、启动Activity等)

aapt命令获取apk详细信息(包名、版本号、版本名称、兼容api级别、启动Activity等)

第一步:找到aapt/AAPT2

找到sdk的根目录,然后找到build-tools文件夹,然后会看到一些build-tools的版本号,随便点开一个,就可以看到aapt了,如下图

继续阅读aapt/aapt2命令获取apk详细信息(包名、版本号、版本名称、兼容api级别、启动Activity等)

RN 技术探索:Hermes Engine 初探

自从 Google 的 Flutter 发布之后,Facebook 对 React-Native 的迭代开始快了起来,优化 React-Native 的性能表现,避免被 Flutter 比下去。最近一个比较大的动作是开源了一个 JavaScript 引擎,并将其包含到 React-Native 中。那么这款引擎它有什么不同,相比 V8、JSC 这些 JavaScript 引擎又有什么优势呢,现在本文来为你揭晓。

1.  Hermes 引擎是什么,优势有哪些?

重要的事情提前说:Hermes 引擎是 Facebook 研发,在 React-Native Android 端用于替换 JavaScript Core 的 JavaScript 引擎。Hermes 引擎的优势是适合移动端的轻量级 JavaScript 引擎,使用 aot 编译,可以减少 Android 端内存使用,减小安装包大小,提升执行效率。

2.  什么是 JavaScript 引擎?

JavaScript 引擎是一个专门处理 JavaScript 脚本的虚拟机,一般会附带在网页浏览器之中。

3.  主流 JavaScript 引擎

V8(Google)、JavaScriptCore(Apple)、SpiderMonkey(Firefox)

4.  RN 中的 JavaScript 引擎

Weex,Android:V8,iOS:JavaScriptCore

RN,Android:JavaScriptCore(Hermes、V8),iOS:JavaScriptCore(Apple 要求)

注:Hermes Engine在React-native 0.60.2 版本后支持

5.  Hermes 的特色

  • 预编译字节码(引擎加载二进制代码效率高于运行JS脚本)

  • 无 JIT 编译器(减小了引擎大小,优化内存占用,但直接运行 JS 脚本的性能差于 V8 和 JSC)

  • 针对移动端的垃圾回收策略

继续阅读RN 技术探索:Hermes Engine 初探

年终盘点跨平台技术优劣势对比(Hybrid、RN、Weex、Flutter)

跨平台技术发展的三个阶段

  • 第一阶段是混合开发的web容器时代

    • 为了解决原生开发的高成本、低效率,出现了Hybrid混合开发
    • 原生中嵌入依托于浏览器的WebView
    • Web浏览器中可以实现的需求在WebView中基本都可以实现
    • 但是Web最大的问题是,它的性能和体验与原生开发存在肉眼可感知的差异
    • 因此并不适用于对性能和用户体验要求较高的场景
  • 第二阶段是以RN和Weex为代表的泛web容器时代

    • RN对Web标准进行了功能裁剪
    • 用户体验更接近于原生了
    • 由于进行了功能裁剪,所以RN对业务的支持能力还不到浏览器的5%
    • 因此仅适用于中低复杂度的低交互类页面。面对稍微复杂一点儿的交互和动画需求,都需要通过调用原生代码去扩展才能实现
  • 第三阶段是以Flutter为代表的自绘引擎时代

    • Flutter是构建Google物联网操作系统Fuchsia的SDK
    • 它使用Dart语言开发APP
    • 一套代码可以同时运行在iOS和Android平台上
    • Flutter采用自带的Native渲染引擎渲染视图,它是自己完成了组件渲染的闭环
    • 而RN、Weex之类的框架,只是通过JavaScript虚拟机扩展调用系统组件,最后是由Android或者iOS系统来完成组件的渲染

继续阅读年终盘点跨平台技术优劣势对比(Hybrid、RN、Weex、Flutter)

Android自动化测试--Espresso使用

相比上一篇文章所讲的Instrumented Unit Tests,本文所讲的自动化测试Espresso最显著的特点就是,可以与UI相交互。

使用

首先我们在Android Studio中新建一个项目,取名为EspressoTests。同时删除自动生成的一些文件,最终目录结构如下:

继续阅读Android自动化测试--Espresso使用

Espresso单元测试等待界面上某个元素显示出来/某个操作完成

在使用 Espresso 进行单元测试的时候,我们需要等待被测试界面上某个元素显示出来,这个时候需要进行等待,等待的时间需要我们自行控制。

继续阅读Espresso单元测试等待界面上某个元素显示出来/某个操作完成

WindowManager中removeView(View v)与removeViewImmediate(View v)的区别

问题及原因:

   我们在做UI相关的代码时有时候会碰到WindowLeak,也就是所谓的窗体泄露,泄露的原因是因为Android UI操作在主线程中操作,但是我们会需要在一些线程或者异步任务中操作UI界面元素的需求,那么这个时候可能会出现类似问题。我在做浮动窗口的时候碰到了这个问题,浮动窗口需要用到WindowManager, WindowManger又是一个Activity的一个变量,它依存于Activity,当横竖屏切换或者Activity销毁的时候这个变量会销毁。销毁的时候导致WindowManager通过AddView()方法添加的View没有依存,导致窗体泄露。那么问题来了,为什么这里会泄露了?

2.解决方法:我在onDestroy()里面调用了removeView方法,想要避免窗体泄露,但是这个方法并不管用,后来换成removeViewImmediate()就解决了这个问题,原因就是两个方法设计到线程同步问题,removeViewImmediate()是通知View立刻调用View.onDetachWindow(),这说明这个方法是通过一个监听或者观察者来实现的,因为线程的同步跟异步问题导致Activity销毁了,但View还没有被remove完,于是就产生了所谓的窗体泄露。说到这里,我想大家也能明白这两个方法的区别了。

参考链接


android WindowManager中removeView(View v)与removeViewImmediate(View v)的区别

NDK is missing a "platforms" directory.unset the NDK variable from ANDROID_NDK_HOME o...

首先这个错误之前没有的,可能是NDK升级到最新导致的编译失败。

尝试按照网上搜索的解决方法解决:

  • 1 删除NDK重新下载,最后删除重新下载后还下载失败,让我自己去看看错误的logAndroid Studio - Help - Show Log In Explorer打开查看log
  • 2 自己去官网下载NDK解压设置路径,都无济于事
  • 3 想到之前看到一篇类似错误的文章说过错误提示缺少哪个文件如果没有就新建一个空文件放在目录下,于是我看了解压后的android-ndk-r22,确实没有错误里提到的platforms,就新建了一个空的platforms文件夹,修改了项目的新NDK路径,再执行编译,奇迹发生了,编译成功!!!app按钮终于是绿色不带叉的了。

继续阅读NDK is missing a "platforms" directory.unset the NDK variable from ANDROID_NDK_HOME o...

ubuntu编译weex_js_engine

weex早期在Android上使用的是V8,但经过测试,JavaScriptCore的性能比V8的性能更好,所以便用JavaScriptCore全面替代了V8

主分支默认使用由 UC 提供的 V8 引擎,默认只提供 armeabi-v7ax86 两个版本的引擎。

系统只能是ubuntu 16.04,因为编译的时候需要gcc-4.7的头文件。

继续阅读ubuntu编译weex_js_engine