注册
环信即时通讯云

环信即时通讯云

单聊、群聊、聊天室...
环信开发文档

环信开发文档

环信FAQ

环信FAQ

集成常见问题及答案
RTE开发者社区

RTE开发者社区

汇聚音视频领域技术干货,分享行业资讯
技术讨论区

技术讨论区

技术交流、答疑
资源下载

资源下载

收集了海量宝藏开发资源
iOS Library

iOS Library

不需要辛辛苦苦的去找轮子, 这里都有
Android Library

Android Library

不需要辛辛苦苦的去找轮子, 这里都有

Jetpack之Navigation(1)

1.基本使用引入库 def nav_version = "2.3.2" // Java language implementation implementation "androidx.navigation:navigation-fragment:$nav_...
继续阅读 »

1.基本使用

引入库



def nav_version = "2.3.2"
// Java language implementation
implementation "androidx.navigation:navigation-fragment:$nav_version"
implementation "androidx.navigation:navigation-ui:$nav_version"
复制代码

Activity布局


<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
tools:context=".MainActivity">

<!--
app:defaultNavHost="true"
拦截系统back键
-->

<androidx.fragment.app.FragmentContainerView
android:id="@+id/my_nav_host_fragment"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_weight="9"
android:name="androidx.navigation.fragment.NavHostFragment"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toTopOf="parent"
app:defaultNavHost="true"
app:navGraph="@navigation/nav_graph_main"/>


</LinearLayout>
复制代码

在res/navigation目录下nav_graph_main.xml


<?xml version="1.0" encoding="utf-8"?>
<navigation xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/nav_graph_main.xml"
app:startDestination="@id/page1Fragment">

<fragment
android:id="@+id/page1Fragment"
android:name="com.example.lsn4_navigationdemo.MainPage1Fragment"
android:label="fragment_page1"
tools:layout="@layout/fragment_main_page1">


<!--action:程序中使用id跳到destination对应的类-->
<action
android:id="@+id/action_page2"
app:destination="@id/page2Fragment" />

</fragment>

<fragment
android:id="@+id/page2Fragment"
android:name="com.example.lsn4_navigationdemo.MainPage2Fragment"
android:label="fragment_page2"
tools:layout="@layout/fragment_main_page2">

<action
android:id="@+id/action_page1"
app:destination="@id/page1Fragment" />

<action
android:id="@+id/action_page3"
app:destination="@id/page3Fragment" />

</fragment>

<!-- <navigation-->
<!-- android:id="@+id/nav_graph_page3"-->
<!-- app:startDestination="@id/page3Fragment">-->
<fragment
android:id="@+id/page3Fragment"
android:name="com.example.lsn4_navigationdemo.MainPage3Fragment"
android:label="fragment_page3"
tools:layout="@layout/fragment_main_page3"
>

<action
android:id="@+id/action_page2"
app:destination="@id/page2Fragment"/>

</fragment>


</navigation>
复制代码

Fragment中调用跳转


//方式一:直接跳入指定的fragment
Navigation.findNavController(view).navigate(R.id.page2Fragment);

//方式二:通过action
Navigation.findNavController(view).navigate(R.id.action_page2); //跳入page2
复制代码

Activity中调用跳转


//获取controller方式一
NavController controller=Navigation.findNavController(this,R.id.my_nav_host_fragment);

//获取controller方式二
NavHostFragment navHostFragment = (NavHostFragment) getSupportFragmentManager().findFragmentById(R.id.my_nav_host_fragment);
NavController controller = navHostFragment.getNavController();

//跳转
controller.navigate(R.id.page2Fragment);
复制代码

Activity绑定navigation


除了在Activity的布局中指定navigation布局资源以外,还可以通过java代码进行设置


public class MainActivity extends AppCompatActivity {


@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);

//方式一
val finalHost = NavHostFragment.create(R.navigation.nav_graph_main)
supportFragmentManager.beginTransaction()
.replace(R.id.ll_fragment_navigation, finalHost)
.setPrimaryNavigationFragment(finalHost)
.commit();
}

//方式二
@Override
public boolean onSupportNavigateUp() {
Fragment fragment = getSupportFragmentManager().findFragmentById(R.id.my_nav_host_fragment);
return NavHostFragment.findNavController(fragment).navigateUp();
}
}
复制代码

底部导航


引入底部导航控件


implementation 'com.google.android.material:material:1.1.0'
复制代码

布局


<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical"
tools:context=".MainActivity">
<!--
app:defaultNavHost="true"
拦截系统back键
-->
<androidx.fragment.app.FragmentContainerView
android:id="@+id/my_nav_host_fragment"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_weight="9"
android:name="androidx.navigation.fragment.NavHostFragment"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toTopOf="parent"
app:defaultNavHost="true"
app:navGraph="@navigation/nav_graph_main"/>

<com.google.android.material.bottomnavigation.BottomNavigationView
android:id="@+id/nav_view"
android:layout_width="match_parent"
android:layout_weight="1"
android:layout_height="wrap_content"
app:itemTextColor="#ff0000"
app:menu="@menu/menu"/>

</LinearLayout>
复制代码

menu


<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android">
<item
android:id="@+id/page1Fragment"
android:icon="@drawable/ic_launcher_foreground"
android:title="1"/>
<item
android:id="@+id/page2Fragment"
android:icon="@drawable/ic_launcher_foreground"
android:title="2"/>
<item
android:id="@+id/page3Fragment"
android:icon="@drawable/ic_launcher_foreground"
android:title="3"/>

</menu>
复制代码

Activity绑定导航


public class MainActivity extends AppCompatActivity {

BottomNavigationView bottomNavigationView;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
findViewById(R.id.action_page1);
bottomNavigationView=findViewById(R.id.nav_view);

//获取controller方式一
//NavController controller=Navigation.findNavController(this,R.id.my_nav_host_fragment);

//获取controller方式二
NavHostFragment navHostFragment = (NavHostFragment) getSupportFragmentManager().findFragmentById(R.id.my_nav_host_fragment);
NavController controller = navHostFragment.getNavController();

//绑定导航
NavigationUI.setupWithNavController(bottomNavigationView,controller);

}

作者:贾里
链接:https://juejin.cn/post/6953624951194664968
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

drawable用Kotlin应该这样写

前言 通常我们在res/drawable下面自定义shape和selector来满足一些UI的设计,但是由于xml最终转换为drawable需要经过IO或反射创建,会有一些性能损耗,另外随着项目的增大和模块化等,很多通用的样式并不能快速复用,需要合理的项目资源...
继续阅读 »

前言


通常我们在res/drawable下面自定义shapeselector来满足一些UI的设计,但是由于xml最终转换为drawable需要经过IO或反射创建,会有一些性能损耗,另外随着项目的增大和模块化等,很多通用的样式并不能快速复用,需要合理的项目资源管理规范才能实施。那么通过代码直接创建这些drawable,可以在一定程度上降低这些副作用。本篇介绍用kotlin DSL简洁的语法特性来实现常见的drawable.


代码对应效果预览


shape_line
RECTANGLE
OVAL
LayerList
Selector

集成和使用



  1. 在项目级的build.gradle文件种添加仓库Jitpack:


allprojects {
repositories {
...
maven { url 'https://jitpack.io' }
}
}
复制代码


  1. 添加依赖


dependencies {		
implementation 'com.github.forJrking:DrawableDsl:0.0.1’
}
复制代码


  1. 抛弃xml创建方式示例(其他参见demo)


// infix用法用于去掉括号更加简洁,详细后面说明
image src = shapeDrawable {
//指定shape样式
shape(ShapeBuilder.Shape.RECTANGLE)
//圆角,支持4个角单独设置
corner(20f)
//solid 颜色
solid("#ABE2E3")
//stroke 颜色,边框dp,虚线设置
stroke(android.R.color.white, 2f, 5f, 8f)
}
//按钮点击样式
btn.background = selectorDrawable {
//默认样式
normal = shapeDrawable {
corner(20f)
gradient(90, R.color.F97794, R.color.C623AA2)
}
//点击效果
pressed = shapeDrawable {
corner(20f)
solid("#84232323")
}
}
复制代码

实现思路


xml如何转换成drawable


xml变成drawable,通过android.graphics.drawable.DrawableInflater这个类来IO解析标签创建:


//标签创建
private Drawable inflateFromTag(@NonNull String name) {
switch (name) {
case "selector":
return new StateListDrawable();
case "level-list":
return new LevelListDrawable();
case "layer-list":
return new LayerDrawable();
....
case "color":
return new ColorDrawable();
case "shape":
return new GradientDrawable();
case "vector":
return new VectorDrawable();
...
}
}
//反射创建
private Drawable inflateFromClass(@NonNull String className) {
try {
Constructor<? extends Drawable> constructor;
synchronized (CONSTRUCTOR_MAP) {
constructor = CONSTRUCTOR_MAP.get(className);
if (constructor == null) {
final Class<? extends Drawable> clazz = mClassLoader.loadClass(className).asSubclass(Drawable.class);
constructor = clazz.getConstructor();
CONSTRUCTOR_MAP.put(className, constructor);
}
}
return constructor.newInstance();
} catch (NoSuchMethodException e) {
...
}
复制代码

代码实现


由于创建shape等需要设置各种属性来构建,比较符合build设计模式,那我们首先封装build模式的shapeBuilder,这样做虽然代码比起直接使用apply{}多但是可以让纯java项目用起来很舒服,其他实现请查看源码:


class ShapeBuilder : DrawableBuilder {
private var mRadius = 0f
private var mWidth = 0f
private var mHeight = 0f
...
private var mShape = GradientDrawable.RECTANGLE
private var mSolidColor = 0

/**分别设置四个角的圆角*/
fun corner(leftTop: Float,rightTop: Float,leftBottom: Float,rightBottom: Float): ShapeBuilder {
....
return this
}

fun solid(@ColorRes colorId: Int): ShapeBuilder {
mSolidColor = ContextCompat.getColor(context, colorId)
return this
}
// 省略其他参数设置方法 详细代码查看源码
override fun build(): Drawable {
val gradientDrawable = GradientDrawable()
gradientDrawable = GradientDrawable()
gradientDrawable.setColor(mSolidColor)
gradientDrawable.shape = mShape
....其他参数设置
return gradientDrawable
}
}
复制代码

把build模式转换为dsl


理论上所有的build模式都可以轻松转换为dsl写法:


inline fun shapeDrawable(builder: ShapeBuilder.() -> Unit): Drawable {
return ShapeBuilder().also(builder).build()
}
//使用方法
val drawable = shapeDrawable{
...
}
复制代码

备注:dsl用法参见juejin.cn/post/695318… 中dsl小节


infix函数来去括号


通过上面封装已经实现了dsl的写法,通常setBackground可以通过setter简化,但是我发现由于有些api设计还需要加括号,这样不太kotlin:


//容易阅读
iv1.background = shapeDrawable {
shape(ShapeBuilder.Shape.RECTANGLE)
solid("#ABE2E3")
}
//多了括号看起来不舒服
iv2.setImageDrawable(shapeDrawable {
solid("#84232323")
})
复制代码

怎么去掉括号呢?这里就要用到infix函数特点和规范:



  • Kotlin允许在不使用括号和点号的情况下调用函数

  • 必须只有一个参数

  • 必须是成员函数或扩展函数

  • 不支持可变参数和带默认值参数


/**为所有ImageView添加扩展infix函数 来去掉括号*/
infix fun ImageView.src(drawable: Drawable?) {
this.setImageDrawable(drawable)
}
//使用如下 舒服了
iv2 src shapeDrawable {
shape(ShapeBuilder.Shape.OVAL)
solid("#E3ABC2")
}
复制代码

当然了代码是用来阅读的。个人认为如果我们大量使用infix函数,阅读困难会大大增加,所以建议函数命名必须可以直击函数功能,而且函数功能简单且单一。


优缺点


优点:



  • 代码直接创建比起xml方式可以提升性能

  • dsl方式比起build模式和调用方法设置更加简洁符合kotlin风格

  • 通过合适的代码管理可以复用这些代码,比xml管理方便


缺点:



  • 没有as的预览功能,只有通过上机观测

  • api还没有覆盖所有drawable属性


后语


上面把的DrawableDsl基础用法介绍完了,欢迎大家使用,欢迎提Issues,记得给个star哦。Github链接:https://github.com/forJrking/DrawableDsl


作者:forJrking
链接:https://juejin.cn/post/6953472037012635655
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

Android各版本的行为变更

本文的主要内容来自官方,摘出了Android开发者应该关注的重点变更,目前已经更新到Android 11,新版本发布时会持续更新,如果对您有帮助请不吝点赞! 一、Android 5.0——21——Lollipop(棒棒糖) ART 限制获取AppTask ...
继续阅读 »

本文的主要内容来自官方,摘出了Android开发者应该关注的重点变更,目前已经更新到Android 11,新版本发布时会持续更新,如果对您有帮助请不吝点赞!



一、Android 5.0——21——Lollipop(棒棒糖)



  1. ART


  2. 限制获取AppTask


  3. WebView默认阻止第三方内容:setMixedContentMode()


  4. Material Design


  5. 提出JobScheduler



  6. 屏幕采集和屏幕共享


    Android 5.0 引入了新的 android.media.projection API,让您可以为应用添加屏幕采集和屏幕共享功能。例如,如果您想在视频会议应用中启用屏幕共享,便可使用此功能。

    新增的 createVirtualDisplay() 方法允许您的应用将主屏幕(默认显示)的内容采集到一个 Surface 对象中,然后您的应用便可将其发送至整个网络。该 API 只允许采集非安全屏幕内容,不允许采集系统音频。要开始采集屏幕,您的应用必须先使用通过 createScreenCaptureIntent() 方法获得的 Intent 启动屏幕采集对话框,请求用户授予权限。



二、Android 6.0——23——Marshmallow(棉花糖)



  1. 省电机制Doze引入

  2. 运行时权限

  3. 移除了对设备本地硬件标识符的编程访问权

  4. 指纹API


三、Android 7.0——24——Nougat(牛轧糖)



  1. FileProvider

  2. 低耗电模式进一步优化

  3. 多窗口支持

  4. 添加JIT,属于对AOT的一种补充机制


四、Android 8.0——26——Oreo(奥利奥)



  1. 当您的应用进入已缓存状态时,如果没有活动的组件,系统将解除应用具有的所有唤醒锁。


  2. 应用无法使用其清单注册大部分隐式广播


  3. 应用尝试在不允许其创建后台服务的情况下使用 startService() 函数,则该函数将引发一个 IllegalStateException


  4. 后台应用时,降低了后台应用接收位置更新的频率


  5. 画中画模式


  6. 应用快捷菜单


  7. 音频自动闪避,失去焦点时自动调小音量



  8. 多显示器支持(移动Activity到另一个窗口会onConfigChange)


    在多窗口模式下,在任意时间点都只有用户最近一次互动的 Activity 处于活动状态。此 Activity 被视为最顶层的 Activity,而且是唯一处于 RESUMED 状态的 Activity。所有其他可见的 Activity 均处于 STARTED 而非 RESUMED 状态。不过,这些可见但并不处于 RESUMED 状态的 Activity 在系统中享有比不可见 Activity 更高的优先级。如果用户与其中一个可见的 Activity 互动,那么该 Activity 将进入 RESUMED 状态,而之前的最顶层 Activity 将进入 STARTED 状态。



五、Android 9.0——28——Pie



  1. 后台应用无法访问用户输入和一些传感器数据,如麦克风相机,加速器陀螺仪等,除非使用前台服务

  2. 通话记录权限从Phone组移动到CALL_LOG组,plus,一个组的权限有了一个,其他的的权限也就有了(申请会自动授权)

  3. 不允许使用非SDKAPI,也就是hide的一些SDK方法不许用反射和JNI调用

  4. 支持检测显示屏缺口,非功能区域DisplayCutout,比如检测挖孔屏

  5. 利用 Wi-Fi RTT 进行室内定位

  6. ImageDecoder类可取代BitmapFactory


六、Android 10——29——Q



  1. 屏幕边缘手势导航(各大厂商早就实现了)



  2. 为了让用户更好地管理自己的文件并减少混乱,以 Android 10(API 级别 29)及更高版本为目标平台的应用在默认情况下被赋予了对外部存储空间的分区访问权限(即分区存储)。此类应用只能访问外部存储空间上的应用专属目录,以及本应用所创建的特定类型的媒体文件。

    注意:如果您的应用在运行时请求与存储空间相关的权限,面向用户的对话框会表明您的应用正在请求对外部存储空间的广泛访问,即使已启用分区存储也是如此。


  • 后台应用不能启动一个新的Activity


  • 新增后台访问位置信息权限,无则不可以(ACCESS_BACKGROUND_LOCATION)


  • 应用必须具有 READ_PRIVILEGED_PHONE_STATE 特许权限才能访问设备的不可重置标识符(包含 IMEI 和序列号),普通应用基本是不可以的


  • 除非您的应用是默认输入法 (IME) 或是目前处于焦点的应用,否则它无法访问 Android 10 或更高版本平台上的剪贴板数据。



  • 七、Android 11——30——R



    1. 单次授权(权限只给这一次)


    2. 自动重置权限——几个月用户未与应用交互,将回收应用权限



    3. 支持瀑布屏API


      现有的 DisplayCutout.getSafeInset…() 方法现在会返回能够避开瀑布区域以及刘海的安全边衬区



    4. 新增前台服务类型属性,必须指明为camera和microphone才能访问麦克风,在后台运行时启动的前台服务无法访问麦克风和相机,除非具备后台访问权限


      <manifest>
      ...
      <service ... android:foregroundServiceType="location|camera" />
      </manifest>



    5. 软件包可见性——不是所有应用都对软件可见了


      1.影响queryIntentActivities()的返回结果
      2.影响启动其他应用的Service
      3.不影响启动Activity
      4.别的应用和你发生交互,那它对你是可见的
      5.系统的一些支持程序是可见的
      6.ContentProvider是可见的,如果你具备权限的话
      7.用<queries>生命想要可见的一些应用





    1. 应用退出原因


      Android 11 引入了 ActivityManager.getHistoricalProcessExitReasons() 方法,用于报告近期任何进程终止的原因。应用可以使用此方法收集崩溃诊断信息,例如进程终止是由于 ANR、内存问题还是其他原因所致。此外,您还可以使用新的 setProcessStateSummary() 方法存储自定义状态信息,以便日后进行分析。



    2. 资源加载器ResourcesLoader——可用做换肤和插件化


      Android 11 引入了一个新 API,允许应用动态扩展资源的搜索和加载方式。新的 API 类 ResourcesLoader 和 ResourcesProvider 主要负责提供新功能。两者协同作用,可以提供额外的资源,或修改现有资源的值。

      ResourcesLoader 对象是向应用的 Resources 实例提供 ResourcesProvider 对象的容器,而 ResourcesProvider 对象提供从 APK 和资源表加载资源数据的方法。

      此 API 的一个主要用例是自定义资源加载。您可以使用 loadFromDirectory() 创建一个 ResourcesProvider,用于重定向基于文件的资源的解析,从而让其搜索特定目录,而不是应用 APK。您可以通过 AssetManager API 类中的 open() 系列方法访问这些资源,就像访问 APK 中绑定的资源一样。


    作者:Mr云台
    链接:https://www.jianshu.com/p/e9fbbd52065b
    来源:简书
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。  

    收起阅读 »

    iOS------OpenGL 图形专有名词与坐标解析

    一.OpenGL简介OpenGL(英语:Open Graphics Library,译名:开放图形库或者“开放式图形库”)是用于渲染2D、3D矢量图形的跨语言、跨平台的应用程序编程接口(API)。它将计算机的资源抽象称为⼀个个OpenGL的对象,对这些资源的操...
    继续阅读 »

    一.OpenGL简介

    OpenGL(英语:Open Graphics Library,译名:开放图形库或者“开放式图形库”)是用于渲染2D3D矢量图形的跨语言跨平台应用程序编程接口(API)。它将计算机的资源抽象称为⼀个个OpenGL的对象,对这些资源的操作抽象为⼀个个的OpenGL指令,开发者可以在mac程序中使用OpenGl来实现图形渲染。图形API的目的就是实现图形的底层渲染,比如游戏场景/游戏人物的渲染,音视频解码后数据的渲染,地图上的渲染,动画绘制等。在iOS开发中,开发者唯一能够GPU的就是图形API。(GPU---图形处理器(英语:Graphics Processing Unit,缩写:GPU),又称显示核心、视觉处理器、显示芯片,是一种专门在个人电脑工作站、游戏机和一些移动设备(如平板电脑智能手机等)上做图像和图形相关运算工作的微处理器。)

    二.OpenGL专业名词解析

        1.OpenGL 上下⽂( context )

            OpenGL Context,中文解释就是OpenGL的上下文,因为OpenGL没有窗口的支持,我们在使用OpenGl的时候,一般是在main函数创建窗口: 

            //GLUT窗口大小、窗口标题

            glutInitWindowSize(800, 600);

            glutCreateWindow("Triangle");

            然后我们在创建的窗口里面绘制,个人理解上下文的意思就是指的是OpenGL的作用范围,当然OpenGL的Context不只是这个窗口,这个窗口我们可以理解为OpenGL的default framebuffer,所以Context还包含关于这个framebuffer的一些参数设置信息,具体内容可以查看OpenGL的Context的结构体,Context记录了OpenGL渲染需要的所有信息,它是一个大的结构体,它里面记录了当前绘制使用的颜色、是否有光照计算以及开启的光源等非常多我们使用OpenGL函数调用设置的状态和状态属性等等,你可以把它理解为是一个巨大的状态机,它里面保存OpenGl的指令,在图形渲染的时候,可以理解为这个状态机开始工作了,对某个属性或者开关发出指令。它的特点就是:有记忆功能,接收输入,根据输入的指令,修改当前的状态,并且可以输出内容,当停机的时候不再接收指令。

    2.渲染

            渲染就是把数据显示到屏幕上,在OpenGl中,渲染指的是将图形/图像数据转换为2D空间图像操作叫渲染

    3.顶点数组/顶点缓冲区

            在OpenGL中,基本图元有三种:点,线,三角形,复杂的图形由这三种图元组成,我们在画点/线/三角形的时候是不是应该先知道每个顶点的坐标,而这些坐标放在数组里,就叫顶点数组。顶点数组存在内存当中,但是为了提高性能,提前分配一块显存,将顶点数组预先存入到显存当中,这部分的显存就叫顶点缓冲区。

    4.着色器(shader)

            为什么要使用着色器?我们知道,OpenGL一般使用经典的固定渲染管线来渲染对象,OpenGL在实际调⽤绘制函数之前,还需指定⼀个由shader编译成的着⾊器程序。常⻅的着⾊器主要有顶点着⾊器(VertexShader),⽚段着⾊器(FragmentShader)/像素着⾊器(PixelShader),⼏何着⾊器(GeometryShader),曲⾯细分着⾊器(TessellationShader)。⽚段着⾊器和像素着⾊器只是在OpenGL和DX中的不同叫法⽽已。可惜的是,直到OpenGLES 3.0,依然只⽀持了顶点着⾊器和⽚段着⾊器这两个最基础的着⾊器。OpenGL在处理shader时,和其他编译器⼀样。通过编译、链接等步骤,⽣成了着⾊器程序(glProgram),着⾊器程序同时包含了顶点着⾊器和⽚段着⾊器的运算逻辑。在OpenGL进⾏绘制的时候,⾸先由顶点着⾊器对传⼊的顶点数据进⾏运算。再通过图元装配,将顶点转换为图元。然后进⾏光栅化,将图元这种⽮量图形,转换为栅格化数据。最后,将栅格化数据传⼊⽚段着⾊器中进⾏运算。⽚段着⾊器会对栅格化数据中的每⼀个像素进⾏运算,并决定像素的颜⾊(顶点着色器和片段/片元着色器会在下面讲解)

    5.管线

            OpenGL在渲染图形/图像的时候是按照特定的顺序来执行的,不能修改打破,管线的意思个人理解是读取顶点数据—>顶点着色器—>组装图元—>光栅化图元—>片元着色器—>写入帧缓冲区—>显示到屏幕上,类似这样的流水线,当图像/图形显示到屏幕上,这一条管线完成工作。下面是分步讲解:

           (1)读取顶点数据指的是将待绘制的图形的顶点数据传递给渲染管线中。

            (2)顶点着色器最终生成每个定点的最终位置,执行顶点的各种变换,它会针对每个顶点执行一次,确定了最终位置后,OpenGL就可以把这些顶点集合按照给定的参数类型组装成点,线或者三角形。


         (3)组装图元阶段包括两部分:图元的组装和图元处理,图元组装指的是顶点数据根据设置的绘制方式参数结合成完整的图元,例如点绘制方式中每个图元就只包含一个点,线段绘制方式中每个图源包含两个点;图元处理主要是剪裁以使得图元位于视景体内部的部分传递到下一个步骤,视景体外部的部分进行剪裁。视景体的概念与投影有关。

          (4)光栅化图元主要指的是将一个图元离散化成可显示的二维单元片段,这些小单元称为片元。一个片元对应了屏幕上的一个或多个像素,片元包括了位置,颜色,纹理坐标等信息,这些值是由图元的顶点信息进行插值计算得到的。

          (5)片元着色器为每个片元生成最终的颜色,针对每个片元都会执行一次。一旦每个片元的颜色确定了,OpenGL就会把它们写入到帧缓冲区中。


    6.顶点着色器

             • ⼀般⽤来处理图形每个顶点变换(旋转/平移/投影等)                     

            • 顶点着⾊器是OpenGL中⽤于计算顶点属性的程序。顶点着⾊器是逐顶点运算的程序,也就是说每个顶点数据都会执⾏⼀次顶点着⾊器,当然这是并⾏的,并且顶点着⾊器运算过程中⽆法访问其他顶点的数据

            • ⼀般来说典型的需要计算的顶点属性主要包括顶点坐标变换、逐顶点光照运算等等。顶点坐标由⾃身坐标系转换到归⼀化坐标系的运算,就是在这⾥发⽣的。

    7.片元着色器(片段着色器)

            ⼀般⽤来处理图形中每个像素点颜⾊计算和填充⽚段着⾊器是OpenGL中⽤于计算⽚段(像素)颜⾊的程序。⽚段着⾊器是逐像素运算的程序,也就是说每个像素都会执⾏⼀次⽚段着⾊器,当然也是并⾏的

    8.光栅化Rasterization 

            • 是把顶点数据转换为⽚元的过程,具有将图转化为⼀个个栅格组成的图象的作⽤,特点是每个元素对应帧缓冲区中的⼀像素。

            • 光栅化就是把顶点数据转换为⽚元的过程。⽚元中的每⼀个元素对应于帧缓冲区中的⼀个像素。

            • 光栅化其实是⼀种将⼏何图元变为⼆维图像的过程。该过程包含了两部分的⼯作。第⼀部分⼯作:决定窗⼝坐标中的哪些整型栅格区域被基本图元占⽤;第⼆部分⼯作:分配⼀个颜⾊值和⼀个深度值到各个区域。光栅化过程产⽣的是⽚元

            • 把物体的数学描述以及与物体相关的颜⾊信息转换为屏幕上⽤于对应位置的像素及⽤于填充像素的颜⾊,这个过程称为光栅化,这是⼀个将模拟信号转化为离散信号的过程

    9.纹理

            纹理可以理解为图⽚. ⼤家在渲染图形时需要在其编码填充图⽚,为了使得场景更加逼真.⽽这⾥使⽤的图⽚,就是常说的纹理.但是在OpenGL,我们更加习惯叫纹理,⽽不是图⽚

    10.混合(Blending)

            在测试阶段之后,如果像素依然没有被剔除,那么像素的颜⾊将会和帧缓冲区中颜⾊附着上的颜⾊进⾏混合,混合的算法可以通过OpenGL的函数进⾏指定。但是OpenGL提供的混合算法是有限的,如果需要更加复杂的混合算法,⼀般可以通过像素着⾊器进⾏实现,当然性能会⽐原⽣的混合算法差⼀些,个人理解有点像iOS给RGB中红,绿,蓝设置不同的值得到不同的颜色,只是这里是操作片元着色器,来达到不同的显示。

    11.变换矩阵(Transformation)/投影矩阵Projection 

            在iOS核心动画中我们也会和矩阵打交到,变换矩阵顾名思义就是对图像/图形的放大/缩小/平移/选装等座处理。

            投影矩阵就是⽤于将3D坐标转换为⼆维屏幕坐标,实际线条也将在⼆维坐标下进⾏绘制    

    12.渲染上屏/交换缓冲区(SwapBuffer)     

        • 渲染缓冲区⼀般映射的是系统的资源⽐如窗⼝。如果将图像直接渲染到窗⼝对应的渲染缓冲区,则可以将图像显示到屏幕上。

        • 但是,值得注意的是,如果每个窗⼝只有⼀个缓冲区,那么在绘制过程中屏幕进⾏了刷新,窗⼝可能显示出不完整的图像

        • 为了解决这个问题,常规的OpenGL程序⾄少都会有两个缓冲区。显示在屏幕上的称为屏幕缓冲区,没有显示的称为离屏缓冲区。在⼀个缓冲区渲染完成之后,通过将屏幕缓冲区和离屏缓冲区交换,实现图像在屏幕上的显示。

        • 由于显示器的刷新⼀般是逐⾏进⾏的,因此为了防⽌交换缓冲区的时候屏幕上下区域的图像分属于两个不同的帧,因此交换⼀般会等待显示器刷新完成的信号,在显示器两次刷新的间隔中进⾏交换,这个信号就被称为垂直同步信号,这个技术被称为垂直同步

        • 使⽤了双缓冲区和垂直同步技术之后,由于总是要等待缓冲区交换之后再进⾏下⼀帧的渲染,使得帧率⽆法完全达到硬件允许的最⾼⽔平。为了解决这个问题,引⼊了三缓冲区技术,在等待垂直同步时,来回交替渲染两个离屏的缓冲区,⽽垂直同步发⽣时,屏幕缓冲区和最近渲染完成的离屏缓冲区交换,实现充分利⽤硬件性能的⽬的

    13.坐标系

          OpenGl常见的坐标系有:

            1. Object or model coordinates(物体或模型坐标系)每一个实物都有自己的坐标系,在高中数学中,以自身建立的坐标系,自身坐标系由世界坐标系平移而来

            2. World coordinates(世界坐标系)个人理解为地球相对自己建立的坐标系,地球上所有生物都处于这个坐标系当中

            3. Eye (or Camera) coordinates(眼(或相机)坐标系)

            4. Normalized device coordinates(标准化的设备坐标系)

            5. Window (or screen) coordinates(.窗口(或屏幕)坐标系)个人理解为iOS下

            6.Clip coordinates(裁剪坐标系)主要作用是当图形/图像超出时,按照这个坐标系裁剪,裁剪好之后转换到screen坐标系

    14.正投影/透视投影

            正投影:类似于照镜子,1:1形成图形大小,这里不做重点讲解

            透视投影:在OpenGL中,如果想对模型进行操作,就要对这个模型的状态(当前的矩阵)乘上这个操作对应的一个矩阵.如果乘以变换矩阵(平移, 缩放, 旋转), 那相乘之后, 模型的位置被变换;如果乘以投影矩阵(将3D物体投影到2D平面), 相乘后, 模型的投影方式被设置;如果乘以纹理矩阵(), 模型的纹理方式被设置.而用来指定乘以什么类型的矩阵, 就是glMatriMode(GLenummode);glMatrixMode有3种模式: GL_PROJECTION 投影, GL_MODELVIEW 模型视图, GL_TEXTURE 纹理.所以,在操作投影矩阵以前,需要调用函数:glMatrixMode(GL_PROJECTION); //将当前矩阵指定为投影矩阵然后把矩阵设为单位矩阵




    作者:枫紫_6174
    链接:https://www.jianshu.com/p/03d3a5ab2db0






    收起阅读 »

    iOS Category---为什么只能加方法不能加属性

    一.面试题            相信大家在面试的时候经常会被问到Category的实现原理,以及Category为什么只能加方法不能加属性?个人理解这个问题本...
    继续阅读 »

    一.面试题

                相信大家在面试的时候经常会被问到Category的实现原理,以及Category为什么只能加方法不能加属性?个人理解这个问题本身问的就有问题,首先我们看分类的底层代码

                            struct category_t {

                                        const char *name;

                                        classref_t cls;

                                        struct method_list_t *instanceMethods; // 对象方法

                                        struct method_list_t *classMethods; // 类方法

                                        struct protocol_list_t *protocols; // 协议

                                        struct property_list_t *instanceProperties; // 属性

                                        // Fields below this point are not always present on disk.

                                        struct property_list_t *_classProperties;

                                        method_list_t*methodsForMeta(boolisMeta) {

                                    if(isMeta)returnclassMethods;

                                                elsereturninstanceMethods;

                                }

                            property_list_t*propertiesForMeta(boolisMeta,structheader_info *hi);

                        };

            通过上面的分类底层代码我们可以找到category_t 结构体,它里面包含了对象方法,类方法,协议,属性,既然分类的底层代码里面已经包含了属性,为什么我们面试的时候会被问到分类为什么不能添加属性?下面我们来揭开它的神秘面纱

            1.首先我们创建一个person类,再给penson类创建一个分类Person+TCText,在分类的.h文件




    这么写工程是不会报任何错误,给我们一种表面上其实是可以添加属性的,写上一个属性,系统会自动帮我们生成setter和getter方法,在分类里面写属性或者成员变量,系统只会帮我们做的一件事情就是它只会声明我们的setter和getter方法,不会帮我们实现,上面的这个属性等同于我们在分类里面写




    无论上面何种写法,我们在ViewController都能访问TCName这个属性


    但是,当我们在分类里面重写settet或者getter的时候,它就会出现:



    为什么什么会报错了?因为分类的属性,系统不会自动帮我们生成_TCName(相关属性赋值可以看苹果官网API,这里不做解释),在这里我们如果写:




    表面看上去不会报错,但是当外部访问TCName的时候,就会发现:



    程序一旦运行起来,就会因为递归,程序闪退。

    总结:不是说分类不能添加属性,是因为分类可以添加属性,但是由于系统不会自动帮分类的属性实现getter和setter方法,也不会帮其生成_TCName,无论你重写settet或者getter还是,你不能通过self.TCName去访问属性,重写了setter,这么访问就会发生递归,直接导致程序闪退。所以下次你该知道怎么回答面试官的问题了吧!!!



    作者:枫紫_6174
    链接:https://www.jianshu.com/p/49d131c61348








    收起阅读 »

    iOS Metal语言规范深入

    一.函数修饰符Metal 有以下3种函数修饰符:        1)kernel , 表示该函数是⼀个数据并⾏计算着⾊函数. 它可以被分配在⼀维/⼆维/三维线程组中去执⾏      &nbs...
    继续阅读 »

    一.函数修饰符

    Metal 有以下3种函数修饰符:

            1)kernel , 表示该函数是⼀个数据并⾏计算着⾊函数. 它可以被分配在⼀维/⼆维/三维线程组中去执⾏

            2)vertex , 表示该函数是⼀个顶点着⾊函数 , 它将为顶点数据流中的每个顶点数据执⾏⼀次然后为每个顶 点⽣成数据输出到绘制管线

            3)fragment , 表示该函数是⼀个⽚元着⾊函数, 它将为⽚元数据流中的每个⽚元 和其关联执⾏⼀次然后 将每个⽚元⽣成的颜⾊数据输出到绘制管线中; 

    eg:

    //1.并行计算函数(kernel)

    kernelvoidCCTestKernelFunctionA(inta,intb)

    {

        /*

         注意:

         1. 使用kernel 修饰的函数返回值必须是void 类型

         2. 一个被函数修饰符修饰过的函数,不允许在调用其他的被函数修饰过的函数. 非法

         3. 被函数修饰符修饰过的函数,只允许在客户端对齐进行操作. 不允许被普通的函数调用.

         */

        //不可以的!

        //一个被函数修饰符修饰过的函数,不允许在调用其他的被函数修饰过的函数. 非法

        CCTestKernelFunctionB(1,2);//非法

        CCTestVertexFunctionB(1,2);//非法

        //可以! 你可以调用普通函数.而且在Metal 不仅仅只有这3种被修饰过的函数.普通函数也可以存在

        CCTest();

    }

    kernelvoidCCTestKernelFunctionB(inta,intb)

    {

    }

    //顶点函数

    vertexintCCTestVertexFunctionB(inta,intb){

    }

    //片元函数

    fragmentintCCTestVertexFunctionB(inta,intb){

    }

    //普通函数

    voidCCTest()

    {

    }

            说明:使⽤kernel 修饰的函数. 其返回值类型必须是void 类型; 只有图形着⾊函数才可以被 vertex 和 fragment 修饰. 对于图形着⾊函数, 返回值类型可以辨认出它是为 顶点做计算还是为每像素做计算. 图形着⾊函数的返回值可以为 void , 但是这也就意味着该函数不产⽣数 据输出到绘制管线; 这是⼀个⽆意义的动作; ⼀个被函数修饰符修饰的函数不能在调⽤其他也被函数修饰符修饰的函数; 这样会导致编译失败;

    二.⽤于变量或者参数的地址空间修饰符

            Metal 着⾊器语⾔使⽤ 地址空间修饰符 来表示⼀个函数变量或者参数变量 被分配于那⼀⽚内存区域. 所有的着⾊函数(vertex, fragment, kernel)的参数,如果是指针或是引⽤, 都必须带有地址空间修饰符号; 

            1) device: 设备地址空间

            Device Address Space(设备地址空间) ,在设备地址空间(Device) 指向设备内存池分配出来的缓存对象, 它是可读也是可写的; ⼀个缓存对象可 以被声明成⼀个标量,向量或是⽤户⾃定义结构体的指针或是引⽤. 

    eg:

            // 设备地址空间: device 用来修饰指针.引用

            //1.修饰指针变量

            device float4 *color;

            structCCStruct{

                floata[3];

                intb[2];

            };

            //2.修饰结构体类的指针变量

            device  CCStruct*my_CS;

            注意: 纹理对象总是在设备地址空间分配内存, device 地址空间修饰符不必出现在纹理类型定义中. ⼀个纹 理对象的内容⽆法直接访问. Metal 提供读写纹理的内建函数; 

            2)threadgroup: 线程组地址空间

            线程组地址空间⽤于为 并⾏计算着⾊函数分配内存变量. 这些变量被⼀个线程组的所有线程共享. 在线 程组地址空间分配的变量不能被⽤于图形绘制着⾊函数[顶点着⾊函数, ⽚元着⾊函数] 在并⾏计算着⾊函数中, 在线程组地址空间分配的变量为⼀个线程组使⽤, 声明周期和线程组相同; 

    eg:

            /*

             1. threadgroup 被并行计算计算分配内存变量, 这些变量被一个线程组的所有线程共享. 在线程组分配变量不能被用于图像绘制.

             2. thread 指向每个线程准备的地址空间. 在其他线程是不可见切不可用的

             */

            kernel void CCTestFouncitionF(threadgroup float *a)

            {

                //在线程组地址空间分配一个浮点类型变量x

                threadgroup float x;

                //在线程组地址空间分配一个10个浮点类型数的数组y;

                threadgroup float y[10];

            }

            constant float sampler[] = {1.0f,2.0f,3.0f,4.0f};

            kernel  void  CCTestFouncitionG(void)

            {

                //在线程空间分配空间给x,p

                float  x;

                thread  float  p = &x;

    }

           3) constant 常量地址空间

            常量地址空间指向的缓存对象也是从设备内存池分配存储, 但是它是只读的; 在程序域的变量必须定义在常量地址空间并且声明的时候初始化; ⽤来初始化的值必须是编译时的常 量. 在程序域的变量的⽣命周期和程序⼀样, 在程序中的并⾏计算着⾊函数或者图形绘制着⾊函数调⽤, 但 是constant 的值会保持不变; 

            注意: 常量地址空间的指针或是引⽤可以作为函数的参数. 向声明为常量的变量赋值会产⽣编译错误. 声明常量但是没有赋予初值也会产⽣编译错误; 

    eg:

            1 constant float samples[] = { 1.0f, 2.0f, 3.0f, 4.0f }; 

            2 //对⼀个常量地址空间的变量进⾏修改也会失败,因为它只读的 

            3 sampler[4] = {3,3,3,3}; //编译失败; 

            4 //定义为常量地址空间声明时不赋初值也会编译失败 

            5 constant float a; 

            4)thread 线程地址空间

            thread 地址空间指向每个线程准备的地址空间, 这个线程的地址空间定义的变量在其他线程不可⻅, 在 图形绘制着⾊函数或者并⾏计算着⾊函数中声明的变量thread 地址空间分配; 在图形绘制着色函数 或者 并行计算着色函数中声明的变量,在线程地址空间分配存储

    eg:

            kernel void CCTestFouncitionG(void){

            //在线程空间分配空间给x,p

            float x; 

            thread   float   p=&x;

            }

            对于图形着⾊器函数, 其指针或是引⽤类型的参数必须定义为 device 或是 constant 地址空间; 对于并⾏计算着⾊函数, 其指针或是引⽤类型的参数必须定义为 device 或是 threadgrounp 或是 constant 地址空间; 并不是所有的变量都需要修饰符,也可以定义普通变量(即无修饰符的变量)

    三.函数参数与变量

            图形绘制或者并⾏计算着⾊器函数的输⼊输出都是通过参数传递. 除了常量地址空间变量和程序域定义 的采样器以外.

            device buffer- 设备缓存, ⼀个指向设备地址空间的任意数据类型的指针或者引⽤; 

            constant buffer -常量缓存区, ⼀个指向常量地址空间的任意数据类型的指针或引⽤ 

            texture - 纹理对象; 

            sampler - 采样器对象; 

            threadGrounp - 在线程组中供各线程共享的缓存.

            注意: 被着⾊器函数的缓存(device 和 constant) 不能重名; 

            Attribute Qualifiers to Locate Buffers, Textures, and Samplers ⽤于寻址缓存,纹理, 采样器的属性修饰符;对于每个着⾊器函数来说, ⼀个修饰符是必须指定的. 他⽤来设定⼀个缓存,纹理, 采样器的位置; 

            device buffers/ constant buffer --> [[buffer (index)]] 

            texture -- [[texture (index)]] 

            sampler -- [[sampler (index)]] 

            threadgroup buffer -- [[threadgroup (index)]] 

            index是⼀个unsigned integer类型的值,它表示了⼀个缓存、纹理、采样器参数的位置(在函数参数索引 表中的位置)。 从语法上讲,属性修饰符的声明位置应该位于参数变量名之后 

            例⼦中展示了⼀个简单的并⾏计算着⾊函数 add_vectors,它把两个设备地址空间中的缓存inA和inB相 加,然后把结果写⼊到缓存out。属性修饰符 “(buffer(index))”为着⾊函数参数设定了缓存的位置。

    //属性修饰符

    /*

     1. device buffer(设备缓存)

     2. constant buffer(常量缓存)

     3. texture Object(纹理对象)

     4. sampler Object(采样器对象)

     5. 线程组 threadgroup


     属性修饰符目的:

     1. 参数表示资源如何定位? 可以理解为端口

     2. 在固定管线和可编程管线进行内建变量的传递

     3. 将数据沿着渲染管线从顶点函数传递片元函数.


     在代码中如何表现:

     1.已知条件:device buffer(设备缓存)/constant buffer(常量缓存)

     代码表现:[[buffer(index)]]

     解读:不变的buffer ,index 可以由开发者来指定.


     2.已知条件:texture Object(纹理对象)

     代码表现: [[texture(index)]]

     解读:不变的texture ,index 可以由开发者来指定.


     3.已知条件:sampler Object(采样器对象)

     代码表示: [[sampler(index)]]

     解读:不变的sampler ,index 可以由开发者来指定.


     4.已知条件:threadgroup Object(线程组对象)

     代码表示: [[threadgroup(index)]]

     解读:不变的threadgroup ,index 可以由开发者来指定.

     */

    //并行计算着色器函数add_vectros ,实现2个设备地址空间中的缓存A与缓存B相加.然后将结果写入到缓存out.

    //属性修饰符"(buffer(index))" 为着色函数参数设定了缓存的位置

    //并行计算着色器函数add_vectros ,实现2个设备地址空间中的缓存A与缓存B相加.然后将结果写入到缓存out.

    //属性修饰符"(buffer(index))" 为着色函数参数设定了缓存的位置

    kernelvoidadd_vectros(

                    const device float4*inA [[buffer(0)]],

                    const device float4*inB [[buffer(1)]],

                    device float4*out [[buffer(2)]]

                    uintid[[thread_position_in_grid]])

    {

        out[id] = inA[id] + inB[id];

    }

            注意:thread_position_in_grid : ⽤于表示当前节点在多线程⽹格中的位置; 

    四.内建变量属性修饰符 

            [[vertex_id]] 顶点id 标识符; 

            [[position]] 顶点信息(float4) /� 述了⽚元的窗⼝相对坐标(x, y, z, 1/w) 

            [[point_size]] 点的⼤⼩(float) 

            [[color(m)]] 颜⾊, m编译前得确定; 

            struct MyFragmentOutput { 

             // color attachment 0 

             float4 clr_f [[color(0)]]; // color attachment 1 

             int4 clr_i [[color(1)]]; // color attachment 2 

             uint4 clr_ui [[color(2)]]; }; 

             fragment MyFragmentOutput my_frag_shader( ... ) 

             { 

             MyFragmentOutput f; 

             .... 

             f.clr_f = ...; 

             ... 

             return f;

            }

            [[stage_in]] : ⽚元着⾊函数使⽤的单个⽚元输⼊数据是由顶点着⾊函数输出然后经过光栅化⽣成的.顶 点和⽚元着⾊函数都是只能有⼀个参数被声明为使⽤“stage_in”修饰符,对于⼀个使⽤ 了“stage_in”修饰符的⾃ 定义的结构体,其成员可以为⼀个整形或浮点标量,或是整形或浮点向量



    作者:枫紫_6174
    链接:https://www.jianshu.com/p/a2baf448dd94
    收起阅读 »

    iOS YUV与RGB&YUV算法

    数字媒体压缩        为缩小数字媒体文件的大小,我们需要对其使用压缩技术,一般来说我们所欣赏的媒体内容都进行过一定程度的压缩,无论在电视上的视频,蓝光碟片,网页上的视频流还是...
    继续阅读 »

    数字媒体压缩

            为缩小数字媒体文件的大小,我们需要对其使用压缩技术,一般来说我们所欣赏的媒体内容都进行过一定程度的压缩,无论在电视上的视频,蓝光碟片,网页上的视频流还是冲iTunes Store购买的资源,我们其实都是和这些内容的原始文件的压缩格式在打交到,对数字媒体进行压缩可以大幅度缩小文件的尺寸,但是通常会在资源的质量上有小幅可见的衰减,

    色彩的二次采样

            视频数据是使用称之为YCbCr颜色模式,它也常称为YUV,虽然YUV术语并不准确,但是读起来比较方便,大部分的软件开发者都更熟悉RGB颜色模式,即每个像素点都由红,绿,蓝三个颜色组合而成,YCbCr或者是YUV则使用色彩(颜色)通道UV替换了像素的亮度通道.




    从上图中我们可以看到图片的细节都保存在亮度的通道中,假设世界上没有阳光,我们的眼睛是看不到任何的东西,如果去除亮度,剩下的就是一副灰度图片,我们在看整合的色彩通道中关于图片的所有细节都丢失了,这是由于我们眼睛对亮度的敏感度要高于颜色,所以,在YUV中,我们可以通过大幅减少存储在每个像素点中的颜色信息,而不致于图片的质量严重受损,这个减少颜色数据的过程就称之为色彩的二次采样。

    我们平时所说的4:4:4和4:2:2以及4:2:0到底指的是什么,以及它的由来?

            色彩的二次采样一般发生在取样时,一些专业的相机以4:4:4的参数捕捉图像,但大部分情况下对于图片的拍摄使用4:2:2的方式进行的,面向消费者的摄像头装置,比如iPhone手机上的摄像头,通常是以4:2:0的方式进行拍摄,即使经过大量层级的二次抽样之后仍然可以捕捉到高质量的图片,iPhone手机上拍出来的高质量视频就是很好的例证,

    1.RGB的颜色编码

            RGB 三个字⺟分别代表了 红(Red)、绿(Green)、蓝(Blue),这三种颜⾊称为 三原⾊,将它们以不同的⽐例相加,可以产⽣多种多样的颜⾊。


     在图像显示中,⼀张1280 * 720 ⼤⼩的图⽚,就代表着它有1280 * 720 个像素点。其中每⼀个像素点的颜⾊显示都采⽤RGB 编码⽅法,将RGB 分别取不同的值,就会展示不同的颜⾊。

            RGB 图像中,每个像素点都有红、绿、蓝三个原⾊,其中每种原⾊都占⽤8 bit,也就是⼀个字节,那么⼀个像素点也就占⽤24 bit,也就是三个字节。

            ⼀张1280 * 720 ⼤⼩的图⽚,就占⽤1280 * 720 * 3 / 1024 / 1024 = 2.63 MB 存储空间

    2.YUV的颜色编码

            YUV 颜⾊编码采⽤的是 明亮度 和 ⾊度 来指定像素的颜⾊。其中,Y 表示明亮度(Luminance、Luma),⽽U 和V 表示⾊度(Chrominance、Chroma)。⽽⾊度⼜定义了颜⾊的两个⽅⾯:⾊调和饱和度



      和RGB 表示图像类似,每个像素点都包含Y、U、V 分量。但是它的Y 和UV 分量是可以分离的,如果没有UV 分量⼀样可以显示完整的图像,只不过是⿊⽩的。对于YUV 图像来说,并不是每个像素点都需要包含了Y、U、V 三个分量,根据不同的采样格式,可以每个Y 分量都对应⾃⼰的UV 分量,也可以⼏个Y 分量共⽤UV 分量

    传说中的4:4:4

            在4:4:4的模式下,色彩的全部信息被保全下来,如图:




    相邻的四个像素点ABCD,每个像素点有自己的YUV,在色彩的二次采样的过程中,分别保留自己的YUV,称之为4:4:4;

    传说中的4:2:2


    如图ABCD四个相邻的像素点,A(Y0,U0,V0),B(Y1,U1,V1),C(Y2,U2,V2),D(Y3,U3,V3),当二次采样的时候,A采样的时候保留(Y0,U0),B保留(Y1,V1),C保留(Y2,U2),D保留(Y3,V3);也就是说,每个像素点的Y(明亮度)保留其本身的值,而U和V的值是每间隔一个采样,而最终就变成:





     也就是说A借B的V1,B借A的U0,C借D的V3,D借C的U2,这就是传说中的4:2:2,⼀张1280 * 720 ⼤⼩的图⽚,在YUV 4:2:2 采样时的⼤⼩为:

    (1280 * 720 * 8 + 1280 * 720 * 0.5 * 8 * 2)/ 8 / 1024 / 1024 = 1.76 MB 。

            可以看到YUV 4:2:2 采样的图像⽐RGB 模型图像节省了三分之⼀的存储空间,在传输时占⽤的带宽也会随之减少

    传说中的4:2:0

            在上面说到的4:2:2中我们可以看到相邻的两个像素点的UV是左右互相借的,那可不可以上下左右借了,答案当然是可以的,






    YUV 4:2:0 采样,并不是指只采样U 分量⽽不采样V 分量。⽽是指,在每⼀⾏扫描时,只扫描⼀种⾊度分量(U 或者V),和Y 分量按照2 : 1 的⽅式采样。⽐如,第⼀⾏扫描时,YU 按照2 : 1 的⽅式采样,那么第⼆⾏扫描时,YV 分量按照2:1 的⽅式采样。对于每个⾊度分量来说,它的⽔平⽅向和竖直⽅向的采样和Y 分量相⽐都是2:1 。假设第⼀⾏扫描了U 分量,第⼆⾏扫描了V 分量,那么需要扫描两⾏才能够组成完整的UV 分量

            从映射出的像素点中可以看到,四个Y 分量是共⽤了⼀套UV 分量,⽽且是按照2*2 的⼩⽅格的形式分布的,相⽐YUV 4:2:2 采样中两个Y 分量共⽤⼀套UV 分量,这样更能够节省空间。⼀张1280 * 720 ⼤⼩的图⽚,在YUV 4:2:0 采样时的⼤⼩为:

    (1280 * 720 * 8 + 1280 * 720 * 0.25 * 8 * 2)/ 8 / 1024 / 1024 = 1.32 MB 相对于2.63M节省了一半的空间

    RGB — YUV 颜⾊编码转换

            对于图像显示器来说,它是通过RGB 模型来显示图像的,⽽在传输图像数据时⼜是使⽤YUV 模型,这是因为YUV 模型可以节省带宽。因此就需要采集图像时将RGB 模型转换到YUV 模型,显示时再将YUV 模型转换为RGB 模型。

            RGB 到YUV 的转换,就是将图像所有像素点的R、G、B 分量转换到Y、U、V 分量。

            Y = 0.299 * R + 0.587 * G + 0.114 * B 

            U = -0.147 * R - 0.289 * G + 0.436 * B 

            V = 0.615 * R - 0.515 * G - 0.100 * B

            R = Y + 1.14 * V 

            G = Y - 0.39 * U - 0.58 * V 

            B = Y + 2.03 * U



    作者:枫紫_6174
    链接:https://www.jianshu.com/p/65cf8f073ee5


    收起阅读 »

    线程切换哪家强?RxJava与Flow的操作符对比

    Flow作为Coroutine版的RxJava,同RxJava一样可以方便地进行线程切换。 本文针对两者在多线程场景中的使用区别进行一个简单对比。 1. RxJava 我们先来回顾一下RxJava中的线程切换 如上,RxJava使用subscriberOn...
    继续阅读 »

    Flow作为Coroutine版的RxJava,同RxJava一样可以方便地进行线程切换。
    本文针对两者在多线程场景中的使用区别进行一个简单对比。


    1. RxJava




    我们先来回顾一下RxJava中的线程切换
    在这里插入图片描述


    如上,RxJava使用subscriberOnobserveOn进行线程切换


    subscribeOn


    subscribeOn用来决定在哪个线程进行订阅,对于Cold流来说即决定了数据的发射线程。使用中有两点注意:



    1. 当调用链上只有一个subscribeOn时,可以出现在任意位置


    在这里插入图片描述
    在这里插入图片描述


    上面两种写法效果是一样的:都是在io线程订阅后发射数据



    1. 当调用链上有多个subscribeOn时,只有第一个生效:


    在这里插入图片描述


    上面第二个subscribeOn没有意义


    observeOn


    observeOn用来决定在哪个线程上响应



    1. observeOn决定调用链上下游操作符执行的线程


    在这里插入图片描述


    上面绿线部分的代码将会运行在主线程



    1. subscribeOn不同,调用链上允许存在多个observeOn且每个都有效


    在这里插入图片描述


    上面蓝色绿色部分因为observeOn的存在分别切换到了不同线程执行


    just


    RxJava的初学者经常会犯的一个错误是在Observable.just(...)里做耗时任务。 just并不是接受lambda,所以是立即执行的,不受subscribeOn的影响


    在这里插入图片描述


    如上,loadDataSync()不会在io执行,


    想要在io执行,需要使用Observable.deffer{}


    在这里插入图片描述


    flatMap


    结合上面介绍的RxJava的线程切换,看下面这段代码


    在这里插入图片描述


    如果我们希望loadData(id)并发执行,那么上面的写法是错误的。


    subscribe(io())意味着其上游的数据在单一线程中串行发射。因此虽然flatMap{}返回多个Observable, 都是都在单一线程中订阅,多个loadData始终运行在同一线程。


    代码经过一下修改后,可以达到并发执行的效果:


    在这里插入图片描述


    当订阅flatMap返回的Observable时,通过subscribeOn分别指定订阅线程。


    其他类似flatMap这种涉及多个Observable订阅的操作符(例如mergezip等),需要留意各自的subscribeOn的线程,以防不符合预期的行为出现。


    2. Flow




    接下来看一下 Flow的线程切换 。


    Flow是基于CoroutineContext进行线程切换,所以这部分内容需要你对Croutine事先有基本的了解。


    在这里插入图片描述
    flowOn类似于RxJava的subscribeOn,Flow中没有对应observeOn的操作符,因为collect是一个suspend函数,必须在CoroutineScope中执行,所以响应线程是由CoroutineContext决定的。例如你在main中执行collect,那么响应线程就是Dispatcher.Main


    flowOn


    flowOn类似于subscribeOn,因为它们都可以用来决定上游线程
    在这里插入图片描述
    上面代码中,flowOn前面代码将会在IO执行。


    subscribeOn不同的是,flowOn允许出现多次,每个都会影响其前面的操作
    在这里插入图片描述
    上面代码,根据颜色可以看出来flowOn影响的范围


    launchIn


    collect是suspend函数,所以后续代码因为协程挂起不会继续执行
    在这里插入图片描述
    所以上面代码可能会不符合预期,因为第一个collect不走完第二个走不到。


    正确的写法是为每个collect单独起一个协程
    在这里插入图片描述
    或者使用launchIn,写法更加优雅
    在这里插入图片描述
    launchIn不会挂起协程,所以与RxJava的subscribe更加接近。


    通过名字可以感觉出来launchIn只不过是之前例子中launch的一个链式调用的语法糖。


    flowOf


    flowOf类似于Observable.just(),需要注意flowOf内的内容是立即执行的,不受flowOn影响
    在这里插入图片描述


    希望calculate()运行在IO,可以使用flow{ }


    在这里插入图片描述


    flatMapMerge


    flatMapMerge类似RxJava的flatMap
    在这里插入图片描述
    如上,2个item各自flatMap成2个item,即一共发射了4条数据,日志输出如下:


    inner: pool-2-thread-2 @coroutine#4
    inner: pool-2-thread-3 @coroutine#5
    inner: pool-2-thread-3 @coroutine#5
    inner: pool-2-thread-2 @coroutine#4
    collect: pool-1-thread-2 @coroutine#2
    collect: pool-1-thread-2 @coroutine#2
    collect: pool-1-thread-2 @coroutine#2
    collect: pool-1-thread-2 @coroutine#2
    复制代码

    通过日志我们发现flowOn虽然写在flatMapMerge外面,inner的日志却可以打印在多个线程上(都来自pool2线程池),这与flatMap是不同的,同样场景下flatMap只能运行在线程池的固定线程上。


    如果将flowOn写在flatMapMerge内部


    在这里插入图片描述


    结果如下:


    inner: pool-2-thread-2 @coroutine#6
    inner: pool-2-thread-1 @coroutine#7
    inner: pool-2-thread-2 @coroutine#6
    inner: pool-2-thread-1 @coroutine#7
    collect: pool-1-thread-3 @coroutine#2
    collect: pool-1-thread-3 @coroutine#2
    collect: pool-1-thread-3 @coroutine#2
    collect: pool-1-thread-3 @coroutine#2
    复制代码

    inner仍然打印在多个线程,flowOn无论写在flatMapMerge内部还是外部,对flatMapMerge内的处理没有区别。


    但是flatMapMerge之外还是有区别的,看下面两段代码
    在这里插入图片描述
    在这里插入图片描述


    通过颜色可以知道flowOn影响的范围,向上追溯到flowOf为止


    3. Summary




    RxJava的Observable与Coroutine的Flow都支持线程切换,相关API的对比如下:































    线程池调度线程操作符数据源同步创建异步创建并发执行
    RxJavaSchedulers (io(), computation(), mainThread())subscribeOn, observeOnjustdeffer{}flatMap(inner subscribeOn)
    FlowDispatchers (IO, Default, Main)flowOnflowOfflow{}flatMapMerge(inner or outer flowOn)

    最后通过一个例子看一下如何将代码从RxJava迁移到Flow


    RxJava


    RxJava代码如下:


    在这里插入图片描述


    使用到的Schedulers定义如下:
    在这里插入图片描述


    代码执行结果:


    1: pool-1-thread-1
    1: pool-1-thread-1
    1: pool-1-thread-1
    2: pool-3-thread-1
    2: pool-3-thread-1
    2: pool-3-thread-1
    inner 1: pool-4-thread-1
    inner 1: pool-4-thread-2
    inner 1: pool-4-thread-1
    inner 1: pool-4-thread-1
    inner 1: pool-4-thread-2
    inner 1: pool-4-thread-2
    inner 1: pool-4-thread-3
    inner 2: pool-5-thread-1
    inner 2: pool-5-thread-2
    3: pool-5-thread-1
    inner 2: pool-5-thread-2
    inner 1: pool-4-thread-3
    inner 2: pool-5-thread-2
    inner 2: pool-5-thread-3
    3: pool-5-thread-1
    3: pool-5-thread-1
    3: pool-5-thread-1
    end: pool-6-thread-1
    end: pool-6-thread-1
    inner 1: pool-4-thread-3
    end: pool-6-thread-1
    3: pool-5-thread-1
    inner 2: pool-5-thread-1
    3: pool-5-thread-1
    inner 2: pool-5-thread-3
    inner 2: pool-5-thread-1
    end: pool-6-thread-1
    3: pool-5-thread-3
    3: pool-5-thread-3
    end: pool-6-thread-1
    inner 2: pool-5-thread-3
    3: pool-5-thread-3
    end: pool-6-thread-1
    end: pool-6-thread-1
    end: pool-6-thread-1
    end: pool-6-thread-1
    复制代码

    代码较长,通过颜色标记法帮我们理清线程关系


    在这里插入图片描述


    上色后一目了然了,需要特别注意的是由于flatMap中切换了数据源的同时切换了线程,所以打印 3的线程不是s2 而是 s4


    Flow


    首相创建对应的Dispatcher


    在这里插入图片描述


    然后将代码换成Flow的写法,主要遵循下列原则



    • RxJava通过observeOn切换后续代码的线程

    • Flow通过flowOn切换前置代码的线程


    在这里插入图片描述


    打印结果如下:


    1: pool-1-thread-1 @coroutine#6
    1: pool-1-thread-1 @coroutine#6
    1: pool-1-thread-1 @coroutine#6
    2: pool-2-thread-2 @coroutine#5
    2: pool-2-thread-2 @coroutine#5
    2: pool-2-thread-2 @coroutine#5
    inner 1: pool-3-thread-1 @coroutine#10
    inner 1: pool-3-thread-2 @coroutine#11
    inner 1: pool-3-thread-3 @coroutine#12
    inner 1: pool-3-thread-2 @coroutine#11
    inner 1: pool-3-thread-3 @coroutine#12
    inner 2: pool-4-thread-3 @coroutine#9
    inner 1: pool-3-thread-1 @coroutine#10
    inner 1: pool-3-thread-3 @coroutine#12
    inner 1: pool-3-thread-2 @coroutine#11
    inner 2: pool-4-thread-1 @coroutine#7
    inner 2: pool-4-thread-2 @coroutine#8
    inner 2: pool-4-thread-1 @coroutine#7
    inner 2: pool-4-thread-3 @coroutine#9
    inner 1: pool-3-thread-1 @coroutine#10
    3: pool-4-thread-1 @coroutine#3
    inner 2: pool-4-thread-3 @coroutine#9
    inner 2: pool-4-thread-2 @coroutine#8
    end: pool-5-thread-1 @coroutine#2
    3: pool-4-thread-1 @coroutine#3
    inner 2: pool-4-thread-2 @coroutine#8
    3: pool-4-thread-1 @coroutine#3
    end: pool-5-thread-1 @coroutine#2
    3: pool-4-thread-1 @coroutine#3
    end: pool-5-thread-1 @coroutine#2
    end: pool-5-thread-1 @coroutine#2
    3: pool-4-thread-1 @coroutine#3
    3: pool-4-thread-1 @coroutine#3
    end: pool-5-thread-1 @coroutine#2
    end: pool-5-thread-1 @coroutine#2
    3: pool-4-thread-1 @coroutine#3
    3: pool-4-thread-1 @coroutine#3
    end: pool-5-thread-1 @coroutine#2
    end: pool-5-thread-1 @coroutine#2
    inner 2: pool-4-thread-1 @coroutine#7
    3: pool-4-thread-1 @coroutine#3
    end: pool-5-thread-1 @coroutine#2
    复制代码

    从日志可以看到,123的时序性以及inner1inner2的并发性与RxJava的一致。


    4. FIN




    Flow在线程切换方面可以完全取代RxJava的能力,而且将subscribeOnobserveOn两个操作符合二为一成flowOn,学习成本更低。随着flow的操作符种类日趋完善,未来在Android/Kotlin开发中可以跟RxJava说再见了👋🏻


    image.png


    作者:fundroid
    链接:https://juejin.cn/post/6943037393893064734
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    收起阅读 »

    用Jetpack Compose制作出可爱的天气动画

    1. 背景介绍 最近参加了Compose挑战赛的终极挑战,使用Compose完成了一个天气app。之前几轮挑战我也都有参与,每次都学到不少新东西,希望在这最后一轮挑战中,活用这段时间的积累做出更加成熟的作品。 项目挑战 因为没有美工协助,所以我考虑通过代码实...
    继续阅读 »

    1. 背景介绍




    最近参加了Compose挑战赛的终极挑战,使用Compose完成了一个天气app。之前几轮挑战我也都有参与,每次都学到不少新东西,希望在这最后一轮挑战中,活用这段时间的积累做出更加成熟的作品。


    项目挑战


    因为没有美工协助,所以我考虑通过代码实现app中的所有UI元素例如各种icon等,这样的UI在任何分辨率下都不会失真,而且可以更灵活地完成各种动画效果。


    为了降低实现成本,我将app中的UI元素定义成偏卡通的风格,更利于代码实现:
    在这里插入图片描述



    上面的动画没有使用giflottie等三方资源,所有效果都基于Compose代码绘制。



    MyApp:CuteWeather




    App界面比较简洁,采用单页面呈现(这也是挑战赛要求),可以查看近一周的天气信息和温度走势等。


    项目地址: github.com/vitaviva/co…


    在这里插入图片描述


    其中,卡通风格的天气动画算是这个app相对于同类应用的特色,本文将围绕这些天气动画介绍一下如何使用Compose绘制自定义图形、并基于这些图形实现动画。




    2. Compose自定义绘制




    像常规的Android开发一样,除了各种默认的Composable控件以外,Compose也提供了Canvas用来绘制自定义图形。


    Canvas相关的API在各个平台都大同小异,但在Compose上具有以下特点:



    • 用声明式的方式创建和使用Canvas

    • 通过DrawScope提供必要的state及各种APIs

    • API更简单易用


    声明式地创建和使用Canvas


    Compose中,Canvas作为Composable可以声明式地添加到其他Composable中,并通过Modifier进行配置


    Canvas(modifier = Modifier.fillMaxSize()){ // this: DrawScope 
    //内部进行自定义绘制
    }
    复制代码

    传统方式需要获取Canvas句柄命令式地进行绘制,而Canvas{...}通过状态驱动的方式执行block内的绘制逻辑,从而刷新UI。


    强大的DrawScope


    Canvas{...}通过DrawScope提供了一些当前绘制所需的state,例如经常使用到的size;DrawScope还提了各种常用的绘制API,例如drawLine


    Canvas(modifier = Modifier.fillMaxSize()){
    //通过size获取当前canvas的width和height
    val canvasWidth = size.width
    val canvasHeight = size.height

    //绘制直线
    drawLine(
    start = Offset(x=canvasWidth, y = 0f),
    end = Offset(x = 0f, y = canvasHeight),
    color = Color.Blue,
    strokeWidth = 5F //设置直线宽度
    )
    }
    复制代码

    上面代码绘制效果如下:


    在这里插入图片描述


    简单易用的API


    传统的Canvas API需要进行Paint的配置,而DrawScope的API则更简单、使用更友好。


    例如绘制一个圆,传统的API是这样:


    public void drawCircle(float cx, float cy, float radius, @NonNull Paint paint) {
    //...
    }
    复制代码

    DrawScope提供的API:


    fun drawCircle(
    color: Color,
    radius: Float = size.minDimension / 2.0f,
    center: Offset = this.center,
    alpha: Float = 1.0f,
    style: DrawStyle = Fill,
    colorFilter: ColorFilter? = null,
    blendMode: BlendMode = DefaultBlendMode
    ) {...}
    复制代码

    虽然看起来参数变多了,但是其实已经通过size等设置了合适的默认值,同时省去了Paint的创建和配置,使用起来更方便。


    使用原生Canvas


    目前DrawScope提供的API还不及原生Canvas丰富(比如不支持drawText等),当不满足使用需求时,也可以直接使用原生Canvas对象进行绘制


       drawIntoCanvas { canvas ->
    //nativeCanvas是原生canvas对象,android平台即android.graphics.Canvas
    val nativeCanvas = canvas.nativeCanvas

    }
    复制代码

    上面对Compose中的Canvas做了简单介绍,下面结合app中的具体示例看一下实际使用效果


    首先,看一下雨水的绘制过程。




    3. 雨天效果




    雨天天气的关键是如何绘制不断下落的雨水


    在这里插入图片描述


    雨滴的绘制


    我们先绘制构成雨水的基本单元:雨滴


    在这里插入图片描述


    经拆解后,雨水效果可由三组雨滴构成,每一组雨滴分成上下两段,这样在运动时可以形成接连不断的效果。


    我们使用drawLine绘制每一段黑线,设置适当的stokeWidth,并通过cap设置端点的圆形效果:


    @Composable
    fun rainDrop() {

    Canvas(modifier) {

    val x: Float = size.width / 2 //x坐标: 1/2的位置

    drawLine(
    Color.Black,
    Offset(x, line1y1), //line1 的起点
    Offset(x, line1y2), //line1 的终点
    strokeWidth = width, //设置宽度
    cap = StrokeCap.Round//头部圆形
    )

    // line2同上
    drawLine(
    Color.Black,
    Offset(x, line2y1),
    Offset(x, line2y2),
    strokeWidth = width,
    cap = StrokeCap.Round
    )
    }
    }
    复制代码

    雨滴下落动画


    完成雨滴的基本图形绘制后,接下来为两线段增加位移动画,形成流动的效果。


    在这里插入图片描述


    以两线段中间空隙为动画的锚点,根据animationState变动其y轴位置,从canvas的顶端移动到低端(0 ~ size.hight),然后restart这个动画。


    然后以锚点为基准绘制上下两线段,就行成接连不断的动画效果了


    在这里插入图片描述


    代码如下:


    @Composable
    fun rainDrop() {
    //循环播放的动画 ( 0f ~ 1f)
    val animateTween by rememberInfiniteTransition().animateFloat(
    initialValue = 0f,
    targetValue = 1f,
    animationSpec = infiniteRepeatable(
    tween(durationMillis, easing = LinearEasing),
    RepeatMode.Restart //start动画
    )
    )

    Canvas(modifier) {

    // scope : 绘制区域
    val width = size.width
    val x: Float = size.width / 2

    // width/2是strokCap的宽度,scopeHeight处预留strokCap宽度,让雨滴移出时保持正圆,提高视觉效果
    val scopeHeight = size.height - width / 2

    // space : 两线段的间隙
    val space = size.height / 2.2f + width / 2 //间隙size
    val spacePos = scopeHeight * animateTween //锚点位置随animationState变化
    val sy1 = spacePos - space / 2
    val sy2 = spacePos + space / 2

    // line length
    val lineHeight = scopeHeight - space

    // line1
    val line1y1 = max(0f, sy1 - lineHeight)
    val line1y2 = max(line1y1, sy1)

    // line2
    val line2y1 = min(sy2, scopeHeight)
    val line2y2 = min(line2y1 + lineHeight, scopeHeight)

    // draw
    drawLine(
    Color.Black,
    Offset(x, line1y1),
    Offset(x, line1y2),
    strokeWidth = width,
    colorFilter = ColorFilter.tint(
    Color.Black
    ),
    cap = StrokeCap.Round
    )

    drawLine(
    Color.Black,
    Offset(x, line2y1),
    Offset(x, line2y2),
    strokeWidth = width,
    colorFilter = ColorFilter.tint(
    Color.Black
    ),
    cap = StrokeCap.Round
    )
    }
    }

    复制代码

    Compose自定义布局


    完成了单个雨滴的动画,接下来我们使用三个雨滴组成雨水的效果。


    首先可以使用Row+Space的方式进行组装,但是这种方式缺少灵活性,仅通过Modifier很难准确布局三雨滴的相对位,因此考虑借助Compose的自定义布局,以提高灵活性和准确性:


    Layout(
    modifier = modifier.rotate(30f), //雨滴旋转角度
    content = { // 定义子Composable
    Raindrop(modifier.fillMaxSize())
    Raindrop(modifier.fillMaxSize())
    Raindrop(modifier.fillMaxSize())
    }
    ) { measurables, constraints ->
    // List of measured children
    val placeables = measurables.mapIndexed { index, measurable ->
    // Measure each children
    val height = when (index) { //让三个雨滴的height不同,增加错落感
    0 -> constraints.maxHeight * 0.8f
    1 -> constraints.maxHeight * 0.9f
    2 -> constraints.maxHeight * 0.6f
    else -> 0f
    }
    measurable.measure(
    constraints.copy(
    minWidth = 0,
    minHeight = 0,
    maxWidth = constraints.maxWidth / 10, // raindrop width
    maxHeight = height.toInt(),
    )
    )
    }

    // Set the size of the layout as big as it can
    layout(constraints.maxWidth, constraints.maxHeight) {
    var xPosition = constraints.maxWidth / ((placeables.size + 1) * 2)

    // Place children in the parent layout
    placeables.forEachIndexed { index, placeable ->
    // Position item on the screen
    placeable.place(x = xPosition, y = 0)

    // Record the y co-ord placed up to
    xPosition += (constraints.maxWidth / ((placeables.size + 1) * 0.8f)).roundToInt()
    }
    }
    }
    复制代码

    Compose中可以使用Layout{...}对Composable进行自定义布局,content{...}中定义参与布局的子Composable。


    跟传统Android视图一样,自定义布局需要先后经历measurelayout两步。



    • measruemeasurables返回所有待测量的子Composable,constraints类似于MeasureSpec,封装父容器对子元素的布局约束。measurable.measure()中对子元素进行测量

    • layoutplaceables返回测量后的子元素,依次调用placeable.place()对雨滴进行布局,通过xPosition预留雨滴在x轴的间隔


    经过layout之后,通过 modifier.rotate(30f) 对Composable进行旋转,完成最终效果:


    在这里插入图片描述




    4. 雪天效果




    雪天效果的关键在于雪花的飘落。


    在这里插入图片描述


    雪花的绘制


    雪花的绘制非常简单,用一个圆圈代表一个雪花


    Canvas(modifier) {

    val radius = size / 2

    drawCircle( //白色填充
    color = Color.White,
    radius = radius,
    style = FILL
    )

    drawCircle(// 黑色边框
    color = Color.Black,
    radius = radius,
    style = Stroke(width = radius * 0.5f)
    )
    }
    复制代码

    雪花飘落动画


    雪花飘落的过程相对于雨滴坠落要复杂一些,由三个动画组成:



    1. 下落:改变y轴坐标:0f ~ 2.5f

    2. 左右飘移:改变x轴的offset:-1f ~ 1f

    3. 逐渐消失:改变alpha:1f ~ 0f


    借助InfiniteTransition同步控制多个动画,代码如下:


    @Composable
    private fun Snowdrop(
    modifier: Modifier = Modifier,
    durationMillis: Int = 1000 // 雪花飘落动画的druation
    ) {

    //循环播放的Transition
    val transition = rememberInfiniteTransition()

    //1. 下降动画:restart动画
    val animateY by transition.animateFloat(
    initialValue = 0f,
    targetValue = 2.5f,
    animationSpec = infiniteRepeatable(
    tween(durationMillis, easing = LinearEasing),
    RepeatMode.Restart
    )
    )

    //2. 左右飘移:reverse动画
    val animateX by transition.animateFloat(
    initialValue = -1f,
    targetValue = 1f,
    animationSpec = infiniteRepeatable(
    tween(durationMillis / 3, easing = LinearEasing),
    RepeatMode.Reverse
    )
    )

    //3. alpha值:restart动画,以0f结束
    val animateAlpha by transition.animateFloat(
    initialValue = 1f,
    targetValue = 0f,
    animationSpec = infiniteRepeatable(
    tween(durationMillis, easing = FastOutSlowInEasing),
    )
    )

    Canvas(modifier) {

    val radius = size.width / 2

    // 圆心位置随AnimationState改变,实现雪花飘落的效果
    val _center = center.copy(
    x = center.x + center.x * animateX,
    y = center.y + center.y * animateY
    )

    drawCircle(
    color = Color.White.copy(alpha = animateAlpha),//alpha值的变化实现雪花消失效果
    center = _center,
    radius = radius,
    )

    drawCircle(
    color = Color.Black.copy(alpha = animateAlpha),
    center = _center,
    radius = radius,
    style = Stroke(width = radius * 0.5f)
    )
    }
    }
    复制代码

    animateYtargetValue设为2.5f是为了让雪花的运动轨迹更长,看起来更加真实


    雪花的自定义布局


    像雨滴一样,对雪花也使用Layout自定义布局


    @Composable
    fun Snow(
    modifier: Modifier = Modifier,
    animate: Boolean = false,
    ) {

    Layout(
    modifier = modifier,
    content = {
    //摆放三个雪花,分别设置不同duration,增加随机性
    Snowdrop( modifier.fillMaxSize(), 2200)
    Snowdrop( modifier.fillMaxSize(), 1600)
    Snowdrop( modifier.fillMaxSize(), 1800)
    }
    ) { measurables, constraints ->
    val placeables = measurables.mapIndexed { index, measurable ->
    val height = when (index) {
    // 雪花的height不同,也是为了增加随机性
    0 -> constraints.maxHeight * 0.6f
    1 -> constraints.maxHeight * 1.0f
    2 -> constraints.maxHeight * 0.7f
    else -> 0f
    }
    measurable.measure(
    constraints.copy(
    minWidth = 0,
    minHeight = 0,
    maxWidth = constraints.maxWidth / 5, // snowdrop width
    maxHeight = height.roundToInt(),
    )
    )
    }

    layout(constraints.maxWidth, constraints.maxHeight) {
    var xPosition = constraints.maxWidth / ((placeables.size + 1))

    placeables.forEachIndexed { index, placeable ->
    placeable.place(x = xPosition, y = -(constraints.maxHeight * 0.2).roundToInt())

    xPosition += (constraints.maxWidth / ((placeables.size + 1) * 0.9f)).roundToInt()
    }
    }
    }
    }
    复制代码

    最终效果如下:


    在这里插入图片描述




    5. 晴天效果




    通过一个旋转的太阳代表晴天效果


    在这里插入图片描述


    太阳的绘制


    太阳的图形由中心圆形和围绕圆环的等分线段组成。


    @Composable
    fun Sun(modifier: Modifier = Modifier) {

    Canvas(modifier) {

    val radius = size.width / 6
    val stroke = size.width / 20

    // draw circle
    drawCircle(
    color = Color.Black,
    radius = radius + stroke / 2,
    style = Stroke(width = stroke),
    )
    drawCircle(
    color = Color.White,
    radius = radius,
    style = Fill,
    )

    // draw line

    val lineLength = radius * 0.2f
    val lineOffset = radius * 1.8f
    (0..7).forEach { i ->

    val radians = Math.toRadians(i * 45.0)

    val offsetX = lineOffset * cos(radians).toFloat()
    val offsetY = lineOffset * sin(radians).toFloat()

    val x1 = size.width / 2 + offsetX
    val x2 = x1 + lineLength * cos(radians).toFloat()

    val y1 = size.height / 2 + offsetY
    val y2 = y1 + lineLength * sin(radians).toFloat()

    drawLine(
    color = Color.Black,
    start = Offset(x1, y1),
    end = Offset(x2, y2),
    strokeWidth = stroke,
    cap = StrokeCap.Round
    )
    }
    }
    }
    复制代码

    均分360度,每间隔45度画一条线段,cos计算x轴坐标,sin计算y轴坐标。


    太阳的旋转


    太阳的旋转动画很简单,通过Modifier.rotate不断转动Canvas即可。


    @Composable
    fun Sun(modifier: Modifier = Modifier) {

    //循环动画
    val animateTween by rememberInfiniteTransition().animateFloat(
    initialValue = 0f,
    targetValue = 360f,
    animationSpec = infiniteRepeatable(tween(5000), RepeatMode.Restart)
    )

    Canvas(modifier.rotate(animateTween)) {// 旋转动画

    val radius = size.width / 6
    val stroke = size.width / 20
    val centerOffset = Offset(size.width / 30, size.width / 30) //圆心偏移量

    // draw circle
    drawCircle(
    color = Color.Black,
    radius = radius + stroke / 2,
    style = Stroke(width = stroke),
    center = center + centerOffset //圆心偏移
    )

    //...略
    }
    }
    复制代码

    此外,DrawScope提供了rotate的API,也可以实现旋转效果。


    最后我们给太阳的圆心增加一个偏移量,让转动更加活泼:


    在这里插入图片描述




    6. 动画的组合、切换




    在实现了RainSnowSun等图形后,就可以使用这些图形组合成各种天气效果了。


    将图形组合成天气


    Compose的声明式语法非常有利于UI的组合:


    比如,多云转阵雨,我们摆放SunCloudRain等元素后,通过Modifier调整各自位置即可:


    @Composable
    fun CloudyRain(modifier: Modifier) {
    Box(modifier.size(200.dp)){
    Sun(Modifier.size(120.dp).offset(140.dp, 40.dp))
    Rain(Modifier.size(80.dp).offset(80.dp, 60.dp))
    Cloud(Modifier.align(Aligment.Center))
    }
    }
    复制代码

    让动画切换更加自然


    在这里插入图片描述


    当在多个天气动画之间进行切换时,我们希望能实现更自然的过渡。实现思路是将组成天气动画的各元素的Modifier配置变量化,然后通过Animation不断改变


    假设所有的天气都由CloudSunRain组成,无非就是offsetsizealpha值的不同:


    ComposeInfo


    data class IconInfo(
    val size: Float = 1f,
    val offset: Offset = Offset(0f, 0f),
    val alpha: Float = 1f,
    )
    复制代码

    //天气组合信息,即Sun、Cloud、Rain的位置信息
    data class ComposeInfo(
    val sun: IconInfo,
    val cloud: IconInfo,
    val rains: IconInfo,

    ) {
    operator fun times(float: Float): ComposeInfo =
    copy(
    sun = sun * float,
    cloud = cloud * float,
    rains = rains * float
    )

    operator fun minus(composeInfo: ComposeInfo): ComposeInfo =
    copy(
    sun = sun - composeInfo.sun,
    cloud = cloud - composeInfo.cloud,
    rains = rains - composeInfo.rains,
    )

    operator fun plus(composeInfo: ComposeInfo): ComposeInfo =
    copy(
    sun = sun + composeInfo.sun,
    cloud = cloud + composeInfo.cloud,
    rains = rains + composeInfo.rains,
    )
    }

    复制代码

    如上,ComposeInfo中持有各种元素的位置信息,运算符重载用于跟随Animation计算当前最新值。


    定义不同天气的ComposeInfo如下:


    //晴天
    val SunnyComposeInfo = ComposeInfo(
    sun = IconInfo(1f),
    cloud = IconInfo(0.8f, Offset(-0.1f, 0.1f), 0f),
    rains = IconInfo(0.4f, Offset(0.225f, 0.3f), 0f),
    )

    //多云
    val CloudyComposeInfo = ComposeInfo(
    sun = IconInfo(0.1f, Offset(0.75f, 0.2f), alpha = 0f),
    cloud = IconInfo(0.8f, Offset(0.1f, 0.1f)),
    rains = IconInfo(0.4f, Offset(0.225f, 0.3f), alpha = 0f),
    )

    //雨天
    val RainComposeInfo = ComposeInfo(
    sun = IconInfo(0.1f, Offset(0.75f, 0.2f), alpha = 0f),
    cloud = IconInfo(0.8f, Offset(0.1f, 0.1f)),
    rains = IconInfo(0.4f, Offset(0.225f, 0.3f), alpha = 1f),
    )

    复制代码

    ComposedIcon


    接着,定义ComposedIcon,消费ComposeInfo绘制天气组合的UI


    @Composable
    fun ComposedIcon(modifier: Modifier = Modifier, composeInfo: ComposeInfo) {

    //各元素的ComposeInfo
    val (sun, cloud, rains) = composeInfo

    Box(modifier) {

    //应用ComposeInfo到Modifier
    val _modifier = remember(Unit) {
    { icon: IconInfo ->
    Modifier
    .offset( icon.size * icon.offset.x, icon.size * icon.offset.y )
    .size(icon.size)
    .alpha(icon.alpha)
    }
    }

    Sun(_modifier(sun))
    Rains(_modifier(rains))
    AnimatableCloud(_modifier(cloud))
    }
    }
    复制代码

    ComposedWeather


    最后,定义ComposedWeather,通过动画更新当前的ComposedIcon


    @Composable
    fun ComposedWeather(modifier: Modifier, composedIcon: ComposedIcon) {

    val (cur, setCur) = remember { mutableStateOf(composedIcon) }
    var trigger by remember { mutableStateOf(0f) }

    DisposableEffect(composedIcon) {
    trigger = 1f
    onDispose { }
    }

    //创建动画(0f ~ 1f),用于更新ComposeInfo
    val animateFloat by animateFloatAsState(
    targetValue = trigger,
    animationSpec = tween(1000)
    ) {
    //当动画结束时,更新ComposeWeather到最新state
    setCur(composedIcon)
    trigger = 0f
    }

    //根据AnimationState计算当前ComposeInfo
    val composeInfo = remember(animateFloat) {
    cur.composedIcon + (weatherIcon.composedIcon - cur.composedIcon) * animateFloat
    }

    //使用最新的ComposeInfo显示Icon
    ComposedIcon(
    modifier,
    composeInfo
    )
    }
    复制代码

    到此,我们就实现了天气动画的自然过度了。



    作者:fundroid
    链接:https://juejin.cn/post/6944884453038620685
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    为Fragment换装ViewPager2

    1. 开启ViewPager2之旅距离ViewPager2正式版的发布已经一年多了,目前ViewPager早已停止更新,官方鼓励使用ViewPager2替代。 ViewPager2底层基于RecyclerView实现,因此可以获得RecyclerView带来的...
    继续阅读 »

    为Fragment换装ViewPager2

    1. 开启ViewPager2之旅

    image.png

    距离ViewPager2正式版的发布已经一年多了,目前ViewPager早已停止更新,官方鼓励使用ViewPager2替代。 ViewPager2底层基于RecyclerView实现,因此可以获得RecyclerView带来的诸多收益:

    • 抛弃传统的PagerAdapter,统一了Adapter的API
    • 通过LinearLayoutManager可以实现类似抖音的纵向滑动
    • 支持DiffUitl,可以实现局部刷新
    • 支持RTL(right-to-left),对于一些有出海需求的APP非常有用
    • 支持ItemDecorator

    2. ViewPager2 + Fragment

    跟ViewPager一样,除了View以外,ViewPager2更多的是配合Fragment使用,这需要借助于FragmentStateAdapter

    image.png

    接下来,本文简单介绍一下FragmentStateAdapter的使用及实现原理:

    首先在gradle中引入ViewPager2:

     implementation 'androidx.viewpager2:viewpager2:1.1.0'
    复制代码

    然后在xml中布局:

    <androidx.viewpager2.widget.ViewPager2
    android:id="@+id/doppelgangerViewPager"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

    复制代码

    FragmentStateAdapter

    import androidx.appcompat.app.AppCompatActivity
    import androidx.fragment.app.Fragment
    import androidx.viewpager2.adapter.FragmentStateAdapter

    class DoppelgangerAdapter(activity: AppCompatActivity, val doppelgangerList: List<DoppelgangerItem>) :
    FragmentStateAdapter(activity) {

    override fun getItemCount(): Int {
    return doppelgangerList.size
    }

    override fun createFragment(position: Int): Fragment {
    return DoppelgangerFragment.getInstance(doppelgangerList[position])
    }
    }
    复制代码

    FragmentStateAdapter的API跟旧的Adapter很相似:

    • getItemCount:返回Item的数量
    • createFragment:用来根据position创建fragment
    • DoppelgangerFragment:创建的具体Fragment类型

    MainActivity

    在Activity中为ViewPager2设置Adapter:

    val doppelgangerAdapter = DoppelgangerAdapter(this, doppelgangerList) 
    doppelgangerViewPager.adapter = doppelgangerAdapter
    复制代码

    在这里插入图片描述


    3. 揭秘FragmentStateAdapter的实现

    因为ViewPager2继承自RecyclerView,因此可以推断出FragmentStateAdapter继承自RecyclerView.Adapter

    public abstract class FragmentStateAdapter extends 
    RecyclerView.Adapter<FragmentViewHolder> implements StatefulAdapter {
    }
    复制代码

    虽说是继承关系,但两者的API却不一致,RecyclerView.Adapter关注的是ViewHolder的复用,而在FragmentStateAdapter中Framgent是不会复用的,即有多少个item就应该创建多少个Fragment,那么这其中是如何转换的呢?

    onCreateViewHolder

    通过FragmentStateAdapter声明中的泛型可以知道,ViewPager2之所以能够在RecyclerView的基础上对外屏蔽对ViewHolder的使用,其内部是借助FragmentViewHolder实现的。

    onCreateViewHolder中会创建一个FragmentViewHolder

    @NonNull
    @Override
    public final FragmentViewHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) {
    return FragmentViewHolder.create(parent);
    }
    复制代码

    FragmentViewHolder的主要作用是通过FrameLayout为Fragment提供用作容器的container:

    @NonNull static FragmentViewHolder create(@NonNull ViewGroup parent) {
    FrameLayout container = new FrameLayout(parent.getContext());
    container.setLayoutParams(
    new ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,
    ViewGroup.LayoutParams.MATCH_PARENT));
    container.setId(ViewCompat.generateViewId());
    container.setSaveEnabled(false);
    return new FragmentViewHolder(container);
    }
    复制代码

    onBindViewHolder

    @Override
    public final void onBindViewHolder(final @NonNull FragmentViewHolder holder, int position) {
    ...
    ensureFragment(position);
    ...
    gcFragments();
    }
    复制代码

    ensureFragment(position),其内部会最终回调用createFragment创建当前Fragment

       private void ensureFragment(int position) {
    long itemId = getItemId(position);
    if (!mFragments.containsKey(itemId)) {
    // TODO(133419201): check if a Fragment provided here is a new Fragment
    Fragment newFragment = createFragment(position);
    newFragment.setInitialSavedState(mSavedStates.get(itemId));
    mFragments.put(itemId, newFragment);
    }
    }
    复制代码

    mFragments缓存创建的Fragment,供后面placeFramentInViewholder使用; gcFragments回收已经不再使用的的Fragment(对应的item已经删除),节省内存开销。

    placeFragmentInViewHolder

      @Override
    public final void onViewAttachedToWindow(@NonNull final FragmentViewHolder holder) {
    placeFragmentInViewHolder(holder);
    gcFragments();
    }
    复制代码

    onViewAttachToWindow的时候调用placeFragmentInViewHolder,将FragmentViewHolder的container与当前Fragment绑定

        void placeFragmentInViewHolder(@NonNull final FragmentViewHolder holder) {
    Fragment fragment = mFragments.get(holder.getItemId());
    if (fragment == null) {
    throw new IllegalStateException("Design assumption violated.");
    }
    FrameLayout container = holder.getContainer();
    View view = fragment.getView();

    ...
    if (fragment.isAdded() && view.getParent() != null) {
    if (view.getParent() != container) {
    addViewToContainer(view, container);
    }
    return;
    }
    ...
    }
    复制代码

    void addViewToContainer(@NonNull View v, @NonNull FrameLayout container) {
    ...

    if (container.getChildCount() > 0) {
    container.removeAllViews();
    }

    if (v.getParent() != null) {
    ((ViewGroup) v.getParent()).removeView(v);
    }

    container.addView(v);
    }
    复制代码

    通过上面源码分析可以知道,虽然Fragment没有被复用,但是通过复用了ViewHolder的container实现了Framgent的交替显示


    4. 滑动监听

    监听页面滑动是一个常见需求,ViewPager2的API也发生了变化,使用OnPageChangeCallback

    image.png

    使用效果如下:

    var doppelgangerPageChangeCallback = object : ViewPager2.OnPageChangeCallback() {
    override fun onPageSelected(position: Int) {
    Toast.makeText(this@MainActivity, "Selected position: ${position}",
    Toast.LENGTH_SHORT).show()
    }
    }
    复制代码

    OnPageChangeCallback同样也有三个方法:

    • onPageScrolled: 当前页面开始滑动时
    • onPageSelected: 当页面被选中时
    • onPageScrollStateChanged: 当前页面滑动状态变动时

    在这里插入图片描述


    5. 纵向滑动

    设置纵向滑动很简单,一行代码搞定

    doppelgangerViewPager.orientation = ViewPager2.ORIENTATION_VERTICAL
    复制代码

    在这里插入图片描述

    源码也很简单

    /**
    * Sets the orientation of the ViewPager2.
    *
    * @param orientation {@link #ORIENTATION_HORIZONTAL} or {@link #ORIENTATION_VERTICAL}
    */

    public void setOrientation(@Orientation int orientation) {
    mLayoutManager.setOrientation(orientation);
    mAccessibilityProvider.onSetOrientation();
    }
    复制代码

    6. TabLayout


    配合TabLayout的使用也是一个常见需求,TabLayout需要引入material

    implementation 'com.google.android.material:material:1.2.0-alpha04'
    复制代码

    然后在xml中声明

    <com.google.android.material.tabs.TabLayout
    android:id="@+id/tabLayout"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:background="@color/colorPrimary"
    app:tabMode="scrollable"
    app:tabTextColor="@android:color/white" />

    复制代码

    TabsLayoutMediator

    要关联TabLayout和ViewPager2需要借助TabLayoutMediator

    public TabLayoutMediator(
    @NonNull TabLayout tabLayout,
    @NonNull ViewPager2 viewPager,
    @NonNull TabConfigurationStrategy tabConfigurationStrategy)
    {
    this(tabLayout, viewPager, true, tabConfigurationStrategy);
    }
    复制代码

    其中,TabConfigurationStrategy定义如下:根据position配置当前tab

    /**
    * A callback interface that must be implemented to set the text and styling of newly created
    * tabs.
    */

    public interface TabConfigurationStrategy {
    /**
    * Called to configure the tab for the page at the specified position. Typically calls {@link
    * TabLayout.Tab#setText(CharSequence)}, but any form of styling can be applied.
    *
    * @param tab The Tab which should be configured to represent the title of the item at the given
    * position in the data set.
    * @param position The position of the item within the adapter's data set.
    */

    void onConfigureTab(@NonNull TabLayout.Tab tab, int position);
    }
    复制代码

    在MainActivity中具体使用如下:

    TabLayoutMediator(tabLayout, doppelgangerViewPager) { tab, position ->
    //To get the first name of doppelganger celebrities
    tab.text = doppelgangerList[position].title
    }.attach()
    复制代码

    attach方法很关键,经过前面一系列配置后最终需要通过它关联两个组件。

    加入TabLayout后的最终效果如下:

    在这里插入图片描述


    7. DiffUtil 局部更新

    RecyclerView基于DiffUtil可以实现局部更新,如今,FragmentStateAdapter也可以对Fragment实现局部更新。

    首先定义DiffUtil.Callback

    class PagerDiffUtil(private val oldList: List<DoppelgangerItem>, private val newList: List<DoppelgangerItem>) : DiffUtil.Callback() {

    enum class PayloadKey {
    VALUE
    }

    override fun getOldListSize() = oldList.size

    override fun getNewListSize() = newList.size

    override fun areItemsTheSame(oldItemPosition: Int, newItemPosition: Int): Boolean {
    return oldList[oldItemPosition].id == newList[newItemPosition].id
    }

    override fun areContentsTheSame(oldItemPosition: Int, newItemPosition: Int): Boolean {
    return oldList[oldItemPosition].value == newList[newItemPosition].value
    }

    override fun getChangePayload(oldItemPosition: Int, newItemPosition: Int): Any? {
    return listOf(PayloadKey.VALUE)
    }
    }
    复制代码

    然后在Adapter中使用DiffUtil更新数据


    class DoppelgangerAdapter(private val activity: FragmentActivity) : FragmentStateAdapter(activity) {

    private val items: ArrayList<DoppelgangerItem> = arrayListOf()


    override fun createFragment(position: Int): Fragment {
    return DoppelgangerFragment.getInstance(doppelgangerList[position])
    }

    override fun getItemCount() = items.size

    override fun getItemId(position: Int): Long {
    return items[position].id.toLong()
    }

    override fun containsItem(itemId: Long): Boolean {
    return items.any { it.id.toLong() == itemId }
    }

    fun setItems(newItems: List<PagerItem>) {
    //不借助DiffUtil更新数据
    //items.clear()
    //items.addAll(newItems)
    //notifyDataSetChanged()

    //使用DiffUtil更新数据
    val callback = PagerDiffUtil(items, newItems)
    val diff = DiffUtil.calculateDiff(callback)
    items.clear()
    items.addAll(newItems)
    diff.dispatchUpdatesTo(this)
    }
    }
    复制代码

    8. 总结

    本文主要介绍了ViewPager2配合Fragment的使用方法以及FragmentStateAdapter的实现原理,顺带介绍了TabLayoutOnPageChangeCallbackDiffUtil等常见功能的用法。ViewPager2的使用非常简单,在性能以及使用体验等各方面都要优于传统的ViewPager,没尝试的小伙伴抓紧用起来吧~

    收起阅读 »

    一道面试题:ViewModel为什么横竖屏切换时不销毁?

    又到金三银四 往年面试中有关Jetpack的考察可以算是加分项,随着官方对Modern Android development (MAD) 的大力推广,今年基本上都是必选题了。 很多候选人对Jetpack各组件的功能及用法如数家珍,但一问及到原理往往卡壳。原理...
    继续阅读 »

    又到金三银四


    往年面试中有关Jetpack的考察可以算是加分项,随着官方对Modern Android development (MAD) 的大力推广,今年基本上都是必选题了。


    很多候选人对Jetpack各组件的功能及用法如数家珍,但一问及到原理往往卡壳。原理不清虽不影响API的使用,但也正因为如此,如果能对源码有一定了解,也许可以脱颖而出得到加分。


    本文分享一个入门级的源码分析,也是在面试中经常被问到的问题




    # ViewModel


    ViewModel是Android Jetpack中的重要组件,其优势是具有下图这样的生命周期、不会因为屏幕旋转等Activity配置变化而销毁,是实现MVVM架构中UI状态管理的重要基础。
    在这里插入图片描述


    class MyActivity : AppCompatActivity {

    override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    Log.d(TAG, "onCreate")

    val activity: FragmentActivity = this
    val factory: ViewModelProvider.Factory = ViewModelProvider.NewInstanceFactory()

    // Activity由于横竖品切换销毁重建,此处的viewModel 仍然是重建前的实例
    val viewModel = ViewModelProvider(activity, factory).get(MyViewModel::class.java)
    // 如果直接new实例则会创建新的ViewModel实例
    // val viewModel = MyViewModel()

    Log.d(TAG, " - Activity :${this.hashCode()}")
    Log.d(TAG, " - ViewModel:${viewModel.hashCode()}")
    }
    }
    复制代码

    上面代码在横竖屏切换时的log如下:


    #Activity初次启动
    onCreate
    - Activity :132818886
    - ViewModel:249530701
    onStart
    onResume

    #屏幕旋转
    onPause
    onStop
    onRetainNonConfigurationInstance
    onDestroy
    onCreate
    - Activity :103312713 #Activity实例不同
    - ViewModel:249530701 #ViewModel实例相同
    onStart
    onResume
    复制代码

    下面代码是保证屏幕切换时ViewModel不销毁的关键,我们依次为入口看一下源码


    val viewModel = ViewModelProvider(activity, factory).get(MyViewModel::class.java)
    复制代码



    # ViewModelProvider


    ViewModelProvider源码很简单,分别持有一个ViewModelProvider.FactoryViewModelStore实例


    package androidx.lifecycle;

    public class ViewModelProvider {

    public interface Factory {
    @NonNull
    <T extends ViewModel> T create(@NonNull Class<T> modelClass);
    }

    private final Factory mFactory;
    private final ViewModelStore mViewModelStore;

    public ViewModelProvider(@NonNull ViewModelStoreOwner owner, @NonNull Factory factory) {
    this(owner.getViewModelStore(), factory);
    }

    public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {
    mFactory = factory;
    this.mViewModelStore = store;
    }

    ...
    }
    复制代码

    get()返回ViewModel实例


    package androidx.lifecycle;

    public class ViewModelProvider {
    ...

    public <T extends ViewModel> T get(@NonNull Class<T> modelClass) {
    String canonicalName = modelClass.getCanonicalName();

    ...

    return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
    }

    public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) {
    ViewModel viewModel = mViewModelStore.get(key);

    if (modelClass.isInstance(viewModel)) {
    //noinspection unchecked
    return (T) viewModel;
    } else {
    //noinspection StatementWithEmptyBody
    if (viewModel != null) {
    // TODO: log a warning.
    }
    }

    viewModel = mFactory.create(modelClass);
    mViewModelStore.put(key, viewModel);
    //noinspection unchecked
    return (T) viewModel;
    }

    ...
    }
    复制代码

    逻辑非常清晰:



    1. ViewModelProvider通过ViewModelStore获取ViewModel

    2. 若获取失败,则通过ViewModelProvider.Factory创建ViewModel




    # ViewModelStore


    package androidx.lifecycle;

    public class ViewModelStore {

    private final HashMap<String, ViewModel> mMap = new HashMap<>();

    final void put(String key, ViewModel viewModel) {
    ViewModel oldViewModel = mMap.put(key, viewModel);
    if (oldViewModel != null) {
    oldViewModel.onCleared();
    }
    }

    final ViewModel get(String key) {
    return mMap.get(key);
    }

    public final void clear() {
    for (ViewModel vm : mMap.values()) {
    vm.onCleared();
    }
    mMap.clear();
    }
    }
    复制代码

    可见,ViewModelStore就是一个对Map的封装。


    val viewModel = ViewModelProvider(activity, factory).get(FooViewModel::class.java)
    复制代码

    上面代码ViewModelProvider()构造参数1中传入的FragmentActivity(基类是ComponentActivity)实际上是ViewModelStoreOwner的一个实现。


    package androidx.lifecycle;

    public interface ViewModelStoreOwner {
    @NonNull
    ViewModelStore getViewModelStore();
    }
    复制代码

    ViewModelProvider中的ViewModelStore正是来自ViewModelStoreOwner。


    public class ViewModelProvider {

    private final ViewModelStore mViewModelStore;

    public ViewModelProvider(@NonNull ViewModelStoreOwner owner, @NonNull Factory factory) {
    this(owner.getViewModelStore(), factory);
    }

    public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {
    this.mViewModelStore = store;
    }
    复制代码

    Activity在onDestroy会尝试对ViewModelStore清空。如果是由于ConfigurationChanged带来的Destroy则不进行清空,避免横竖屏切换等造成ViewModel销毁。


    //ComponentActivity.java
    getLifecycle().addObserver(new LifecycleEventObserver() {
    @Override
    public void onStateChanged(@NonNull LifecycleOwner source,
    @NonNull Lifecycle.Event event) {
    if (event == Lifecycle.Event.ON_DESTROY) {
    // Clear out the available context
    mContextAwareHelper.clearAvailableContext();
    // And clear the ViewModelStore
    if (!getLifecycle().addObserver(new LifecycleEventObserver() {
    @Override
    public void onStateChanged(@NonNull LifecycleOwner source,
    @NonNull Lifecycle.Event event) {
    if (event == Lifecycle.Event.ON_DESTROY) {
    // Clear out the available context
    mContextAwareHelper.clearAvailableContext();
    // And clear the ViewModelStore
    if (!isChangingConfigurations()) {
    getViewModelStore().clear();
    }
    }
    }
    });()) {
    getViewModelStore().clear();
    }
    }
    }
    });
    复制代码



    # FragmentActivity#getViewModelStore()


    FragmentActivity实现了ViewModelStoreOwnergetViewModelStore方法


    package androidx.fragment.app;

    public class FragmentActivity extends ComponentActivity implements ViewModelStoreOwner ... {

    private ViewModelStore mViewModelStore;

    @NonNull
    @Override
    public ViewModelStore getViewModelStore() {
    ...

    if (mViewModelStore == null) {
    NonConfigurationInstances nc =
    (NonConfigurationInstances) getLastNonConfigurationInstance();
    if (nc != null) {
    // Restore the ViewModelStore from NonConfigurationInstances
    mViewModelStore = nc.viewModelStore;
    }
    if (mViewModelStore == null) {
    mViewModelStore = new ViewModelStore();
    }
    }
    return mViewModelStore;
    }

    static final class NonConfigurationInstances {
    Object custom;
    ViewModelStore viewModelStore;
    FragmentManagerNonConfig fragments;
    }

    ...
    }
    复制代码

    通过getLastNonConfigurationInstance() 获取 NonConfigurationInstances 实例,从而得到真正的viewModelStoregetLastNonConfigurationInstance()又是什么?


    # Activity#getLastNonConfigurationInstance()


    package android.app;

    public class Activity extends ContextThemeWrapper implements ... {

    /* package */ NonConfigurationInstances mLastNonConfigurationInstances;

    @Nullable
    public Object getLastNonConfigurationInstance() {
    return mLastNonConfigurationInstances != null
    ? mLastNonConfigurationInstances.activity : null;
    }
    复制代码


    Retrieve the non-configuration instance data that was previously returned by onRetainNonConfigurationInstance(). This will be available from the initial onCreate(Bundle) and onStart() calls to the new instance, allowing you to extract any useful dynamic state from the previous instance.



    通过官方文档我们知道,屏幕旋转前通过onRetainNonConfigurationInstance()返回的Activity实例,屏幕旋转后可以通过getLastNonConfigurationInstance()获取,因此屏幕旋转前后不销毁的关键就在onRetainNonConfigurationInstance




    # Activity#onRetainNonConfigurationInstance()


    #Activity初次启动
    onCreate
    - Activity :132818886
    - ViewModel:249530701
    onStart
    onResume

    #屏幕旋转
    onPause
    onStop
    onRetainNonConfigurationInstance
    onDestroy
    onCreate
    - Activity :103312713 #Activity实例不同
    - ViewModel:249530701 #ViewModel实例相同
    onStart
    onResume
    复制代码

    屏幕旋转时,onRetainNonConfigurationInstance()onStoponDestroy之间调用


    package android.app;

    public class Activity extends ContextThemeWrapper implements ... {

    public Object onRetainNonConfigurationInstance() {
    return null;
    }

    ...
    }
    复制代码

    onRetainNonConfigurationInstance在Activity中只有空实现,在FragmentActivity中被重写


    package androidx.fragment.app;

    public class FragmentActivity extends ComponentActivity implements ViewModelStoreOwner, ... {

    @Override
    public final Object onRetainNonConfigurationInstance() {
    Object custom = onRetainCustomNonConfigurationInstance();

    FragmentManagerNonConfig fragments = mFragments.retainNestedNonConfig();

    if (fragments == null && mViewModelStore == null && custom == null) {
    return null;
    }

    NonConfigurationInstances nci = new NonConfigurationInstances();
    nci.custom = custom;
    nci.viewModelStore = mViewModelStore;
    nci.fragments = fragments;
    return nci;
    }

    static final class NonConfigurationInstances {
    Object custom;
    ViewModelStore viewModelStore;
    FragmentManagerNonConfig fragments;
    }

    ...
    }
    复制代码

    FragmentActivity 通过 onRetainNonConfigurationInstance() 返回 了存放ViewModelStore的NonConfigurationInstances 实例。
    值得一提的是onRetainNonConfigurationInstance提供了一个hook时机:onRetainCustomNonConfigurationInstance,允许我们像ViewModel一样使得自定义对象不被销毁


    NonConfigurationInstances会在attach中由系统传递给新重建的Activity:


    final void attach(Context context, ActivityThread aThread,
    Instrumentation instr, IBinder token, int ident,
    Application application, Intent intent, ActivityInfo info,
    CharSequence title, Activity parent, String id,
    NonConfigurationInstances lastNonConfigurationInstances,
    Configuration config, String referrer, IVoiceInteractor voiceInteractor,
    Window window, ActivityConfigCallback activityConfigCallback, IBinder assistToken)

    复制代码

    然后在onCreate中,通过getLastNonConfigurationInstance()获取NonConfigurationInstances中的ViewModelStore


    package androidx.fragment.app;

    public class FragmentActivity extends ComponentActivity implements ViewModelStoreOwner ... {

    private ViewModelStore mViewModelStore;

    @SuppressWarnings("deprecation")
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
    mFragments.attachHost(null /*parent*/);

    super.onCreate(savedInstanceState);

    NonConfigurationInstances nc =
    (NonConfigurationInstances) getLastNonConfigurationInstance();
    if (nc != null && nc.viewModelStore != null && mViewModelStore == null) {
    mViewModelStore = nc.viewModelStore;
    }
    ...
    }
    }
    复制代码



    # 总结


    Activity首次启动



    • FragmentActivity#onCreate()被调用

      • 此时 FragmentActivity 的 mViewModelStore 尚为 null



    • HogeActivity的onCreate() 被调用

      • ViewModelProvider 实例创建

      • FragmentActivity#getViewModelStore() 被调用,mViewModelStore被创建并赋值




    发生屏幕旋转



    • FragmentActivity#onRetainNonConfigurationInstance() 被调用

      • 持有mViewModelStore 的NonConfigurationInstances 实例被返回




    Activity重建



    • FragmentActivity#onCreate() 被调用

      • 从Activity#getLastNonConfigurationInstance() 获取 NonConfigurationInstances 实例

      • NonConfigurationInstances 中保存了屏幕旋转前的 FragmentActivity 的 mViewModelStore,将其赋值给重建后的FragmentActivity 的 mViewModelStore



    • HogeActivity#onCreate() 被调用

      • 通过ViewModelProvider#get() 获取 ViewModel 实例




    收起阅读 »

    android 逆向工程-工具篇 jadx(九)

    Android逆向工程篇:android 逆向工程-工具篇 drozer(一)android 逆向工程-工具篇 apktool(二)android 逆向工程-语言篇 Smali(三)android 逆向工程-分析篇 漏洞与风险(四)android 逆向工程-工...
    继续阅读 »

    Android逆向工程篇:


    Jadx Github

    下载地址:https://github.com/skylot/jadx


    使用 jadx

    双击 jadx-gui运行起来,直接打开  apk、dex、jar、zip、class、aar 文件。

    搜索功能

    点击 Navigation -> Text Search 或 Navigation -> Class Search 

    Class、Method、Field、Code四种类型搜索


    搜索引用的代码


    deobfuscation

    Tools -> deobfusation 方便我们识别和搜索,以免被混淆后的代码绕晕。

    一键导出 Gradle 

    主要是为了借助 AS 强大的 IDE 功能,例如方法跳转、引用搜索等等,阅读更方便。

    收起阅读 »

    android 逆向工程-技术篇 Android studio动态调试(八)

    Android逆向工程篇:android 逆向工程-工具篇 drozer(一)android 逆向工程-工具篇 apktool(二)android 逆向工程-语言篇 Smali(三)android 逆向工程-分析篇 漏洞与风险(四)android 逆向工程-工...
    继续阅读 »

    Android逆向工程篇:


    一、下载插件smalidea

    地址: https://bitbucket.org/JesusFreke/smali/downloads    下载smalidea-0.03.zip


    二、反编译APK

    java -jar apktool.jar d -f F:\apktools\demo.apk -o F:\apktools\demo


    三、添加DUBUG属性

    在AndroidManifest.xml的application添加属性:android:debuggable="true"


    四、安装修改后的应用


    1、安装上面重新签名得到的apk应用

    2、创建目录Smali/src,并且把smali反编译出的文件放到该目录下


    五、调试启动应用

    adb shell am start -D -n app.mm.demo/.demoActivity
    adb shell  ps | grep demo 查看应用pid  24551
    然后进行端口转发:
    adb forward tcp:8700 jdwp:24551
    注意:如果不允许建立则输入netstat -ano查看进程
    kill了8700进程就好了


    六、用Android studio打开smali文件

    配置如下


    end

    Run->Debug,开始动态调试

    收起阅读 »

    android 逆向工程-工具篇 IDA pro入门(七)

    Android逆向工程篇:android 逆向工程-工具篇 drozer(一)android 逆向工程-工具篇 apktool(二)android 逆向工程-语言篇 Smali(三)android 逆向工程-分析篇 漏洞与风险(四)android 逆向工程-工...
    继续阅读 »

    Android逆向工程篇:


    注:自行网上下载IDA pro

    我安装好的IDA 包含64和32两个版本,经测试 32位支持伪代码,可以F5对照C语言等进行更方便的分析。

    用IDA pro打开一个so文件


    展示如下(F5查看伪代码)


    • IDA View-A是反汇编窗口
    • HexView-A是十六进制格式显示的窗口
    • Imports是导入表(程序中调用到的外面的函数)
    • Functions是函数表(这个程序中的函数)
    • Structures是结构
    • Enums是枚举

    IDA View-A

    这里会有流程图(按回车进行切换),判断是执行绿色,判断否执行红色,蓝色为一个执行块。

    分析

    先展示些ARM汇编的基础

    寄存器

    • R0-R3:用于函数参数及返回值的传递
    • R4-R6, R8,R10-R11:没有特殊规定,就是普通的通用寄存器
    • R7:栈帧指针(Frame Pointer).指向前一个保存的栈帧(stack frame)和链接寄存器(link register, lr)在栈上的地址。
    • R9:操作系统保留
    • R12:又叫IP(intra-procedure scratch)
    • R13:又叫SP(stack pointer),是栈顶指针
    • R14:又叫LR(link register),存放函数的返回地址。
    • R15:又叫PC(program counter),指向当前指令地址。
    • CPSR:当前程序状态寄存器(Current Program State Register),在用户状态下存放像condition标志中断禁用等标志的。
    • VFP:(向量浮点运算)相关的寄存器

    基本的指令

    • add 加指令
    • sub 减指令
    • str 把寄存器内容存到栈上去
    • ldr 把栈上内容载入一寄存器中
    • .w是一个可选的指令宽度说明符。它不会影响为此指令的行为,它只是确保生成 32 位指令。
    • bl 执行函数调用,并把使lr指向调用者(caller)的下一条指令,即函数的返回地址
    • blx 同上,但是在ARM和thumb指令集间切换。
    • bx bx lr返回调用函数(caller)。
    • bne 数据跳转指令,标志寄存器中Z标志位不等于零时, 跳转到BNE后标签处。
    • CMP 比较命令
    • B 无条件跳转
    收起阅读 »

    android 逆向工程-开发篇 apk加固(六)

    Android逆向工程篇:android 逆向工程-工具篇 drozer(一)android 逆向工程-工具篇 apktool(二)android 逆向工程-语言篇 Smali(三)android 逆向工程-分析篇 漏洞与风险(四)android 逆向工程-工...
    继续阅读 »

    Android逆向工程篇:

    注:参考 https://blog.csdn.net/jiangwei0910410003/article/details/48415225

    加密工具:https://github.com/dileber/DexShellTools/tree/master

    壳程序Apk:https://github.com/dileber/ReforceApk/tree/master

    加固原理

    一句话:通过修改壳apk中的dex文件,把需要加壳的apk通过二进制形式,来加密到壳apk中,运行时进行解密操作。

    加壳重点(其余的参考注释的文章):

    加壳时需要了解dex文件头部

    加壳后的dex文件需要替换壳的dex文件

    加壳后的apk需要对其重新签名:

    jarsigner -verbose -keystore 签名文件 -storepass 密码  -keypass alias的密码 -sigfile CERT -digestalg SHA1 -sigalg MD5withRSA  签名后的文件 签名前的apk alias名称

    eg:
    jarsigner -verbose -keystore forceapk -storepass 123456 -keypass 123456 -sigfile CERT -digestalg SHA1 -sigalg MD5withRSA -signedjar ReforceApk_des.apk ReforceApk_src.apk jiangwei

    签名文件的密码:123456
    alais的密码:123456


    收起阅读 »

    android 逆向工程-工具篇 dex2jar jd-gui(五)

    Android逆向工程篇: android 逆向工程-工具篇 drozer(一) android 逆向工程-工具篇 apktool(二) android 逆向工程-语言篇 Smali(三) android 逆向工程-分析篇 漏洞与风险(四) android ...
    继续阅读 »

    Android逆向工程篇:



    获取classes.dex文件:


    使用压缩软件打开apk,把目录下的classes.dex文件解压出来


    下载dex2jar,并解压到目录下。


    在cmd中运行




    d2j-dex2jar.bat classes.dex


    于是在dex2jar目录下产生了一个classes.jar


    下载 jd-gui 官网地址


    直接下载win版打开 jar文件


    收起阅读 »

    java设计模式:状态模式

    定义对有状态的对象,把复杂的“判断逻辑”提取到不同的状态对象中,允许状态对象在其内部状态发生改变时改变其行为。优点结构清晰,状态模式将与特定状态相关的行为局部化到一个状态中,并且将不同状态的行为分割开来,满足“单一职责原则”。将状态转换显示化,减少对象间的相互...
    继续阅读 »

    定义

    对有状态的对象,把复杂的“判断逻辑”提取到不同的状态对象中,允许状态对象在其内部状态发生改变时改变其行为。

    优点

    1. 结构清晰,状态模式将与特定状态相关的行为局部化到一个状态中,并且将不同状态的行为分割开来,满足“单一职责原则”。
    2. 将状态转换显示化,减少对象间的相互依赖。将不同的状态引入独立的对象中会使得状态转换变得更加明确,且减少对象间的相互依赖。
    3. 状态类职责明确,有利于程序的扩展。通过定义新的子类很容易地增加新的状态和转换。

    缺点

    1. 状态模式的使用必然会增加系统的类与对象的个数。
    2. 状态模式的结构与实现都较为复杂,如果使用不当会导致程序结构和代码的混乱。
    3. 状态模式对开闭原则的支持并不太好,对于可以切换状态的状态模式,增加新的状态类需要修改那些负责状态转换的源码,否则无法切换到新增状态,而且修改某个状态类的行为也需要修改对应类的源码。

    代码实现

    状态模式包含以下主要角色。

    1. 环境类:也称为上下文,它定义了客户端需要的接口,内部维护一个当前状态,并负责具体状态的切换。
    2. 抽象状态:定义一个接口,用以封装环境对象中的特定状态所对应的行为,可以有一个或多个行为。
    3. 具体状态:实现抽象状态所对应的行为,并且在需要的情况下进行状态切换。
    状态模式中,行为是由状态来决定的,不同状态下有不同行为。

    举个例子把,比如电视,电视有2个状态,一个是开机,一个是关机,开机时可以切换频道,关机时切换频道不做任何响应。
    public interface TvState{
    public void nextChannerl();
    public void prevChannerl();
    public void turnUp();
    public void turnDown();
    }

    public class PowerOffState implements TvState{
    public void nextChannel(){}
    public void prevChannel(){}
    public void turnUp(){}
    public void turnDown(){}

    }


    public class PowerOnState implements TvState{
    public void nextChannel(){
    System.out.println("下一频道");
    }
    public void prevChannel(){
    System.out.println("上一频道");
    }
    public void turnUp(){
    System.out.println("调高音量");
    }
    public void turnDown(){
    System.out.println("调低音量");
    }

    }

    public interface PowerController{
    public void powerOn();
    public void powerOff();
    }

    public class TvController implements PowerController{
    TvState mTvState;
    public void setTvState(TvStete tvState){
    mTvState=tvState;
    }
    public void powerOn(){
    setTvState(new PowerOnState());
    System.out.println("开机啦");
    }
    public void powerOff(){
    setTvState(new PowerOffState());
    System.out.println("关机啦");
    }
    public void nextChannel(){
    mTvState.nextChannel();
    }
    public void prevChannel(){
    mTvState.prevChannel();
    }
    public void turnUp(){
    mTvState.turnUp();
    }
    public void turnDown(){
    mTvState.turnDown();
    }

    }


    public class Client{
    public static void main(String[] args){
    TvController tvController=new TvController();
    tvController.powerOn();
    tvController.nextChannel();
    tvController.turnUp();

    tvController.powerOff();
    //调高音量,此时不会生效
    tvController.turnUp();
    }


    }

    应用场景

    通常在以下情况下可以考虑使用状态模式。
    • 当一个对象的行为取决于它的状态,并且它必须在运行时根据状态改变它的行为时,就可以考虑使用状态模式。
    • 一个操作中含有庞大的分支结构,并且这些分支决定于对象的状态时。

    例子:

    应用在已登录状态,点击评论,会正常弹出评论框,而未登录状态下,则是要跳转到登录界面登录后,再正常评论。

    所以已登录和未登录状态下的评论行为是不同的,这个就可以用状态模式设计。

    收起阅读 »

    android 逆向工程-分析篇 漏洞与风险(四)

    Android逆向工程篇:android 逆向工程-工具篇 drozer(一)android 逆向工程-工具篇 apktool(二)android 逆向工程-语言篇 Smali(三)android 逆向工程-分析篇 漏洞与风险(四)android 逆向工程-工...
    继续阅读 »

    Android逆向工程篇:


    风险与漏洞:

    1.静态破解获取源码
    通过各种工具可以对未加密应用反编译出源码

    2.二次打包
    将反编译出的源码,进行修改,再次打包,签名

    3.输入监听
    通过adb shell getevent/sendevent 对用户数据进行窃取,存储,编辑

    4.页面截图
    通过截图来获取用户隐私信息

    5.获取本地存储的数据库,缓存文件
    对本地应用储存的数据进行窃取、编辑、存储。

    6.网络数据抓取
    通过数据抓包来获取网络中的数据,对数据进行截获,重放,编辑,存储。
    收起阅读 »

    android 逆向工程-语言篇 Smali(三)

    Android逆向工程篇:android 逆向工程-工具篇 drozer(一)android 逆向工程-工具篇 apktool(二)android 逆向工程-语言篇 Smali(三)android 逆向工程-分析篇 漏洞与风险(四)android 逆向工程-工...
    继续阅读 »

    Android逆向工程篇:


    数据类型

    • B---byte
    • C---char
    • D---double
    • F---float
    • I---int
    • J---long
    • S---short
    • V---void
    • Z---boolean
    • [XXX---array
    • Lxxx/yyy---object

    基本语法

    .field private isFlag:z定义变量
    .method方法
    .parameter方法参数
    .prologue方法开始
    .line 12此方法位于第12行
    invoke-super调用父函数
    const/high16  v0, 0x7fo3把0x7fo3赋值给v0
    invoke-direct调用函数
    return-void函数返回void
    .end method函数结束
    new-instance创建实例
    iput-object对象赋值
    iget-object调用对象
    invoke-static调用静态函数

    条件跳转分支:

    if-eq vA, vB, :cond_**如果vA等于vB则跳转到:cond_**
    if-ne vA, vB, :cond_**如果vA不等于vB则跳转到:cond_**
    if-lt vA, vB, :cond_**如果vA小于vB则跳转到:cond_**
    if-ge vA, vB, :cond_**如果vA大于等于vB则跳转到:cond_**
    if-gt vA, vB, :cond_**如果vA大于vB则跳转到:cond_**
    if-le vA, vB, :cond_**如果vA小于等于vB则跳转到:cond_**
    if-eqz vA, :cond_**如果vA等于0则跳转到:cond_**
    if-nez vA, :cond_**如果vA不等于0则跳转到:cond_**
    if-ltz vA, :cond_**如果vA小于0则跳转到:cond_**
    if-gez vA, :cond_**如果vA大于等于0则跳转到:cond_**
    if-gtz vA, :cond_**如果vA大于0则跳转到:cond_**
    if-lez vA, :cond_**如果vA小于等于0则跳转到:cond_**

    smali文件格式

    .class < 访问权限> [ 修饰关键字] < 类名>  
    .
    super < 父类名>
    .
    source <源文件名>

    MainActivity.smali展示

    .class public Lcom/droider/crackme0502/MainActivity;     //指令指定了当前类的类名。  
    .super Landroid/app/Activity; //指令指定了当前类的父类。
    .source "MainActivity.java" //指令指定了当前类的源文件名。

    smali文件中字段的声明使用“.field”指令。字段有静态字段与实例字段两种。静态字段的声明格式如下:

    .field < 访问权限> static [ 修饰关键字] < 字段名>:< 字段类型>  

    实例字段的声明与静态字段类似,只是少了static关键字,它的格式如下:

    .field < 访问权限> [ 修饰关键字] < 字段名>:< 字段类型>  

    比如以下的实例字段声明。  

    .field private btnAnno:Landroid/widget/Button;  //私有字段  

    smali 文件中方法的声明使用“.method ”指令,方法有直接方法与虚方法两种。

    .method <访问权限> [ 修饰关键字] < 方法原型>  
    <.locals> //指定了使用的局部变量的个数
    [.parameter] //指定了方法的参数
    [.prologue] //指定了代码的开始处,混淆过的代码可能去掉了该指令
    [.line] //指定了该处指令在源代码中的行号
    <代码体>
    .end method

    虚方法的声明与直接方法相同,只是起始处的注释为“virtual methods”,如果一个类实现了接口,会在smali 文件中使用“.implements ”指令指出,相应的格式声明如下:

    .implements < 接口名>        //接口关键字  

    如果一个类使用了注解,会在 smali 文件中使用“.annotation ”指令指出,注解的格式声明如下:  

    .annotation [ 注解属性] < 注解类名>  
    [ 注解字段 = 值]
    .end annotation

    注解的作用范围可以是类、方法或字段。如果注解的作用范围是类,“.annotation ”指令会直接定义在smali 文件中,如果是方法或字段,“.annotation ”指令则会包含在方法或字段定义中。例如:

    .field public sayWhat:Ljava/lang/String;            //String 类型 它使用了 com.droider.anno.MyAnnoField 注解,注解字段info 值为“Hello my friend”  
    .annotation runtime Lcom/droider/anno/MyAnnoField;
    info = "Hello my friend"
    .end annotation
    .end field


    收起阅读 »

    android 逆向工程-工具篇 apktool(二)

    Android逆向工程篇:android 逆向工程-工具篇 drozer(一)android 逆向工程-工具篇 apktool(二)android 逆向工程-语言篇 Smali(三)android 逆向工程-分析篇 漏洞与风险(四)android 逆向工程-工...
    继续阅读 »

    Android逆向工程篇:


    注:java环境自行安装

    apktool 下载

    Apktool

    运行

    apk文件 F:\apktools\demo.apk

    导出目录 F:\apktools\demo

    解包执行

    java -jar apktool.jar d -f F:\apktools\demo.apk -o F:\apktools\demo

    结果

    assets(未被编译) assets文件
    res(未被编译) res文件
    smali(被编译) smali格式文件

    二次打包执行

     java -jar  apktool.jar b F:\apktools\demo

    重新打包后的apk在要打包的文件夹里的dist目录下

    这样打完的apk是没有签名的

    jarsigner 签名apk

    jarsigner -verbose -keystore signapk.keystore -signedjar signapk_new.apk signapk.apk keyAlias

    注意:

    signapk.keystore 自己的签名证书
    signapk_new.apk  签名成功之后输出的apk名称
    signapk.apk 输入的待签名的apk
    keyAlias keyAlias名称

    收起阅读 »

    android 逆向工程-工具篇 drozer(一)

    Android逆向工程篇:android 逆向工程-工具篇 drozer(一)android 逆向工程-工具篇 apktool(二)android 逆向工程-语言篇 Smali(三)android 逆向工程-分析篇 漏洞与风险(四)android 逆向工程-工...
    继续阅读 »

    注:adb,java环境请自行配制好

    drozer 官方网站:https://labs.mwrinfosecurity.com/tools/drozer/

    下载安装以下两个文件:


    android 端:安装好 drozer.apk后,点击开启服务

    pc端:

    使用 forward 端口映射 将31415端口进行映射

    adb forward tcp:31415 tcp:31415
     

    drozer目录下cmd 运行 drozer console connect


    特殊(出现java环境没有找到):

    按照提示在 用户目录下添加 .drozer_config文件 内容如下:

    [executables]
    java=D:\Java\jdk1.7.0_65\bin\java.exe
    javac=D:\Java\jdk1.7.0_65\bin\javac.exe

    命令:

    list或ls 查看可用模块 

    run app.package.list  查看程序安装包  

    run app.package.info -a com.example.myapp  查看程序包信息  

    run app.package.attacksurface com.example.myapp  查看项目对外exported的组件 

    run app.activity.info -a com.example.myapp  查看对外activity的信息  

    run app.service.info -a com.example.myapp  查看对外service的信息  

    run app.broadcast.info -a com.example.myapp  查看对外broadcast的信息  

    run app.provider.info -a com.example.myapp  查看对外provider的信息  

    run app.activity.start --component com.example.myapp com.example.MainActivity 尝试启动MainActivity  

    run scanner.provider.finduris -a com.example.myapp 探测出可以查询的URI  

    run app.provider.query content://***/ -vertical  获取Uri的数据  

    run app.provider.insert URI对应数据表中的字段    对数据库表进行插入操作

    run app.provider.delete URI-selection “条件” 对数据库表进行删除操作

    Content Providers(SQL注入)
    run app.provider.query content://***/ --projection "'"
    run app.provider.query content://***/ --selection "'"

    报错则说明存在SQL注入。
    run app.provider.query content://***/ --projection "* FROM SQLITE_MASTER WHERE type='table';--"
    获取某个表(如Key)中的数据:
    run app.provider.query content://***/ --projection "* FROM Key;--"
    同时检测SQL注入和目录遍历
    run scanner.provider.injection -a com.example.myapp
    run scanner.provider.traversal -a com.example.myapp
     
    收起阅读 »

    java设计模式:原型模式

    定义用一个已经创建的实例作为原型,通过复制该原型对象来创建一个和原型相同或相似的新对象。在这里,原型实例指定了要创建的对象的种类。用这种方式创建对象非常高效,根本无须知道对象创建的细节。 优点 Java 自带的原型模式基于内存二进制流的复制,在性能上比直接 n...
    继续阅读 »

    定义

    用一个已经创建的实例作为原型,通过复制该原型对象来创建一个和原型相同或相似的新对象。在这里,原型实例指定了要创建的对象的种类。用这种方式创建对象非常高效,根本无须知道对象创建的细节。


    优点


    • Java 自带的原型模式基于内存二进制流的复制,在性能上比直接 new 一个对象更加优良。
    • 可以使用深克隆方式保存对象的状态,使用原型模式将对象复制一份,并将其状态保存起来,简化了创建对象的过程,以便在需要的时候使用(例如恢复到历史某一状态),可辅助实现撤销操作。

      缺点

    • 需要为每一个类都配置一个 clone 方法
    • clone 方法位于类的内部,当对已有类进行改造的时候,需要修改代码,违背了开闭原则。
    • 当实现深克隆时,需要编写较为复杂的代码,而且当对象之间存在多重嵌套引用时,为了实现深克隆,每一层对象对应的类都必须支持深克隆,实现起来会比较麻烦。因此,深克隆、浅克隆需要运用得当。

      代码实现

      原型模式包含以下主要角色。


    1. 抽象原型类:规定了具体原型对象必须实现的接口。
    2. 具体原型类:实现抽象原型类的 clone() 方法,它是可被复制的对象。
    3. 访问类:使用具体原型类中的 clone() 方法来复制新的对象。

    在这里插入图片描述

    浅克隆与深克隆


    • 浅克隆:创建一个新对象,新对象的属性和原来对象完全相同,对于非基本类型属性,仍指向原有属性所指向的对象的内存地址。
    • 深克隆:创建一个新对象,属性中引用的其他对象也会被克隆,不再指向原有对象地址。

    //具体原型类
    class Realizetype implements Cloneable {
    Realizetype() {
    System.out.println("具体原型创建成功!");
    }
    public Object clone() throws CloneNotSupportedException {
    System.out.println("具体原型复制成功!");
    return (Realizetype) super.clone();
    }
    }
    //原型模式的测试类
    public class PrototypeTest {
    public static void main(String[] args) throws CloneNotSupportedException {
    Realizetype obj1 = new Realizetype();
    Realizetype obj2 = (Realizetype) obj1.clone();
    System.out.println("obj1==obj2?" + (obj1 == obj2));
    }
    }

    输出


    具体原型创建成功!
    具体原型复制成功!
    obj1==obj2?false

    应用场景


    • 对象之间相同或相似,即只是个别的几个属性不同的时候。
    • 创建对象成本较大,例如初始化时间长,占用CPU太多,或者占用网络资源太多等,需要优化资源。
    • 创建一个对象需要繁琐的数据准备或访问权限等,需要提高性能或者提高安全性。
    • 系统中大量使用该类对象,且各个调用者都需要给它的属性重新赋值。

    收起阅读 »

    扫盲:Kotlin 的泛型(2)

    Kotlin 的 out 和 in 和 Java 泛型一样,Kolin 中的泛型本身也是不可变的。 不过换了一种表现形式: 使用关键字 out 来支持协变,等同于 Java 中的上界通配符 ? extends。 使用关键字 in 来支持逆变,等同于 Java...
    继续阅读 »

    Kotlin 的 out 和 in


    和 Java 泛型一样,Kolin 中的泛型本身也是不可变的。


    不过换了一种表现形式:



    • 使用关键字 out 来支持协变,等同于 Java 中的上界通配符 ? extends

    • 使用关键字 in 来支持逆变,等同于 Java 中的下界通配符 ? super


    val appleShop: Shop<out Fruit>
    val fruitShop: Shop<in Apple>
    复制代码

    它们完全等价于:


    Shop<? extends Fruit> appleShop;
    Shop<? super Apple> fruitShop;
    复制代码

    换了个写法,但作用是完全一样的。out 表示,我这个变量或者参数只用来输出,不用来输入,你只能读我不能写我;in 就反过来,表示它只用来输入,不用来输出,你只能写我不能读我。


    泛型的上下界约束


    上面讲的都是在使用的时候再对泛型进行限制,我们称之为「上界通配符」和「下界通配符」。那我们可以在函数设计的时候,就设置这个限制么?


    可以的可以的。


    比如:


    open class Animal
    class PetShop<T : Animal?>(val t: T)
    复制代码

    等同于 Java 的:


    class PetShop<T extends Animal> {
    private T t;

    PetShop(T t) {
    this.t = t;
    }
    }
    复制代码

    这样,我们在设计宠物店类 PetShop 就给支持的泛型设置了上界约束,支持的泛型类型必须是 Animal 的子类。所以我们使用的话:


    class Cat : Animal()

    val catShop = PetShop(Cat())
    val appleShop = PetShop(Apple())
    // 👆 报错:Type mismatch. Required: Animal? Found: Apple
    复制代码

    很明显,Apple 并不是 Animal 的子类,当然不满足 PetShop 泛型类型的上界约束。


    那....可以设置多个上界约束么?


    当然可以,在 Java 中,给一个泛型参数声明多个约束的方式是,使用 &


    class PetShop<T extends Animal & Serializable> {
    // 👆 通过 & 实现了两个上界,必须是 Animal 和 Serializable 的子类或实现类
    private T t;

    PetShop(T t) {
    this.t = t;
    }
    }
    复制代码

    而在 Kotlin 中舍弃了 & 这种方式,而是增加了 where 关键字:


    open class Animal
    class PetShop<T>(val t: T) where T : Animal?, T : Serializable
    复制代码

    通过上面的方式,就实现了多个上界的约束。


    Kotlin 的通配符 *


    前面我们说的泛型类型都是在我们需要知道参数类型是什么类型的,那如果我们对泛型参数的类型不感兴趣,有没有一种方式处理这个情况呢?


    有的有的。


    在 Kotlin 中,可以用通配符 * 来替代泛型参数。比如:


    val list: MutableList<*> = mutableListOf(1, "nanchen2251")
    list.add("nanchen2251")
    // 👆 报错:Type mismatch. Required: Nothing Found: String
    复制代码

    这个报错确实让人匪夷所思,上面用通配符代表了 MutableList 的泛型参数类型。初始化里面也加入了 String 类型,但在新 add 字符串的时候,却发生了编译错误。


    而如果是这样的代码:


    val list: MutableList<Any> = mutableListOf(1, "nanchen2251")
    list.add("nanchen2251")
    // 👆 不再报错
    复制代码

    看来,所谓的通配符作为泛型参数并不等价于 Any 作为泛型参数。MutableList<*>MutableList<Any> 并不是同一种列表,后者的类型是确定的,而前者的类型并不确定,编译器并不能知道这是一种什么类型。所以它不被允许添加元素,因为会导致类型不安全。


    不过细心的同学肯定发现了,这个和前面泛型的协变非常类似。其实通配符 * 不过是一种语法糖,背后也是用协变来实现的。所以:MutableList<*> 等价于 MutableList<out Any?>,使用通配符与协变有着一样的特性。


    在 Java 中,也有一样意义的通配符,不过使用的是 ? 作为通配。


    List<?> list = new ArrayList<Apple>(); 
    复制代码

    Java 中的通配符 ? 也等价于 ? extends Object


    多个泛型参数声明


    那可以声明多个泛型么?


    可以的可以的。


    HashMap 不就是一个典型的例子么?


    class HashMap<K,V>
    复制代码

    多个泛型,可以通过 , 进行分割,多个声明,上面是两个,实际上多个都是可以的。


    class HashMap<K: Animal, V, T, M, Z : Serializable>
    复制代码

    泛型方法


    上面讲的都是都是在类上声明泛型类型,那可以声明在方法上么?


    可以的可以的。


    如果你是一名 Android 开发,ViewfindViewById 不就是最好的例子么?


    public final <T extends View> T findViewById(@IdRes int id) {
    if (id == NO_ID) {
    return null;
    }
    return findViewTraversal(id);
    }
    复制代码

    很明显,View 是没有泛型参数类型的,但其 findViewById 就是典型的泛型方法,泛型声明就在方法上。


    上述写法改写成 Kotlin 也非常简单:


    fun <T : View?> findViewById(@IdRes id: Int): T? {
    return if (id == View.NO_ID) {
    null
    } else findViewTraversal(id)
    }
    复制代码

    Kotlin 的 reified


    前面有说到,由于 Java 中的泛型存在类型擦除的情况,任何在运行时需要知道泛型确切类型信息的操作都没法用了。比如你不能检查一个对象是否为泛型类型 T 的实例:


    <T> void printIfTypeMatch(Object item) {
    if (item instanceof T) { // 👈 IDE 会提示错误,illegal generic type for instanceof

    }
    }
    复制代码

    Kotlin 里同样也不行:


    fun <T> printIfTypeMatch(item: Any) {
    if (item is T) { // 👈 IDE 会提示错误,Cannot check for instance of erased type: T
    println(item)
    }
    }
    复制代码

    这个问题,在 Java 中的解决方案通常是额外传递一个 Class<T> 类型的参数,然后通过 Class#isInstance 方法来检查:


                                   👇
    <T> void check(Object item, Class<T> type) {
    if (type.isInstance(item)) {
    👆
    }
    }
    复制代码

    Kotlin 中同样可以这么解决,不过还有一个更方便的做法:使用关键字 reified 配合 inline 来解决:


      👇          👇
    inline fun <reified T> printIfTypeMatch(item: Any) {
    if (item is T) { // 👈 这里就不会在提示错误了

    }
    }
    复制代码

    上面的 Gson 解析的时候用的非常广泛,比如咱们项目里就有这样的扩展方法:


    inline fun <reified T> String?.toObject(type: Type? = null): T? {
    return if (type != null) {
    GsonFactory.GSON.fromJson(this, type)
    } else {
    GsonFactory.GSON.fromJson(this, T::class.java)
    }
    }
    复制代码

    总结


    本文花了非常大的篇幅来讲 Kotlin 的泛型和 Java 的泛型,现在再回过头去回答文首的几个问题,同学你有谱了吗?如果还是感觉一知半解,不妨多看几遍。


    作者:nanchen2251
    链接:https://juejin.cn/post/6911659839282216973
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    扫盲:Kotlin 的泛型(1)

    引子南尘很久没有写文章啦,其实一直在思考挺多问题,如何才能写出对大家有价值的文字。思来想去,参看了好几位新继网红博主的风格,我觉得我时候开启新篇章了。没错,这就是扫盲。今天,就带来扫盲的第一篇:Kotlin 的泛型。相信总是有很多同学,总是在抱怨泛型无论怎么学...
    继续阅读 »

    扫盲:Kotlin 的泛型

    引子

    南尘很久没有写文章啦,其实一直在思考挺多问题,如何才能写出对大家有价值的文字。思来想去,参看了好几位新继网红博主的风格,我觉得我时候开启新篇章了。没错,这就是扫盲。

    今天,就带来扫盲的第一篇:Kotlin 的泛型。

    相信总是有很多同学,总是在抱怨泛型无论怎么学习,都只是停留在一个简单使用的水平,所以一直为此而备受苦恼。

    Kotlin 作为一门能和 Java 相互调用的语言,自然也支持泛型,不过 Kotlin 的新关键字 in  out 却总能绕晕一部分人,归根结底,还是因为 Java 的泛型基本功没有足够扎实。

    很多同学总是会产生这些疑问:

    • Kotlin 泛型和 Java 泛型到底有何区别?
    • Java 泛型存在的意义到底是什么?
    • Java 的类型擦除到底是指什么?
    • Java 泛型的上界、下界、通配符到底有何区别?它们可以实现多重限制么?
    • Java 的 <? extends T><? super T><?> 到底对应了什么?有哪些使用场景?
    • Kotlin 的 inout*where 到底有何魔力?
    • 泛型方法又是什么?

    今天,就用一篇文章为大家解除上述疑惑。

    泛型:类型安全的利刃

    总所周知,Java 在 1.5 之前,是没有泛型这个概念的。那时候的 List 还只是一个可以装下一切的集合。所以我们难免会写上这样的代码:

    List list = new ArrayList();
    list.add(1);
    list.add("nanchen2251");
    String str = (String) list.get(0);
    复制代码

    上面的代码编译并没有任何问题,但运行的时候一定会出现常见的 ClassCastException 异常:

    Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
    复制代码

    这个体验非常糟糕,我们真正需要的是在代码编译的时候就能发现错误,而不是让错误的代码发布到生产环境中。

    而如果上述代码我们增加上泛型,就会在编译期就能看到明显的错误啦。

    List<String> list = new ArrayList<>();
    list.add(1);
    // 👆 报错 Required type:String but Provided:int
    list.add("nanchen2251");
    String str = list.get(0);
    复制代码

    很明显,泛型的出现,让类型更加安全,使我们在使用 ListMap 等不再需要去专门编写 StringListStringMap 了,只需要在声明 List 的同时指定参数类型即可。

    总的来说,泛型具备以下优势:

    • 类型检查,能在编译时就帮开发检查出错误;
    • 更加语义化,比如我们声明一个 LIst<String>,我们可以很直接知道里面存储的是 String 对象;
    • 能自动进行类型转换,获取数据的时候不需要再做强转操作;
    • 能写出更加通用化的代码。

    类型擦除

    可能有些同学思考过这样一个问题,既然泛型是和类型相关的,那么是不是也能使用类型的多态呢?

    我们知道,一个子类型是可以赋值给父类型的,比如:

    Object obj = "nanchen2251";
    // 👆 这是多态
    复制代码

    Object 作为 String 的父类,自然可以接受 String 对象的赋值,这样的代码我们早已司空见惯,并没有什么问题。

    但当我们写下这串代码:

    List<String> list = new ArrayList<String>();
    List<Object> objects = list;
    // 👆 多态用在这里会报错 Required type:List<Object> Provided: List<String>
    复制代码

    上面发生了赋值错误,这是因为 Java 的泛型本身具有「不可变性 Invariance」,Java 里面认为 List<String>  List<Object> 类型并不一致,也就是说,子类的泛型 List<String> 不属于泛型 List<Object> 的子类。

    由于 Java 的泛型本身是一种 「伪泛型」,Java 为了兼容 1.5 以前的版本,不得以在泛型底层实现上使用 Object 引用,所以我们声明的泛型在编译时会发生「类型擦除」,泛型类型会被 Object 类型取代。比如:

    class Demo<T> {
    void func(T t){
    // ...
    }
    }
    复制代码

    会被编译成:

    class Demo {
    void func(Object t){
    // ...
    }
    }
    复制代码

    可能你会好奇,在编译时发生类型擦除后,我们的泛型都被更换成了 Object,那为什么我们在使用的时候,却不需要强转操作呢?比如:

    List<String> list = new ArrayList<>();
    list.add("nanchen2251");
    String str = list.get(0);
    // 👆 这里并没有要求我们把 list.get(0) 强转为 String
    复制代码

    这是因为编译器会根据我们声明的泛型类型进行提前的类型检查,然后再进行类型擦除,擦除为 Object,但在字节码中其实还存储了我们的泛型的类型信息,在使用到泛型类型的时候会把擦除后的 Object 自动做类型强转操作。所以上面的 list.get(0) 本身就是一个经过强转的 String 对象了。

    这个技术看起来还蛮好的,但却有一个弊端。就是既然擦成 Object 了,那么在运行的时候,你根本不能确定这个对象到底是什么类型,虽然你可以通过编译器帮你插入的 checkcast 来获得此对象的类型。但是你并不能把 T 真正的当作一个类型使用:比如这条语句在 Java 中是非法的。

    T a = new T();
    // 👆 报错:Type parameter 'T' cannot be instantiated directly
    复制代码

    同理,因为都被擦成了 Object,你就不能根据类型来做某种区分。

    比如 instanceof

    if("nanchen2251" instanceof T.class){
    // 👆 报错:Identifier expected Unexpected token
    }
    复制代码

    比如重载:

    void func(T t){
    // 👆 报错:'func(T)' clashes with 'func(E)'; both methods have same erasure
    }
    void func(E e){
    }
    复制代码

    同样,因为基本数据类型不属于 oop,所以也不能被擦除为 Object,所以 Java 的泛型也不能用于基本类型:

    List<int> list;
    // 👆 报错:Type argument cannot be of primitive type
    复制代码

    oop:面向对象的程序设计(Object Oriented Programming)

    到这里,是不是可以回答上面的第 3 个问题了:Java 的类型擦除到底是指什么?

    首先你要明白一点,一个对象的类型永远不会被擦出的,比如你用一个 Object 去引用一个 Apple 对象,你还是可以获得到它的类型的。比如用 RTTI。

    RTTI:运行时类型信息,运行时类型识别 (Run Time Type Identification)

    Object object = new Apple();
    System.out.println(object.getClass().getName());
    // 👆 will print Apple
    复制代码

    哪怕它是放到泛型里的。

    class FruitShop<T>{
    private T t;

    public void set(T t){
    this.t = t;
    }

    public void showFruitName(){
    System.out.println(t.getClass().getName());
    }
    }
    FruitShop<Apple> appleShop = new FruitShop<Apple>();
    appleShop.set(new Apple());
    appleShop.showFruitName();
    // 👆 will print Apple too
    复制代码

    为啥?因为引用就是一个用来访问对象的标签而已,对象一直在堆上放着呢。

    所以不要断章取义认为类型擦除就是把容器内对象的类型擦掉了,所谓的类型擦除,是指容器类FruitShop<Apple>,对于 Apple 的类型声明在编译期的类型检查之后被擦掉,变为和 FruitShop<Object> 等同效果,也可以说是 FruitShop<Apple>  FruitShop<Banana> 被擦为和 FruitShop<Object> 等价,而不是指里面的对象本身的类型被擦掉!

    那,Kotlin 中有类型擦除么?

    C# 和 Java 在一开始都是不支持泛型的。Java 在 1.5 开始才加入了泛型。为了让一个不支持泛型的语言支持泛型,只有两条路可以走:

    • 以前的非泛型容器保持不变,然后平行的增加一套泛型化的类型。
    • 直接把已有的非泛型容器扩展为泛型,不添加任何新的泛型版本。

    Java 由于 1.5 之前市面上一句有大量的代码,所以不得以选择了第 2 种方式,而 C# 比较机智就选择了第一种。

    而 Kotlin 本身就是基于 Java 1.6 编写的,一开始就有泛型,不存在兼容老版本代码的问题,那 Kotlin 实现的泛型还具备类型擦除么?

    当然具备。上面其实已经说的很清楚了,Kotlin 本身就是基于 Java 1.6 编写的,而且 Kotlin 和 Java 有极强的互调能力,当然也存在类型擦除。

    不过...

    你还是会发现有意思的点:

    val list = ArrayList()
    // 👆 报错:Not enough information to infer type variable E
    复制代码

    在 Java 中,不指定泛型类型是没问题的,但 Kotlin 这样不好使了。想来也简单,毕竟在 Java 1.5 之前是肯定不存在上述类似代码的,而泛型的设计初衷就不是用来装默认的 Kotlin Any 的。

    泛型的上界通配符

    前面说到:因为 Java 的泛型本身具有「不可变性 Invariance」,所以即使 Fruit 类是 Apple 类的父类,但 Java 里面认为 List<Fruit>  List<Apple> 类型并不一致,也就是说,子类的泛型 List<Apple> 不属于泛型 List<Fruit> 的子类。

    所以这样的代码并不被运行。

    List<Apple> apples = new ArrayList<Apple>();
    List<Fruit> fruits = apples;
    // 👆 多态用在这里会报错 Required type:List<Fruit> Provided: List<Apple>
    复制代码

    那假如我们想突破这层限制,怎么办?使用上界通配符 ? extends

    List<Apple> apples = new ArrayList<Apple>();
    List<? extends Fruit> fruits = apples;
    // 👆使用上界通配符后,编译不再报错
    复制代码

    「上界通配符」,可以使 Java 泛型具有「协变性 Covariance」,协变就是允许上面的赋值是合法的。

    在继承关系树中,子类继承自父类,可以认为父类在上,子类在下。extends 限制了泛型类型的父类型,所以叫上界。

    它有两层意思:

    • 其中 ? 是个通配符,表示这个 List 的泛型类型是一个未知类型。
    • extends 限制了这个未知类型的上界,也就是泛型类型必须满足这个 extends 的限制条件,这里和定义 class  extends 关键字有点不一样:
      • 它的范围不仅是所有直接和间接子类,还包括上界定义的父类本身,也就是 Fruit
      • 它还有 implements 的意思,即这里的上界也可以是 interface

    这个突破限制有意义么?

    有的有的。

    假如我们有一个接口 Fruit

    interface Fruit {
    float getWeight();
    }
    复制代码

    有两个水果类实现了 Fruit 接口:

    class Banana implements Fruit {
    @Override
    public float getWeight() {
    return 0.5f;
    }
    }

    class Apple implements Fruit {
    @Override
    public float getWeight() {
    return 1f;
    }
    }
    复制代码

    假设我们有个需求是需要给水果称重:

    List<Apple> apples = new ArrayList<>();
    apples.add(new Apple());
    float totalWeight = getTotalWeight(apples);
    // 👆 报错:Required type: List<Fruit> Provided: List<Apple>

    private float getTotalWeight(List<Fruit> fruitList) {
    float totalWeight = 0;
    for (Fruit fruit : fruitList) {
    totalWeight += fruit.getWeight();
    }
    return totalWeight;
    }
    复制代码

    想来这也是一个非常正常的需求,秤可以称各种水果的重量,但也可以只称苹果。你不能因为我只买苹果就不给我称重吧。所以把上面的代码加上上界通配符就可以啦。

    List<Apple> apples = new ArrayList<>();
    apples.add(new Apple());
    float totalWeight = getTotalWeight(apples);
    // 👆 不再报错
    // 👇 增加了上界通配符 ? extends
    private float getTotalWeight(List<? extends Fruit> fruitList) {
    float totalWeight = 0;
    for (Fruit fruit : fruitList) {
    totalWeight += fruit.getWeight();
    }
    return totalWeight;
    }
    复制代码

    不过,上面使用 ? extends 上界通配符突破了一层限制,却被施加了另一层限制:只可输出不可输入

    什么意思呢?

    比如:

    List<Apple> apples = new ArrayList<Apple>();
    List<? extends Fruit> fruits = apples;
    Fruit fruit = fruits.get(0);
    fruits.add(new Apple());
    // 👆 报错:Required type: capture of ? extends Fruit Provided: Apple
    复制代码

    声明了上界通配符泛型的集合,不再允许 add 新的对象,Apple 不行,Fruit 也不行。拓展开来说:不止是集合,自己编写一个泛型做输入也不行

    interface Shop<T> {
    void showFruitName(T t);
    T getFruit();
    }

    Shop<? extends Fruit> apples = new Shop<Apple>(){
    @Override
    public void showFruitName(Apple apple) { }

    @Override
    public Apple getFruit() {
    return null;
    }
    };
    apples.getFruit();
    apples.showFruitName(new Apple());
    // 👆 报错:Required type: capture of ? extends Fruit Provided: Apple
    复制代码

    泛型的下界通配符

    泛型有上界通配符,那有没有下界通配符呢?

    有的有的。

    与上界通配符 ? extends 对应的就是下界通配符 ? super

    下界通配符 ? super 所有情况和 ? extends 上界通配符刚刚相反:

    • 通配符 ? 表示 List 的泛型类型是一个 未知类型
    • super 限制了这个未知类型的下界,也就是泛型类型必须满足这个 super 的限制条件
      • 它的范围不仅是所有直接和间接子父类,还包括下界定义的子类本身。
      • super 同样支持 interface

    它被施加的新限制是:只可输入不可输出

    Shop<? super Apple> apples = new Shop<Fruit>(){
    @Override
    public void showFruitName(Fruit apple) { }

    @Override
    public Fruit getFruit() {
    return null;
    }
    };
    apples.showFruitName(new Apple());
    Apple apple = apples.getFruit();
    // 👆 报错:Required type: Apple Provided: capture of ? super Apple
    复制代码

    解释下,首先 ? 表示未知类型,编译器是不确定它的类型的。

    虽然不知道它的具体类型,不过在 Java 里任何对象都是 Object 的子类,所以这里只能把apples.getFruit() 获取出来的对象赋值给 Object。由于类型未知,所以直接赋值给一个 Apple 对象肯定是不负责任的,需要我们做一层强制转换,不过强制转换本身可能发生错误。

     Apple 对象一定是这个未知类型的子类型,根据多态的特性,这里通过 showFruitName 输入 Button 对象是合法的。

    小结下,Java 的泛型本身是不支持协变和逆变的:

    • 可以使用泛型通配符 ? extends 来使泛型支持协变,但是「只能读取不能修改」,这里的修改仅指对泛型集合添加元素,如果是 remove(int index) 以及 clear 当然是可以的。
    • 可以使用泛型通配符 ? super 来使泛型支持逆变,但是「只能修改不能读取」,这里说的不能读取是指不能按照泛型类型读取,你如果按照 Object 读出来再强转当然也是可以的。

    理解了 Java 的泛型之后,再理解 Kotlin 中的泛型,就比较容易了。

    收起阅读 »

    Kotlin写一个解释器(1)---词法分析

    为什么学最近对编译器很感兴趣,为什么要学习编译原理,于我而言是因为最近需要写一个DSL,需要一个解释器,而对于大部分程序员来说,学习编译器可能有一下三个方面:(1)学习编译器设计,可以帮助更好的理解程序以及计算机是怎么运行的,同时编写编译器或者解释器需要大量的...
    继续阅读 »

    Kotlin写一个解释器(1)---词法分析

    为什么学

    最近对编译器很感兴趣,为什么要学习编译原理,于我而言是因为最近需要写一个DSL,需要一个解释器,而对于大部分程序员来说,学习编译器可能有一下三个方面:

    (1)学习编译器设计,可以帮助更好的理解程序以及计算机是怎么运行的,同时编写编译器或者解释器需要大量的计算机技巧,对技术 也是一个提升。

    (2)面试需要,所谓“工作拧螺丝,面试造火箭”。学习编译器设计有助于加强计算机基础能力,提高编码素养,更好的应对面试,毕竟你不知道你的面试官是不是对这个也感兴趣。

    (3)工作需要,有的时候你可能需要创造一些领域特定语言或者发明一种新语言(这个需要不太多),这个时候你就需要写一个编译器或者解释器来满足你的需要了。

    编译器与解释器

    编译器将以某种语言编写的程序作为输入,产生一个等价的程序作为输出,通常这个输入语言可能就是C活着C++,等价的目标程序通常是某种处理器的指令集,然后可以直接运行该目标程序。解释器与编译器的不同就在于它直接执行由编程语言或者脚本编写的代码,并不会把源代码预编译成指令集,它会实时的返回结果。如下图所示

    compiler.jpg

    还有一种编译器,它将一种高级语言翻译成另一种高级语言,比如将php转为C++,这种编译器一般称为源到源的转换器。

    目标

    这个博客系列的目标其实很小,就是利用Kotlin去实现一个小型的解释器来进行正数的四则运算,因为本人目前也是学习阶段,所以只能先弄一个这样的小功能,等技术提高了再开新番。该系列只会涉及到词法分析、语法分析、抽象语法树等编译器前端相关的概念,至于编译器后端相关的代码优化以及代码生成不会涉及。

    词法分析

    词法分析的任务是将字符流变换为输入语言的单词流。每个单词都必须归类到某个语法范畴中,也叫词类。词法分析器是编译器中唯一会接触到程序中每个字符的一趟处理。这里有几个概念要说明,比如词类,列比我们平时的语言,我们会说“走”是动词,“跑”也是动词,“漂亮”是形容词,“美丽”也是形容词,这里动词和形容词,就是词类,代表着单词的分类,还有一个就是词素,前面说的“走”,“跑”,"漂亮“等其实就是词素,也就是具体的单词内容,实际的文本。词法分析的作用就是将源代码中的文件按字符读入,根据读入的字符识别单词组成一个词法单元,每个词法单元由词法单元名和词素组成,列如<形容词:漂亮>,其中形容词就是词法单元名,可以看做和词类相同,漂亮就是词素,而对于我们要实现的计算器来说可能就是<PLUS,+>,<NUMBER,9>这样的。

    代码

    定义词法单元

    前面说过,词法单元由词法单元名和词素组成,所以我们定义一个类Token来代表词法单元,TokenType这个枚举类来代表词法单元名

    data class Token(val tokenType: TokenType, val value: String) {
    override fun toString(): String {
    return "Token(tokenType=${this.tokenType.value}, value= ${this.value})"
    }
    }


    enum class TokenType(val value: String) {
    NUMBER("NUMBEER"), PLUS("+"), MIN("-"), MUL("*"), DIV("/"), LBRACKETS("("), RBRACKETS(")"), EOF("EOF")
    }
    复制代码

    可以看到我有8个TokenType,8个TokenType代表着8个词法单元名,也就是8个词类,其中EOF代表END OF FILE及源文件扫描结束。

    定义词法分析器

    import java.lang.RuntimeException

    class Lexer(private val text: String) {

    private var nextPos = 0

    private val tokenMap = mutableMapOf<String, TokenType>()

    private var nextChar: Char? = null

    init {
    TokenType.values().forEach {
    if(it!=TokenType.NUMBER) {
    tokenMap[it.value] = it
    }
    }
    nextChar = text.getOrNull(nextPos)
    }

    fun getNextToken(): Token {
    loop@ while (nextChar != null) {
    when (nextChar) {
    in '0'..'9' -> {
    return Token(TokenType.NUMBER, getNumber())
    }
    ' ' -> {
    skipWhiteSpace()
    continue@loop
    }
    }
    if (tokenMap.containsKey(nextChar.toString())) {
    val tokenType = tokenMap[nextChar.toString()]
    if (tokenType != null) {
    val token = Token(tokenType, tokenType.value)
    advance()
    return token
    }
    }
    throw RuntimeException("Error parsing input")
    }
    return Token(TokenType.EOF, TokenType.EOF.value)
    }

    private fun getNumber(): String {
    var item = ""
    while (nextChar != null && nextChar!! in '0'..'9') {
    item += nextChar
    advance()
    if ('.' == nextChar) {
    item += nextChar
    advance()
    while (nextChar != null && nextChar!! in '0'..'9') {
    item += nextChar
    advance()
    }
    }
    }
    return item
    }

    private fun skipWhiteSpace() {
    var nextChar = text.getOrNull(nextPos)
    while (nextChar != null && ' ' == nextChar) {
    advance()
    nextChar = text.getOrNull(nextPos)
    }
    }

    private fun advance() {
    nextPos++
    nextChar = if (nextPos > text.length - 1) {
    null
    } else {
    text.getOrNull(nextPos)
    }
    }

    }
    复制代码

    先看成员变量,其中text代表的是源文件内容,nextPos代表着源代码中下一个字符的位置,nextChar代表着源代码中下一个字符,tokenMap代表着词素和词法单元是唯一对应的Map,其中key代表的是词素,TokenType代表的词法单元,可以看到在我们的定义中除了TokenType.NUMBER其他都是存在唯一对应的,因为对于数字来说,9对应的是词法单元是NUMBER,10对应的词法单元也是NUMBER,不存在唯一对应,所以需要我们单独识别。

    构造方法很简单,为tokenMap和nextChar计算赋值

    再看剩下的方法,其实这个词法解析器对外暴露的只有getNextToken方法用以返回Token,其他方法都是private的用以辅助返回Token,在getNextToken方法中,有一个while循环判断nextChar是否为null,如果为null代表着源文件已经处理完毕,返回Token(TokenType.EOF, TokenType.EOF.value),否则的话就判断当前字符是不是数字,如果是数字,就返回Token(TokenType.NUMBER, getNumber()),其中getNumber方法用以获取数字内容直到nextChar不再为数字为止。如果nextChar为空格,就跳过空格skipWhiteSpce,然后继续当前循环,如果既不是数字也不是空格,那么就根据tokenMap获取相应的TokenType,看看是不是运算符号或者括号,如果也不存在,说明输入中存在非数字和四则运算符号以及括号的字符,抛出错误"Error parsing input”。

    测试

    import java.util.*

    fun main() {
    while(true) {
    val scanner = Scanner(System.`in`)
    val text = scanner.nextLine()
    val lexer = Lexer(text)
    var nextToken = lexer.getNextToken()
    while (TokenType.EOF != nextToken.tokenType) {
    println(nextToken.toString())
    nextToken = lexer.getNextToken()
    }
    }
    }
    复制代码

    编写测试代码,打印相应的token,运行代码,在代码中输入数据并回车,查看结果

    截屏2021-04-20 上午10.37.01.png

    至此词法分析器基本完成,其实词法分析器还有很多概念可说,比如说正则表达式,然后由正则表达式生成NFA,NFA应用最小子集法生成DFA,再由DFA生成最小DFA,其中有很多概念,但是个人认为太多的概念会让人迷茫,不如先由简单的例子开始,然后逐步加深理解,熟悉概念

    收起阅读 »

    Android从源码分析RecyclerView四级缓存复用机制二(复用ViewHolder)

    上一篇文章说了RecyclerView的四级缓存中的缓存ViewHolder,文章链接在这里:Android从源码分析RecyclerView四级缓存复用机制一(缓存ViewHolder) 列表视图在原生开发中一直占用重要地位,不管是之前的ListV...
    继续阅读 »

    Android从源码分析RecyclerView四级缓存复用机制二(复用ViewHolder)

    上一篇文章说了RecyclerView的四级缓存中的缓存ViewHolder,文章链接在这里:Android从源码分析RecyclerView四级缓存复用机制一(缓存ViewHolder) 列表视图在原生开发中一直占用重要地位,不管是之前的ListView还是现在RecyclerView,无论实在性能上还是使用功能上都有着巨大的优势,其中最重要的其实还是对于视图的复用机制。从ListView的RecycleBin到RecyclerView的Recycler,Google对于列表视图的缓存的设计一直非常考究值得我们学习和研究。而网页的H5以及RN对于复杂的列表视图的渲染性能不好从这里面其实也可以寻找到一些原因。 本文就来说一下ViewHolder的复用(回收) ,缓存的ViewHolder必须要复用才能够体现缓存的意义。

    1.总流程图

    放上一张Bugly的一篇博客对RecyclerView的缓存的流程图吧(自己绘制也差不多,直接拿来用了...若侵立删) 在这里插入图片描述

    2 .调用方法跟踪

    recyclerView在什么时候复用被缓存的ViewHolder,毫无疑问肯定是在recyclerView滚动的时候。recyclerView在滚动的时候触发复用。

    // 1.RecyclerView的scrollBy()方法
    @Override
    public void scrollBy(int x, int y) {
    //...
    final boolean canScrollHorizontal = mLayout.canScrollHorizontally();
    final boolean canScrollVertical = mLayout.canScrollVertically();
    //横向滑动和纵向滑动都可以进入if
    if (canScrollHorizontal || canScrollVertical) {
    scrollByInternal(canScrollHorizontal ? x : 0, canScrollVertical ? y : 0, null);
    }
    }

    // 2.RecyclerView的scrollByInternal()方法
    boolean scrollByInternal(int x, int y, MotionEvent ev) {
    int unconsumedX = 0, unconsumedY = 0;
    int consumedX = 0, consumedY = 0;

    consumePendingUpdateOperations();
    if (mAdapter != null) {
    eatRequestLayout();
    onEnterLayoutOrScroll();
    TraceCompat.beginSection(TRACE_SCROLL_TAG);
    if (x != 0) {
    //横向滑动调用LayoutManager的scrollHorizontallyBy
    consumedX = mLayout.scrollHorizontallyBy(x, mRecycler, mState);
    unconsumedX = x - consumedX;
    }
    if (y != 0) {
    //纵向滑动调用LayoutManager的scrollVerticallyBy
    consumedY = mLayout.scrollVerticallyBy(y, mRecycler, mState);
    unconsumedY = y - consumedY;
    }
    //...
    }
    //...
    }

    // 3.RecyclerView.LayoutManager的scrollVerticallyBy()方法 本文主要分析纵向滑动其实都一样
    public int scrollVerticallyBy(int dy, Recycler recycler, State state) {
    return 0;
    }

    // 4.LinearLayoutManager重写了LayoutManager的scrollVerticallyBy()方法
    @Override
    public int scrollVerticallyBy(int dy, RecyclerView.Recycler recycler,RecyclerView.State state) {
    if (mOrientation == HORIZONTAL) {
    return 0;
    }
    return scrollBy(dy, recycler, state);
    }

    // 5.LinearLayoutManager的scrollBy()
    int scrollBy(int dy, RecyclerView.Recycler recycler, RecyclerView.State state) {
    //...
    //这里调用fill方法
    final int consumed = mLayoutState.mScrollingOffset
    + fill(recycler, mLayoutState, state, false);
    //...
    final int scrolled = absDy > consumed ? layoutDirection * consumed : dy;
    mOrientationHelper.offsetChildren(-scrolled);
    //...
    mLayoutState.mLastScrollDelta = scrolled;
    return scrolled;
    }
    // 6.LinearLayoutManager的fill()
    int fill(RecyclerView.Recycler recycler, LayoutState layoutState,
    RecyclerView.State state, boolean stopOnFocusable)
    {
    //...
    while ((layoutState.mInfinite || remainingSpace > 0) && layoutState.hasMore(state)) {
    //...
    //根据当前的布局方向调用适当的回收方法
    layoutChunk(recycler, state, layoutState, layoutChunkResult);
    //...
    }
    //...
    }
    // 7.LinearLayoutManager的layoutChunk()
    void layoutChunk(RecyclerView.Recycler recycler, RecyclerView.State state,LayoutState layoutState, LayoutChunkResult result) {
    //传入recycler获取到相应的view
    View view = layoutState.next(recycler);
    //...
    if (layoutState.mScrapList == null) {
    if (mShouldReverseLayout == (layoutState.mLayoutDirection== LayoutState.LAYOUT_START)) {
    //将获取到的view重新添加到recyclerview中
    addView(view);
    } else {
    addView(view, 0);
    }
    }
    //...
    }
    // 8.LinearLayoutManager的next()
    View next(RecyclerView.Recycler recycler) {
    if (mScrapList != null) {
    return nextViewFromScrapList();
    }
    //根据位置获取view
    final View view = recycler.getViewForPosition(mCurrentPosition);
    mCurrentPosition += mItemDirection;
    return view;
    }
    // 9.RecyclerView.Recycler的getViewForPosition()
    View getViewForPosition(int position, boolean dryRun) {
    return tryGetViewHolderForPositionByDeadline(position, dryRun, FOREVER_NS).itemView;
    }
    复制代码

    回顾一下方法的调用

    入口:滑动 Move 事件 --> scrollByInternal --> scrollStep --> mLayout.scrollVerticallyBy 
    --> scrollBy --> fill --> layoutChunk --> layoutState.next --> addView(view);

    layoutState.next--> getViewForPosition --> tryGetViewHolderForPositionByDeadline
    复制代码

    经过一系列的方法调用,我们调用到了RecyclerView.Recycler的tryGetViewHolderForPositionByDeadline()方法中拿到四级缓存中的ViewHolder然后拿到view,然后在layoutChunk()中的addView(view)方法中添加到recyclerView中。

    下面通过源码来验证一下1.总流程图

    3.核心源码分析

    ViewHolder tryGetViewHolderForPositionByDeadline(int position,
    boolean dryRun, long deadlineNs)
    {
    //...各种判断
    boolean fromScrapOrHiddenOrCache = false;
    ViewHolder holder = null;
    if (mState.isPreLayout()) {
    // 1.对应的是一级缓存中的 -- mChangeScrap 与动画相关的ViewHolder
    holder = getChangedScrapViewForPosition(position);
    fromScrapOrHiddenOrCache = holder != null;
    }
    //如果一级缓存没有对应位置的holder
    if (holder == null) {
    //2.对应的是二级缓存中-- mAttachedScrap 、mCachedViews 存储屏幕外的ViewHolder
    holder = getScrapOrHiddenOrCachedHolderForPosition(position, dryRun);
    if (holder != null) {
    if (!validateViewHolderForOffsetPosition(holder)) {
    if (!dryRun) {
    //...一堆判断
    //回收方法
    recycleViewHolderInternal(holder);
    }
    holder = null;
    } else {
    fromScrapOrHiddenOrCache = true;
    }
    }
    }
    if (holder == null) {
    //...

    final int type = mAdapter.getItemViewType(offsetPosition);
    if (mAdapter.hasStableIds()) {
    // 3.对应的是二级缓存中-- mAttachedScrap 、mCachedViews 根据(ViewType,itemid) 获取的ViewHolder
    holder = getScrapOrCachedViewForId(mAdapter.getItemId(offsetPosition),
    type, dryRun);
    if (holder != null) {
    holder.mPosition = offsetPosition;
    fromScrapOrHiddenOrCache = true;
    }
    }
    if (holder == null && mViewCacheExtension != null) {
    //4.对应的是三级缓存 -- 自定义缓存 -- (使用情况:局部刷新??)的ViewHolder
    final View view = mViewCacheExtension
    .getViewForPositionAndType(this, position, type);
    if (view != null) {
    holder = getChildViewHolder(view);
    //...
    }
    }
    if (holder == null) { // fallback to pool
    //...
    //5.对应的是四级缓存-- 从缓冲池里面获取 ViewHolder
    holder = getRecycledViewPool().getRecycledView(type);
    if (holder != null) {
    holder.resetInternal();
    if (FORCE_INVALIDATE_DISPLAY_LIST) {
    invalidateDisplayListInt(holder);
    }
    }
    }
    if (holder == null) {
    long start = getNanoTime();
    //...
    // 6.四级缓存都找不到 ViewHolder则走createViewHolder()创建ViewHolder
    holder = mAdapter.createViewHolder(RecyclerView.this, type);
    //...
    }
    //...
    return holder;
    }
    复制代码

    至此文章中的大体的源码就分析完了,如果想进一步了解更多的recyclerView回收复用的更多的细节的话,可以自己阅读一下源码。

    收起阅读 »

    Android与JS相互通信

    Android调用js的方法实现是引入一个webview用webview打开一个页面调取的JS函数。private void InitWebView() { mWebView = (WebView) findViewById(R.id.webview)...
    继续阅读 »

    Android与JS相互通信

    Android调用js的方法实现是引入一个webview用webview打开一个页面调取的JS函数。

    private void InitWebView() {
    mWebView = (WebView) findViewById(R.id.webview);

    WebSettings webSettings = mWebView.getSettings();

    // 设置与Js交互的权限
    webSettings.setJavaScriptEnabled(true);
    // 设置允许JS弹窗
    webSettings.setJavaScriptCanOpenWindowsAutomatically(true);

    //把js弹窗转化成安卓弹窗
    SetJavaScriptAlertEnable();

    // 先载入html代码
    // 格式规定为:file:///android_asset/文件名.html
    // 只需要将第一种方法的loadUrl()换成下面该方法即可
    // Android版本变量
    //mWebView.addJavascriptInterface(new AndroidtoJs(), "test");//AndroidtoJS类对象映射到js的test对象
    mWebView.loadUrl("file:///android_asset/javascript.html");
    //SetWebChromeClient()//处理JS调用Android函数的方法在第二部分解释

    }
    复制代码

    首先先初始化webview

    第二步对webview基本初始化

    第三部设置JS交互权限

    其余有明确注释

    loadurl是加载html网页端的

    我们以button点击开始执行js事件为例

    首先app/src/main下创建assets文件

    下面是javascript.html文件我们在引入文件时需要将文件放到所在的Android项目的/project_home/app/src/main/assets/javascript.html 下就可以使用了。

    <!DOCTYPE html>
    <html>

    <head>
    <meta charset="utf-8">
    <title>Carson_Ho</title>
    <h1 id="ip">
    你好这里已经调用过文件了
    </h1>
    <button onclick="callJS()">调用弹窗</button>
    <button type="button" id="button1" onclick="callAndroid()">点击调用Android代码</button>
    <button type="button" id="button2" onclick="clickprompt()">点击调用Androidtest代码</button>
    <script>
    function callJS() {
    alert("Android调用了JS的callJS方法");
    }

    function change() {
    document.getElementById('ip').innerText = "真的难啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊a";
    }
    function clickprompt(){
    var result=prompt("js://demo?arg1=111&arg2=222");
    alert("demo " + result);
    }
    function callAndroid(){
    // 由于对象映射,所以调用test对象等于调用Android映射的对象
    test.hello("js调用了android中的hello方法");
    }

    </script>

    // JS代码
    <script src="./1/roslib.min.js"></script>
    <script src="./1/RoboX.js"></script>

    </head>

    </html>
    复制代码

    将JS弹窗改为Android弹窗方法SetJavaScriptAlertEnable();

    private void SetJavaScriptAlertEnable() {
    // 由于设置了弹窗检验调用结果,所以需要支持js对话框
    // webview只是载体,内容的渲染需要使用webviewChromClient类去实现
    // 通过设置WebChromeClient对象处理JavaScript的对话框
    //设置响应js 的Alert()函数
    mWebView.setWebChromeClient(new WebChromeClient() {
    @Override
    public boolean onJsAlert(WebView view, String url, String message, final JsResult result) {
    //设置弹窗
    AlertDialog.Builder b = new AlertDialog.Builder(MainActivity.this);
    b.setTitle("Alert");
    b.setMessage(message);
    b.setPositiveButton(android.R.string.ok, new DialogInterface.OnClickListener() {
    @Override
    public void onClick(DialogInterface dialog, int which) {
    result.confirm();
    }
    });
    b.setCancelable(true);
    b.create().show();
    return true;
    }
    });
    }
    复制代码

    初始化界面用button测试程序是否能通信。

    private void InitView() {

    button = (Button) findViewById(R.id.button);

    button.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
    // 通过Handler发送消息
    mWebView.post(new Runnable() {
    @Override
    public void run() {

    // 注意调用的JS方法名要对应上
    // 调用javascript的callJS()方法
    final int version = Build.VERSION.SDK_INT;//获取系统版本
    //我们需要判断当前系统版本。为了尽可能减少错误我们使用了两种方式来实现调用JS方法。
    if (version < 18) {
    mWebView.loadUrl("javascript:callJS()");
    } else {

    // Toast.makeText(getApplicationContext(), "单击完成", Toast.LENGTH_SHORT).show();


    //Toast.makeText(getApplicationContext(), ans.toString(), Toast.LENGTH_SHORT).show();
    mWebView.evaluateJavascript("javascript:callJS()", new ValueCallback<String>() {
    @Override
    public void onReceiveValue(String value) {
    //此处为 js 返回的结果
    }
    });
    mWebView.evaluateJavascript("javascript:change()", new ValueCallback<String>() {
    @Override
    public void onReceiveValue(String value) {
    //此处为 js 返回的结果
    }
    });
    }
    }
    });

    }
    });
    }
    复制代码

    下面是JS同Android的通信,JS调用Android的函数方法。

    将上边webview初始化中取消注释SetWebChromeClient()同时取消注mWebView.addJavascriptInterface(new AndroidtoJs(), "test");重新创建一个类继承于Object同时创建的test对象在js中同样如此像HTML文件中的

    function callAndroid(){
    // 由于对象映射,所以调用test对象等于调用Android映射的对象
    test.hello("js调用了android中的hello方法");
    }
    复制代码

    下面是创建的类AndroidtoJS

    import android.webkit.JavascriptInterface;

    public class AndroidtoJs extends Object {
    @JavascriptInterface
    public void hello(String msg) {
    System.out.println("JS调用了Android的hello方法woc");
    }
    }

    复制代码

    SetWebChromeClient()是处理JS和Android之间通信的在下边有详细解释

    private void SetWebChromeClient() {
    mWebView.setWebChromeClient(new WebChromeClient() {
    // 拦截输入框(原理同方式2)
    // 参数message:代表promt()的内容(不是url)
    // 参数result:代表输入框的返回值
    @RequiresApi(api = Build.VERSION_CODES.HONEYCOMB)
    @Override
    public boolean onJsPrompt(WebView view, String url, String message, String defaultValue, JsPromptResult result) {
    // 根据协议的参数,判断是否是所需要的url(原理同方式2)
    // 一般根据scheme(协议格式) & authority(协议名)判断(前两个参数)
    //假定传入进来的 url = "js://demo?arg1=111&arg2=222"(同时也是约定好的需要拦截的)

    Uri uri = Uri.parse(message);
    // 如果url的协议 = 预先约定的 js 协议
    // 就解析往下解析参数
    if (uri.getScheme().equals("js")) {

    // 如果 authority = 预先约定协议里的 webview,即代表都符合约定的协议
    // 所以拦截url,下面JS开始调用Android需要的方法
    if (uri.getAuthority().equals("demo")) {

    //
    // 执行JS所需要调用的逻辑
    System.out.println("js调用了Android的方法");
    // 可以在协议上带有参数并传递到Android上
    HashMap<String, String> params = new HashMap<>();
    Set<String> collection = uri.getQueryParameterNames();

    //参数result:代表消息框的返回值(输入值)
    result.confirm("js调用了Android的方法成功啦");
    }
    return true;
    }
    return super.onJsPrompt(view, url, message, defaultValue, result);
    }

    // 通过alert()和confirm()拦截的原理相同,此处不作过多讲述
    // 拦截JS的警告框
    @Override
    public boolean onJsAlert(WebView view, String url, String message, JsResult result) {
    return super.onJsAlert(view, url, message, result);
    }

    //拦截JS的确认框
    @Override
    public boolean onJsConfirm(WebView view, String url, String message, JsResult result) {
    return super.onJsConfirm(view, url, message, result);
    }
    }
    );
    }

    复制代码

    我们不是采用直接调用的方法而是采用拦截的方法

    第一次接触Android项目有的地方写的可能有问题有的地方说的也可不能不准确,大家下方积极留言,第一次写博客排版也没搞好大家见谅吧哈哈哈哈。

    收起阅读 »

    算法与数据结构之数组

    个人说明:拿过国内某算法大赛全国三等。。。(渣渣) 概念它用一组连续的内存空间,来存储一组具有相同类型的数据。优点:查找速度快,可以快速随机访问缺点:删除,插入效率低,大小固定,不支持动态扩展,要求内存空间必须连续数组是一种线性表结构 基本操作(以下图都是盗的...
    继续阅读 »

    个人说明:拿过国内某算法大赛全国三等。。。(渣渣)


    概念

    它用一组连续的内存空间,来存储一组具有相同类型的数据。
    优点:查找速度快,可以快速随机访问
    缺点:删除,插入效率低,大小固定,不支持动态扩展,要求内存空间必须连续
    数组是一种线性表结构

    基本操作(以下图都是盗的,有侵的话私聊我)

    插入:

    如果要想在任意位置插入元素,那么必须要将这个位置后的其他元素后移。
    那么其最好的时间复杂度O(1) 最差的时间复杂度为O(n)
    在这里插入图片描述

    删除

    同样的删除数据需要前移


    注意事项:
    如果插入的数据多的情况下,那么数组的容量是固定的,那么就存在扩容的操作。
    同样的,如果删除数据多的情况下,也会出现缩容的操作
    例:java的arraylist
    首先,先看看ArrayList的初始化,源码如下:

    public ArrayList(int initialCapacity) {
    if (initialCapacity > 0) {
    //更根据初始值大小创建数组
    this.elementData = new Object[initialCapacity];
    } else if (initialCapacity == 0) {
    //默认无规定初始值大小时,会创建一个空数组
    //private static final Object[] EMPTY_ELEMENTDATA = {};
    //待通过add方法时创建初始容量为10的数组
    this.elementData = EMPTY_ELEMENTDATA;
    } else {
    throw new IllegalArgumentException("Illegal Capacity: "+
    initialCapacity);
    }
    }

    add(E e)方法的源码解析


    public boolean add(E e) {
    //检查是否需要扩容
    ensureCapacityInternal(size + 1); // Increments modCount!!
    //添加新元素
    elementData[size++] = e;
    return true;
    }

    //传入数组最小所需要的长度
    private void ensureCapacityInternal(int minCapacity) {
    ensureExplicitCapacity(calculateCapacity(elementData, minCapacity));
    }
    //检查原先数组是否为空数组,返回数组所需最小长度
    private static int calculateCapacity(Object[] elementData, int minCapacity) {
    //判断数组是否为空。
    //private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {};
    if (elementData == DEFAULTCAPACITY_EMPTY_ELEMENTDATA) {
    //private static final int DEFAULT_CAPACITY = 10;
    //数组为空时,返回DEFAULT_CAPACITY与minCapacity中大的数,减少扩容次数
    return Math.max(DEFAULT_CAPACITY, minCapacity);
    }
    //直接返回数组所需的最小长度size+1
    return minCapacity;
    }

    //判断当前数组长度是否超过添加元素所需的最小长度
    private void ensureExplicitCapacity(int minCapacity) {
    modCount++;

    // overflow-conscious code
    //如果所需最小长度大于当前数组长度
    if (minCapacity - elementData.length > 0)
    //进行扩容
    grow(minCapacity);
    //否则,不做任何处理
    }


    private void grow(int minCapacity) {
    // overflow-conscious code
    int oldCapacity = elementData.length;
    //新数组长度等于旧长度+1/2旧长度
    int newCapacity = oldCapacity + (oldCapacity >> 1);
    //计算newCapacity的大小
    if (newCapacity - minCapacity < 0)
    newCapacity = minCapacity;
    //private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8;
    if (newCapacity - MAX_ARRAY_SIZE > 0)
    newCapacity = hugeCapacity(minCapacity);
    // minCapacity is usually close to size, so this is a win:
    //拷贝到新数组,数组长度为newCapacity
    elementData = Arrays.copyOf(elementData, newCapacity);
    }

    private static int hugeCapacity(int minCapacity) {
    if (minCapacity < 0) // overflow
    throw new OutOfMemoryError();
    return (minCapacity > MAX_ARRAY_SIZE) ?
    Integer.MAX_VALUE :
    MAX_ARRAY_SIZE;
    }

    ArrayList缩容
    ArrayList没有自动缩容机制。无论是remove方法还是clear方法,它们都不会改变现有数组elementData的长度。但是它们都会把相应位置的元素设置为null,以便垃圾收集器回收掉不使用的元素,节省内存。ArrayList的缩容,需要我们自己手动去调用trimToSize()方法,达到缩容的目的。

    /**
    * Trims the capacity of this <tt>ArrayList</tt> instance to be the
    * list's current size. An application can use this operation to minimize
    * the storage of an <tt>ArrayList</tt> instance.
    */
    public void trimToSize() {
    modCount++;
    //判断当前容量与数组长度的大小关系
    if (size < elementData.length) {
    //如果size小于elementData.length,则将数组拷贝到长度为size的数组中,如果size==0,则将elementData 置为空数组,{}
    elementData = (size == 0)
    ? EMPTY_ELEMENTDATA
    : Arrays.copyOf(elementData, size);
    }
    }

    有关数组的算法

    以下算法只给思路(代码写一写就知道了)


    数组算法注意事项

    并没什么可注意的,哈哈哈哈
    在这里插入图片描述
    有一点就是:数组根据下标进行访问时,时间复杂度为O(1),进行插入和删除操作时,时间复杂度为O(n)(主要就是结构可以让他这么屌)

    算法一(一个未排序的整数数组,找出最长连续序列的长度。)

    leetcode等级困难
    时间要求O(n)
    示例:

    输入: [100, 4, 200, 1, 3, 2]
    输出: 4
    解释: 最长连续序列是 [1, 2, 3, 4]。它的长度为 4。

    思路:
    java中Hashset数组是个没有重复元素的集合,那么可以将所有数据存入到set中,之后进行顺序删除,把数组进行遍历,把每个遍历的元素进行删除,删除的最大长度则为数组最大序列长度。

    public int longestConsecutive(int[] nums) {
    if(nums.length<=0){
    return 0;
    }
    Set<Integer> set = new HashSet<>();
    for(int n : nums){
    set.add(n);
    }
    int maxv = 1;
    for(int n : nums){
    if(!set.remove(n)){
    continue;
    }
    int vb = 1;
    int va = 1;
    while (set.remove(n-vb)){ vb++; }
    while (set.remove(n+va)){ va++; }
    maxv = Math.max(maxv,vb + va -1);
    }
    return maxv;
    }

    时间复杂度为O(n)空间复杂度为O(n) remove 的次数最多为n


    算法二(奇偶数排序)

    给定一个整数数组,请调整数组中数的顺序,使得所有奇数位于数组的前半部分,所有偶数位于数组的后半部分。
    要求时间复杂度为O(n)
    思路:
    双指针法,可以两个指针分别从前往后,进行交换。

    算法三(两个有序整数数组成为一个有序数组)

    给你两个有序整数数组 nums1 和 nums2,请你将 nums2 合并到 nums1 中,使 nums1 成为一个有序数组。


    示例 1:
    输入:nums1 = [1,2,3,0,0,0], m = 3, nums2 = [2,5,6], n = 3
    输出:[1,2,2,3,5,6]

    思路:
    双指针法
    收起阅读 »

    算法与数据结构之算法复杂度

    情景回顾平时在聊天谈论算法时候,发现很多人并不清楚算法的时间复杂度怎么计算,一些稍微复杂的算法时间复杂度问题,就无法算出时间复杂度。那么我在今天的文章里去解答这些问题 时间复杂度与空间复杂度时间复杂度执行这个算法所需要的计算工作量 随着输入数据的规模,时间也...
    继续阅读 »

    情景回顾

    平时在聊天谈论算法时候,发现很多人并不清楚算法的时间复杂度怎么计算,一些稍微复杂的算法时间复杂度问题,就无法算出时间复杂度。那么我在今天的文章里去解答这些问题


    时间复杂度与空间复杂度

    时间复杂度

    执行这个算法所需要的计算工作量



    1. 随着输入数据的规模,时间也不断增长,那么时间复杂度就是一个算法性能可观的数据。


    2. 由于实际算法的时间会根据机器的性能,软件的环境导致不同的结果,那么通常都是预估这个时间。


    3. 算法花费时间与执行语句次数成正比,执行次数称为语句频度或时间频度。记为T(n)


    4. 在时间频度中,n称为问题的规模,当n不断变化时,它所呈现出来的规律,称之为时间复杂度



    说明:



    • 若算法中的语句执行次数为一个常数,则时间复杂度为o(1)
    • 不同算法的时间频度不一样,但他们的时间复杂度却可能是一样的。

    例如:T(n)=2n+4+n^2
    T(n)=n+8 + 4n^2
    很明显时间频度不同,但是他们时间复杂度是相同的 都为O(n^2)

    计算时间复杂度步骤:


    1. 找出算法中的基本语句(执行次数最多的那条语句就是基本语句,通常是最内层循环的循环体。)
    2. 计算基本语句的执行次数的数量级(只要保证基本语句执行次数的函数中的最高次幂正确即可,可以忽略所有低次幂和最高次幂的系数。这样能够简化算法分析,并且使注意力集中在最重要的一点上:增长率。)
    3. 用大Ο记号表示算法的时间性能。

    原则:



    1. 如果运行时间是常数量级,用常数1表示
    2. 只保留时间函数中的最高阶项
    3. 如果最高阶项存在,则省去最高阶项前面的系数

    例1:


            for(i in 0..n){
    a++
    }
    for(i in 0..n){
    for(i in 0..n){
    a++
    }
    }

    在看这个算法时候,很明显时间 复杂度为O(n+n^2) 但要留下最高阶 也就是O(n^2)
    例2:

            for(i in 0..n){
    a++
    b++
    c++
    }

    在看这个算法时候,很明显时间 复杂度为O(3n) 但要抹掉常数3 也就是O(n)


    例3:


            var i = 1
    while (i < n) {
    a++
    b++
    c++
    i *= 2
    }

    在看这个算法时候,很明显时间 复杂度为O(3logn) 但要抹掉常数3 也就是O(logn)


    例4:


               a++
    b++
    c++

    在看这个算法时候,很明显时间 复杂度为O(3) 常数级别的算法都为O(1)


    平衡二叉搜索树的时间复杂度是怎么计算出来的呢(重点)

    为啥我要加个重点标识呢?因为很多人都不晓得平衡二叉搜索树的O(logn)是咋计算出来的,今天我给大家掰扯掰扯


    假设生成高度树h的节点数是n(h) ,高度为h-1的节点数为n(h-1)
    他们之间的关系为 n(h) = n(h-1)+n(h-1)+1
    n(h) = 2n(h-1)+1
    n(h) 约等于 2n(h-1)
    注意的一点 n(h-1) 几乎是一半的节点数目
    基准点 h(0) = 1 h(1) = 3
    依次类推
    n(h) 约等于 h^2
    那么
    n(h) = h^2
    那么
    h = log2n
    则平衡二叉搜索树的时间复杂度 O(logn)

    时间复杂度比较

    常见的时问复杂度如表所
    在这里插入图片描述
    常用的时间复杂度所耗费的时间从小到大依次是:
    在这里插入图片描述
    复杂度在1s内,能处理的数据量大小
    在这里插入图片描述

    复杂度分析的4个概念


    1. 最坏情况时间复杂度:代码在最坏情况下执行的时间复杂度。
    2. 最好情况时间复杂度:代码在最理想情况下执行的时间复杂度。
    3. 平均时间复杂度:代码在所有情况下执行的次数的加权平均值。
    4. 均摊时间复杂度:在代码执行的所有复杂度情况中绝大部分是低级别的复杂度,个别情况是高级别复杂度且发生具有时序关系时,可以将个别高级别复杂度均摊到低级别复杂度上。基本上均摊结果就等于低级别复杂度。

    为什么要引入这4个概念?



    1. 同一段代码在不同情况下时间复杂度会出现量级差异,为了更全面,更准确的描述代码的时间复杂度,所以引入这4个概念。
    2. 代码复杂度在不同情况下出现量级差别时才需要区别这四种复杂度。大多数情况下,是不需要区别分析它们的。

    如何分析平均、均摊时间复杂度?



    1. 平均时间复杂度
      代码在不同情况下复杂度出现量级差别,则用代码所有可能情况下执行次数的加权平均值表示。
    2. 均摊时间复杂度
      两个条件满足时使用:
      1)代码在绝大多数情况下是低级别复杂度,只有极少数情况是高级别复杂度;
      2)低级别和高级别复杂度出现具有时序规律。均摊结果一般都等于低级别复杂度。

    最坏情况与平均情况

    我们查找一个有n 个随机数字数组中的某个数字,最好的情况是第一个数字就是,那么算法的时间复杂度为O(1),但也有可能这个数字就在最后一个位置上待着,那么算法的时间复杂度就是O(n),这是最坏的一种情况了。
    最坏情况运行时间是一种保证,那就是运行时间将不会再坏了。 在应用中,这是一种最重要的需求, 通常, 除非特别指定, 我们提到的运行时间都是最坏情况的运行时间。
    而平均运行时间也就是从概率的角度看, 这个数字在每一个位置的可能性是相同的,所以平均的查找时间为n/2次后发现这个目标元素。平均运行时间是所有情况中最有意义的,因为它是期望的运行时间。也就是说,我们运行一段程序代码时,是希望看到平均运行时间的。可现实中,平均运行时间很难通过分析得到,一般都是通过运行一定数量的实验数据后估算出来的。一般在没有特殊说明的情况下,都是指最坏时间复杂度。

    空间复杂度

    执行这个算法所需要的内存空间



    1. 空间复杂度是对一个算法在运行过程中临时占用存储空间大小的量度
    2. 在算法计算中,其中的辅助变量与空间复杂度相关
    3. 一般的,只要算法不涉及到动态分配的空间,以及递归、栈所需的空间,空间复杂度通常为O(1)
    4. 时间复杂度和空间复杂度往往是相互影响,空间复杂度越好相对的时间会耗费的较多,反之亦然。


            var m = arrayOfNulls<Int>(n)
    for(i in 0..n){
    a++
    m[i] = a
    }

    空间复杂度为 O(n)


    常用算法的时间复杂度和空间复杂度

    在这里插入图片描述
    收起阅读 »

    算法与数据结构之链表

    个人说明:拿过国内某算法大赛全国三等。。。(渣渣) 概念链表是计算机数据结构中比较重要的一个,也是最基础之一。在开发过程中,有些时候会采用这种结构。链表可以说是一种动态的数据结构。链表是一种物理存储上非连续的存储结构,数据的顺序与关联通过链表中的节点指针来实现...
    继续阅读 »

    个人说明:拿过国内某算法大赛全国三等。。。(渣渣)


    概念

    链表是计算机数据结构中比较重要的一个,也是最基础之一。在开发过程中,有些时候会采用这种结构。链表可以说是一种动态的数据结构。
    链表是一种物理存储上非连续的存储结构,数据的顺序与关联通过链表中的节点指针来实现。结点可以动态变更,那也就说明链表这种结构可快速添加数据。
    链表是一种线性表结构

    链表分类(以下图都是盗的,有侵的话私聊我)

    单链表

    链表中的元素的指向只能指向链表中的下一个元素或者为空,元素之间不能相互指向,是一种线性链表
    在这里插入图片描述

    循环链表

    在单向链表和双向链表的基础上,将两种链表的最后一个结点指向第一个结点从而实现循环
    在这里插入图片描述

    双向链表

    每个节点既有指向下一个元素的指针,又有指向前一个元素的指针,其中每个结点都有两种指针
    在这里插入图片描述

    基本单位

    节点
    包含下一节点(上一节点)指针与数据

    基本操作

    就拿单链表作为示例(其他链表操作没太大区别)


    删除节点

    在这里插入图片描述
    删除头节点:
    直接让root节点指向头节点的下一个节点
    删除中间节点:
    直接让中间节点的前一个节点指向当前节点的下一个节点
    删除尾节点:
    直接让当前尾节点的上一个节点指向null

    添加节点

    在这里插入图片描述
    增加的新节点会指向当前节点的下一个,那么当前节点的下一个又会指向新的节点。很快就增加了一个新节点。
    添加节点如果在头部的话,root指到新节点,新节点的下一个节点指向旧root
    添加尾节点的话,就让尾节点的下一个节点指向新节点
    例:java的LinkedList(本文针对的是1.7的源码)
    首先,先看看LinkedList的初始化,源码如下:
    LinkedList包含3个全局参数,
    size存放当前链表有多少个节点。
    first为指向链表的第一个节点的引用。
    last为指向链表的最后一个节点的引用。

    // 什么都没做,是一个空实现
    public LinkedList() {
    }

    public LinkedList(Collection<? extends E> c) {
    this();
    addAll(c);
    }

    public boolean addAll(Collection<? extends E> c) {
    return addAll(size, c);
    }

    public boolean addAll(int index, Collection<? extends E> c) {
    // 检查传入的索引值是否在合理范围内
    checkPositionIndex(index);
    // 将给定的Collection对象转为Object数组
    Object[] a = c.toArray();
    int numNew = a.length;
    // 数组为空的话,直接返回false
    if (numNew == 0)
    return false;
    // 数组不为空
    Node<E> pred, succ;
    if (index == size) {
    // 构造方法调用的时候,index = size = 0,进入这个条件。
    succ = null;
    pred = last;
    } else {
    // 链表非空时调用,node方法返回给定索引位置的节点对象
    succ = node(index);
    pred = succ.prev;
    }
    // 遍历数组,将数组的对象插入到节点中
    for (Object o : a) {
    @SuppressWarnings("unchecked") E e = (E) o;
    Node<E> newNode = new Node<>(pred, e, null);
    if (pred == null)
    first = newNode;
    else
    pred.next = newNode;
    pred = newNode;
    }

    if (succ == null) {
    last = pred; // 将当前链表最后一个节点赋值给last
    } else {
    // 链表非空时,将断开的部分连接上
    pred.next = succ;
    succ.prev = pred;
    }
    // 记录当前节点个数
    size += numNew;
    modCount++;
    return true;
    }

    Node节点类:


        private static class Node<E> {
    E item;
    Node<E> next;
    Node<E> prev;

    Node(Node<E> prev, E element, Node<E> next) {
    this.item = element;
    this.next = next;
    this.prev = prev;
    }
    }

    addFirst/addLast


    public void addFirst(E e) {
    linkFirst(e);
    }

    private void linkFirst(E e) {
    final Node<E> f = first;
    final Node<E> newNode = new Node<>(null, e, f); // 创建新的节点,新节点的后继指向原来的头节点,即将原头节点向后移一位,新节点代替头结点的位置。
    first = newNode;
    if (f == null)
    last = newNode;
    else
    f.prev = newNode;
    size++;
    modCount++;
    }

    getFirst/getLast


    public E getFirst() {
    final Node<E> f = first;
    if (f == null)
    throw new NoSuchElementException();
    return f.item;
    }

    public E getLast() {
    final Node<E> l = last;
    if (l == null)
    throw new NoSuchElementException();
    return l.item;
    }

    get方法,在操作时候会判断索引位置,来从后或从前找,提升查找效率


    public E get(int index) {
    // 校验给定的索引值是否在合理范围内
    checkElementIndex(index);
    return node(index).item;
    }

    Node<E> node(int index) {
    //如果索引小于size的一半则从前往后找,如果大于则从后往前找
    if (index < (size >> 1)) {
    Node<E> x = first;
    for (int i = 0; i < index; i++)
    x = x.next;
    return x;
    } else {
    Node<E> x = last;
    for (int i = size - 1; i > index; i--)
    x = x.prev;
    return x;
    }
    }

    removeFirst/removeLast


    public E removeFirst() {
    final Node<E> f = first;
    if (f == null)
    throw new NoSuchElementException();
    return unlinkFirst(f);
    }

    private E unlinkFirst(Node<E> f) {
    // assert f == first && f != null;
    final E element = f.item;
    final Node<E> next = f.next;
    f.item = null;
    f.next = null; // help GC
    //摘掉头结点,将原来的第二个节点变为头结点,改变frist的指向
    first = next;
    if (next == null)
    last = null;
    else
    next.prev = null;
    size--;
    modCount++;
    return element;
    }

    有关链表的算法

    以下算法只给思路(代码写一写就知道了)


    链表算法注意事项

    并没什么可注意的,哈哈哈哈
    在这里插入图片描述
    有一点就是:链表的插入和删除操作O(1)的复杂度(主要就是结构可以让他这么屌)

    算法一(单链表的倒数第K个结点)

    这是个比较简单的算法
    思路:由于单链表的结构无法从链表尾节点来倒序查找,那么你可以两个节点相差k-1来计算倒数k个节点,如果节点1的next是空,那么节点2就是你要找的。

    算法二(判断一个链表有环)

    首先创建两个指针1和2,同时指向这个链表的头节点。让指针1每次向下移动一个节点,让指针2每次向下移动两个节点,然后比较两个指针指向的节点是否相同。如果相同,则判断出链表有环,如果不同,则继续下一次循环。


    算法三(两个链表的第一个公共结点)

    将两个链表的节点分别存在两个栈中,


    生活中的算法(排排坐,赶走第三者)

    题目:
    有100人排排坐,从第一个人开始,喊号(1,2,3)。第一个人喊1,第二个人喊2,第三个人喊3,这时候第三个人就出队,第四个人开始喊1,如此循环,最后剩下哪个人?
    思路:
    循环链表,把100个人放到循环链表里,循环每次到三时候,把三这个删除节点,继续循环,直到一个节点的next指针指到自己,结束循环。
    收起阅读 »

    Jetpack之Lifecycle

    1.什么是Lifecycle Lifecycle是具备宿主生命周期感知能力的组件。它能持有组件(如Activity或Fragment)生命周期状态的信息,并且允许其他观察者监听宿主的状态。它也是Jetpack组件库的核心基础,包括我们就会讲到的LiveData...
    继续阅读 »

    1.什么是Lifecycle


    Lifecycle是具备宿主生命周期感知能力的组件。它能持有组件(如Activity或Fragment)生命周期状态的信息,并且允许其他观察者监听宿主的状态。它也是Jetpack组件库的核心基础,包括我们就会讲到的LiveData,ViewModel组件等也都是基于它来实现的。



    再也不用手动分发宿主生命周期,再也不用手动反注册了



    2.Lifecycle的使用方法


    使用Lifecycle前需要先添加依赖


    //通常情况下,只需要添加appcompat就可以了
    api 'androidx.appcompat:appcompat:1.1.0'

    //如果想单独使用,可引入下面这个依赖
    api 'androidx.lifecycle:lifecycle-common:2.1.0'
    复制代码

    被观察者


    通过实现LifecycleOwner接口


    androidx中的ComponentActivity和Fragment自生都已经实现了LifecycleOwner。


    public class ComponentActivity extends androidx.core.app.ComponentActivity implements
    LifecycleOwner,
    ViewModelStoreOwner,
    HasDefaultViewModelProviderFactory,
    SavedStateRegistryOwner,
    OnBackPressedDispatcherOwner {}

    //androidx.fragment.app.Fragment
    public class Fragment implements ComponentCallbacks, OnCreateContextMenuListener, LifecycleOwner,
    ViewModelStoreOwner, HasDefaultViewModelProviderFactory, SavedStateRegistryOwner {}
    复制代码

    如果要自己实现可以参考androidx的Activity和Fragment的实现。


    观察者


    方式一:LifecycleObserver配合注解


    //1. 自定义的LifecycleObserver观察者,用注解声明每一个观察者的宿主状态
    class LocationObserver implements LifecycleObserver{
    //宿主执行了onstart时,会分发该事件
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    void onStart(@NotNull LifecycleOwner owner){
    //开启定位
    }

    //宿主执行了onstop时 会分发该事件
    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    void onStop(@NotNull LifecycleOwner owner){
    //停止定位
    }
    }

    //2. 注册观察者,观察宿主生命周期状态变化
    class MyFragment extends Fragment{
    public void onCreate(Bundle bundle){
    LocationObserver observer =new LocationObserver()
    getLifecycle().addObserver(observer);
    }
    }
    复制代码

    方式二:实现FullLifecyclerObserver接口


    class LocationObserver implements FullLifecycleObserver{

    void onCreate(LifecycleOwner owner);

    void onStart(LifecycleOwner owner);

    void onResume(LifecycleOwner owner);

    void onPause(LifecycleOwner owner);

    void onStop(LifecycleOwner owner);

    void onDestroy(LifecycleOwner owner);

    }
    复制代码

    方式三:LifecycleEventObserver宿主生命周期事件封装成Lifecycle.Event


    //1.源码
    public interface LifecycleEventObserver extends LifecycleObserver {
    void onStateChanged(LifecycleOwner source, Lifecycle.Event event);
    }
    //2.用法
    class LocationObserver extends LifecycleEventObserver{
    @override
    void onStateChanged(LifecycleOwner source, Lifecycle.Event event){
    //需要自行判断life-event是onstart, 还是onstop
    }
    }
    复制代码

    上面的这两种Lifecycle写法比较推荐第二种和第三种,因为第一种你虽然用注解很爽,但是如果没有添加lifecycle-compiler这个注解处理器的话,运行时会使用反射的形式回调到对应的方法上。


    订阅关系


    //被观察者.addObserver(观察者)
    getLifecycle().addObserver(presenter);
    复制代码

    3.实现原理


    引入的库


    dependencies {
    implementation "androidx.lifecycle:lifecycle-runtime:2.0.0"
    implementation "androidx.lifecycle:lifecycle-extensions:2.0.0"
    implementation "androidx.lifecycle:lifecycle-common-java8:2.0.0"
    annotationProcessor "androidx.lifecycle:lifecycle-compiler:2.0.0"
    }
    复制代码

    核心类


    事件在分发宿主生命期事件的流程中涉及到三个类:



    • LifecycleOwner :Activity和Fragment都实现了该接口,用以生命周期观察,它是一个能够提供生命周期事件的宿主 。同时必须复写getLifecycle()方法提供一个Lifecycle对象;可以将其理解为观察者模式中的Observable。

    • Lifecycle :是一个抽象类 ,里面定义了两个枚举State宿主的状态,Event需要分发的事件的类型;

    • LifecycleRegistry :是Lifecycle的唯一实现类 ,主要用来负责注册Observer ,以及分发宿主状态事件给它们。LifecycleRegistr聚合多个LifecycleObserver,生命周期改变时通知LifecycleObserver进行相应的方法调用。


    img


    具体的类关系请看下面的Fragment的基本实现。


    宿主生命周期监听


    Fragment是如何实现Lifecycle的?


    使用Fragment实现Lifecycle需要在各个生命周期方法内里用LifecycleRegistry分发相应的事件给每个观察者,以实现生命周期观察的能力:


    public class Fragment implements LifecycleOwner {

    LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);

    @Override
    public Lifecycle getLifecycle() {
    //复写自LifecycleOwner,所以必须new LifecycleRegistry对象返回
    return mLifecycleRegistry;
    }

    void performCreate(){
    mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
    }

    void performStart(){
    mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START);
    }
    .....
    void performResume(){
    mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_RESUME);
    }

    }
    复制代码

    Activity是如何实现Lifecycle的?


    Activity实现Lifecycle需要借助于ReportFragment往Activity上添加一个fragment用以报告生命周期的变化。目的是为了兼容不是集成自
    AppCompactActivity的场景,同时也支持我们自定义LifecycleOwener的场景。


    public class ComponentActivity extends Activity implements LifecycleOwner{

    private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
    @NonNull
    @Override
    public Lifecycle getLifecycle() {
    return mLifecycleRegistry;
    }

    protected void onCreate(Bundle bundle) {
    super.onCreate(savedInstanceState);
    //往Activity上添加一个fragment,用以报告生命周期的变化
    //目的是为了兼顾不是继承自AppCompactActivity的场景.
    ReportFragment.injectIfNeededIn(this);
    }
    复制代码

    注意:ComponentActivity的部分生命周期是自己实现的,并不是全部都是ReportFragment实现的。


    ReportFragment核心源码


    这里的实现其实跟Fragment中的源码是一样的,在各个生命周期方法内利用LifecycleRegistry派发相应的Lifecycle.Event事件给每个观察者。


    注意:在具体的生命周期的调用上有所差异:


    SDK>=29:用LifecycleCallbacks进行回调


    SDK<29:用ReportFragment的生命周期中调用


    public class ReportFragment extends Fragment{


    public static void injectIfNeededIn(Activity activity) {

    //注意:在29以后对Activity注册了一个LifecycleCallbacks,这里的dispatch的调用时机有所差异
    if (Build.VERSION.SDK_INT >= 29) {
    activity.registerActivityLifecycleCallbacks(
    new LifecycleCallbacks());
    }


    android.app.FragmentManager manager = activity.getFragmentManager();
    if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
    manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
    manager.executePendingTransactions();
    }
    }


    @Override
    public void onStart() {
    super.onStart();
    dispatch(Lifecycle.Event.ON_START);
    }
    @Override
    public void onResume() {
    super.onResume();
    dispatch(Lifecycle.Event.ON_RESUME);
    }
    @Override
    public void onPause() {
    super.onPause();
    dispatch(Lifecycle.Event.ON_PAUSE);
    }
    @Override
    public void onDestroy() {
    super.onDestroy();
    dispatch(Lifecycle.Event.ON_DESTROY);
    }

    //只要<29才借助的ReportFragment的生命周期
    private void dispatch(@NonNull Lifecycle.Event event) {
    if (Build.VERSION.SDK_INT < 29) {
    dispatch(getActivity(), event);
    }
    //29之后的另外处理
    }

    //最终收拢在这里处理
    static void dispatch(@NonNull Activity activity, @NonNull Lifecycle.Event event) {
    //兼容Activity自己实现的LifecycleRegistryOwner
    if (activity instanceof LifecycleRegistryOwner) {
    ((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
    return;
    }

    if (activity instanceof LifecycleOwner) {
    Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
    if (lifecycle instanceof LifecycleRegistry) {
    ((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
    }
    }
    }
    }
    复制代码

    SDK29以后的实现调用


    //ReportFragment的静态内部类
    static class LifecycleCallbacks implements Application.ActivityLifecycleCallbacks {
    @Override
    public void onActivityCreated(@NonNull Activity activity,
    @Nullable Bundle bundle) {
    }

    @Override
    public void onActivityPostCreated(@NonNull Activity activity,
    @Nullable Bundle savedInstanceState) {
    //调用的是静态方法
    dispatch(activity, Lifecycle.Event.ON_CREATE);
    }

    @Override
    public void onActivityStarted(@NonNull Activity activity) {
    }

    @Override
    public void onActivityPostStarted(@NonNull Activity activity) {
    dispatch(activity, Lifecycle.Event.ON_START);
    }

    @Override
    public void onActivityResumed(@NonNull Activity activity) {
    }

    @Override
    public void onActivityPostResumed(@NonNull Activity activity) {
    dispatch(activity, Lifecycle.Event.ON_RESUME);
    }

    @Override
    public void onActivityPrePaused(@NonNull Activity activity) {
    dispatch(activity, Lifecycle.Event.ON_PAUSE);
    }

    @Override
    public void onActivityPaused(@NonNull Activity activity) {
    }

    @Override
    public void onActivityPreStopped(@NonNull Activity activity) {
    dispatch(activity, Lifecycle.Event.ON_STOP);
    }

    @Override
    public void onActivityStopped(@NonNull Activity activity) {
    }

    @Override
    public void onActivitySaveInstanceState(@NonNull Activity activity,
    @NonNull Bundle bundle) {
    }

    @Override
    public void onActivityPreDestroyed(@NonNull Activity activity) {
    dispatch(activity, Lifecycle.Event.ON_DESTROY);
    }

    @Override
    public void onActivityDestroyed(@NonNull Activity activity) {
    }
    }
    复制代码

    在Activity中的生命周期对进行回调


        //Activity
    private void dispatchActivityCreated(@Nullable Bundle savedInstanceState) {
    getApplication().dispatchActivityCreated(this, savedInstanceState);
    Object[] callbacks = collectActivityLifecycleCallbacks();
    if (callbacks != null) {
    for (int i = 0; i < callbacks.length; i++) {
    ((Application.ActivityLifecycleCallbacks) callbacks[i]).onActivityCreated(this,
    savedInstanceState);
    }
    }
    }

    private void dispatchActivityPostCreated(@Nullable Bundle savedInstanceState) {
    Object[] callbacks = collectActivityLifecycleCallbacks();
    if (callbacks != null) {
    for (int i = 0; i < callbacks.length; i++) {
    //回调监听
    ((Application.ActivityLifecycleCallbacks) callbacks[i]).onActivityPostCreated(this,
    savedInstanceState);
    }
    }
    getApplication().dispatchActivityPostCreated(this, savedInstanceState);
    }
    复制代码

    而dispatch()方法则会判断Activity是否实现了LifecycleOwner接口,如果实现了该接口就调用LifecycleRegister的handleLifecycleEvent()
    这样生命周期的状态就会借由LifecycleRegistry通知给各个LifecycleObserver从而调用其中对应Lifecycle.Event的方法。这种通过Fragment来感知Activity生命周期的方法其实在Glide的中也是有体现的。


    宿主生命周期与宿主状态模型图


    LifecycleRegistry在分发事件的时候会涉及到两个概念:



    • 宿主生命周期 :就是我们烂熟于心的onCreate,onStart,onResume,onPause,onStop...;

    • 宿主的状态 :这个不是很好理解,这个意思是指宿主执行了上述方法后,它处于对应周期的生命状态。


    从下面这张图不难看出宿主生命周期与宿主状态的对应关系分裂为onCreate-Created、onStart-Started、onResume-Resumed、onPause-Started、onStop-Created、onDestroy-Destroyed,这里不用全部记住有个印象即可。



    添加observer时,完整的生命周期事件分发


    基于Lifecycle的特性我们在任意生命周期方法内注册观察者都能接受到完整的生命周期事件,比如在onResume中注册一个观察者,它会依次收到:


    LifecycleEvent.onCreate -> LifecycleEvent.onStart -> LifecycleEvent.onResume
    复制代码

    image-20201224082259033


    分发同步生命周期


    添加Observer时完整的生命周期事件分发


    这一点需要掌握,面试中是肯定会考察的。但是如果没有看过源码是回答不上来的:


    public void addObserver(@NonNull LifecycleObserver observer) {
    //1.初始状态。添加新的Observer时,会首先根据宿主的状态计算出它的初始状态,只要不是在onDestroy中注册的,它的初始状态都是INITIALIZED
    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;

    //2.将观察者和状态封装。
    //会把observer包装成ObserverWithState,这个类主要是包含了观察者及其状态。每个事件都会经由这个对象类转发,这个类后面会来分析
    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
    //3.添加到集合,如果之前已经添加过了,则return
    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
    if (previous != null) {
    return;
    }

    State targetState = calculateTargetState(observer);
    //4.同步状态
    //这里的while循环,是实现上图状态同步与事件分发的主要逻辑
    //拿观察者的状态和宿主当前状态做比较,如果小于0,说明两者状态还没有对齐。
    while ((statefulObserver.mState.compareTo(targetState) < 0
    && mObserverMap.contains(observer))) {
    pushParentState(statefulObserver.mState);
    //接着就会分发一次相应的事件,于此同时statefulObserver的mState对象也会被升级
    //假设是在宿主的onresume方法内注册的该观察者
    //第一次:分发on_Create事件,观察者状态INIT->CREATED
    //第二次:分发on_Start事件,观察者状态CREATED->STARTED
    //第三次:分发on_Resume事件,观察者状态STARTED->RESUMED
    statefulObserver.dispatchEvent(lifecycleOwner, upEvent(statefulObserver.mState));
    //再一次计算观察者应该到达的状态,在下一轮循环中和宿主状态在做比较,知道两者状态对齐,退出循环。
    targetState = calculateTargetState(observer);
    }
    }
    复制代码

    宿主生命周期变化后相应事件的分发


    这一点了解即可,面试中也不会考这一部分的内容:


    //宿主生命周期变化时触发
    public void handleLifecycleEvent(@NonNull Lifecycle.Event event){
    //宿主的每个生命周期的变化都会分发一个对应的Lifecycle.Event,走到这里
    //此时会根据需要分发的事件反推出宿主当前的状态
    State next = getStateAfter(event);
    // moveToState方法只是将传入的宿主新的state和前持有宿主状态作比对,然后保存一下。
    moveToState(next);
    }

    private void moveToState(State next) {
    if (mState == next) {
    return;
    }
    mState = next;
    if (mHandlingEvent || mAddingObserverCounter != 0) {
    mNewEventOccurred = true;
    // we will figure out what to do on upper level.
    return;
    }
    mHandlingEvent = true;
    sync();
    mHandlingEvent = false;
    }

    //如果宿主状态有变动,则调用sync方法来完成事件的分发和观察者状态的同步
    private void sync() {
    while (!isSynced()) {
    //如果宿主当前转态 小于 mObserverMap集合中最先添加的那个观察者的状态
    //则说明宿主可能发生了状态回退,比如当前是RESUMED状态,执行了onPause则回退到STARTED状态
    //此时调用backwardPass把集合中的每个一观察者分发一个on_pause事件,并同步它的状态。
    if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
    backwardPass(lifecycleOwner);
    }
    //如果宿主当前转态 大于 mObserverMap集合中最先添加的那个观察者的状态
    //则说明宿主可能发生了状态前进,比如当前是STARTED状态,执行了onResume则前进到RESUMED状态
    //此时调用forwardPass把集合中的每个一观察者分发一个on_resume事件,并同步它的状态。
    Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
    if (!mNewEventOccurred && newest != null
    && mState.compareTo(newest.getValue().mState) > 0) {
    forwardPass(lifecycleOwner);
    }
    }
    }
    复制代码

    同步状态


    ObserverWithState:持有观察者及其状态的内部类


    把传入的LifecycleObserver适配成LifecycleEventObserver,目的是为了统一事件的分发形式。


    持有观察者的状态,方便与宿主状态做比对同步:


    static class ObserverWithState {
    State mState;
    LifecycleEventObserver mLifecycleObserver;
    ObserverWithState(LifecycleObserver observer, State initialState) {
    //把传入的LifecycleObserver适配成LifecycleEventObserver,目的是为了统一事件的分发形式
    //因为我们前面提到观察者有三种类型,每种类型接收事件的形式并不一样,如果在分发的时候不统一事件分发的形式,将会变得很麻烦
    //至于是如何适配转换的,由于不是本文重点,所以不再详细展开
    //但核心思想这里说明一下,同学们自行看下就能明白
    //它会判断传入的observer是前面提到的那一种类型,进而转换成对应的适配器类,适配器类会对onStateChanged方法进行适配,并以相应的方式(反射、中转、)把事件转发到我们的observer上
    mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
    mState = initialState;
    }

    void dispatchEvent(LifecycleOwner owner, Event event) {
    //再一次根据需要分发的事件类型反推出该观察者的状态,这样的好处是事件 & 状态 一一对应,不会出现跳跃。但阅读上可能会稍微有点绕
    State newState = getStateAfter(event);
    mState = min(mState, newState);
    //把事件分发给被包装的对象,完成本次流程。
    mLifecycleObserver.onStateChanged(owner, event);
    mState = newState;
    }
    }
    复制代码

    4.总结


    本篇从三种用法+分发原理+面试考点 三个维度展开对Lifecycle组件的介绍,现在相信同学们已经掌握了Lifecycle的核心了。Lifecycle组件是Jetpack组件库的核心,一旦跟宿主生命周期挂钩,那可以做很多文章,后面讲到的LiveData、ViewModel都是基于它来实现的。


    5.拓展


    基于Lifecycle实现APP前后台切换事件观察的能力。


    参考:使用 ProcessLifecycle 优雅地监听应用前后台切换


    class AppLifecycleOwner implements LifecycleOwner{
    LifecycleRegistry registry = new LifecycleRegistry(this)
    @override
    Lifecycle getLifecycle(){
    return registry
    }

    void init(Application application){
    //利用application的 ActivityLifecycleCallbacks 去监听每一个 Activity的onstart,onStop事件。
    //计算出可见的Activity数量,从而计算出当前处于前台还是后台。然后分发给每个观察者
    }
    }

    作者:贾里
    链接:https://juejin.cn/post/6953218024329445389
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    java设计模式:抽象工厂模式

    定义是一种为访问类提供一个创建一组相关或相互依赖对象的接口,且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。 抽象工厂模式是工厂方法模式的升级版本,工厂方法模式只生产一个等级的产品,而抽象工厂模式可生产多个等级的产品。 使用抽象工厂模式...
    继续阅读 »

    定义

    是一种为访问类提供一个创建一组相关或相互依赖对象的接口,且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。


    抽象工厂模式是工厂方法模式的升级版本,工厂方法模式只生产一个等级的产品,而抽象工厂模式可生产多个等级的产品。


    使用抽象工厂模式一般要满足以下条件。



    • 系统中有多个产品族,每个具体工厂创建同一族但属于不同等级结构的产品。
    • 系统一次只可能消费其中某一族产品,即同族的产品一起使用。

    优点

    抽象工厂模式除了具有工厂方法模式的优点外,其他主要优点如下。



    • 可以在类的内部对产品族中相关联的多等级产品共同管理,而不必专门引入多个新的类来进行管理。
    • 当需要产品族时,抽象工厂可以保证客户端始终只使用同一个产品的产品组。
    • 抽象工厂增强了程序的可扩展性,当增加一个新的产品族时,不需要修改原代码,满足开闭原则。

    缺点

    当产品族中需要增加一个新的产品时,所有的工厂类都需要进行修改。增加了系统的抽象性和理解难度。


    代码实现

    抽象工厂模式的主要角色如下。



    • 抽象工厂:提供了创建产品的接口,它包含多个创建产品的方法 newProduct(),可以创建多个不同等级的产品。
    • 具体工厂:主要是实现抽象工厂中的多个抽象方法,完成具体产品的创建。
    • 抽象产品:定义了产品的规范,描述了产品的主要特性和功能,抽象工厂模式有多个抽象产品。
    • 具体产品:实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间是多对一的关系。

    在这里插入图片描述

    interface IProduct{
    fun setPingPai(string: String)
    fun showName() :String
    }

    interface ITools{
    fun setPingPai(string: String)
    fun showName() :String
    }

    class Dog : IProduct{
    var pinPai:String? = null
    override fun setPingPai(string: String) {
    this.pinPai = string
    }

    override fun showName() = "dog"

    }

    class DogTools : ITools{
    var pinPai:String? = null
    override fun setPingPai(string: String) {
    this.pinPai = string
    }

    override fun showName() = "DogTools"

    }

    class Cat : IProduct{
    var pinPai:String? = null
    override fun setPingPai(string: String) {
    this.pinPai = string
    }
    override fun showName() = "cat"
    }

    class CatTools : ITools{
    var pinPai:String? = null
    override fun setPingPai(string: String) {
    this.pinPai = string
    }
    override fun showName() = "CatTools"
    }

    interface IFactory{
    fun getPinPai():String
    fun createProduct(type:Int):IProduct
    fun createProductTools(type:Int):ITools
    }

    class ABCFactory():IFactory{
    override fun getPinPai() = "ABC"

    override fun createProduct(type: Int): IProduct {
    return when(type){
    1-> Dog().apply { setPingPai(getPinPai()) }
    2-> Cat().apply { setPingPai(getPinPai()) }
    else -> throw NullPointerException()
    }
    }

    override fun createProductTools(type: Int): ITools {
    return when(type){
    1-> DogTools().apply { setPingPai(getPinPai()) }
    2-> CatTools().apply { setPingPai(getPinPai()) }
    else -> throw NullPointerException()
    }
    }

    }

    class CBDFactory():IFactory{
    override fun getPinPai() = "CBD"
    override fun createProduct(type: Int): IProduct {
    return when(type){
    1-> Dog().apply { setPingPai(getPinPai()) }
    2-> Cat().apply { setPingPai(getPinPai()) }
    else -> throw NullPointerException()
    }
    }

    override fun createProductTools(type: Int): ITools {
    return when(type){
    1-> DogTools().apply { setPingPai(getPinPai()) }
    2-> CatTools().apply { setPingPai(getPinPai()) }
    else -> throw NullPointerException()
    }
    }

    }

    收起阅读 »

    聊聊 Activity 的启动模式

    Activity 的启动模式本身是一个挺难理解的知识点,大多数开发者对这个概念的了解可能只限于四种 launchMode 属性值,但启动模式其实还需要受 Intent flag 的影响。而且 Activity 启动模式并不只是单纯地用来启动一个 Activit...
    继续阅读 »

    Activity 的启动模式本身是一个挺难理解的知识点,大多数开发者对这个概念的了解可能只限于四种 launchMode 属性值,但启动模式其实还需要受 Intent flag 的影响。而且 Activity 启动模式并不只是单纯地用来启动一个 Activity,实际上还会直接影响到用户的直观感受和使用体验,因为启动模式直接就决定了应用的任务栈和返回栈,这都是用户能直接接触到的


    本篇文章就来简单介绍下 Activity 的启动模式,希望对你有所帮助 😇😇


    1、任务栈


    任务栈是指用户在执行某项工作时与之互动的一系列 Activity 的集合,这些 Activity 按照打开的顺序排列在一个后进先出的栈中。例如,电子邮件应用包含一个 Activity 来显示邮件列表,当用户选择一封邮件时就会打开一个新的 Activity 来显示邮件详情,这个新的 Activity 就会添加到任务栈中,被推送到栈顶部并获得焦点,从而获得了与用户进行交互的机会。当用户按返回键时,邮件详情 Activity 就会从任务栈中退出并被销毁,邮件列表 Activity 就会成为新的栈顶并重新获得焦点


    任务栈代表的是一个整体,本身包含了多个 Activity,当任务栈中的所有 Activity 都被弹出后,任务栈也就随之就被回收了。就像下图所示,三个 Activity 通过相继启动组成了一个任务栈,Activity 1 是整个任务栈的根 Activity,当用户不断按返回键,Activity 就会依次被弹出



    2、返回栈


    返回栈是从用户使用的角度来进行定义的,返回栈中包含一个或多个任务栈,但同时只会有一个任务栈够处于前台,只有处于前台任务栈的 Activity 才能与用户交互


    例如,用户先启动了应用 A,先后打开了 Activity 1 和 Activity 2,此时 Task A 是前台任务栈。之后用户又点击 Home 键回到了桌面,启动了应用 B,又先后打开了 的 Activity 3 和 Activity 4,此时 Task B 就成为了前台任务栈,Task A 成了后台任务栈。用户点击返回键的过程中依次展现的页面就会是 Activity 4 -> Activity 3 -> 桌面


    而如果用户在打开应用 B 时并没有回到桌面,而是直接通过应用 A 启动了应用 B 的话,用户点击返回键的过程中依次展现的页面就会是 Activity 4 -> Activity 3 -> Activity 2 -> Activity 1 -> 桌面


    返回栈所表示的就是当用户不断回退页面时所能看到的一系列 Activity 的集合,而这些页面可能是处于多个不同的任务栈中。在第一种情况中,返回栈只包含 Task B 一个任务栈,所以当 Task B 被清空后就会直接回到桌面。在第二种情况中,返回栈中包含 Task A 和 Task B 两个任务栈,所以当 Task B 被清空后也会先切回到 Task A,等到 Task A 也被清空后才会回到桌面


    需要注意的是,返回栈中包含的多个任务栈之间并没有强制的先后顺序,多个任务栈之间的叠加关系可以随时发现变化。例如,当应用 A 启动了应用 B 后,Task B 是处于 Task A 之上,但之后如果应用 B 又反向启动了应用 A 的话,Task A 就会重新成为前台 Task 并覆盖在 Task B 之上


    3、taskAffinity


    返回栈这个概念对应的就是 taskAffinity,是 Activity 在 AndroidManifest 文件中声明的一个属性值。taskAffinity 翻译为“亲和性”,用于表示特定 Activity 倾向于将自身存放在哪个任务栈中


    在默认情况下,同一应用中的所有 Activity 会具有相同的亲和性,所有 Activity 默认会以当前应用的 applicationId 作为自己的 taskAffinity 属性值。我们可以手动为应用内的部分 Activity 指定特定的 taskAffinity,从而将这部分 Activity 进行分组


            <activity
    android:name=".StandardActivity"
    android:launchMode="standard"
    android:taskAffinity="task.test1" />
    <activity
    android:name=".SingleTopActivity"
    android:launchMode="singleTop"
    android:taskAffinity="task.test2" />
    <activity
    android:name=".SingleTaskActivity"
    android:launchMode="singleTask"
    android:taskAffinity="task.test3" />
    <activity
    android:name=".SingleInstanceActivity"
    android:launchMode="singleInstance"
    android:taskAffinity="task.test4" />
    复制代码

    从概念上讲,具有相同 taskAffinity 的 Activity 归属于同一任务栈(实际上并不一定)。从用户的角度来看则是归属于同一“应用”,因为每种 taskAffinity 在最近任务列表中会各自独占一个列表项,看起来就像一个个单独的应用,而实际上这些列表项可能是来自于同个应用


    4、启动模式


    Activity 的启动模式是一个很复杂的难点,其决定了要启动的 Activity 和任务栈还有返回栈之间的关联关系,直接影响到了用户的直观感受


    启动模式就由 launchMode 和 Intent flag 这两者来共同决定,我们可以通过两种方式来进行定义:



    • 在 AndroidManifest 文件中为 Activity 定义 launchMode 属性值,一共包含四种类型的属性值

    • 当通过 startActivity(Intent) 启动 Activity 时,向 Intent 添加或设置 flag 标记位,通过该 flag 来定义启动模式


    如果只看四个 launchMode 的话其实并不难理解,可是再考虑多应用交互还有 Intent flag 的话,情况就会变得复杂很多,其复杂性和难点主要就在于:单个任务栈包含的 Activity 可以是来自于不同的应用、单个应用也可以包含多个任务栈、返回栈包含的多个任务栈之间也可以进行顺序切换、甚至任务栈中的 Activity 也可以被迁移到另外一个任务栈、Intent flag 可以多个组合使用


    有些启动模式可通过 launchMode 来定义,但不能通过 Intent flag 定义,同样,有些启动模式可通过 Intent flag 定义,却不能在 launchMode 中定义。两者互相补充,但不能完全互相替代,且 Intent flag 的优先级会更高一些


    5、launchMode


    launchMode 一共包含以下四种属性值:



    • standard。默认模式。系统会在启动该 Activity 的任务栈中创建一个目标 Activity 的新实例,使该目标 Activity 成为任务栈的栈顶。该模式下允许先后启动多个相同的目标 Activity,一个任务栈可以拥有多个目标 Activity 实例,且不同 Activity 实例可以属于不同的任务栈

    • singleTop。如果当前任务栈的顶部已存在目标 Activity 的实例,则系统会通过调用其 onNewIntent() 方法来将 Intent 转送给该实例并进行复用,否则会创建一个目标 Activity 的新实例。目标 Activity 可以多次实例化,不同实例可以属于不同的任务栈,一个任务栈可以拥有多个实例(此时多个实例不会连续叠放在一起)

    • singleTask。如果系统当前不包含目标 Activity 的目标任务栈,那么系统就会先创建出目标任务栈,然后实例化目标 Activity 使之成为任务栈的根 Activity。如果系统当前包含目标任务栈,且该任务栈中已存在该目标 Activity 的实例,则系统会通过调用其 onNewIntent() 方法将 Intent 转送给该现有实例,而不会创建新实例,并同时弹出该目标 Activity 之上的所有其它实例,使目标 Activity 成为栈顶。如果系统当前包含目标任务栈,但该任务栈不包含目标 Activity 实例,则会实例化目标 Activity 并将其入栈。因此,系统全局一次只能有一个目标 Activity 实例存在

    • singleInstance。与 singleTask 相似,唯一不同的是通过 singleInstance 启动的 Activity 会独占一个任务栈,系统不会将其和其它 Activity 放置到同个任务栈中,由该 Activity 启动的任何 Activity 都会在其它的任务栈中打开


    四种 launchMode 还是很好理解的,当中比较特殊的应该属 singleTask,使用 singleTask 标记的 Activity 会有将自己存放在特定任务栈的倾向。如果目标任务栈和目标 Activity 都已经存在,则会进行复用,否则才会创建目标任务栈和目标 Activity。singleInstance 则是在 singleTask 的基础上多了一个“独占任务栈”的特性


    采用 singleTask 启动的 Activity 添加到返回栈的过程就如下图所示。一开始返回栈中只包含 Activity 1 和 Activity 2 组成的任务栈,当 Activity 2 启动了处于后台的 Activity Y 时,Activity Y 和 Activity X 组成的任务栈就会被转到前台,覆盖住当前任务栈。最终返回栈中就变成了四个 Activity



    再来写个 Demo 来验证下这四种 launchMode 的效果


    声明四种不同 launchMode 的 Activity,每个 Activity 均声明了不同的 taskAffinity


            <activity
    android:name=".StandardActivity"
    android:launchMode="standard"
    android:taskAffinity="task.a" />
    <activity
    android:name=".SingleTopActivity"
    android:launchMode="singleTop"
    android:taskAffinity="task.b" />
    <activity
    android:name=".SingleTaskActivity"
    android:launchMode="singleTask"
    android:taskAffinity="task.c" />
    <activity
    android:name=".SingleInstanceActivity"
    android:launchMode="singleInstance"
    android:taskAffinity="task.d" />
    复制代码

    通过打印 Activity 的 hashCode() 方法返回值来判断 Activity 的实例是否被复用了,再通过 getTaskId() 方法来判断 Activity 处于哪个任务栈中


    /**
    * @Author: leavesC
    * @Date: 2021/4/16 16:38
    * @Desc:
    * @Github:https://github.com/leavesC
    */
    abstract class BaseLaunchModeActivity : BaseActivity() {

    override val bind by getBind<ActivityBaseLaunchModeBinding>()

    override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    bind.tvTips.text =
    getTip() + "\n" + "hashCode: " + hashCode() + "\n" + "taskId: " + taskId
    bind.btnStartStandardActivity.setOnClickListener {
    startActivity(StandardActivity::class.java)
    }
    bind.btnStartSingleTopActivity.setOnClickListener {
    startActivity(SingleTopActivity::class.java)
    }
    bind.btnStartSingleTaskActivity.setOnClickListener {
    startActivity(SingleTaskActivity::class.java)
    }
    bind.btnStartSingleInstanceActivity.setOnClickListener {
    startActivity(SingleInstanceActivity::class.java)
    }
    log("onCreate")
    }

    override fun onNewIntent(intent: Intent?) {
    super.onNewIntent(intent)
    log("onNewIntent")
    }

    override fun onDestroy() {
    super.onDestroy()
    log("onDestroy")
    }

    abstract fun getTip(): String

    private fun log(log: String) {
    Log.e(getTip(), log + " " + "hashCode: " + hashCode() + " " + "taskId: " + taskId)
    }

    }

    class StandardActivity : BaseLaunchModeActivity() {

    override fun getTip(): String {
    return "StandardActivity"
    }

    }
    复制代码

    四个 Activity 相继互相启动,查看输出的日志,可以看出 SingleTaskActivity 和 SingleInstanceActivity 均处于独立的任务栈中,而 StandardActivity 和 SingleTopActivity 处于同个任务栈中。说明 taskAffinity 对于 standard 和 singleTop 这两种模式不起作用


    E/StandardActivity: onCreate hashCode: 31933912 taskId: 37
    E/SingleTopActivity: onCreate hashCode: 95410735 taskId: 37
    E/SingleTaskActivity: onCreate hashCode: 255733510 taskId: 38
    E/SingleInstanceActivity: onCreate hashCode: 20352185 taskId: 39
    复制代码

    再依次启动 SingleTaskActivity 和 SingleTopActivity。可以看到 SingleTaskActivity 被复用了,且在 38 这个任务栈上启动了一个新的 SingleTopActivity 实例。之所以没有复用 SingleTopActivity,是因为之前的 SingleTopActivity 是在 37 任务栈中,并非当前任务栈


    E/SingleTaskActivity: onNewIntent hashCode: 255733510 taskId: 38
    E/SingleTopActivity: onCreate hashCode: 20652250 taskId: 38
    复制代码

    再启动一次 SingleTopActivity,两次 StandardActivity。可以看到 SingleTopActivity 的确在当前任务栈中被复用了,并均创建了两个新的 StandardActivity 实例。说明 singleTop 想要被复用需要当前任务栈的栈顶就是目标 Activity,而 standard 模式每次均会创建新实例


    E/SingleTopActivity: onNewIntent hashCode: 20652250 taskId: 38
    E/StandardActivity: onCreate hashCode: 252563788 taskId: 38
    E/StandardActivity: onCreate hashCode: 25716630 taskId: 38
    复制代码

    再依次启动 SingleTaskActivity 和 SingleInstanceActivity。可以看到 SingleTaskActivity 和 SingleInstanceActivity 均被复用了,且 SingleTaskActivity 之上的三个 Activity 均从任务栈中被弹出销毁了,SingleTaskActivity 成为了 task 38 新的栈顶 Activity


    E/StandardActivity: onDestroy hashCode: 252563788 taskId: 38
    E/SingleTopActivity: onDestroy hashCode: 20652250 taskId: 38
    E/SingleTaskActivity: onNewIntent hashCode: 255733510 taskId: 38
    E/StandardActivity: onDestroy hashCode: 25716630 taskId: 38
    E/SingleInstanceActivity: onNewIntent hashCode: 20352185 taskId: 39
    复制代码

    再依次启动 StandardActivity 和 SingleTopActivity。可以看到创建了一个新的任务栈,且启动的是两个新的 Activity 实例。由于 SingleInstanceActivity 所在的任务栈只会由其自身所独占,所以 StandardActivity 启动时就需要创建一个新的任务栈用来容纳自身


    E/StandardActivity: onCreate hashCode: 89641200 taskId: 40
    E/SingleTopActivity: onCreate hashCode: 254021317 taskId: 40
    复制代码

    可以做个总结:



    • standard 和 singleTop 这两种模式下 taskAffinity 属性均不会生效,这两种模式启动的 Activity 总会尝试加入到启动者所在的任务栈中,如果启动者是 singleInstance 的话则会创建一个新的任务栈

    • standard 模式的 Activity 每次启动都会创建一个新的实例,不会考虑任何复用

    • singleTop 模式的 Activity 想要被复用,需要启动者所在的任务栈的栈顶就是该 Activity 实例

    • singleTask 模式的 Activity 事实上是系统全局单例,只要实例没有被回收就会一直被复用。singleTask 可以通过声明 taskAffinity 从而在一个特定的任务栈中被启动,且允许其它 Activity 一起共享同一个任务栈。如果不声明 taskAffinity 的话就会尝试寻找或者主动创建 taskAffinity 为 applicationId 的任务栈,然后在该任务栈中创建或复用 Activity

    • singleInstance 可以看做是 singleTask 的加强版,singleInstance 在任何时候都会独占一个任务栈,不管是否声明了 taskAffinity。在 singleInstance 任务栈中启动的其它 Activity 都会加入到其它任务栈中


    需要注意的是,以上结论只适用于没有主动添加 Intent flag 的情况,如果同时添加了 Intent flag 的话就会出现很多奇奇怪怪的现象了


    6、Intent flag


    在启动 Activity 时,我们可以通过在传送给 startActivity(Intent) 方法的 Intent 中设置多个相应的 flag 来修改 Activity 与其任务栈的默认关联,即 Intent flag 的优先级会比 launchMode 高


    Intent 提供的设置 flag 的方法有以下两个,一个是覆盖设置,一个是增量添加


        private int mFlags;

    public @NonNull Intent setFlags(@Flags int flags) {
    mFlags = flags;
    return this;
    }

    public @NonNull Intent addFlags(@Flags int flags) {
    mFlags |= flags;
    return this;
    }
    复制代码

    通过如下方式来添加 flag 并启动 Activity


            val intent = Intent(this, StandardActivity::class.java)
    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP)
    startActivity(intent)
    复制代码

    如果 Activity 的启动模式只由 launchMode 定义的话,那么在运行时 Activity 的启动模式就再也无法改变了,相当于被写死了,所以 launchMode 适合于那些具有固定情景的业务。而 Intent flag 存在的意义就是为了改变或者补充 launchMode,适合于那些大部分情况下固定,少数情况下需要动态进行变化的场景,例如在某些情况下不希望 singleInstance 模式的 Activity 被重用,此时就可以通过 Intent flag 来动态实现


    而这也造成了 Intent flag 很难理清楚逻辑,因为 Intent flag 往往需要组合使用,且还需要考虑和 launchMode 的各种组合配置,两者并不是简单的进行替换


    Intent flag 有很多个,比较常见的有四个,这里就简单介绍下这几种 Intent flag



    • FLAG_ACTIVITY_NEW_TASK

    • FLAG_ACTIVITY_SINGLE_TOP

    • FLAG_ACTIVITY_CLEAR_TOP

    • FLAG_ACTIVITY_CLEAR_TASK


    FLAG_ACTIVITY_NEW_TASK


    FLAG_ACTIVITY_NEW_TASK 应该是大多数开发者最熟悉的一个 flag,比较常用的一个场景就是用于在非 ActivityContext 环境下启动 Activity。Android 系统默认情况下是会将待启动的 Activity 加入到启动者所在的任务栈,而如果启动 Activity 的是 ServiceContext 的话,此时系统就不确定该如何存放目标 Activity 了,此时就会抛出一个 RuntimeException


    java.lang.RuntimeException: Unable to start service github.leavesc.launchmode.MyService@e3183b7 with Intent { cmp=github.leavesc.demo/github.leavesc.launchmode.MyService }: android.util.AndroidRuntimeException: Calling startActivity() from outside of an Activity  context requires the FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?
    复制代码

    从异常信息可以看出此时 Intent 需要添加一个 FLAG_ACTIVITY_NEW_TASK 才行,添加后 Activity 就可以正常启动了


            val intent = Intent(this, StandardActivity::class.java)
    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
    startActivity(intent)
    复制代码

    FLAG_ACTIVITY_NEW_TASK 也有一个隐含的知识点,上文有讲到 standard 和 singleTop 这两种模式下 taskAffinity 属性均不会生效,但这个结论也只适用于没有主动添加 Intent flag 的情况


    FLAG_ACTIVITY_NEW_TASK 和 standard 模式的组合情况可以总结为:



    • standard 没有设置 taskAffinity。此时系统就会去复用或者创建一个默认任务栈,然后直接在该任务栈上新建一个 Activity 实例入栈

    • standard 有设置 taskAffinity。此时又可以分为当前系统是否存在 taskAffinity 关联的任务栈两种情况

      • 不存在目标任务栈。此时系统就会创建目标任务栈,然后直接在该任务栈上新建一个 Activity 实例入栈

      • 存在目标任务栈。此时系统会判断任务栈中是否已经存在目标 Activity 的实例,如果不存在的话则新建一个 Activity 实例入栈。如果存在目标实例的话,则只是将该任务栈转到前台而已,既不会新建 Activity 实例,也不会回调 onNewIntent方法,甚至也不管该 Activity 实例是否处于栈顶,总之只要存在相同实例就不做任何响应。。。。。。。




    可以看到,FLAG_ACTIVITY_NEW_TASK 的语义还是有点费解的,该标记位可以使得 taskAffinity 生效,创建或者复用任务栈并将其转到前台,但并不要求必须创建一个新的 Activity 实例,而是只要 Activity 实例有存在即可,而且也无需该 Activity 实例就在栈顶


    FLAG_ACTIVITY_SINGLE_TOP


    FLAG_ACTIVITY_SINGLE_TOP 这个 flag 看名字就很容易和 singleTop 联系在一起,实际上该 flag 也的确起到了和 singleTop 相同的作用


    只要待启动的 Activity 添加了该标记位,且当前任务栈的栈顶就是目标 Activity,那么该 Activity 实例就会被复用,并且回调其onNewIntent方法,即使该 Activity 声明了 standard 模式,这相当于将 Activity 的 launchMode 覆盖为了 singleTop


    FLAG_ACTIVITY_CLEAR_TOP


    FLAG_ACTIVITY_CLEAR_TOP 这个 flag 则是起到了清除目标 Activity 之上所有 Activity 的作用。例如,假设当前要启动的 Activity 已经在目标任务栈中了,那么设置该 flag 后系统就会清除目标 Activity 之上的所有其它 Activity,但系统最终并不一定会复用现有的目标 Activity 实例,有可能是销毁后再次创建一个新的实例


    看个例子。先以不携带 flag 的方式启动 StandardActivity 和 SingleTopActivity,此时日志信息如下


    E/StandardActivity: onCreate hashCode: 76763823 taskId: 39
    E/SingleTopActivity: onCreate hashCode: 217068130 taskId: 39
    复制代码

    再启动一次 StandardActivity,此时就带上 FLAG_ACTIVITY_CLEAR_TOP。此时就会看到最开始启动的两个 Activity 都会销毁了,并且再次新建了一个 StandardActivity 实例入栈


    E/StandardActivity: onDestroy hashCode: 76763823 taskId: 39
    E/StandardActivity: onCreate hashCode: 51163106 taskId: 39
    E/SingleTopActivity: onDestroy hashCode: 217068130 taskId: 39
    复制代码

    而如果同时加上 FLAG_ACTIVITY_SINGLE_TOP 和 FLAG_ACTIVITY_CLEAR_TOP 两个 flag 的话,那么 SingleTopActivity 就会被弹出,StandardActivity 会被复用,并且回调其onNewIntent方法,两个 flag 相当于组合出了 singleTask 的效果。这一个效果读者可以自行验证


    FLAG_ACTIVITY_CLEAR_TASK


    FLAG_ACTIVITY_CLEAR_TASK 的源码注释标明了该 flag 必须和 FLAG_ACTIVITY_NEW_TASK 组合使用,它起到的作用就是将目标任务栈中的所有 Activity 情空,然后新建一个目标 Activity 实例入栈,该 flag 的优先级很高,即使是 singleInstance 类型的 Activity 也会被销毁


    看个例子。先启动一个 SingleInstanceActivity,然后以添加了 NEW_TASK 和 CLEAR_TASK 两个 flag 的方式再次启动 SingleInstanceActivity,可以看到旧的 Activity 实例被销毁了,并重建了一个新实例入栈,但比较奇怪的一点就是:旧的 Activity 实例的 onNewIntent 方法同时也被调用了


    E/SingleInstanceActivity: onCreate hashCode: 144724929 taskId: 47
    E/SingleInstanceActivity: onNewIntent hashCode: 144724929 taskId: 47
    E/SingleInstanceActivity: onCreate hashCode: 106721743 taskId: 47
    E/SingleInstanceActivity: onDestroy hashCode: 144724929 taskId: 47
    复制代码

    7、总结


    关于 Activity 的启动模式的讲解到这里就结束了,最后再强调一遍,launchMode 和 Intent flag 的各种组合效果还是有点过于难理解了,使得我很难全面地进行描述,再加上似乎还存在版本兼容性问题,使用起来就更加麻烦了,所以我觉得开发者只需要有个大致的印象即可,当真正要使用的时候再来亲自测试验证效果就好,不必强行记忆


    以上各个示例 Demo 点这里:AndroidOpenSourceDemo


    作者:业志陈
    链接:https://juejin.cn/post/6952886121328345101
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    Okio-很棒的文章

    前言 本文不去阐述 Okio 产生原因,也不去对比 Okio 与 Java 原生 IO 的优劣性,单纯分析 Okio 的实现,对每个关键点分析透彻,并配上精美图解。 本文分析点目录 Okio 类框架图 Source 与 Sink Buffer Segment...
    继续阅读 »

    前言


    本文不去阐述 Okio 产生原因,也不去对比 Okio 与 Java 原生 IO 的优劣性,单纯分析 Okio 的实现,对每个关键点分析透彻,并配上精美图解。


    本文分析点目录



    • Okio 类框架图

    • Source 与 Sink

    • Buffer

    • Segment

    • 具体分析 Buffer 的 write 方法,看数据流转过程


    Okio 类框架图


    Okio 整个框架的代码量并不大,体现了高内聚的设计,类框架大概如下:



    图中体现了框架内部类之间的关系,整个框架做的事情大致就是:


    Source 与 Sink


    Source 与 Sink 是 Okio 中所有输入输出流的基类接口,类似 Java IO 中 InputStream,OutputStream。


    Source,源的意思,也就是说我是数据源,你们要的数据都从我这来。


    Sink,往下沉,往外运输的意思,从 Source 中读到数据后,通过我传出去。


    分别定义了数据流的读写接口:


    public interface Source extends Closeable {
    /**
    * Removes at least 1, and up to {@code byteCount} bytes from this and appends
    * them to {@code sink}. Returns the number of bytes read, or -1 if this
    * source is exhausted.
    */
    long read(Buffer sink, long byteCount) throws IOException;

    /** Returns the timeout for this source. */
    Timeout timeout();

    /**
    * Closes this source and releases the resources held by this source. It is an
    * error to read a closed source. It is safe to close a source more than once.
    */
    @Override void close() throws IOException;
    }
    复制代码

    public interface Sink extends Closeable, Flushable {
    /** Removes {@code byteCount} bytes from {@code source} and appends them to this. */
    void write(Buffer source, long byteCount) throws IOException;

    /** Pushes all buffered bytes to their final destination. */
    @Override void flush() throws IOException;

    /** Returns the timeout for this sink. */
    Timeout timeout();

    /**
    * Pushes all buffered bytes to their final destination and releases the
    * resources held by this sink. It is an error to write a closed sink. It is
    * safe to close a sink more than once.
    */
    @Override void close() throws IOException;
    }
    复制代码

    在 Okio 中 Source,Sink 也有几个实现类,我们只看 RealBufferedSource,RealBufferedSink。


    RealBufferedSource


    从名字中看出,带有缓冲的数据源(既然是源,那么你们想要的数据都从我这拿),但是它不是真正的数据源,真正的数据源是成员变量 source,它只是包装装饰了一下,
    当 read 开头的方法被调用时,都是从成员变量 source 中读取,读到数据后,先存入成员变量 buffer 中,然后再从 buffer 中读数据。


    来看 read 方法:


    --> RealBufferedSource.java


    final class RealBufferedSource implements BufferedSource {
    // 缓冲,数据先放到 buffer 中,别人来读的时候先从 buffer 中读,没有的话再从 source 中读
    public final Buffer buffer = new Buffer();
    // 真正数据源,也是此 RealBufferedSource 的上游数据源,当 buffer 中没数据时,从 source 中读
    public final Source source;
    boolean closed;
    ...

    @Override public long read(Buffer sink, long byteCount) throws IOException {
    // 该方法作用:从当前 Source 中 读取 byteCount 个字节存到 sink 中
    if (sink == null) throw new IllegalArgumentException("sink == null");
    if (byteCount < 0) throw new IllegalArgumentException("byteCount < 0: " + byteCount);
    if (closed) throw new IllegalStateException("closed");

    // 若当前 buffer 中没数据,就从成员变量 source 读,读到了再存入 buffer 中
    // 若当前 source 中也没数据,则返回-1
    // 若当前 buffer 中有数据,则跳过这里,直接从 buffer 中读
    if (buffer.size == 0) {
    long read = source.read(buffer, Segment.SIZE);
    if (read == -1) return -1;
    }

    // 到这里 buffer 中肯定是有数据的,取小者,因为 buffer 中的数据量可能不足 byteCount 个,谁小就用谁
    long toRead = Math.min(byteCount, buffer.size);
    // 将 buffer 中数据读到 sink 中
    return buffer.read(sink, toRead);
    }

    }
    复制代码

    RealBufferedSink
    从名字中看出,带有缓冲的输出流(既然是输出流,那么你们想要往外写的数据都通过我来写),但它不是真正的输出流,真正的输出流是 成员变量 sink,它只是包装装饰了一下,当 write 开头的方法被调用时,都是先将数据写到成员变量 buffer 中,然后再通过成员变量 sink 往外写。


    来看 write 方法:


    final class RealBufferedSink implements BufferedSink {
    // 缓冲,当需要通过我进行数据输出时,数据会先存到 buffer 中,再通过 sink 输出
    public final Buffer buffer = new Buffer();
    // 真正输出流,也是此 RealBufferedSink 的下游,当需要进行数据输出时,通过 sink 输出
    public final Sink sink;
    boolean closed;
    ...
    @Override public void write(Buffer source, long byteCount)
    throws IOException {
    if (closed) throw new IllegalStateException("closed");
    // 将 source 中的数据写到 buffer 中
    buffer.write(source, byteCount);
    // 将 buffer 中的数据通过 sink 写出去,内部具体如何写的,在后续 Buffer 章节中详细分析
    emitCompleteSegments();
    }
    复制代码

    整个输入流到输出流可用如下图表示:



    Buffer


    缓冲的意思,Buffer 是 Okio 中的核心类,整个数据中转靠的就是它。


    那么请问,我们为什么要 Buffer 这个东西?我们之前用 Java IO 时不用带 Buffer 的 InputStream 不也照样可以读么?


    我们举个通俗的例子解答这个问题,假如,我们在果园里有一颗苹果树,想吃的时候,去摘一个,什么时候再想吃了,再去树上摘一个,那么,这样跑来跑去的不累么?每次还得跑到园子里。那我们何不先摘个十个八个的,放到箩筐里面带回家,想吃的时候,直接从箩筐里拿,就不必跑那么远到树上去摘了。


    Buffer 就是扮演的上面的箩筐的角色,所以 Buffer 的存在是非常关键的,可以做到省时省力。


    看下 Okio 中 Buffer:


    --> Buffer.java


    public final class Buffer implements BufferedSource, BufferedSink, Cloneable, ByteChannel {
    // Buffer 实现了 BufferedSource,BufferedSink,也就是说,Buffer 既可以
    // 作为 Source 的缓冲,也可以作为 Sink 的缓冲,
    private static final byte[] DIGITS =
    { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' };
    static final int REPLACEMENT_CHARACTER = '\ufffd';

    // 关键点,存储数据链表头
    @Nullable Segment head;
    // 当前 buffer 中的字节数量
    long size;
    ...

    public Buffer() {
    }
    }

    复制代码

    Buffer 是用来缓冲数据的,要缓冲数据,就需要容器,那么它内部靠什么来存储数据?是 Segment。Buffer 中主要就是依靠 Segment 来存储数据,将 Segment 组成循环链表的结构,可用下图表示:



    那我们就来看看 Segment 是什么,注意,Buffer 还没说完,等 Segment 分析完后,会再通过分析具体方法,来看看 Buffer 与 Segment 是如何配合完成工作的。


    Segment


    Segment 片段的意思,先看下类源码:


    --> Segment.java


    final class Segment {
    // 每个 Segment 最大容量,也就是最多容纳 8192 个字节
    static final int SIZE = 8192;

    // 在 Segment 分割的场景(后面讲),如果要分割出去的字节数大于 1024 这个临界值,
    // 那么直接共享 data,不要去做数组拷贝了
    static final int SHARE_MINIMUM = 1024;

    // 真正存放数据的地方
    final byte[] data;

    // data 中第一个可读位置,比如当前 data 中有 1024 个字节,pos = 0,被读取了一个字节后
    // pos = 1,下次再读的话,就要从 1 开始读了
    int pos;

    // data 中第一个可写的位置,比如当前 data 中有 1024 个字节,那么第一个可写的位置是 1025
    int limit;

    // 此 Segment 是否在与别的 Segment 或者 ByteString 共享 data
    boolean shared;

    // 该 Segment 是否独享 data,独享时,可向 data 写入数据
    boolean owner;

    // 循环链表下一个节点
    Segment next;

    // 循环链表前一个节点
    Segment prev;

    Segment() {
    this.data = new byte[SIZE];
    this.owner = true;
    this.shared = false;
    }

    Segment(byte[] data, int pos, int limit, boolean shared, boolean owner) {
    this.data = data;
    this.pos = pos;
    this.limit = limit;
    this.shared = shared;
    this.owner = owner;
    }
    ...
    }
    复制代码

    看到 next,prev,就知道 Segment 会组成双向链表结构,只不过 Okio 中是双向循环链表,Segment 可用如下图表示:


    Segment 内部定义了操作数据、操作链表的方法,我们着重分析以下几个方法:



    • push

    • pop

    • split

    • compact

    • writeTo


    push


    // 往当前链表中添加一个节点,放在被调用 Segment 之后
    public final Segment push(Segment segment) {
    segment.prev = this;
    segment.next = next;
    next.prev = segment;
    next = segment;
    return segment;
    }
    复制代码

    pop


    // 从当前链表中删除该节点
    public final @Nullable Segment pop() {
    Segment result = next != this ? next : null;
    prev.next = next;
    next.prev = prev;
    next = null;
    prev = null;
    return result;
    }
    复制代码

    上面两个方法是简单的链表增删操作,不需要注释,只需要注意以下几点:


    push:


    1、先将被push进来的节点的 prev、next 安顿好


    2、再将与新节点相邻的前一个节点的 next 安顿好


    3、最后将与新节点相邻的后一个节点的 prev 安顿好


    pop:


    1、先安顿前邻居的 next


    2、再安顿后邻居的 prev


    3、最后安顿自己的 prev、next


    总之,在一个双向链表中增删操作,无非就是关心三个节点:自己、前邻居、后邻居,自己要解决prev next,前邻居解决next,后邻居解决 prev


    split



    public final Segment split(int byteCount) {
    if (byteCount <= 0 || byteCount > limit - pos) throw new IllegalArgumentException();
    Segment prefix;

    // We have two competing performance goals:
    // 我们有两个竞争的性能目标
    // - Avoid copying data. We accomplish this by sharing segments.
    // - 避免数据的拷贝。我们通过共享 Segment 来达成这一目标
    // - Avoid short shared segments. These are bad for performance because they are readonly and
    // may lead to long chains of short segments.
    // - 避免短的共享 Segment,这样会导致性能差,因为共享后,Segment 只能读不能写,并且
    // 可能导致链表中短 Segment 链变的很长
    // To balance these goals we only share segments when the copy will be large.
    // 为了平衡这些目标,我们只在需要拷贝的数据量比较大时,才会采用共享 Segment 的方式
    if (byteCount >= SHARE_MINIMUM) {
    // 当要分割出去的数据大于SHARE_MINIMUM(1024)时,会采用共享 Segment 的方式创建新的Segment,
    // 注意,共享的是 Segment 里面的 data,还是会创建一个新的 Segment,只不过 data 是同一个
    prefix = sharedCopy();
    } else {
    // 当要分割的数据小于SHARE_MINIMUM(1024)时,那么直接 copy 吧,反正顶天不会超过 1024 个字节
    prefix = SegmentPool.take();
    System.arraycopy(data, pos, prefix.data, 0, byteCount);
    }

    // 到这里,我们分割出来的 Segment 就创建好了,但是我们要始终注意的是:分割的是
    // Segment 里的 data,data 被一刀两断了,那么两个 Segment 是不是要把 pos,limit 都调整下

    // 调整新创建的 Segment 的 limit 为 pos + byteCount
    prefix.limit = prefix.pos + byteCount;
    // 调整原 Segment 的 pos 为 pos + byteCount
    pos += byteCount;
    // 加到该 Segment 的前节点后面,其实在 Okio 中,这个 prev 就是 tail,
    // 你可能会问,这个方法哪个 Segment 对象都可以调用,这个 prev 是调用这个方法
    // 的 Segment 的前节点,为啥会是 tail 节点?其实在 Okio 框架内部只有一个地方
    // 调用了,就是在 Buffer 的 write(Buffer source, long byteCount) 里,
    // 里面是用 head 去调用的,而 head 的 prev 是 tail
    // 你可能又有疑问了,这方法是 public 的,外部都可以访问啊,但请看 Segment ,这家伙
    // 不是 public 的,包内访问限制,外部无法使用,只能在 Okio 内使用,so...
    prev.push(prefix);
    return prefix;
    }
    复制代码

    split 方法的过程可用下图表示:



    split 过程完成后,Buffer 中 链表变化如下图:



    那么这个 split 方法有何用呢? 上面注释中提到过,split 方法在 Okio 中唯一调用处在 Buffer 的 write(Buffer source, long byteCount),这个方法中的最后一段注释这样写道:


    /**
    * Occasionally we write only part of a source buffer to a sink buffer. For
    * example, given a sink [51%, 91%], we may want to write the first 30% of
    * a source [92%, 82%] to it. To simplify, we first transform the source to
    * an equivalent buffer [30%, 62%, 82%] and then move the head segment,
    * yielding sink [51%, 91%, 30%] and source [62%, 82%].
    */
    复制代码

    意思是:在某些场景下,我们只需要从 Source 中 写一部分数据 到 Sink 中,例如我们现在有一个 Sink,未读数据占比是[51%, 91%](注意,代表这个 Buffer 有两个 Segment,未读数据占比),我们可能想从一个[92%, 82%]的 Source 中往 Sink 中写30%的数据。为了简便,我们首先把 Source 转化为一个同等的 Buffer [30%, 62%, 82%],然后把头 Segment 移动到 Sink 中去(注意是移动,不是拷贝,这样就是一个指针操作),那么此时 Source 中只剩[62%, 82%]。


    不难理解,无非就是把 Source 的两个 Segment 拆成三个,然后把其中一个移到 Sink 中,这样就避免了比较大的数据量的拷贝,只是移动了指针,在 split 中,当需要写的数据小于1024,才会有拷贝操作,大于1024时,直接共享数据,所以这里是一个性能提升的地方。


    writeTo


    // 把当前 Segment 数据写到 sink 中去
    public final void writeTo(Segment sink, int byteCount) {
    // 当 sink 不独享数据时,直接抛异常,因为不独享时,只可读,不可写
    if (!sink.owner) throw new IllegalArgumentException();
    // 若 sink 的可写空间不足了
    if (sink.limit + byteCount > SIZE) {
    // We can't fit byteCount bytes at the sink's current position. Shift sink first.
    // 若 sink 与别的 Segment 共享数据,只读不写,直接抛异常
    if (sink.shared) throw new IllegalArgumentException();
    // 若将已读空间重复利用,sink空间还不够,抛异常
    if (sink.limit + byteCount - sink.pos > SIZE) throw new IllegalArgumentException();
    System.arraycopy(sink.data, sink.pos, sink.data, 0, sink.limit - sink.pos);
    sink.limit -= sink.pos;
    sink.pos = 0;
    }

    System.arraycopy(data, pos, sink.data, sink.limit, byteCount);
    sink.limit += byteCount;
    pos += byteCount;
    }
    }
    复制代码

    writeTo 过程可用如下图表示:



    compact


    // 压缩,将 tail 中数据往 prev 中转移
    public final void compact() {
    // 若前节点就是自己,那么此时链表中只有一个节点
    if (prev == this) throw new IllegalStateException();
    // 若前节点非独享,也就是不可写,直接return
    if (!prev.owner) return; // Cannot compact: prev isn't writable.
    // 当前节点的未读数据大小
    int byteCount = limit - pos;
    // 前节点的最大可写空间,记得我们上面的 writeTo方法吗,最大可写空间=可写空间+已读空间
    int availableByteCount = SIZE - prev.limit + (prev.shared ? 0 : prev.pos);
    // 若前节点的最大可写空间容不下即将要写入的数据,直接return
    if (byteCount > availableByteCount) return; // Cannot compact: not enough writable space.
    // 到这里肯定是可以写入的,可不还是调用 writeTo 么
    writeTo(prev, byteCount);
    // 当前节点从链表中断开
    pop();
    // 从链表中断开了别扔了,回收,下次利用
    SegmentPool.recycle(this);
    }
    复制代码

    compact 是压缩的意思,在有的情况下,链表中的 Segment 利用率不高(可写的空间还有很多),这个时候我们能不能把后面一个节点的数据往这个节点里面压一压呢?以提高利用率,同时可以回收后一个节点,减小链表长度,一举两得。要注意的是,这个方法是 tail 节点调用。


    compact过程可由下图表示:

    Segment 提供了这些原子方法,让他人去调用吧。


    Buffer 的 write 和 read 方法


    之前在 Buffer 小节,还未说完,我们现在通过 Buffer 的 write 和 read 方法来具体分析从一个缓存到另一个缓存的读写过程。


    write


    // 从 source 中移动 byteCount 个字节到当前Buffer(去掉许多注释)
    @Override public void write(Buffer source, long byteCount) {
    // Move bytes from the head of the source buffer to the tail of this buffer
    // 从 source 的 head 移动数据到当前Buffer的 tail中

    if (source == null) throw new IllegalArgumentException("source == null");
    if (source == this) throw new IllegalArgumentException("source == this");
    // 检查偏移和移动数量,防止越界
    checkOffsetAndCount(source.size, 0, byteCount);
    // 为什么是while循环,因为byteCount可能很大,而Segment移动数据有限
    while (byteCount > 0) {
    // Is a prefix of the source's head segment all that we need to move?
    // 如果source的头里面的未读数据就比byteCount大
    if (byteCount < (source.head.limit - source.head.pos)) {
    // 因为写都是往尾部写入,这里先找到当前Buffer的tail节点
    Segment tail = head != null ? head.prev : null;
    if (tail != null && tail.owner
    && (byteCount + tail.limit - (tail.shared ? 0 : tail.pos) <= Segment.SIZE)) {
    // Our existing segments are sufficient. Move bytes from source's head to our tail.
    // 当前Buffer的tail节点的可写空间就够了,直接将数据写入tail就行,这里使用的是拷贝
    source.head.writeTo(tail, (int) byteCount);
    source.size -= byteCount;
    size += byteCount;
    return;
    } else {
    // We're going to need another segment. Split the source's head
    // segment in two, then move the first of those two to this buffer.
    // 将source的head一分为二,因为当前Buffer的tail容不下byteCount个字节了
    // 当然,你可能会问,如果tail为null或者不满足上面的if里的任何一个条件都会走
    // 这里的else,别忘了,这个else始终被外层的if条件约束着
    source.head = source.head.split((int) byteCount);
    }
    }

    // Remove the source's head segment and append it to our tail.
    // 如过走了上面的if,那么这里的source.head已经是分割过的,如果没走if,什么都没干
    Segment segmentToMove = source.head;
    long movedByteCount = segmentToMove.limit - segmentToMove.pos;
    // 将segmentToMove从source中移除,因为它将要加入到当前的Buffer中
    source.head = segmentToMove.pop();
    if (head == null) {
    head = segmentToMove;
    head.next = head.prev = head;
    } else {
    Segment tail = head.prev;
    // 加入到当前Buffer中
    tail = tail.push(segmentToMove);
    // 再压缩一下,尽量让segment满载,提高利用率
    tail.compact();
    }

    // 数据移动完了,设置source与当前Buffer的变量,source数据少了,这边多了
    source.size -= movedByteCount;
    size += movedByteCount;
    byteCount -= movedByteCount;

    //如果一趟没将byteCount个字节的数据移动完,再进行下一次循环
    }
    }
    复制代码

    read


    public long read(Buffer sink, long byteCount) {
    if (sink == null) throw new IllegalArgumentException("sink == null");
    if (byteCount < 0) throw new IllegalArgumentException("byteCount < 0: " + byteCount);
    if (size == 0) return -1L;
    if (byteCount > size) byteCount = size;
    // 其实就是将当前Buffer中的数据写到sink中,这里好像与我们看到这个方法的第一反应
    // 有点不同,我们可能想的是:既然是read,就是要从外头读数据,但是这里是往外头读
    // 我们还是要理解source与sink的概念,从source读,往sink中写
    sink.write(this, byteCount);
    return byteCount;
    }

    作者:HuntX
    链接:https://juejin.cn/post/6953205123803775006
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    java 设计模式:责任链模式与Android事件传递

    1、概念是一个请求有多个对象来处理,这些对象是一条链,但具体由哪个对象来处理,根据条件判断来确定,如果不能处理会传递给该链中的下一个对象,直到有对象处理它为止。2、使用场景有多个对象可以处理同一个请求,具体哪个对象处理该请求待运行时刻再确定在不明确指定接收者的...
    继续阅读 »

    1、概念

    是一个请求有多个对象来处理,这些对象是一条链,但具体由哪个对象来处理,根据条件判断来确定,如果不能处理会传递给该链中的下一个对象,直到有对象处理它为止。

    2、使用场景

    1. 有多个对象可以处理同一个请求,具体哪个对象处理该请求待运行时刻再确定
    2. 在不明确指定接收者的情况下,向多个对象中的一个提交一个请求。
    3. 可动态制定一组对象处理请求,客户端可以动态创建职责链来处理请求。

    3、uml结构分析


    4、实际代码分析


    /**
    * 抽象请假审批类
    */
    public abstract class Handler {
    public int maxDay;
    private Handler nextHandler;

    public Handler(int maxDay) {
    this.maxDay = maxDay;
    }

    public void setNextHandler(Handler nextHandler) {
    this.nextHandler = nextHandler;
    }

    public void handlerRequest(int day){
    if(day <= maxDay){
    reply(day);
    } else{
    if(nextHandler != null){
    nextHandler.handlerRequest(day);
    }else {
    System.out.println("没有跟高的领导审批了");
    }
    }
    }

    protected abstract void reply(int day);
    }
    /**
    * 技术主管审批类
    */
    public class Handler1 extends Handler {
    public Handler1() {
    super(10);
    }

    @Override
    protected void reply(int day) {
    System.out.print(day+"天请假,技术主管直接通过");
    }
    }

    * 项目经理审批类
    */
    public class Handler2 extends Handler {
    public Handler2() {
    super(5);
    }

    @Override
    protected void reply(int day) {
    System.out.print(day+"天请假,项目经历直接通过");
    }
    }
    //代码运行
    Handler2 handler2 = new Handler2();
    handler2.setNextHandler(new Handler1());
    handler2.handlerRequest(3);

    在java中的实际运用,try-cache语句

    在android 中发布有序广播 ordered broadcast,viewGroup/view 事件传递

    优点与缺点

    责任链模式是一种对象行为型模式,其主要优点如下。

    1. 降低了对象之间的耦合度。该模式使得一个对象无须知道到底是哪一个对象处理其请求以及链的结构,发送者和接收者也无须拥有对方的明确信息。
    2. 增强了系统的可扩展性。可以根据需要增加新的请求处理类,满足开闭原则。
    3. 增强了给对象指派职责的灵活性。当工作流程发生变化,可以动态地改变链内的成员或者调动它们的次序,也可动态地新增或者删除责任。
    4. 责任链简化了对象之间的连接。每个对象只需保持一个指向其后继者的引用,不需保持其他所有处理者的引用,这避免了使用众多的 if 或者 if···else 语句。
    5. 责任分担。每个类只需要处理自己该处理的工作,不该处理的传递给下一个对象完成,明确各类的责任范围,符合类的单一职责原则。


    其主要缺点如下。

    1. 不能保证每个请求一定被处理。由于一个请求没有明确的接收者,所以不能保证它一定会被处理,该请求可能一直传到链的末端都得不到处理。
    2. 对比较长的职责链,请求的处理可能涉及多个处理对象,系统性能将受到一定影响。
    3. 职责链建立的合理性要靠客户端来保证,增加了客户端的复杂性,可能会由于职责链的错误设置而导致系统出错,如可能会造成循环调用。

    viewGroup/view 事件传递

    1)主要概念

    MotionEvent 事件分发的基本操作,所有事件都是MotionEvent,对MotionEvent操作。

    主要有三种操作 ACTION_DOWN/ACTION_MOVE/ACTION_UP

    三个方法

    dispatchTouchEvent 当有事件传递给view的时候,view就会调用该方法。这个返回值为boolean,返回告诉系统是否消耗了该事件。true为消耗,不会继续向下分发

    onIntereptTouchEvent 拦截事件,只存在于viewgroup,view(存在于view树的最底层,没必要拦截了)中没有拦截事件。如果当前view 成功拦截这个事件,则要返回true,默认为false

    onTouchEvent 具体处理整个事件逻辑的,对于他的返回结果就是是否消耗当前事件,如果不消耗当前事件的话,对于同一个事件,当前view就不会再接到这个事件。

    总结:如果当前view可以处理就拦截处理,如果不可以,就交给子view

    事件处理顺序

    Activity -> PhoneWindow ->RootView ->ViewGroup ->View

    2)viewgroup的事件分发

    流程:

    1. 判断自身是否需要
    2. 自身不需要或者不确定,询问childview
    3. 如果子childview 不需要则调用自身的onTouchEvent

    3)view的事件分发

    view为啥会有dispatchTouchEvent方法?view可以注册很多事件监听器,可以进行事件分发

    1. 单机事件(onClickListener)
    2. 长按事件(onLongClickListener)
    3. 触摸事件(onTouchListener)
    4. View自身处理(onTouchEvent)

    事件调用顺序:onTouchListener>onTouchEvent>onLongClickListener>onClickListener

    收起阅读 »

    java 设计模式:观察者

    1、概念在对象之间定义了一对多的依赖,使得么当一个对象状态发生改变,其相关依赖对象会收到通知并自动更新。2、场景一个抽象模型有两个方面,其中一个方面依赖于另一个方面一个对象的改变将导致一个或多个其他对象也发生改变需要在系统中创建一个触发链3、UML结构图分析抽...
    继续阅读 »

    1、概念

    在对象之间定义了一对多的依赖,使得么当一个对象状态发生改变,其相关依赖对象会收到通知并自动更新。

    2、场景

    1. 一个抽象模型有两个方面,其中一个方面依赖于另一个方面
    2. 一个对象的改变将导致一个或多个其他对象也发生改变
    3. 需要在系统中创建一个触发链

    3、UML结构图分析

    • 抽象被观察者角色:也就是一个抽象主题,它把所有对观察者对象的引用保存在一个集合中,每个主题都可以有任意数量的观察者。抽象主题提供一个接口,可以增加和删除观察者角色。一般用一个抽象类和接口来实现。
    • 抽象观察者角色:为所有的具体观察者定义一个接口,在得到主题通知时更新自己。
    • 具体被观察者角色:也就是一个具体的主题,在集体主题的内部状态改变时,所有登记过的观察者发出通知。
    • 具体观察者角色:实现抽象观察者角色所需要的更新接口,一边使本身的状态与制图的状态相协调。

    4、实际代码分析

    实现观察者代码:


    /**
    *
    * 创建观察者抽象类
    */
    public interface Observer {

    //更新方法
    void update(String newStatus);

    }

    /**
    * 创建观察者实现类
    */
    public class ConcreteObserver implements Observer {

    /**
    * 观察者状态
    */
    private String observerState;

    @Override
    public void update(String newStatus) {
    observerState = newStatus;
    System.out.println(newStatus);
    }
    }

    /**
    * 创建抽象目标者
    * Created by shidawei on 2019/5/23.
    */
    public abstract class Subject {

    private List<Observer> mObservers = new ArrayList<>();

    /**
    * 注册观察
    * @param observer
    */
    public void attach(Observer observer){
    mObservers.add(observer);
    System.out.println("注册观察");
    }

    /**
    * 移除观察者
    * @param observer
    */
    public void detach(Observer observer){
    mObservers.remove(observer);
    }

    /**
    * 通知观察者
    * @param newStatus
    */
    public void notifyObsercers(String newStatus){
    for(Observer observer:mObservers){
    observer.update(newStatus);
    }
    }
    }

    /**
    * 实现被观察者
    */
    public class ConcreteSubject extends Subject {
    private String state;

    public String getState() {
    return state;
    }
    public void change(String newState){
    state = newState;
    System.out.println(newState);
    notifyObsercers(newState);
    }
    }

    //测试代码
    ConcreteSubject concreteSubject = new ConcreteSubject();
    concreteSubject.attach(new ConcreteObsercer());
    concreteSubject.attach(new ConcreteObsercer());
    concreteSubject.attach(new ConcreteObsercer());
    concreteSubject.change("123");

    java内部的接口实现:

    /**
    * Observable 是被观察者对象接口,是对被观察者的实现
    */
    public class TargetObervable extends Observable {

    private String message;

    public String getMessage() {
    return message;
    }

    public void setMessage(String message) {
    this.message = message;
    //被观察者数据发生改变的时候通过如下两行代码通知所有观察者
    this.setChanged();
    this.notifyObservers();
    }
    }
    /**
    * Observer 对象是观察者,实现Observer的对象就是实现观察者对象
    */
    public class TargetOberver implements Observer {


    private String name;

    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }

    @Override
    public void update(Observable o, Object arg) {
    System.out.println(name + "收到数据变更" + ((TargetObervable) o).getMessage());
    }
    }

    //测试代码

    TargetObervable targetObervable = new TargetObervable();
    targetObervable.addObserver(new TargetOberver());
    targetObervable.addObserver(new TargetOberver());
    targetObervable.addObserver(new TargetOberver());
    targetObervable.setMessage("1234");

    两种观察者对比:

    通过读源码Observable.class我们得知对Observer的集合为Vector

    Vector为线程安全的,会保证线程安全,但是性能差。可以采用CopyOnWriteArrayList来代替Vector。

    观察者设计模式在Android中的实际运用

    回调模式:一对一的模式

    实现了抽象类/接口的实例实现了负累的提供的抽象方法,然后将该方法还给父类来处理。

    Fragment与activity通信的代码实例:

    /**
    *回调接口,与activity通信
    **/

    public interface ISwitchCaoZuoRecordFragment {
    void toSwitch(CaiZuoRecordFragFragment fragment, CaiZuoRecordFragPresenter presenterDecorator);
    }
    /**
    * activity实现该接口
    **/
    public class CaoZuoRecordActivity extends BaseActivity<CaoZuoRecordView, CaoZuoRecordPresenter> implements CaoZuoRecordView ,CaiZuoRecordFragFragment.ISwitchCaoZuoRecordFragment{
    @Override
    public void toSwitch(CaiZuoRecordFragFragment fragment, CaiZuoRecordFragPresenter presenterDecorator) {
    mPresenterDecorator = presenterDecorator;
    if(presenterDecorator.studentName!=null&&!presenterDecorator.studentName.equals("")){
    searchListTitleBar.getSearch().setText(presenterDecorator.studentName);
    searchListTitleBar.getClear().setVisibility(View.VISIBLE);
    searchListTitleBar.getSearch_layout().setVisibility(View.VISIBLE);
    }else{
    searchListTitleBar.getSearch().setText("");
    searchListTitleBar.getClear().setVisibility(View.GONE);
    searchListTitleBar.getSearch_layout().setVisibility(View.GONE);
    }

    }

    /**
    *fragment注册和取消
    */
    @Override
    public void onDetach() {
    super.onDetach();
    iSwitchCaoZuoRecordFragment = null;

    }

    @Override
    public void onAttach(Context context) {
    super.onAttach(context);
    if (context instanceof ISwitchCaoZuoRecordFragment) {
    iSwitchCaoZuoRecordFragment = (ISwitchCaoZuoRecordFragment) context;
    }else{
    throw new RuntimeException(context.toString()
    + " 必须实现 ISwitchCaoZuoRecordFragment");
    }
    }


    收起阅读 »

    java 设计模式:模版方法

    模板方法模式  定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。 模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。通俗的说的就是有很多相同的步骤的,在某一些地方可能有一些差别适合于这种模式,如大话设计模式中说到的考试场景中,每个人...
    继续阅读 »

    模板方法模式

      定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。 模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。通俗的说的就是有很多相同的步骤的,在某一些地方可能有一些差别适合于这种模式,如大话设计模式中说到的考试场景中,每个人的试卷都是一样的,只有答案不一样。这种场景就适合于模板方法模式。

    模板方法模式适用的业务场景

    1. 算法或者操作遵循相似的逻辑
    2. 重构时(把相同的代码抽取到父类中)
    3. 重要、复杂的算法,核心算法设计为模板方法

    代码实现

    现在我有一个需求,就是要建立一套上课业务规则

    • 上课
    • 考情
    • 下课

    /**
    * 班级规则
    */
    public abstract class ClassShangke {

    public void shangke(){

    }

    public abstract void kaoqing();

    public void xiake(){

    }

    //注意模版规则 final 不可被重写
    public final void guize(){
    shangke();
    kaoqing();
    xiake();
    }

    }

    /**
    * A班级上课
    */
    public class AClassKaoQing extends ClassShangke {
    @Override
    public void kaoqing() {
    System.out.println("AClassKaoQing kaoqing");
    }
    }


    /**
    * B班级上课
    */
    public class BClassKaoQing extends ClassShangke {
    @Override
    public void kaoqing() {
    System.out.println("BClassKaoQing kaoqing");
    }
    }

    //运行

    ClassShangke classShangkea = new AClassKaoQing();
    classShangkea.guize();
    ClassShangke classShangkeb = new BClassKaoQing();
    classShangkeb.guize();

    我在项目中对网络请求返回数据进行模版方法定义

    public abstract class BaseRxNetworkResponseObserver<T extends SModel> extends BaseRxNetworkObserver<T> {

    @Override
    public final void onNext(T t) {
    onBeforeResponseOperation();
    try{
    onResponse(t);
    }catch (Exception e){
    ULog.e(e,e.getMessage());
    ULog.e(e);
    TipToast.shortTip(e.getMessage());
    onResponseFail(new CustomarilyException(e.getMessage()));
    }finally {
    onNextFinally();
    }
    }

    protected void onNextFinally() {
    }


    /**
    * 返回值
    * @param t
    */
    public abstract void onResponse(T t);

    /**
    * 错误
    * @param e
    */
    public abstract void onResponseFail(Exception e);

    /**
    * 执行一些起始操作
    */
    protected abstract void onBeforeResponseOperation();
    }

    注意模版方法的final 为了制定一些规则必须不可以被重写

    模板方法模式的优点

    • 封装性好
    • 复用性好 
    • 屏蔽细节
    • 便于维护
    收起阅读 »

    java 设计模式:策略模式

    概念:策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换,策略模式让算法独立于使用它的客户而独立变化。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化。使用场景:一个类定义了多种行为,并且这个行为在这个类的方法中以多个条件语...
    继续阅读 »

    概念:

    策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换,策略模式让算法独立于使用它的客户而独立变化。

    策略模式使这些算法在客户端调用它们的时候能够互不影响地变化。

    使用场景:

    一个类定义了多种行为,并且这个行为在这个类的方法中以多个条件语句形式出现,那么可以使用策略模式避免在类中使用大量的条件语句。

    UML:

    代码展示:

    为了更清晰的展示出策略模式的优点,我在此写一套不用策略模式实现的代码。如下:

    /**
    * 有如下几个超市价格规则 1:五月一日 价格统统8折 2:十月一日 价格统统7折 3:十一月一日 价格统统半价
    * Created by on 2019/4/30.
    */
    public class Price {

    public double jisuanPrice(double price,String s){
    double p = price;
    System.out.println(s);
    switch (s){
    case "五月一日":
    p = price*0.8;
    break;
    case "十月一日":
    p = price*0.7;
    break;
    case "十一月一日":
    p = price*0.5;
    break;
    }
    return p;
    }

    }
    //运行
    Price p = new Price();
    System.out.println(p.jisuanPrice(10),"五月一日");

    你会发现,也很清晰表示了判断不同的日期来计算不同的价格,不同日期用switch来判断,但是呢,如果日期很多,而且规则又有了对特定商品的价格规则,那么这个类的负担是否有些复杂了呢?这个类不是单一职责。还根据swith来计算规则。

    于是我写下了如下的策略方法:

    /**
    * 半价计算策略
    */
    public class Banjia implements IPrice {
    @Override
    public double jisuanPrice(double price) {
    return price*0.5;
    }
    }
    /**
    * 8折计算策略
    */
    public class BaZhe implements IPrice {
    @Override
    public double jisuanPrice(double price) {
    return price*0.8;
    }
    }
    /**
    * 正常计算策略
    */
    public class NorPrice implements IPrice {
    @Override
    public double jisuanPrice(double price) {
    return price;
    }
    }

    /**
    * 7折计算
    */
    public class Qizhe implements IPrice {
    @Override
    public double jisuanPrice(double price) {
    return price*0.7;
    }
    }
    //作为价格管理器一定要持有IPrice的引用
    public class Price{

    private IPrice iPrice;

    public void setiPrice(IPrice iPrice) {
    this.iPrice = iPrice;
    }

    public double jisuanPrice(double price) {
    return iPrice.jisuanPrice(price);
    }
    }
    //运行
    //1.创建具体测策略实现
    IPrice iprice = new BaZhe();
    //2.在创建策略上下文的同时,将具体的策略实现对象注入到策略上下文当中
    Price p = new Price();
    p.setiPrice(iprice);
    //3.调用上下文对象的方法来完成对具体策略实现的回调
    System.out.println(p.jisuanPrice(10));

    这个能够明显是对价格做了分类,假如说十月一日要进行半价打折,那你是不是很容易就改变了策略呢?不需要动其他代码。

    策略模式优点

    1、上下文Context 和具体策略器(oncreteStrategy)是松耦合关系。

    2、满足开-闭原则。增加新的具体策略不需要修改context。

    开闭原则:

    1. 对于扩展是开放的(Open for extension)。这意味着模块的行为是可以扩展的。当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的新行为。也就是说,我们可以改变模块的功能。
    2. 对于修改是关闭的(Closed for modification)。对模块行为进行扩展时,不必改动模块的源代码或者二进制代码。

    策略和上下文的关系:

    • 在策略模式中,一般情况下都是上下文持有策略的引用,以进行对具体策略的调用。但具体的策略对象也可以从上下文中获取所需数据,可以将上下文当做参数传入到具体策略中,具体策略通过回调上下文中的方法来获取其所需要的数据。

    如下例子来自 https://www.cnblogs.com/lewis0077/p/5133812.html 非常好的一篇文章

    **下面我们演示这种情况:**

      在跨国公司中,一般都会在各个国家和地区设置分支机构,聘用当地人为员工,这样就有这样一个需要:每月发工资的时候,中国国籍的员工要发人民币,美国国籍的员工要发美元,英国国籍的要发英镑。
    public interface PayStrategy {
    //在支付策略接口的支付方法中含有支付上下文作为参数,以便在具体的支付策略中回调上下文中的方法获取数据
    public void pay(PayContext ctx);
    }

    //人民币支付策略
    public class RMBPay implements PayStrategy {
    @Override
    public void pay(PayContext ctx) {
    System.out.println("现在给:"+ctx.getUsername()+" 人民币支付 "+ctx.getMoney()+"元!");
    }
    }

    //美金支付策略
    public class DollarPay implements PayStrategy {
    @Override
    public void pay(PayContext ctx) {
    System.out.println("现在给:"+ctx.getUsername()+" 美金支付 "+ctx.getMoney()+"dollar !");
    }
    }

    //支付上下文,含有多个算法的公有数据
    public class PayContext {
    //员工姓名
    private String username;
    //员工的工资
    private double money;
    //支付策略
    private PayStrategy payStrategy;

    public void pay(){
    //调用具体的支付策略来进行支付
    payStrategy.pay(this);
    }

    public PayContext(String username, double money, PayStrategy payStrategy) {
    this.username = username;
    this.money = money;
    this.payStrategy = payStrategy;
    }

    public String getUsername() {
    return username;
    }

    public double getMoney() {
    return money;
    }
    }

    //外部客户端
    public class Client {
    public static void main(String[] args) {
    //创建具体的支付策略
    PayStrategy rmbStrategy = new RMBPay();
    PayStrategy dollarStrategy = new DollarPay();
    //准备小王的支付上下文
    PayContext ctx = new PayContext("小王",30000,rmbStrategy);
    //向小王支付工资
    ctx.pay();

    //准备Jack的支付上下文
    ctx = new PayContext("jack",10000,dollarStrategy);
    //向Jack支付工资
    ctx.pay();
    }
    }
    控制台输出:

    现在给:小王 人民币支付 30000.0元!
    现在给:jack 美金支付 10000.0dollar !

    那现在我们要新增一个银行账户的支付策略,该怎么办呢?

      显然我们应该新增一个支付找银行账户的策略实现,由于需要从上下文中获取数据,为了不修改已有的上下文,我们可以通过继承已有的上下文来扩展一个新的带有银行账户的上下文,然后再客户端中使用新的策略实现和带有银行账户的上下文,这样之前已有的实现完全不需要改动,遵守了开闭原则。

    //银行账户支付
    public class AccountPay implements PayStrategy {
    @Override
    public void pay(PayContext ctx) {
    PayContextWithAccount ctxAccount = (PayContextWithAccount) ctx;
    System.out.println("现在给:"+ctxAccount.getUsername()+"的账户:"+ctxAccount.getAccount()+" 支付工资:"+ctxAccount.getMoney()+" 元!");
    }
    }

    //带银行账户的支付上下文
    public class PayContextWithAccount extends PayContext {
    //银行账户
    private String account;
    public PayContextWithAccount(String username, double money, PayStrategy payStrategy,String account) {
    super(username, money, payStrategy);
    this.account = account;
    }

    public String getAccount() {
    return account;
    }
    }

    //外部客户端
    public class Client {
    public static void main(String[] args) {
    //创建具体的支付策略
    PayStrategy rmbStrategy = new RMBPay();
    PayStrategy dollarStrategy = new DollarPay();
    //准备小王的支付上下文
    PayContext ctx = new PayContext("小王",30000,rmbStrategy);
    //向小王支付工资
    ctx.pay();
    //准备Jack的支付上下文
    ctx = new PayContext("jack",10000,dollarStrategy);
    //向Jack支付工资
    ctx.pay();
    //创建支付到银行账户的支付策略
    PayStrategy accountStrategy = new AccountPay();
    //准备带有银行账户的上下文
    ctx = new PayContextWithAccount("小张",40000,accountStrategy,"1234567890");
    //向小张的账户支付
    ctx.pay();
    }
    }

    控制台输出:

    现在给:小王 人民币支付 30000.0元!
    现在给:jack 美金支付 10000.0dollar !
    现在给:小张的账户:1234567890 支付工资:40000.0 元!

    除了上面的方法,还有其他的实现方式吗?

      当然有了,上面的实现方式是策略实现所需要的数据都是从上下文中获取,因此扩展了上下文;现在我们可以不扩展上下文,直接从策略实现内部来获取数据,看下面的实现:

    //支付到银行账户的策略
    public class AccountPay2 implements PayStrategy {
    //银行账户
    private String account;
    public AccountPay2(String account) {
    this.account = account;
    }
    @Override
    public void pay(PayContext ctx) {
    System.out.println("现在给:"+ctx.getUsername()+"的账户:"+getAccount()+" 支付工资:"+ctx.getMoney()+" 元!");
    }
    public String getAccount() {
    return account;
    }
    public void setAccount(String account) {
    this.account = account;
    }
    }

    //外部客户端
    public class Client {
    public static void main(String[] args) {
    //创建具体的支付策略
    PayStrategy rmbStrategy = new RMBPay();
    PayStrategy dollarStrategy = new DollarPay();
    //准备小王的支付上下文
    PayContext ctx = new PayContext("小王",30000,rmbStrategy);
    //向小王支付工资
    ctx.pay();
    //准备Jack的支付上下文
    ctx = new PayContext("jack",10000,dollarStrategy);
    //向Jack支付工资
    ctx.pay();
    //创建支付到银行账户的支付策略
    PayStrategy accountStrategy = new AccountPay2("1234567890");
    //准备上下文
    ctx = new PayContext("小张",40000,accountStrategy);
    //向小张的账户支付
    ctx.pay();
    }
    }

    控制台输出:

    现在给:小王 人民币支付 30000.0元!
    现在给:jack 美金支付 10000.0dollar !
    现在给:小张的账户:1234567890 支付工资:40000.0 元!

    那我们来比较一下上面两种实现方式:

      扩展上下文的实现:

        优点:具体的策略实现风格很是统一,策略实现所需要的数据都是从上下文中获取的,在上下文中添加的数据,可以视为公共的数据,其他的策略实现也可以使用。

        缺点:很明显如果某些数据只是特定的策略实现需要,大部分的策略实现不需要,那这些数据有“浪费”之嫌,另外如果每次添加算法数据都扩展上下文,很容易导致上下文的层级很是复杂。

      在具体的策略实现上添加所需要的数据的实现:

        优点:容易想到,实现简单

        缺点:与其他的策略实现风格不一致,其他的策略实现所需数据都是来自上下文,而这个策略实现一部分数据来自于自身,一部分数据来自于上下文;外部在使用这个策略实现的时候也和其他的策略实现不一致了,难以以一个统一的方式动态的切换策略实现。


    收起阅读 »

    java 设计模式:工厂方法模式

    前言简单工厂模式每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类,这增加了系统的复杂度,违背了“开闭原则”。“工厂方法模式”是对简单工厂模式的进一步抽象化,其好处是可以使系统在不修改原来代码的情况下引进新的产品,即满足开闭原则。优点:用户只需要知道具...
    继续阅读 »

    前言

    简单工厂模式每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类,这增加了系统的复杂度,违背了“开闭原则”。
    “工厂方法模式”是对简单工厂模式的进一步抽象化,其好处是可以使系统在不修改原来代码的情况下引进新的产品,即满足开闭原则。

    优点:

    • 用户只需要知道具体工厂的名称就可得到所要的产品,无须知道产品的具体创建过程。
    • 灵活性增强,对于新产品的创建,只需多写一个相应的工厂类。
    • 典型的解耦框架。高层模块只需要知道产品的抽象类,无须关心其他实现类,满足迪米特法则、依赖倒置原则和里氏替换原则。

    缺点:

    • 类的个数容易过多,增加复杂度
    • 增加了系统的抽象性和理解难度
    • 抽象产品只能生产一种产品,此弊端可使用抽象工厂模式解决。

    应用场景:

    • 客户只知道创建产品的工厂名,而不知道具体的产品名。如 TCL 电视工厂、海信电视工厂等。
    • 创建对象的任务由多个具体子工厂中的某一个完成,而抽象工厂只提供创建产品的接口。
    • 客户不关心创建产品的细节,只关心产品的品牌

    代码实现

    工厂方法模式的主要角色如下。

    1. 抽象工厂:提供了创建产品的接口,调用者通过它访问具体工厂的工厂方法 newProduct() 来创建产品。
    2. 具体工厂:主要是实现抽象工厂中的抽象方法,完成具体产品的创建。
    3. 抽象产品:定义了产品的规范,描述了产品的主要特性和功能。
    4. 具体产品:实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间一一对应。


      在这里插入图片描述
      在这里插入图片描述

      kotlin代码实现

    //抽象产品:提供了产品的接口
    interface IProduct{
    fun setPingPai(string: String)
    fun showName() :String
    }
    //具体产品1:实现抽象产品中的抽象方法
    class Dog : IProduct{
    var pinPai:String? = null
    override fun setPingPai(string: String) {
    this.pinPai = string
    }

    override fun showName() = "dog"

    }
    //具体产品2:实现抽象产品中的抽象方法
    class Cat : IProduct{
    var pinPai:String? = null
    override fun setPingPai(string: String) {
    this.pinPai = string
    }
    override fun showName() = "cat"
    }
    //抽象工厂:提供了厂品的生成方法
    interface IFactory{
    fun getPinPai():String
    fun createProduct(type:Int):IProduct
    }
    //具体工厂1:实现了厂品的生成方法
    class ABCFactory():IFactory{
    override fun getPinPai() = "ABC"

    override fun createProduct(type: Int): IProduct {
    return when(type){
    1-> Dog().apply { setPingPai(getPinPai()) }
    2-> Cat().apply { setPingPai(getPinPai()) }
    else -> throw NullPointerException()
    }
    }

    }
    //具体工厂2:实现了厂品的生成方法
    class CBDFactory():IFactory{
    override fun getPinPai() = "CBD"
    override fun createProduct(type: Int): IProduct {
    return when(type){
    1-> Dog().apply { setPingPai(getPinPai()) }
    2-> Cat().apply { setPingPai(getPinPai()) }
    else -> throw NullPointerException()
    }
    }

    }

    Android源码分析

    ThreadFactory

    在这里插入图片描述
    在这里插入图片描述
    //抽象产品
    public interface Runnable {
    public abstract void run();
    }

    //抽象工厂
    public interface ThreadFactory {
    Thread newThread(Runnable r);
    }

    具体的实现

    //实现1 TaskThreadFactory
    class TaskThreadFactory(var name: String) : ThreadFactory {
    private val mThreadNumber = AtomicInteger(1)
    override fun newThread(r: Runnable): Thread {
    return Thread(r, name + "#" + mThreadNumber.getAndIncrement())
    }
    }
    //实现2 DiskLruCacheThreadFactory
    private static final class DiskLruCacheThreadFactory implements ThreadFactory {
    @Override
    public synchronized Thread newThread(Runnable runnable) {
    Thread result = new Thread(runnable, "glide-disk-lru-cache-thread");
    result.setPriority(Thread.MIN_PRIORITY);
    return result;
    }
    }

    解释:

    参数Runnable r,我们可以创建很多此类线程的产品类,我们还可以创建工厂来创造某类专用线程

    收起阅读 »

    java 设计模式:简单工厂

    工厂模式的定义定义一个创建产品对象的工厂接口,将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。简单工厂如果要创建的产品不多,只要一个工厂类就可以完成,这种模式叫“简单工厂模式”。简单工厂通常为静态方法,因此...
    继续阅读 »

    工厂模式的定义

    定义一个创建产品对象的工厂接口,将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。

    简单工厂

    如果要创建的产品不多,只要一个工厂类就可以完成,这种模式叫“简单工厂模式”。

    简单工厂通常为静态方法,因此又叫静态工厂方法模式

    优点:

    • 工厂类包含必要的逻辑判断,可以决定在什么时候创建哪一个产品的实例。客户端可以免除直接创建产品对象的职责,很方便的创建出相应的产品。工厂和产品的职责区分明确。
    • 客户端无需知道所创建具体产品的类名,只需知道参数即可。
      也可以引入配置文件,在不修改客户端代码的情况下更换和添加新的具体产品类。

    缺点:

    • 简单工厂模式的工厂类单一,负责所有产品的创建,职责过重,一旦异常,整个系统将受影响。且工厂类代码会非常臃肿,违背高聚合原则。
    • 使用简单工厂模式会增加系统中类的个数(引入新的工厂类),增加系统的复杂度和理解难度
    • 系统扩展困难,一旦增加新产品不得不修改工厂逻辑,在产品类型较多时,可能造成逻辑过于复杂
    • 简单工厂模式使用了 static 工厂方法,造成工厂角色无法形成基于继承的等级结构。

    应用场景

    对于产品种类相对较少的情况,考虑使用简单工厂模式。使用简单工厂模式的客户端只需要传入工厂类的参数,不需要关心如何创建对象的逻辑,可以很方便地创建所需产品。

    代码实现

    简单工厂模式的主要角色如下:

    • 简单工厂:是简单工厂模式的核心,负责实现创建所有实例的内部逻辑。工厂类的创建产品类的方法可以被外界直接调用,创建所需的产品对象。
    • 抽象产品:是简单工厂创建的所有对象的父类,负责描述所有实例共有的公共接口。
    • 具体产品:是简单工厂模式的创建目标。

    其结构图如下图所示。


    kotlin代码实现

    interface IProduct{
    fun showName() :String
    }

    class Dog : IProduct{
    override fun showName() = "dog"

    }

    class Cat : IProduct{
    override fun showName() = "cat"
    }

    object AnimalFactory{
    fun createAnimal(type:Int):IProduct{
    return when(type){
    1-> Dog()
    2-> Cat()
    else -> throw NullPointerException()
    }
    }
    }

    简单工厂模式在Android中的实际应用

    fragment 的构建

    有时候,为了简化简单工厂模式,我们可以将抽象产品类和工厂类合并,将静态工厂方法移至抽象产品类中。Fragment的创建使用简单工厂方法没有抽象产品类,所以工厂类放到了实现产品类中。

    class ListWorkFragment : BMvpFragment<ListWorkView ,ListWorkPresenter>(),ListWorkView,ISubjectView{
    companion object {
    @JvmStatic
    fun newInstance(recommendTypeId: Int,
    termCode: String = "") =
    ListWorkFragment().apply {
    arguments = Bundle().apply {
    putInt("type", recommendTypeId)
    putString("code", termCode)
    }
    }
    }

    优点

    1. 在创建Fragment的时候,可以不需要管内部参数,而从外部输入
    2. Fragment推荐使用setArguments来传递参数,避免在横竖屏切换的时候Fragment自动调用自己的无参构造函数,导致数据丢失。

    Bitmap源码分析

    @UnsupportedAppUsage(maxTargetSdk = 28)
    Bitmap(long nativeBitmap, int width, int height, int density,
    boolean requestPremultiplied, byte[] ninePatchChunk,
    NinePatch.InsetStruct ninePatchInsets) {
    this(nativeBitmap, width, height, density, requestPremultiplied, ninePatchChunk,
    ninePatchInsets, true);
    }

    // called from JNI and Bitmap_Delegate.
    Bitmap(long nativeBitmap, int width, int height, int density,
    boolean requestPremultiplied, byte[] ninePatchChunk,
    NinePatch.InsetStruct ninePatchInsets, boolean fromMalloc) {
    ...
    }

    看构造函数可知,无法new出bitmap,那么怎么创建bitmap对象呢?

     BitmapFactory.decodeFile("")

    内部源码

    public static Bitmap decodeFile(String pathName) {
    return decodeFile(pathName, null);
    }

    public static Bitmap decodeFile(String pathName, Options opts) {
    Bitmap bm = null;
    InputStream stream = null;
    try {
    stream = new FileInputStream(pathName);
    bm = decodeStream(stream, null, opts);
    } catch (Exception e) {
    /* do nothing.
    If the exception happened on open, bm will be null.
    */

    Log.e("BitmapFactory", "Unable to decode stream: " + e);
    } finally {
    if (stream != null) {
    try {
    stream.close();
    } catch (IOException e) {
    // do nothing here
    }
    }
    }
    return bm;
    }

    public static Bitmap decodeStream(InputStream is, Rect outPadding, Options opts) {
    // we don't throw in this case, thus allowing the caller to only check
    // the cache, and not force the image to be decoded.
    if (is == null) {
    return null;
    }

    Bitmap bm = null;

    Trace.traceBegin(Trace.TRACE_TAG_GRAPHICS, "decodeBitmap");
    try {
    if (is instanceof AssetManager.AssetInputStream) {
    final long asset = ((AssetManager.AssetInputStream) is).getNativeAsset();
    bm = nativeDecodeAsset(asset, outPadding, opts);
    } else {
    bm = decodeStreamInternal(is, outPadding, opts);
    }

    if (bm == null && opts != null && opts.inBitmap != null) {
    throw new IllegalArgumentException("Problem decoding into existing bitmap");
    }

    setDensityFromOptions(bm, opts);
    } finally {
    Trace.traceEnd(Trace.TRACE_TAG_GRAPHICS);
    }

    return bm;
    }

    private static native Bitmap nativeDecodeStream(InputStream is, byte[] storage,
    Rect padding, Options opts);

    /**
    * Set the newly decoded bitmap's density based on the Options.
    */

    private static void setDensityFromOptions(Bitmap outputBitmap, Options opts) {
    if (outputBitmap == null || opts == null) return;

    final int density = opts.inDensity;
    if (density != 0) {
    outputBitmap.setDensity(density);
    final int targetDensity = opts.inTargetDensity;
    if (targetDensity == 0 || density == targetDensity || density == opts.inScreenDensity) {
    return;
    }

    byte[] np = outputBitmap.getNinePatchChunk();
    final boolean isNinePatch = np != null && NinePatch.isNinePatchChunk(np);
    if (opts.inScaled || isNinePatch) {
    outputBitmap.setDensity(targetDensity);
    }
    } else if (opts.inBitmap != null) {
    // bitmap was reused, ensure density is reset
    outputBitmap.setDensity(Bitmap.getDefaultDensity());
    }
    }

    看下BitmapFactory的注释我们可以看到,这个工厂支持从不同的资源创建Bitmap对象,包括files, streams, 和byte-arrays,但是调用关系都大同小异。

    收起阅读 »

    Kotlin Vocabulary | 数据类

    一只小奶狗会有名字、品种以及一堆可爱的特点作为其属性。如果将其建模为一个类,并且只用来保存这些属性数据,那么您应当使用数据类。在使用数据类时,编译器会为您自动生成 toString()、equals() 与 hashCode() 函数,并提供开箱即用的 解构 ...
    继续阅读 »

    一只小奶狗会有名字、品种以及一堆可爱的特点作为其属性。如果将其建模为一个类,并且只用来保存这些属性数据,那么您应当使用数据类。在使用数据类时,编译器会为您自动生成 toString()equals()hashCode() 函数,并提供开箱即用的 解构 与拷贝功能,从而帮您简化工作,使您可以专注于那些需要展示的数据。接下来本文将会带您了解数据类的其他好处、限制以及其实现的内部原理。


    用法概览


    声明一个数据类,需要使用 data 修饰符并在其构造函数中以 val 或 var 参数的形式指定其属性。您可以为数据类的构造函数提供默认参数,就像其他函数与构造函数一样;您也可以直接访问和修改属性,以及在类中定义函数。


    但相比于普通类,您可以获得以下几个好处:



    • Kotlin 编译器已为您默认实现了 toString()equals()hashCode() 函数 ,从而避免了一系列人工操作可能造成的小错误,例如: 忘记在每次新增或更新属性后更新这些函数、实现 hashCode 时出现逻辑错误,或是在实现 equals 后忘记实现 hashCode 等;

    • 解构;

    • 通过 copy() 函数轻松进行拷贝。


    /* Copyright 2020 Google LLC.  
    SPDX-License-Identifier: Apache-2.0 */

    data class Puppy(
    val name: String,
    val breed: String,
    var cuteness: Int = 11
    )

    // 创建新的实例
    val tofuPuppy = Puppy(name = "Tofu", breed = "Corgi", cuteness = Int.MAX_VALUE)
    val tacoPuppy = Puppy(name = "Taco", breed = "Cockapoo")

    // 访问和修改属性
    val breed = tofuPuppy.breed
    tofuPuppy.cuteness++

    // 解构
    val (name, breed, cuteness) = tofuPuppy
    println(name) // prints: "Tofu"

    // 拷贝:使用与 tofuPuppy 相同的品种和可爱度创建一个小狗,但名字不同
    val tacoPuppy = tofuPuppy.copy(name = "Taco")

    限制


    数据类有着一系列的限制。


    构造函数参数


    数据类是作为数据持有者被创建的。为了强制执行这一角色,您必须至少传入一个参数到它的主构造函数,而且参数必须是 val 或 var 属性。尝试添加不带 val 或 var 的参数将会导致编译错误。


    作为最佳实践,请考虑使用 val 而不是 var,来提升不可变性,否则可能会出现一些细微的问题。如使用数据类作为 HashMap 对象的键时,容器可能会因为其 var 值的改变而获取出无效的结果。


    同样,尝试在主构造函数中添加 vararg 参数也会导致编译错误:


    /* Copyright 2020 Google LLC.  
    SPDX-License-Identifier: Apache-2.0 */

    data class Puppy constructor(
    val name: String,
    val breed: String,
    var cuteness: Int = 11,
    // 错误:数据类的的主构造函数中只能包含属性 (val 或 var) 参数
    playful: Boolean,
    // 错误:数据类型的主构造函数已禁用 vararg 参数
    vararg friends: Puppy
    )

    vararg 不被允许是由于 JVM 中数组和集合的 equals() 的实现方法不同。Andrey Breslav 的解释是:



    集合的 equals() 进行的是结构化比较,而数组不是,数组使用 equals() 等效于判断其引用是否相等: this === other。


    *阅读更多: blog.jetbrains.com/kotlin/2015…



    继承


    数据类可以继承于接口、抽象类或者普通类,但是不能继承其他数据类。数据类也不能被标记为 open。添加 open 修饰符会导致错误: Modifier ‘open’ is incompatible with ‘data’ (‘open’ 修饰符不兼容 ‘data’)


    内部实现


    为了理解这些功能为何能够实现,我们来检查下 Kotlin 究竟生成了什么。为了做到这点,我们需要查看反编译后的 Java 代码: Tools -> Kotlin -> Show Kotlin Bytecode,然后点击 Decompile 按钮。


    属性


    就像普通的类一样,Puppy 是一个公共 final 类,包含了我们定义的属性以及它们的 getter 和 setter:


    /* Copyright 2020 Google LLC.  
    SPDX-License-Identifier: Apache-2.0 */

    public final class Puppy {
    @NotNull
    private final String name;
    @NotNull
    private final String breed;
    private int cuteness;

    @NotNull
    public final String getName() {
    return this.name;
    }

    @NotNull
    public final String getBreed() {
    return this.breed;
    }

    public final int getCuteness() {
    return this.cuteness;
    }

    public final void setCuteness(int var1) {
    this.cuteness = var1;
    }
    ...
    }
    复制代码

    构造函数


    我们定义的构造函数是由编译器生成的。由于我们在构造函数中使用了默认参数,所以我们也得到了第二个合成构造函数。


    /* Copyright 2020 Google LLC.  
    SPDX-License-Identifier: Apache-2.0 */

    public Puppy(@NotNull String name, @NotNull String breed, int cuteness) {
    ...
    this.name = name;
    this.breed = breed;
    this.cuteness = cuteness;
    }

    // $FF: synthetic method
    public Puppy(String var1, String var2, int var3, int var4, DefaultConstructorMarker var5) {
    if ((var4 & 4) != 0) {
    var3 = 11;
    }

    this(var1, var2, var3);
    }
    ...
    }
    复制代码

    toString()、hashCode() 和 equals()


    Kotlin 会为您生成 toString()hashCode()equals() 方法。当您修改了数据类或更新了属性之后,也能自动为您更新为正确的实现。就像下面这样,hashCode()equals() 总是需要同步。在 Puppy 类中它们如下所示:


    /* Copyright 2020 Google LLC.  
    SPDX-License-Identifier: Apache-2.0 */

    ...
    @NotNull
    public String toString() {
    return "Puppy(name=" + this.name + ", breed=" + this.breed + ", cuteness=" + this.cuteness + ")";
    }

    public int hashCode() {
    String var10000 = this.name;
    int var1 = (var10000 != null ? var10000.hashCode() : 0) * 31;
    String var10001 = this.breed;
    return (var1 + (var10001 != null ? var10001.hashCode() : 0)) * 31 + this.cuteness;
    }

    public boolean equals(@Nullable Object var1) {
    if (this != var1) {
    if (var1 instanceof Puppy) {
    Puppy var2 = (Puppy)var1;
    if (Intrinsics.areEqual(this.name, var2.name) && Intrinsics.areEqual(this.breed, var2.breed) && this.cuteness == var2.cuteness) {
    return true;
    }
    }

    return false;
    } else {
    return true;
    }
    }
    ...


    toStringhashCode 函数的实现很直接,跟一般您所实现的类似,而 equals 使用了 Intrinsics.areEqual 以实现结构化比较:


    public static boolean areEqual(Object first, Object second) {
    return first == null ? second == null : first.equals(second);
    }
    复制代码

    通过使用方法调用而不是直接实现,Kotlin 语言的开发者可以获得更多的灵活性。如果有需要,他们可以在未来的语言版本中修改 areEqual 函数的实现。


    Component


    为了实现解构,数据类生成了一系列只返回一个字段的 componentN() 方法。component 的数量取决于构造函数参数的数量:


    /* Copyright 2020 Google LLC.  
    SPDX-License-Identifier: Apache-2.0 */
    ...
    @NotNull
    public final String component1() {
    return this.name;
    }

    @NotNull
    public final String component2() {
    return this.breed;
    }

    public final int component3() {
    return this.cuteness;
    }
    ...
    您可以通过阅读我们之前的 Kotlin Vocabulary 文章 来了解更多有关解构的内容。

    拷贝


    数据类会生成一个用于创建新对象实例的 copy() 方法,它可以保持任意数量的原对象属性值。您可以认为 copy() 是个含有所有数据对象字段作为参数的函数,它同时用原对象的字段值作为方法参数的默认值。知道了这一点,您就可以理解 Kotlin 为什么会创建两个 copy() 函数: copycopy$default。后者是一个合成方法,用来保证参数没有传值时,可以正确地使用原对象的值:


    /* Copyright 2020 Google LLC.  
    SPDX-License-Identifier: Apache-2.0 */
    ...
    @NotNull
    public final Puppy copy(@NotNull String name, @NotNull String breed, int cuteness) {
    Intrinsics.checkNotNullParameter(name, "name");
    Intrinsics.checkNotNullParameter(breed, "breed");
    return new Puppy(name, breed, cuteness);
    }

    // $FF: synthetic method
    public static Puppy copy$default(Puppy var0, String var1, String var2, int var3, int var4, Object var5) {
    if ((var4 & 1) != 0) {
    var1 = var0.name;
    }

    if ((var4 & 2) != 0) {
    var2 = var0.breed;
    }

    if ((var4 & 4) != 0) {
    var3 = var0.cuteness;
    }

    return var0.copy(var1, var2, var3);
    }
    ...总结

    数据类是 Kotlin 中最常用的功能之一,原因也很简单 —— 它减少了您需要编写的模板代码、提供了诸如解构和拷贝对象这样的功能,从而让您可以专注于重要的事: 您的应用。


    作者:Android_开发者
    链接:https://juejin.cn/post/6951587402041442317
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    Rxjava 线程切换原理

    前言 rxjava 可以很方便的进行线程切换, 那么rxjava是如何进行线程切换的呢?阅读本文可以了解下rxjava 是如何进行线程切换的及线程切换的影响点。 一个简单的代码: Observable.create(new ObservableOnSubsc...
    继续阅读 »

    前言


    rxjava 可以很方便的进行线程切换, 那么rxjava是如何进行线程切换的呢?阅读本文可以了解下rxjava 是如何进行线程切换的及线程切换的影响点。




    一个简单的代码:


    Observable.create(new ObservableOnSubscribe<String>() {
    @Override
    public void subscribe(ObservableEmitter<String> e) throws Exception {
    Log.d("WanRxjava ", "subscrib td ==" + Thread.currentThread().getName());
    e.onNext("我在发送next");
    e.onComplete();
    }
    }).subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(new Observer<String>() {
    @Override
    public void onSubscribe(Disposable d) {
    Log.d("WanRxjava ", "onSubscribe td ==" + Thread.currentThread().getName());
    }

    @Override
    public void onNext(String value) {
    Log.d("WanRxjava ", "onNext td ==" + Thread.currentThread().getName());
    }

    @Override
    public void onError(Throwable e) {

    }

    @Override
    public void onComplete() {
    Log.d("WanRxjava ", "onComplete td ==" + Thread.currentThread().getName());
    }
    });

    如上代码,实现了线程切换和观察者被观察者绑定的逻辑。我们分四部分看上述代码逻辑create、subscribeOn、observeOn、subscribe


    1.create

    create 顾名思议是 创建被观察者,这里有一个参数是 ObservableOnSubscribe,这是个接口类,我们看下create 的源码:


    @SchedulerSupport(SchedulerSupport.NONE)
    public static <T> Observable<T> create(ObservableOnSubscribe<T> source) {
    ObjectHelper.requireNonNull(source, "source is null");
    return RxJavaPlugins.onAssembly(new ObservableCreate<T>(source));
    }



    将ObservableOnSubscribe 传入后 又调用了 new ObservableCreate(source)


    public final class ObservableCreate<T> extends Observable<T> {
    final ObservableOnSubscribe<T> source;

    public ObservableCreate(ObservableOnSubscribe<T> source) {
    this.source = source;
    }
    }


    ObservableCreate 有一个变量是 source,这里只是将传入的ObservableOnSubscribe 赋值给source,也就是做了一层包装,然后返回。


    2.subscribeOn

    调用完create后返回了 ObservableCreate(Observable),然后继续调用subscribeOn,传入了一个变量 Schedulers.io()


    @SchedulerSupport(SchedulerSupport.CUSTOM)
    public final Observable<T> subscribeOn(Scheduler scheduler) {
    ObjectHelper.requireNonNull(scheduler, "scheduler is null");
    return RxJavaPlugins.onAssembly(new ObservableSubscribeOn<T>(this, scheduler));
    }


    我们看到调用了new ObservableSubscribeOn(this, scheduler) 将自身和 scheduler 传入


    public final class ObservableSubscribeOn<T> extends AbstractObservableWithUpstream<T, T> {
    final Scheduler scheduler;

    public ObservableSubscribeOn(ObservableSource<T> source, Scheduler scheduler) {
    super(source);
    this.scheduler = scheduler;
    }
    }


    ObservableSubscribeOn 将scheduler 和 create 返回的对象又包装了一层 返回ObservableSubscribeOn


    3.observeOn

    有一个参数是 Scheduler


    @SchedulerSupport(SchedulerSupport.CUSTOM)
    public final Observable<T> observeOn(Scheduler scheduler) {
    return observeOn(scheduler, false, bufferSize());
    }
    @SchedulerSupport(SchedulerSupport.CUSTOM)
    public final Observable<T> observeOn(Scheduler scheduler, boolean delayError, int bufferSize) {
    ObjectHelper.requireNonNull(scheduler, "scheduler is null");
    ObjectHelper.verifyPositive(bufferSize, "bufferSize");
    return RxJavaPlugins.onAssembly(new ObservableObserveOn<T>(this, scheduler, delayError, bufferSize));
    }


    ObservableSubscribeOn(observable)又调用了observeOn,然后调用了new ObservableObserveOn(this, scheduler, delayError, bufferSize)


    public final class ObservableObserveOn<T> extends AbstractObservableWithUpstream<T, T> {
    final Scheduler scheduler;
    final boolean delayError;
    final int bufferSize;
    public ObservableObserveOn(ObservableSource<T> source, Scheduler scheduler, boolean delayError, int bufferSize) {
    super(source);
    this.scheduler = scheduler;
    this.delayError = delayError;
    this.bufferSize = bufferSize;
    }
    }


    又是一个包装,将ObservableSubscribeOn 和 scheduler 包装成 ObservableObserveOn


    4.subscribe

    上述最后一步即调用ObservableObserveOn.subscribe,传入参数是一个 observer


    //ObservableObserveOn.java
    @SchedulerSupport(SchedulerSupport.NONE)
    @Override
    public final void subscribe(Observer<? super T> observer) {
    ObjectHelper.requireNonNull(observer, "observer is null");
    try {
    observer = RxJavaPlugins.onSubscribe(this, observer);

    ObjectHelper.requireNonNull(observer, "Plugin returned null Observer");

    subscribeActual(observer);
    } catch (NullPointerException e) { // NOPMD
    throw e;
    } catch (Throwable e) {
    Exceptions.throwIfFatal(e);
    // can't call onError because no way to know if a Disposable has been set or not
    // can't call onSubscribe because the call might have set a Subscription already
    RxJavaPlugins.onError(e);

    NullPointerException npe = new NullPointerException("Actually not, but can't throw other exceptions due to RS");
    npe.initCause(e);
    throw npe;
    }
    }


    可以看到调用subscribe 后调用了subscribeActual(observer);将observer 传入


    我们看下 subscribeActual(observer)


    //ObservableObserveOn.java
    @Override
    protected void subscribeActual(Observer<? super T> observer) {
    if (scheduler instanceof TrampolineScheduler) {
    source.subscribe(observer);
    } else {
    Scheduler.Worker w = scheduler.createWorker();

    source.subscribe(new ObserveOnObserver<T>(observer, w, delayError, bufferSize));
    }
    }


    上面的if 先不管,主要看下下面的逻辑,调用了 scheduler.createWorker(),这个scheduler 是 observeOn 传入的,然后调用


    new ObserveOnObserver(observer, w, delayError, bufferSize);将worker /observer 又做了一次包装。


    //ObservableObserveOn 内部类
    static final class ObserveOnObserver<T> extends BasicIntQueueDisposable<T>
    implements Observer<T>, Runnable {

    private static final long serialVersionUID = 6576896619930983584L;
    final Observer<? super T> actual;
    final Scheduler.Worker worker;
    final boolean delayError;
    final int bufferSize;

    SimpleQueue<T> queue;

    Disposable s;

    Throwable error;
    volatile boolean done;

    volatile boolean cancelled;

    int sourceMode;

    boolean outputFused;

    ObserveOnObserver(Observer<? super T> actual, Scheduler.Worker worker, boolean delayError, int bufferSize) {
    this.actual = actual;
    this.worker = worker;
    this.delayError = delayError;
    this.bufferSize = bufferSize;
    }

    @Override
    public void onSubscribe(Disposable s) {
    if (DisposableHelper.validate(this.s, s)) {
    this.s = s;
    if (s instanceof QueueDisposable) {
    @SuppressWarnings("unchecked")
    QueueDisposable<T> qd = (QueueDisposable<T>) s;

    int m = qd.requestFusion(QueueDisposable.ANY | QueueDisposable.BOUNDARY);

    if (m == QueueDisposable.SYNC) {
    sourceMode = m;
    queue = qd;
    done = true;
    actual.onSubscribe(this);
    schedule();
    return;
    }
    if (m == QueueDisposable.ASYNC) {
    sourceMode = m;
    queue = qd;
    actual.onSubscribe(this);
    return;
    }
    }

    queue = new SpscLinkedArrayQueue<T>(bufferSize);

    actual.onSubscribe(this);
    }
    }

    @Override
    public void onNext(T t) {
    if (done) {
    return;
    }

    if (sourceMode != QueueDisposable.ASYNC) {
    queue.offer(t);
    }
    schedule();
    }

    @Override
    public void onError(Throwable t) {
    if (done) {
    RxJavaPlugins.onError(t);
    return;
    }
    error = t;
    done = true;
    schedule();
    }

    @Override
    public void onComplete() {
    if (done) {
    return;
    }
    done = true;
    schedule();
    }

    @Override
    public void dispose() {
    if (!cancelled) {
    cancelled = true;
    s.dispose();
    worker.dispose();
    if (getAndIncrement() == 0) {
    queue.clear();
    }
    }
    }

    @Override
    public boolean isDisposed() {
    return cancelled;
    }

    void schedule() {
    if (getAndIncrement() == 0) {
    worker.schedule(this);
    }
    }

    void drainNormal() {
    int missed = 1;

    final SimpleQueue<T> q = queue;
    final Observer<? super T> a = actual;

    for (;;) {
    if (checkTerminated(done, q.isEmpty(), a)) {
    return;
    }

    for (;;) {
    boolean d = done;
    T v;

    try {
    v = q.poll();
    } catch (Throwable ex) {
    Exceptions.throwIfFatal(ex);
    s.dispose();
    q.clear();
    a.onError(ex);
    return;
    }
    boolean empty = v == null;

    if (checkTerminated(d, empty, a)) {
    return;
    }

    if (empty) {
    break;
    }

    a.onNext(v);
    }

    missed = addAndGet(-missed);
    if (missed == 0) {
    break;
    }
    }
    }

    void drainFused() {
    int missed = 1;

    for (;;) {
    if (cancelled) {
    return;
    }

    boolean d = done;
    Throwable ex = error;

    if (!delayError && d && ex != null) {
    actual.onError(error);
    worker.dispose();
    return;
    }

    actual.onNext(null);

    if (d) {
    ex = error;
    if (ex != null) {
    actual.onError(ex);
    } else {
    actual.onComplete();
    }
    worker.dispose();
    return;
    }

    missed = addAndGet(-missed);
    if (missed == 0) {
    break;
    }
    }
    }

    @Override
    public void run() {
    if (outputFused) {
    drainFused();
    } else {
    drainNormal();
    }
    }

    boolean checkTerminated(boolean d, boolean empty, Observer<? super T> a) {
    if (cancelled) {
    queue.clear();
    return true;
    }
    if (d) {
    Throwable e = error;
    if (delayError) {
    if (empty) {
    if (e != null) {
    a.onError(e);
    } else {
    a.onComplete();
    }
    worker.dispose();
    return true;
    }
    } else {
    if (e != null) {
    queue.clear();
    a.onError(e);
    worker.dispose();
    return true;
    } else
    if (empty) {
    a.onComplete();
    worker.dispose();
    return true;
    }
    }
    }
    return false;
    }

    @Override
    public int requestFusion(int mode) {
    if ((mode & ASYNC) != 0) {
    outputFused = true;
    return ASYNC;
    }
    return NONE;
    }

    @Override
    public T poll() throws Exception {
    return queue.poll();
    }

    @Override
    public void clear() {
    queue.clear();
    }

    @Override
    public boolean isEmpty() {
    return queue.isEmpty();
    }
    }


    包装完ObserveOnObserver后,调用了source.subscribe 这里的source 即ObservableSubscribeOn.subscribe,进而调用ObservableSubscribeOn.subscribeActual


    //ObservableSubscribeOn.java
    @Override
    public void subscribeActual(final Observer<? super T> s) {
    final SubscribeOnObserver<T> parent = new scheduler<T>(s);

    s.onSubscribe(parent);

    parent.setDisposable(scheduler.scheduleDirect(new Runnable() {
    @Override
    public void run() {
    source.subscribe(parent);
    }
    }));
    }

    static final class SubscribeOnObserver<T> extends AtomicReference<Disposable> implements Observer<T>, Disposable {

    private static final long serialVersionUID = 8094547886072529208L;
    final Observer<? super T> actual;

    final AtomicReference<Disposable> s;

    SubscribeOnObserver(Observer<? super T> actual) {
    this.actual = actual;
    this.s = new AtomicReference<Disposable>();
    }

    @Override
    public void onSubscribe(Disposable s) {
    DisposableHelper.setOnce(this.s, s);
    }

    @Override
    public void onNext(T t) {
    actual.onNext(t);
    }

    @Override
    public void onError(Throwable t) {
    actual.onError(t);
    }

    @Override
    public void onComplete() {
    actual.onComplete();
    }

    @Override
    public void dispose() {
    DisposableHelper.dispose(s);
    DisposableHelper.dispose(this);
    }

    @Override
    public boolean isDisposed() {
    return DisposableHelper.isDisposed(get());
    }

    void setDisposable(Disposable d) {
    DisposableHelper.setOnce(this, d);
    }
    }


    ObservableSubscribeOn.subscribeActual


    首先将传入的观察者封装成 SubscribeOnObserver

    然后触发了 onSubscribe,接着调用 scheduler.scheduleDirect(new Runnable() 这里的scheduler 是 subscribeOn 传入的

    最后调用了 scheduler.setsetDisposable方法。

    我们看到 run 的方法体即source.subscribe(parent);这里的source 即 ObservableCreate(ObservableOnSubscribe),传入了observer,然后调用 observer的OnNext 和 OnComplete 方法。


    5.小结:

    a. 调用Observer.OnSubscribe 方法是 不受线程调度影响的

    b.subscribeOn 影响的是发送事件的线程

    c.observerOn 影响的是观察者处理接受数据的线程,如果没有调用observeOn 则不会进行包装成 ObserveOnObserver,也就是说不会执行观察者的线程切换,和 发送者的线程一致

    d.多次调用subscribeOn切换线程,每次都会new ObservableSubscribeOn,触发事件发送时会往上调用,也就是第一次调用的subscribeOn传入的线程 会执行发送事件,后面的线程切换无效

    e.Observer.OnSubscribe 只会执行一次,因为调用DisposableHelper.setOnce(this.s, s)

    f.处理完onComplete 或者onError 后就不会再发出事件,因为被观察者发送完这两个事件后 就会调用disposed


    作者:YDG
    链接:https://juejin.cn/post/6952831553349091358
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    收起阅读 »

    聊聊 Bitmap 的一些知识点

    Bitmap 应该是很多应用中最占据内存空间的一类资源了,Bitmap 也是导致应用 OOM 的常见原因之一。例如,Pixel 手机的相机拍摄的照片最大可达 4048 * 3036 像素(1200 万像素),如果使用的位图配置为 ARGB_8888(Andro...
    继续阅读 »

    Bitmap 应该是很多应用中最占据内存空间的一类资源了,Bitmap 也是导致应用 OOM 的常见原因之一。例如,Pixel 手机的相机拍摄的照片最大可达 4048 * 3036 像素(1200 万像素),如果使用的位图配置为 ARGB_8888(Android 2.3 及更高版本的默认设置),将单张照片加载到内存大约需要 48MB 内存(4048 * 3036 * 4 字节),如此庞大的内存需求可能会立即耗尽应用的所有可用内存


    本篇文章就来讲下 Bitmap 一些比较有用的知识点,希望对你有所帮助 😇😇


    全文可以概括为以下几个问题:



    1. Bitmap 所占内存大小的计算公式?

    2. Bitmap 所占内存大小和所在的 drawable 文件夹的关系?

    3. Bitmap 所占内存大小和 ImageView 的宽高的关系?

    4. Bitmap 如何减少内存大小?


    1、预备知识


    在开始讲关于 Bitmap 的知识点前,需要先阐述一些基础概念作为预备知识


    我们知道,在不同手机屏幕上 1dp 所对应的 px 值可能是会有很大差异的。例如,在小屏幕手机上 1dp 可能对应 1px,在大屏幕手机上对应的可能是 3px,这也是我们的应用实现屏幕适配的原理基础之一


    想要知道在特定一台手机上 1dp 对应多少 px,或者是想要知道屏幕宽高大小,这些信息都可以通过 DisplayMetrics 来获取


    val displayMetrics = applicationContext.resources.displayMetrics


    打印出本文所使用的模拟器的 DisplayMetrics 信息:


    DisplayMetrics{density=3.0, width=1080, height=1920, scaledDensity=3.0, xdpi=480.0, ydpi=480.0}


    从中就可以提取出几点信息:



    1. density 等于 3,说明在该模拟器上 1dp 等于 3px

    2. 屏幕宽高大小为 1920 x 1080 px,即 640 x 360 dp

    3. 屏幕像素密度为 480dpi


    dpi 是一个很重要的值,指的是在系统软件上指定的单位尺寸的像素数量,往往是写在系统出厂配置文件的一个固定值。Android 系统定义的屏幕像素密度基准值是 160dpi,该基准值下 1dp 就等于 1px,依此类推 320dpi 下 1dp 就等于 2px


    dpi 决定了应用在显示 drawable 时是选择哪一个文件夹内的切图。每个 drawable 文件夹都对应不同的 dpi 大小,Android 系统会自动根据当前手机的实际 dpi 大小从合适的 drawable 文件夹内选取图片,不同的后缀名对应的 dpi 大小就如以下表格所示。如果 drawable 文件夹名不带后缀,那么该文件夹就对应 160dpi


    对于本文所使用的模拟器来说,应用在选择图片时就会优先从 drawable-xxhdpi 文件夹拿,如果该文件夹内没找到图片,就会依照 xxxhdpi -> xhdpi -> hdpi -> mdpi -> ldpi 的顺序进行查找,优先使用高密度版本的图片资源


    2、内存大小的计算公式


    先将一张大小为 1920 x 1080 px 的图片保存到 drawable-xxhdpi 文件夹内,然后将其显示在一个宽高均为 180dp 的 ImageView 上,该 Bitmap 所占用的内存就通过 bitmap.byteCount来获取


        val options = BitmapFactory.Options()
    val bitmap = BitmapFactory.decodeResource(resources, R.drawable.icon_awe, options)
    imageView.setImageBitmap(bitmap)
    log("imageView width: " + imageView.width)
    log("imageView height: " + imageView.height)
    log("bitmap width: " + bitmap.width)
    log("bitmap height: " + bitmap.height)
    log("bitmap config: " + bitmap.config)
    log("inDensity: " + options.inDensity)
    log("inTargetDensity: " + options.inTargetDensity)
    log("bitmap byteCount: " + bitmap.byteCount)


    BitmapMainActivity: imageView width: 540
    BitmapMainActivity: imageView height: 540
    BitmapMainActivity: bitmap width: 1920
    BitmapMainActivity: bitmap height: 1080
    BitmapMainActivity: bitmap config: ARGB_8888
    BitmapMainActivity: inDensity: 480
    BitmapMainActivity: inTargetDensity: 480
    BitmapMainActivity: bitmap byteCount: 8294400



    • 由于模拟器的 density 等于 3,所以 ImageView 的宽高都是 540 px

    • Bitmap 的宽高还是保持其原有大小,即1920 x 1080 px

    • ARGB_8888 代表的是该 Bitmap 的编码格式,该格式下一个像素点需要占用 4 byte

    • inDensity 代表的是系统最终选择的 drawable 文件夹类型,等于 480 说明取的是 drawable-xxhdpi文件夹下的图片

    • inTargetDensity 代表的是当前设备的 dpi

    • 8294400 就是 Bitmap 所占用的内存大小,单位是 byte


    从最终结果可以很容易地就逆推出 Bitmap 所占内存大小的计算公式:bitmapWidth * bitmapHeight * 单位像素点所占用的字节数,即 1920 * 1080 * 4 = 8294400


    此外,在 Android 2.3 版本之前,Bitmap 像素存储需要的内存是在 native 上分配的,并且生命周期不太可控,可能需要用户自己回收。2.3 - 7.1 之间,Bitmap 的像素存储在 Dalvik 的 Java 堆上,当然,4.4 之前的甚至能在匿名共享内存上分配(Fresco采用),而 8.0 之后的像素内存又重新回到 native 上去分配,不需要用户主动回收,8.0 之后图像资源的管理更加优秀,极大降低了 OOM


    3、和 drawable 文件夹的关系


    上面之所以很容易就逆推出了 Bitmap 所占内存大小的计算公式,是因为所有条件都被我故意设定为最优情况了,才使得计算过程这么简单。而实际上 Bitmap 所占内存大小和其所在的 drawable 文件夹是有很大关系的,虽然计算公式没变


    现在的大部分应用为了达到最优的显示效果,会为应用准备多套切图放在不同的 drawable 文件夹下,而BitmapFactory.decodeResource 方法在解码 Bitmap 的时候,就会自动根据当前设备的 dpi 和 drawable 文件夹类型来判断是否需要对图片进行缩放显示


    将图片从 drawable-xxhdpi迁移到 drawable-xhdpi文件夹,然后再打印日志信息


    BitmapMainActivity: imageView width: 540
    BitmapMainActivity: imageView height: 540
    BitmapMainActivity: bitmap width: 2880
    BitmapMainActivity: bitmap height: 1620
    BitmapMainActivity: bitmap config: ARGB_8888
    BitmapMainActivity: inDensity: 320
    BitmapMainActivity: inTargetDensity: 480
    BitmapMainActivity: bitmap byteCount: 18662400

    可以看到,Bitmap 的宽高都发生了变化,inDensity 等于 320 也说明了选取的是drawable-xhdpi文件夹内的图片,Bitmap 所占内存居然增加了一倍多


    模拟器的 dpi 是 480,拿到了 dpi 为 320 的drawable-xhdpi文件夹下的图片,在系统的理解中该文件夹存放的都是小图标,是为小屏幕手机准备的,现在要在大屏幕手机上展示的话就需要对其进行放大,放大的比例就是 480 / 320 = 1.5 倍,因此 Bitmap 的宽就会变为 1920 * 1.5 = 2880 px,高就会变为 1080 * 1.5 = 1620 px,最终占用的内存空间大小就是 2880 * 1620 * 4 = 18662400


    所以说,对于同一台手机,Bitmap 在不同 drawable 文件夹下对其最终占用的内存大小是有很大关系的,虽然计算公式没变,但是由于系统会进行自动缩放,Bitmap 的宽高都变为了原先的 1.5 倍,导致最终 Bitmap 的内存大小就变为了 8294400 * 1.5 * 1.5 = 18662400


    同理,对于同个 drawable 文件夹下的同一张图片,在不同的手机屏幕上也可能会占用不同的内存空间,因为不同的手机的 dpi 大小可能是不一样的,BitmapFactory 进行缩放的比例也就不一样


    4、和 ImageView 的宽高的关系


    在上一个例子里,Bitmap 的宽高是 2880 * 1620 px,ImageView 的宽高是 540 * 540 px,该 Bitmap 肯定是会显示不全的,读者可以试着自己改变 ImageView 的宽高大小来验证是否会对 Bitmap 的大小产生影响


    这里就不贴代码了,直接来说结论,答案是没有关系。原因也很简单,毕竟上述例子是先将 Bitmap 加载到内存中后再设置给 ImageView 的,ImageView 自然不会影响到 Bitmap 的加载过程,该 Bitmap 的大小只受其所在的 drawable 文件夹类型以及手机的 dpi 大小这两个因素的影响。但这个结论是需要考虑测试方式的,如果你是使用 Glide 来加载图片,Glide 内部实现了按需加载的机制,避免由于 Bitmap 过大而 ImageView 显示不全导致内存浪费的情况,这种情况下 ImageView 的宽高就会影响到 Bitmap 的内存大小了


    5、BitmapFactory


    BitmapFactory 提供了很多个方法用于加载 Bitmap 对象:decodeFile、decodeResourceStream、decodeResource、decodeByteArray、decodeStream 等多个,但只有 decodeResourceStreamdecodeResource 这两个方法才会根据 dpi 进行自动缩放


    decodeResource 方法也会调用到decodeResourceStream方法,decodeResourceStream方法如果判断到inDensityinTargetDensity 两个属性外部没有主动赋值的话,就会根据实际情况进行赋值。如果是从磁盘或者 assert 目录加载图片的话是不会进行自动缩放的,毕竟这些来源也不具备 dpi 信息,Bitmap 的分辨率也只能保持其原有大小


    	@Nullable
    public static Bitmap decodeResourceStream(@Nullable Resources res, @Nullable TypedValue value,
    @Nullable InputStream is, @Nullable Rect pad, @Nullable Options opts) {
    validate(opts);
    if (opts == null) {
    opts = new Options();
    }
    if (opts.inDensity == 0 && value != null) {
    final int density = value.density;
    if (density == TypedValue.DENSITY_DEFAULT) {
    //如果 density 没有赋值的话(等于0),那么就使用基准值 160 dpi
    opts.inDensity = DisplayMetrics.DENSITY_DEFAULT;
    } else if (density != TypedValue.DENSITY_NONE) {
    //在这里进行赋值,density 就等于 drawable 对应的 dpi
    opts.inDensity = density;
    }
    }
    if (opts.inTargetDensity == 0 && res != null) {
    //如果没有主动设置 inTargetDensity 的话,inTargetDensity 就等于设备的 dpi
    opts.inTargetDensity = res.getDisplayMetrics().densityDpi;
    }
    return decodeStream(is, pad, opts);
    }

    6、Bitmap.Config


    Bitmap.Config 定义了四种常见的编码格式,分别是:



    • ALPHA_8。每个像素点需要一个字节的内存,只存储位图的透明度,没有颜色信息

    • ARGB_4444。A(Alpha)、R(Red)、G(Green)、B(Blue)各占四位精度,共计十六位的精度,折合两个字节,也就是说一个像素点占两个字节的内存,会存储位图的透明度和颜色信息

    • ARGB_8888。ARGB 各占八个位的精度,折合四个字节,会存储位图的透明度和颜色信息

    • RGB_565。R占五位精度,G占六位精度,B占五位精度,一共是十六位精度,折合两个字节,只存储颜色信息,没有透明度信息


    7、优化 Bitmap


    根据 Bitmap 所占内存大小的计算公式:bitmapWidth * bitmapHeight * 单位像素点所占用的字节数,想要尽量减少 Bitmap 占用的内存大小的话就要从降低图片分辨率降低单位像素需要的字节数这两方面来考虑了


    在一开始的情况下加载到的 Bitmap 的宽高是 1920 * 1080,占用的内存空间是 1920 * 1080 * 4 = 8294400,约 7.9 MB,这是优化前的状态


        val options = BitmapFactory.Options()
    val bitmap = BitmapFactory.decodeResource(resources, R.drawable.icon_awe, options)
    imageView.setImageBitmap(bitmap)
    log("bitmap width: " + bitmap.width)
    log("bitmap height: " + bitmap.height)
    log("bitmap config: " + bitmap.config)
    log("inDensity: " + options.inDensity)
    log("inTargetDensity: " + options.inTargetDensity)
    log("bitmap byteCount: " + bitmap.byteCount)

    BitmapMainActivity: bitmap width: 1920
    BitmapMainActivity: bitmap height: 1080
    BitmapMainActivity: bitmap config: ARGB_8888
    BitmapMainActivity: inDensity: 480
    BitmapMainActivity: inTargetDensity: 480
    BitmapMainActivity: bitmap byteCount: 8294400

    1、inSampleSize


    由于 ImageView 的宽高只有 540 * 540 px,此时 Bitmap 也只能在 ImageView 上显示为一个像素缩略图,如果进行原图加载的话其实会造成很大的内存浪费,此时我们就可以通过 inSampleSize 属性来压缩图片尺寸


    例如,将 inSampleSize 设置为 2 后,Bitmap 的宽高就都会缩减为原先的一半,占用的内存空间就变成了原先的四分之一, 960 * 540 * 4 = 2073600,约 1.9 MB


        val options = BitmapFactory.Options()
    options.inSampleSize = 2
    val bitmap = BitmapFactory.decodeResource(resources, R.drawable.icon_awe, options)
    imageView.setImageBitmap(bitmap)
    log("bitmap width: " + bitmap.width)
    log("bitmap height: " + bitmap.height)
    log("bitmap config: " + bitmap.config)
    log("inDensity: " + options.inDensity)
    log("inTargetDensity: " + options.inTargetDensity)
    log("bitmap byteCount: " + bitmap.byteCount)

    BitmapMainActivity: bitmap width: 960
    BitmapMainActivity: bitmap height: 540
    BitmapMainActivity: bitmap config: ARGB_8888
    BitmapMainActivity: inDensity: 480
    BitmapMainActivity: inTargetDensity: 480
    BitmapMainActivity: bitmap byteCount: 2073600

    可以看到,inSampleSize 属性应该设置多少是需要根据 Bitmap 的实际宽高ImageView 的实际宽高这两个条件来一起决定的。我们在正式加载 Bitmap 前要先获取到 Bitmap 的实际宽高大小,这可以通过 inJustDecodeBounds 属性来实现。设置 inJustDecodeBounds 为 true 后 decodeResource方法只会去读取 Bitmap 的宽高属性而不会去进行实际加载,这个操作是比较轻量级的。然后通过每次循环对半折减,计算出 inSampleSize 需要设置为多少才能尽量接近到 ImageView 的实际宽高,之后将 inJustDecodeBounds 设置为 false 去实际加载 Bitmap


        val options = BitmapFactory.Options()
    options.inJustDecodeBounds = true
    BitmapFactory.decodeResource(resources, R.drawable.icon_awe, options)
    val inSampleSize = calculateInSampleSize(options, imageView.width, imageView.height)
    options.inSampleSize = inSampleSize
    options.inJustDecodeBounds = false
    val bitmap = BitmapFactory.decodeResource(resources, R.drawable.icon_awe, options)
    imageView.setImageBitmap(bitmap)

    fun calculateInSampleSize(options: BitmapFactory.Options, reqWidth: Int, reqHeight: Int): Int {
    // Raw height and width of image
    val (height: Int, width: Int) = options.run { outHeight to outWidth }
    var inSampleSize = 1
    if (height > reqHeight || width > reqWidth) {
    val halfHeight: Int = height / 2
    val halfWidth: Int = width / 2
    // Calculate the largest inSampleSize value that is a power of 2 and keeps both
    // height and width larger than the requested height and width.
    while (halfHeight / inSampleSize >= reqHeight && halfWidth / inSampleSize >= reqWidth) {
    inSampleSize *= 2
    }
    }
    return inSampleSize
    }

    需要注意的是,inSampleSize 使用的最终值将是向下舍入为最接近的 2 的幂,BitmapFactory 内部会自动会该值进行校验修正


    2、inTargetDensity


    如果我们不主动设置 inTargetDensity 的话,decodeResource 方法会自动根据当前设备的 dpi 来对 Bitmap 进行缩放处理,我们可以通过主动设置 inTargetDensity 来控制缩放比例,从而控制 Bitmap 的最终宽高。最终宽高的生成规则: 180 / 480 * 1920 = 720,180 / 480 * 1080 = 405,占用的内存空间是 720 * 405 * 4 = 1166400,约 1.1 MB


        val options = BitmapFactory.Options()
    options.inTargetDensity = 180
    val bitmap = BitmapFactory.decodeResource(resources, R.drawable.icon_awe, options)
    imageView.setImageBitmap(bitmap)
    log("bitmap width: " + bitmap.width)
    log("bitmap height: " + bitmap.height)
    log("bitmap config: " + bitmap.config)
    log("inDensity: " + options.inDensity)
    log("inTargetDensity: " + options.inTargetDensity)
    log("bitmap byteCount: " + bitmap.byteCount)

    BitmapMainActivity: bitmap width: 720
    BitmapMainActivity: bitmap height: 405
    BitmapMainActivity: bitmap config: ARGB_8888
    BitmapMainActivity: inDensity: 480
    BitmapMainActivity: inTargetDensity: 480
    BitmapMainActivity: bitmap byteCount: 1166400

    3、Bitmap.Config


    BitmapFactory 默认使用的编码图片格式是 ARGB_8888,每个像素点占用四个字节,我们可以按需改变要采用的图片格式。例如,如果要加载的 Bitmap 不包含透明通道的,我们可以使用 RGB_565,该格式每个像素点占用两个字节,占用的内存空间是 1920 * 1080 * 2 = 4147200,约 3.9 MB


        val options = BitmapFactory.Options()
    options.inPreferredConfig = Bitmap.Config.RGB_565
    val bitmap = BitmapFactory.decodeResource(resources, R.drawable.icon_awe, options)
    imageView.setImageBitmap(bitmap)
    log("bitmap width: " + bitmap.width)
    log("bitmap height: " + bitmap.height)
    log("bitmap config: " + bitmap.config)
    log("inDensity: " + options.inDensity)
    log("inTargetDensity: " + options.inTargetDensity)
    log("bitmap byteCount: " + bitmap.byteCount)

    BitmapMainActivity: bitmap width: 1920
    BitmapMainActivity: bitmap height: 1080
    BitmapMainActivity: bitmap config: RGB_565
    BitmapMainActivity: inDensity: 480
    BitmapMainActivity: inTargetDensity: 480
    BitmapMainActivity: bitmap byteCount: 4147200

    作者:业志陈
    链接:https://juejin.cn/post/6952429810207424526
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

    kotlin 扩展函数之Boolean扩展

    Kotlin 扩展函数Kotlin 能够扩展一个类的新功能而无需继承该类或者使用像装饰者这样的设计模式,这样一来,可以为一个你不能修改的、来自第三方库中的类编写一个新的函数。 这个新增的函数就像那个原始类本来就有的函数一样,可以用普通的方法调用。我们在Andr...
    继续阅读 »

    kotlin 扩展函数之Boolean扩展

    Kotlin 扩展函数

    Kotlin 能够扩展一个类的新功能而无需继承该类或者使用像装饰者这样的设计模式,这样一来,可以为一个你不能修改的、来自第三方库中的类编写一个新的函数。 这个新增的函数就像那个原始类本来就有的函数一样,可以用普通的方法调用。我们在Android 开发中,对于Android 经常使用的API 都可以结合业务做扩展处理,处理之后即可达到某部分业务相关的API逻辑全盘使用。

    比如对于Fragment中ViewMdoel 对象上下文转换的扩展

    inline fun <reified T : ViewModel> Fragment.viewModel(
    factory: ViewModelProvider.Factory,
    body: T.() -> Unit
    ): T {
    val vm = ViewModelProviders.of(this, factory)[T::class.java]
    vm.body()
    return vm
    }
    复制代码

    今天对我们常用的基本数据类型Boolean进行一个扩展

    目的: 能让我们在使用的过程中更加符合阅读的逻辑思维,更加简便,不使用if else(明文)表达式, 先上代码和测试用例:

    代码:BooleanEtx.kt

    package com.kpa.component.ui.extension

    /**
    * @author: kpa
    * @time: 2021/4/17
    * @email: billkp@yeah.net
    **/


    /**
    * 数据
    */

    sealed class BooleanExt<out T>

    object Otherwise : BooleanExt<Nothing>()
    class WithData<T>(val data: T) : BooleanExt<T>()

    /**
    * 判断条件为true 时执行block
    */

    inline fun <T : Any> Boolean.yes(block: () -> T) =
    when {
    this -> {
    WithData(block())
    }
    else -> {
    Otherwise
    }
    }

    /**
    * 判断条件为false 时执行block
    *
    */

    inline fun <T> Boolean.no(block: () -> T) = when {
    this -> Otherwise
    else -> {
    WithData(block())
    }
    }

    /**
    * 与判断条件互斥时执行block
    */

    inline fun <T> BooleanExt<T>.otherwise(block: () -> T): T =
    when (this) {
    is Otherwise -> block()
    is WithData -> this.data
    }
    复制代码

    测试用例:

    @Test
    fun addition_isCorrect() {
    true.yes {
    // doSomething
    }
    false.no{
    // doSomething
    }
    // 有返回值(条件为true)
    val otherwise = getBoolean().yes {
    2
    }.otherwise {
    1
    }
    assertEquals(otherwise, 2)
    // 有返回值(条件为false)
    val otherwise1 = false.no {
    2
    }.otherwise {
    3
    }
    assertEquals(otherwise1, 2)
    }


    fun getBoolean() = true
    复制代码

    总结:

    这样就能在工作中直接根据业务去写对应的逻辑了,并且使用了inline函数,所以在字节码层面我们还是if else 的,所以不需担心安全问题,简化了代码,唯一添加的开销就是创建数据返回类WithData,当然在我们开发中是可以忽略不计的。

    收起阅读 »

    Kotlin 单例模式的常用写法

    饿汉式 object Singleton 复制代码 线程安全的懒汉式 class Singleton private constructor() { companion object { private var instance: S...
    继续阅读 »

    饿汉式


    object Singleton
    复制代码

    线程安全的懒汉式


    class Singleton private constructor() {

    companion object {
    private var instance: Singleton? = null
    get() {
    if (field == null) field = Singleton()
    return field
    }

    @Synchronized
    fun instance(): Singleton {
    return instance!!
    }
    }
    }
    复制代码

    双重校验锁式


    class KtSingleton3 private constructor() {
    companion object {
    val instance by lazy { KtSingleton3() }
    }
    }
    复制代码

    Lazy 是接受一个 lambda 并返回一个 Lazy 实例的函数,返回的实例可以作为实现延迟属性的委托。第一次调用 get() 会执行已传递给 lazy()lambda 表达式并记录结果,后续调用 get() 只是返回记录的结果。Lazy 默认的线程模式就是 LazyThreadSafetyMode.SYNCHRONIZED 内部默认双重校验锁


    Lazy内部实现


    public fun <T> lazy(mode: LazyThreadSafetyMode, initializer: () -> T): Lazy<T> =
    when (mode) {
    LazyThreadSafetyMode.SYNCHRONIZED -> SynchronizedLazyImpl(initializer)
    LazyThreadSafetyMode.PUBLICATION -> SafePublicationLazyImpl(initializer)
    LazyThreadSafetyMode.NONE -> UnsafeLazyImpl(initializer)
    }
    复制代码

    Lazy接口


    public interface Lazy<out T> {
    //当前实例化对象,一旦实例化后,该对象不会再改变
    public val value: T
    //返回true表示,已经延迟实例化过了,false 表示,没有被实例化,
    //一旦方法返回true,该方法会一直返回true,且不会再继续实例化
    public fun isInitialized(): Boolean
    }
    复制代码

    SynchronizedLazyImpl


    private class SynchronizedLazyImpl<out T>(initializer: () -> T, lock: Any? = null) : Lazy<T>, Serializable {
    private var initializer: (() -> T)? = initializer
    @Volatile private var _value: Any? = UNINITIALIZED_VALUE
    // final field is required to enable safe publication of constructed instance
    private val lock = lock ?: this

    override val value: T
    get() {
    val _v1 = _value
    //判断是否已经初始化过,如果初始化过直接返回,不在调用高级函数内部逻辑
    if (_v1 !== UNINITIALIZED_VALUE) {
    @Suppress("UNCHECKED_CAST")
    return _v1 as T
    }

    return synchronized(lock) {
    val _v2 = _value
    if (_v2 !== UNINITIALIZED_VALUE) {
    @Suppress("UNCHECKED_CAST") (_v2 as T)
    }
    else {
    //调用高级函数获取其返回值
    val typedValue = initializer!!()
    //将返回值赋值给_value,用于下次判断时,直接返回高级函数的返回值
    _value = typedValue
    initializer = null
    typedValue
    }
    }
    }
    //省略部分代码
    }
    复制代码

    静态内部类式


    class Singleton private constructor() {
    companion object {
    val instance = SingletonHolder.holder
    }

    private object SingletonHolder {
    val holder = Singleton()
    }
    }
    复制代码

    枚举式


    enum class Singleton {
    INSTANCE;
    }

    作者:Quyunshuo
    链接:https://juejin.cn/post/6952766742598778887
    来源:掘金
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
    收起阅读 »

    java 设计模式:组合模式

    1、概念将对象以树形结构组织起来,以达成“部分-整体”的层次机构,使得客户端对单个对象和组合对象的使用具有一致性。是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象,用来表示部分以及整体层次。这种类型的设计模式属于结构型模式,它创建了对象...
    继续阅读 »

    1、概念

    将对象以树形结构组织起来,以达成“部分-整体”的层次机构,使得客户端对单个对象和组合对象的使用具有一致性。

    是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象,用来表示部分以及整体层次。这种类型的设计模式属于结构型模式,它创建了对象组的树形结构。

    这种模式创建了一个包含自己对象组的类。该类提供了修改相同对象组的方式。

    2、使用场景

    部分、整体场景,如树形菜单,文件、文件夹的管理。

    1. 需要表示一个对象整体或部分层次
    2. 希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象。

    3、如何使用

    树枝和叶子实现统一接口,树枝内部组合该接口。

    4、UML结构图分析

    5、实际代码分析

    例:文件与文件夹的关系

    先进行普通的实现方式

    //文件类
    public class File {
    public String name;

    public File(String name) {
    this.name = name;
    }

    /**
    * 操作方法
    * @return
    */
    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }

    public void watch() {
    System.out.println("文件名"+getName()+"文件数目");
    }
    }
    //文件夹类
    public class Folder{
    public String name;

    private List<File> mFileList;
    public Folder(String name) {
    mFileList = new ArrayList<>();
    this.name = name;
    }

    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }

    public void watch() {
    StringBuilder sb = new StringBuilder();
    for(File f:mFileList){
    sb.append(f.name);
    }
    System.out.println("文件名"+getName()+"文件数目"+ mFileList.size()+"名字"+sb.toString());
    }

    public void add(File file) {
    mFileList.add(file);
    }

    public void remove(File file) {
    mFileList.remove(file);
    }

    public File getChild(int pos) {
    return mFileList.get(pos);
    }
    }
    //运行
    File file = new File("hehe");
    Folder folder = new Folder("heere");
    folder.add(file);
    folder.watch();

    文件和文件夹作为两个类来进行操作,将文件类进行添加文件,但是呢?如果文件夹下添加文件夹该咋办呢?就需要再创建一个list来存放文件夹,这样大家都是节点,为啥搞得这么复杂呢?既然存在上下级节点的问题,咱们就抽象为一个抽象类,用抽象类作为节点,子类就是文件夹和文件。

    //将文件与文件夹统一看作是一类节点,做一个抽象类来定义这种节点,然后以其实现类来区分文件与目录,在实现类中分别定义各自的具体实现内容,把组合方法写到这个节点类中
    public abstract class File {

    public String name;

    public File(String name) {
    this.name = name;
    }

    /**
    * 操作方法
    * @return
    */
    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }

    public abstract void watch();

    /**
    * 组合方法
    * @param file
    */
    public void add(File file){
    throw new UnsupportedOperationException();
    }

    public void remove(File file){
    throw new UnsupportedOperationException();
    }

    public File getChild(int pos){
    throw new UnsupportedOperationException();
    }

    }
    public class Folder extends File{

    private List<File> mFileList;
    public Folder(String name) {
    super(name);
    mFileList = new ArrayList<>();
    }

    @Override
    public void watch() {
    StringBuilder sb = new StringBuilder();
    for(File f:mFileList){
    sb.append(f.name);
    }
    System.out.println("文件名"+getName()+"文件数目"+ mFileList.size()+"名字"+sb.toString());
    }

    @Override
    public void add(File file) {
    mFileList.add(file);
    }

    @Override
    public void remove(File file) {
    mFileList.remove(file);
    }

    @Override
    public File getChild(int pos) {
    return mFileList.get(pos);
    }
    }
    public class TestFile extends File {
    public TestFile(String name) {
    super(name);
    }

    @Override
    public void watch() {
    System.out.println("文件名"+getName()+"文件数目");
    }
    }
    //运行
    TestFile file = new TestFile("hehe");
    Folder folder = new Folder("heere");
    folder.add(file);
    folder.watch();
    folder.getChild(0).watch();

    这种组合模式正是应树形结构而生,所以组合模式的使用场景就是出现树形结构的地方。比如:文件目录显示,多及目录呈现等树形结构数据的操作。

    安全组合模式(简化)如下code

    //将文件与文件夹统一看作是一类节点,做一个抽象类来定义这种节点,然后以其实现类来区分文件与目录,在实现类中分别定义各自的具体实现内容,把组合方法写到这个节点类中
    public abstract class File {

    public String name;

    public File(String name) {
    this.name = name;
    }

    /**
    * 操作方法
    * @return
    */
    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }

    public abstract void watch();


    }
    public class Folder extends File{

    private List<File> mFileList;
    public Folder(String name) {
    super(name);
    mFileList = new ArrayList<>();
    }

    @Override
    public void watch() {
    StringBuilder sb = new StringBuilder();
    for(File f:mFileList){
    sb.append(f.name);
    }
    System.out.println("文件名"+getName()+"文件数目"+ mFileList.size()+"名字"+sb.toString());
    }

    public void add(File file) {
    mFileList.add(file);
    }

    public void remove(File file) {
    mFileList.remove(file);
    }

    public File getChild(int pos) {
    return mFileList.get(pos);
    }
    }
    public class TestFile extends File {
    public TestFile(String name) {
    super(name);
    }

    @Override
    public void watch() {
    System.out.println("文件名"+getName()+"文件数目");
    }
    }
    //运行
    TestFile file = new TestFile("hehe");
    Folder folder = new Folder("heere");
    folder.add(file);
    folder.watch();
    folder.getChild(0).watch();

    安全组合模式分工就很明确了。它还有一个好处就是当我们add/remove的时候,我们能知道具体的类是什么了,而透明组合模式就得在运行时去判断,比较麻烦。

    优点:

    1. 高层模块调用简单
    2. 节点自由增加

    缺点:

    1. 在使用组合模式时,其叶子和树枝的声明都是实现类,而不是接口,违反了依赖倒置原则。
    2. 叶子类型不能控制。比如我想控制ViewGroup添加的View必须为TextView的时候,约束起来就很麻烦。特别是类型多的时候。
    收起阅读 »

    java 设计模式:外观设计模式

    1、概念外观设计模式的主要目的在于让外部减少与子系统内部多个模块的交互,从而让外部能够更简单的使用子系统。他负责把客户端的请求转发给子系统内部的各个模块进行处理。2、使用场景当你要为一个复杂子系统提供一个简单接口时客户程序与抽象类的实现部分之间存在很大的依赖性...
    继续阅读 »

    1、概念

    外观设计模式的主要目的在于让外部减少与子系统内部多个模块的交互,从而让外部能够更简单的使用子系统。他负责把客户端的请求转发给子系统内部的各个模块进行处理。

    2、使用场景

    1. 当你要为一个复杂子系统提供一个简单接口时
    2. 客户程序与抽象类的实现部分之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦,从而提高子系统的独立性和可移植性。
    3. 当你需要构建一个层次结构的子系统时; 在层次化结构中,可以使用外观模式定义系统中每一层的入口,层与层之间不直接产生联系,而通过外观类建立联系,降低层之间的耦合度。

    3、UML结构图分析

    4、实际代码分析


    /**
    * 模块A
    */
    public class SubSystemA {

    public void testFunA(){
    System.out.println("testFunA");
    }

    }
    /**
    * 模块B
    */
    public class SubSystemB {
    public void testFunB(){
    System.out.println("testFunB");
    }
    }
    /**
    * 模块C
    */
    public class SubSystemC {
    public void testFunC(){
    System.out.println("testFunC");
    }
    }
    /**
    * Facade
    */
    public class Facade {

    private SubSystemA subSystemA;
    private SubSystemB subSystemB;
    private SubSystemC subSystemC;
    private Facade(){
    subSystemA = new SubSystemA();
    subSystemB = new SubSystemB();
    subSystemC = new SubSystemC();
    }

    private static Facade instance;

    public static Facade getInstance(){
    if(instance==null){
    instance = new Facade();
    }
    return instance;
    }

    public void tastOperation(){
    subSystemA.testFunA();
    subSystemB.testFunB();
    subSystemC.testFunC();
    }
    }

    //运行
    Facade.getInstance().tastOperation();

    由于外观类维持了对多个子系统类的引用,外观对象在系统运行时将占用较多的系统资源,因此需要对外观对象的数量进行限制,避免系统资源的浪费。可以结合单例模式对外观类进行改进,将外观类设计为一个单例类。通过对外观模式单例化,可以确保系统中只有唯一一个访问子系统的入口,降低系统资源的消耗。

    我在项目中的实践:

    在项目中经常会出现,网络请求,缓存本地,本地有缓存用本地缓存,而且网络请求经常会在多个地方调用,如果不采用外观模式设计,则会出现客户端的代码异常复杂,而且不利于维护。于是我就进行了如下改变,建立中间仓库类来进行数据切换,客户端只需要进行对仓库数据进行调用,不用关心仓库里数据怎样生成的。

    /**
    * 建立仓库接口类
    * TestApiDataSource
    */
    public interface TestApiDataSource {


    /**
    * 登陆接口
    * @param params
    * @return
    */
    Observable<GetLoginResponse> getLogin(GetLoginParams params);
    }
    /**
    * 建立本地数据源(主要是为了方便客户端调用)
    * TestApiLocalDataSource
    */
    public class TestApiLocalDataSource extends BaseLocalDataSource implements TestApiDataSource {


    @Override
    public Observable<GetLoginResponse> getLogin(GetLoginParams params) {

    Observable<GetLoginResponse> observable = Observable.create(new ObservableOnSubscribe<GetLoginResponse>() {
    @Override
    public void subscribe(ObservableEmitter<GetLoginResponse> subscriber) throws Exception {
    subscriber.onComplete();

    }
    });
    return observable;
    }

    }

    /**
    * 建立网络数据源
    * TestApiRemoteDataSource
    */
    public class TestApiRemoteDataSource extends BaseRemoteDataSource implements TestApiDataSource {

    /**
    *
    * 请求网络
    * @param params
    * @return
    */
    @Override
    public Observable<GetLoginResponse> getLogin(GetLoginParams params) {
    return ApiSource.getApiService(AppHuanJingFactory.getAppModel().getApi()).getApi2Service().getLogin(params);
    }

    }

    /**
    * 建立单例仓库类
    * TestApiRepository
    */
    public class TestApiRepository extends BaseRepository<TestApiLocalDataSource,TestApiRemoteDataSource> implements TestApiDataSource {

    public static volatile TestApiRepository instance;


    public static TestApiRepository getInstance(){
    if(instance==null){
    synchronized (TestApiRepository.class){
    if(instance==null){
    instance = new TestApiRepository(new TestApiLocalDataSource(),new TestApiRemoteDataSource());
    }
    }
    }
    return instance;
    }

    protected TestApiRepository(TestApiLocalDataSource localDataSource, TestApiRemoteDataSource remoteDataSource) {
    super(localDataSource, remoteDataSource);
    }


    /**
    * 数据源切换
    * #getLogin#
    * @param params
    * @return
    */
    @Override
    public Observable<GetLoginResponse> getLogin(GetLoginParams params) {
    Observable<GetLoginResponse> observable = Observable.
    concat(localDataSource.getLogin(params),
    remoteDataSource.getLogin(params).
    doOnNext(new Consumer<GetLoginResponse>() {
    @Override
    public void accept(GetLoginResponse response) throws Exception {
    /**
    * cache
    */
    }
    })).compose(RxTransformerHelper.<GetLoginResponse>ioToUI()).firstOrError().toObservable();
    return observable;
    }


    }
    //客户端执行,不需要考虑具体实现
    TestApiRepository.getInstance().getLogin(new GetLoginParams()).subscribe(new BaseRxNetworkResponseObserver<GetLoginResponse>() {
    @Override
    public void onResponse(GetLoginResponse getLoginResponse) {

    }

    @Override
    public void onResponseFail(Exception e) {

    }

    @Override
    protected void onBeforeResponseOperation() {

    }

    @Override
    public void onSubscribe(Disposable d) {
    add(d);
    }
    });


    优点:

    1. 由于Facade类封装了各个模块交互过程,如果今后内部模块调用关系发生了变化,只需要修改facade实现就可以了
    2. facade实现是可以被多个客户端调用的
    3. 使得客户端和子系统之间解耦,让子系统内部的模块功能更容易扩展和维护;客户端根本不需要知道子系统内部的实现,或者根本不需要知道子系统内部的构成,它只需要跟Facade类交互即可。
    收起阅读 »

    java 设计模式:装饰者模式

    简单详解:1、概念动态地给一个对象添加一些额外的职责。就增加功能来说, 装饰模式相比生成子类更为灵活。该模式以对客户端透明的方式扩展对象的功能。2、使用场景在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责。和继承类似添加相应的职责。当不能采用生成...
    继续阅读 »

    简单详解:

    1、概念

    动态地给一个对象添加一些额外的职责。就增加功能来说, 装饰模式相比生成子类更为灵活。该模式以对客户端透明的方式扩展对象的功能。

    2、使用场景

    1. 在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责。和继承类似添加相应的职责。
    2. 当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支持每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏,或类定义不能用于生成子类。

    3、UML结构图分析

    • 抽象构件(Component)角色:给出一个抽象接口,已规范准备接收附加责任的对象。
    • 具体构件(ConcreteComponent)角色:定义一个将要接收附加责任的类
    • 装饰(Decorator)角色:持有一个构件(Component)对象的实例,并定义一个与抽象构件接口一致的接口。
    • 具体装饰(ConcreteDecorator)角色:负责给构件对象“贴上”附加的责任。

    4、实际代码分析

    /**
    * 装饰类Component,所有类的父类
    */
    public interface Component {

    void sampleOperation();
    }

    /**
    * 实现抽象部件,具体装饰过程还是交给子类实现
    */
    public class Decorator implements Component {

    private Component component;
    public Decorator(Component component){
    this.component = component;
    }

    @Override
    public void sampleOperation() {
    component.sampleOperation();
    }

    }

    /**
    * 需要装扮的类
    */
    public class ConcreteComponent implements Component{
    @Override
    public void sampleOperation() {

    }
    }

    /**
    * 具体实现
    */
    public class ConcreateDecoratorA extends Decorator{
    public ConcreateDecoratorA(Component component) {
    super(component);
    }

    @Override
    public void sampleOperation() {
    super.sampleOperation();
    addPingShengm();
    }

    /**
    * 新增业务方法
    */
    private void addPingShengm() {
    System.out.println("添加绘彩1");
    }
    }

    /**
    * 具体实现
    */
    public class ConcreateDecoratorB extends Decorator{
    public ConcreateDecoratorB(Component component) {
    super(component);
    }


    @Override
    public void sampleOperation() {
    super.sampleOperation();
    addPingShengm();
    }


    /**
    * 新增业务方法
    */
    private void addPingShengm() {
    System.out.println("添加绘彩2");
    }
    }

    举一个实际例子:

    工厂需要产生多种水杯,有瓶身绘彩,有不锈钢盖被子,也有不锈钢盖和瓶身绘彩的杯子。(等各种需求)

    假如说采用继承子类的方式。如下code:

    /**
    * 创建水杯的接口包含四个方法,底座,盖子,瓶身,一个实现功能product
    */
    public interface IShuiBei {

    void dizuo();

    void gaizi();

    void pingsheng();

    void product();

    }
    /**
    * 水晶杯实现类
    */
    public class ShuiJInBei implements IShuiBei,Component {
    @Override
    public void dizuo() {
    System.out.println("水晶底座");
    }

    @Override
    public void gaizi() {
    System.out.println("水晶盖子");
    }

    @Override
    public void pingsheng() {
    System.out.println("水晶瓶身");
    }

    @Override
    public void product() {
    dizuo();
    gaizi();
    pingsheng();
    }
    }

    /**
    * 添加绘彩的水晶杯
    */
    public class HuiCaiShuiJinBei extends ShuiJInBei{
    @Override
    public void pingsheng() {
    super.pingsheng();
    System.out.println("添加绘彩");
    }
    }
    /**
    * 不锈钢杯子盖的水晶杯
    */
    public class HuiJinGangGaiBei extends ShuiJInBei{
    @Override
    public void gaizi() {
    System.out.println("不锈钢杯盖");
    }
    }

    /**
    * 不锈钢杯子盖的水晶杯带彩绘
    */
    public class HuiCaiShuiJinGangGaiBei extends ShuiJInBei{
    @Override
    public void gaizi() {
    System.out.println("不锈钢杯盖");
    }
    @Override
    public void pingsheng() {
    super.pingsheng();
    System.out.println("添加绘彩");
    }
    }

    //运行
    HuiCaiShuiJinBei huiCaiShuiJinBei = new HuiCaiShuiJinBei();
    HuiCaiShuiJinGangGaiBei huiCaiShuiJinGangGaiBei = new HuiCaiShuiJinGangGaiBei();
    ShuiJInBei shuiJInBei = new ShuiJInBei();
    huiCaiShuiJinBei.product();
    huiCaiShuiJinGangGaiBei.product();
    shuiJInBei.product();

    一共创建三个子类,一个父类,当然如果需求更多的话,子类会不断的增加。

    装饰类实现如上功能code:

    /**
    * 实现抽象部件
    */
    public class ShuijinbeiDecorator implements IShuiBei{
    IShuiBei iShuiBei;
    public ShuijinbeiDecorator(IShuiBei iShuiBei){
    this.iShuiBei = iShuiBei;
    }

    @Override
    public void dizuo() {
    iShuiBei.dizuo();
    }

    @Override
    public void gaizi() {
    iShuiBei.gaizi();
    }

    @Override
    public void pingsheng() {
    iShuiBei.pingsheng();
    }

    @Override
    public void product() {
    dizuo();
    gaizi();
    pingsheng();
    }
    }
    /**
    * 钢盖实现类
    */
    public class GangGaiDecorator extends ShuijinbeiDecorator{
    public GangGaiDecorator(IShuiBei iShuiBei) {
    super(iShuiBei);
    }

    @Override
    public void gaizi() {
    System.out.println("不锈钢杯盖");
    }
    }

    /**
    * 彩绘实现类
    */
    public class CaihuiDecorator extends ShuijinbeiDecorator{
    public CaihuiDecorator(IShuiBei iShuiBei) {
    super(iShuiBei);
    }

    @Override
    public void pingsheng() {
    super.pingsheng();
    System.out.println("添加绘彩");
    }
    }
    //运行
    IShuiBei iShuiBei = new ShuiJInBei();
    iShuiBei.product();
    iShuiBei = new CaihuiDecorator(iShuiBei);
    iShuiBei.product();
    iShuiBei = new GangGaiDecorator(iShuiBei);
    iShuiBei.product();
    iShuiBei = new ShuiJInBei();
    iShuiBei = new GangGaiDecorator(iShuiBei);
    iShuiBei.product();

    看到如上代码你大概会恍然大悟,装饰模式如果在你的子类特别多,用装饰模式很好,但是比较容易出错哦。

    装饰模式的优点

    1. 装饰模式与继承关系的目的都是要拓展对象的功能,但是装饰模式可以提供比继承更多的灵活性。
    2. 装饰模式允许系统动态决定“贴上”一个需要的“装饰”,或者“除掉”一个不需要的“装饰”。继承关系则不同,继承关系是静态的,它在系统运行前就决定了。
    3. 可以对一个对象进行多次装饰,通过使用不同的具体装饰类以及这些装饰类的排列组合。

    装饰模式的缺点

    由于使用装饰模式,可以比使用继承关系需要较少数目的类。使用较少的类,当然使设计比较易于进行。但是,在另外一方面,使用装饰模式会产生比使用继承关系所产生的更多的对象。而更多的对象会使得查找错误更为困难,特别是这些对象在看上去极为相似的时候。

    装饰模式在Android中的实际应用

    context类簇

    收起阅读 »

    java 设计模式:适配器模式

    adapter定义:将一个接口转换成客户希望的另一个接口,适配器模式使接口不兼容的那些类可以一起工作,其别名为包装器(Wrapper)。类适配器定义:是把适配的类的api转化成为目标类的api。adapter是为了让adaptee与Target发生关系建立的a...
    继续阅读 »

    adapter定义:

    将一个接口转换成客户希望的另一个接口,适配器模式使接口不兼容的那些类可以一起工作,其别名为包装器(Wrapper)。

    类适配器

    定义:

    是把适配的类的api转化成为目标类的api。

    adapter是为了让adaptee与Target发生关系建立的

    adapter 实现Target接口,来继承Adaptee,实现需要实现的方法

    代码:

    //适配接口
    public interface Target {
    void request();
    }

    //需要适配的对象
    public class Adaptee {

    public void SpecialRequest(){
    System.out.println("SpecialRequest");
    }
    }
    //适配器
    public class Adapter extends Adaptee implements Target {

    @Override
    public void request() {
    specialRequest();
    }
    }

    //运行代码
    Target target = new Adapter();
    target.request();
    • 类适配器是继承的方式,方法通过静态定义的
    • 对于类适配器,可以重新定义Adaptee的部分行为。
    • 对于类适配器,仅仅引入一个对象,并不需要额外的引用来间接得到Adaptee。
    • 对于类适配器,由于适配器直接继承adaptee,使得适配器不能和adaptee的子类一起工作。

    对象适配器模式

    定义:与类的适配器模式一样,对象的适配器模式把被适配的类的api转化为目标类的api,与类的适配器模式不同的是,对象的适配器模式不是使用继承关系连接到Adaptee类,而是通过委派关系连接到adaptee类。

    //适配接口
    public interface Target {
    void request();
    }

    //需要适配的对象
    public class Adaptee {

    public void SpecialRequest(){
    System.out.println("SpecialRequest");
    }
    }
    //适配器
    public class Adapter implements Target {

    Adaptee adaptee;

    public Adapter(Adaptee adaptee){
    this.adaptee = adaptee;
    }

    @Override
    public void request() {
    adaptee.specialRequest();
    }
    }

    //运行代码
    Target target = new Adapter(new Adaptee());
    target.request();

    如上两个对比,就能看出类适配器和对象适配器的区别。

    对象适配器:持有一个对象来实现适配器模式

    类适配器:通过继承来实现适配器模式。

    • 对象适配器使用对象组合的方式,是动态组合的方式
    • 对象适配器,一个适配器可以把多种不同的源适配器适配到同一个目标
    • 对于对象适配器,要重定义adapee的行为比较困难
    • 对象适配器需要额外的引用来间接得到adapter

    adaper在Android中的运用

    listview

    收起阅读 »

    java 设计模式:建造者模式

    概念:建造者模式是较为复杂的创建型模式,将组件和组件的组件过程分开,然后一步一步建造一个复杂的对象。所以建造者模式又叫生成器模式。它允许用户在不知道内部构建细节的情况下,非常精细地控制对象构建流程。该模式是为了将构建过程非常复杂的对象进行拆分,让它与它的部件解...
    继续阅读 »

    概念:

    建造者模式是较为复杂的创建型模式,将组件和组件的组件过程分开,然后一步一步建造一个复杂的对象。所以建造者模式又叫生成器模式。它允许用户在不知道内部构建细节的情况下,非常精细地控制对象构建流程。该模式是为了将构建过程非常复杂的对象进行拆分,让它与它的部件解耦,提升代码的可读性以及扩展性。

    使用场景:

    构造一个对象需要很多参数的时候,并且参数的个数或者类型不固定的时候

    UML结构图

    例:

    //创建复杂对象Product
    public class Product {

    private String partA;
    private String partB;
    private String partC;

    public String getPartA() {
    return partA;
    }

    public void setPartA(String partA) {
    this.partA = partA;
    }

    public String getPartB() {
    return partB;
    }

    public void setPartB(String partB) {
    this.partB = partB;
    }

    public String getPartC() {
    return partC;
    }

    public void setPartC(String partC) {
    this.partC = partC;
    }
    }

    //创建抽象类Builder
    public abstract class Builder {

    protected Product product = new Product();

    public abstract void builderPartA();
    public abstract void builderPartB();
    public abstract void builderPartC();

    public Product getResult() {
    return product;
    }
    }

    //创建实现类ConcreateBuilder
    public class ConcreateBuilder extends Builder {
    @Override
    public void builderPartA() {

    }

    @Override
    public void builderPartB() {

    }

    @Override
    public void builderPartC() {

    }
    }

    //创建组装对象Director
    public class Director {

    private Builder builder;

    public Director(Builder builder){
    this.builder = builder;
    }

    public void setBuilder(Builder builder) {
    this.builder = builder;
    }

    public Product constract(){
    builder.builderPartA();
    builder.builderPartB();
    builder.builderPartC();
    return builder.getResult();
    }
    }
    //运行
    Builder builder = new ConcreateBuilder();
    Director director = new Director(builder);
    Product product = director.constract();
    • Builder:他为创建一个创建Product对象的各个部件指定抽象接口
    • ConcreateBuilder:它实现了builder接口,实现各个部件的具体构造和装配方法。
    • Product:他是被构建的复杂对象,包好多个组成部件。
    • Director:指挥者又称为导演类,负责安排复杂对象的建造次序,指挥者与抽象建造者之间存在关联关系。

    优点:

    • 松散耦合:生成其模式可以用同一个构造算法构建出表现上完全不同的产品,实现产品构建和产品表现上的分离。
    • 很容易改变产品内部表示。
    • 更好的复用性:生成器模式很好的实现了构建算法和具体产品实现的分离。

    缺点:

    • 会产生多余的Builder对象,Director对象,消耗内存。
    • 对象构建过程暴露。

    builder模式在Android中的实际运用

    1.AlertDialog

    2.Glide/okhttp

    收起阅读 »