首页 文章 精选 留言 我的

精选列表

搜索[开发者工具],共10000篇文章
优秀的个人博客,低调大师

全栈开发者Git使用指南

一、Git基础 1、Git简介 Git是一种分布式版本控制系统,由Linux之父Linus开发。 所谓分布式版本管理系统,就是在每一台机器上都有一个完整的仓库。 2、Git官网 Git官网:git 在官网上可以获取Git的安装软件。 除此之外,还可以下载《progit》——这是最棒的Git学习资料,而且有中文版本。 3、Git安装 从 https://git-scm.com/downloads官方下载地址下载对应的操作系统版本一步步安装即可。 4、Git基本配置 安装完成之后,在任意目录下,右键 Git Bash Here 全局配置邮箱和用户名(–global表示全局配置,也可以不配置,每个仓库单独配置) $ git config --global user.name "test" $ git config --global user.email test@qq.com 5、Git基本概念 5.1、Git工作区域 Git有四个工作区域: 工作区 简单说工作区就是我们项目的目录。 仓库区/本地仓库 工作区有一个.git目录,其实这个不是工作区,是Git的版本库,存储了Git仓库的所有版本信息 暂存区 暂存区域是一个文件,保存了下次将提交的文件列表信息,一般在 Git 仓库目录中。 有时候也被称作“索引”, 不过一般说法还是叫暂存区域。 远程仓库 对于分布式版本管理系统,远程仓库不是必须存在的,但是通常项目都会有远程仓库。例如Github就是我们非常熟悉的远程仓库。 基本的Git工作流程如下: 在工作目录修改文件 暂存文件,将文件快照放入暂存区 提交更新,找到暂存区的文件,将快照永久性存储到到 Git 仓库区(本地) 将本地仓库的变更推送到远程仓库 以上几个区域的关系可以用下图表示: 5.2、Git分支 分支是为了将修改记录的整个流程分开存储,让分开的分支不受其它分支的影响,所以在同一个数据库里可以同时进行多个不同的修改。 Git 为我们自动创建的第一个分支,也叫主分支,一般其它分支开发完成后都要合并到 master 5.3、Git文件状态 在git中,文件主要有四种状态: Untracked: 未跟踪, 此文件在文件夹中, 但并没有加入到git库, 不参与版本控制. 通过git add 状态变为Staged. Unmodify(Committed): 文件已经入库, 未修改, 即版本库中的文件快照内容与文件夹中完全一致. 这种类型的文件有两种去处, 如果它被修改, 而变为Modified. 如果使用git rm移出版本库, 则成为Untracked文件 Modified: 文件已修改, 仅仅是修改, 并没有进行其他的操作. 这个文件也有两个去处, 通过git add可进入暂存staged状态, 使用git checkout 则丢弃修改过, 返回到unmodify状态, 这个git checkout即从库中取出文件, 覆盖当前修改 Staged: 暂存状态. 执行git commit则将修改同步到库中, 这时库中的文件和本地文件又变为一致, 文件为Unmodify状态. 执行git reset HEAD filename取消暂存, 文件状态为Modified 二、Git应用实践 看完上面的Git基础,你可能有一些迷惑,接下来,我们以实际工作中开发的流程来加深对Git的理解吧。 1、克隆项目 可以通过在工作区使用git init来初始化一个Git仓库,但通常开发中我们不会这样做,因为实际的项目大部分已经进行了部分开发,并进行了版本管理,所以我们首先做的是从远程仓库克隆项目。 这里我从Gitee(一般开发项目的远程仓库是部署在内网的GitLab) fork了一个开源项目,将这个项目作为远程仓库的项目: 点击克隆下载,可以看到项目的路径, HTTPS是凭据式的路径,使用此路径,向远程仓库推送代码的时候需要凭据(账号密码); 这种方式向远程仓库提交,会要求账号密码,输入完成之后,Win10操作系统可以选择记住凭据,这样就不用每一次都输入了,Win10操作系统管理凭据 控制面板 → 用户帐户 → 凭据管理器 → Windows凭据 SSH是秘钥式的路径,向远程仓库推送代码的时候,需要本地的私钥和远程仓库的公钥对应。 SSH配置可以参考 Windows配置Github、Gitee共存的Git环境,这里就不详细展开讲解。 我已经进行了公私钥的配置,所以这里选择SSH。 使用git clone命令克隆项目 2、代码管理 项目已经成功克隆,接下来要进行我们的开发了。 2.1、创建分支 通常开发不是在Master分支上,而是在开发分支上,使用 git branch develop创建一个新分支: 可以通过git branch命令列出所有分支: 可以看到我们新建的分支。 2.2、切换分支 使用git checkout develop命令切换到新建的develop分支: 2.3、添加文件到暂存区 接下来,我们再develop分支上进行一些开发操作,我这里对 redeme 进行了一些修改,需要把修改添加到暂存区。 首先通过 git status命令查看工作区文件状态 接下来使用 git add README.md命令(可以使用git add .添加所有修改)将更改添加到暂存区 可以看到文件已经添加。 2.4、提交修改到仓库 接下来使用`git commit -m "

优秀的个人博客,低调大师

【开发者笔记】MQTT python测试笔记

MQTT是基于订阅/发布的物联网协议。 python测试需要一个发送进程和接收进程,即一个发送客户端和一个接收客户端,如果这两个客户端工作在同一个topic下,那么就能进行消息互通了。 服务器用“iot.eclipse.org”就好了,避免了自己搭建服务器,然后流程还可以跑通。 发送客户端代码: import paho.mqtt.client as mqtt import paho.mqtt.publish as publish idx = 0#往paho/temperature 一直发送内容 while True: print("send success") publish.single("paho/temperature", payload="this is message:%s"%idx, hostname="iot.eclipse.org", client_id="lora1", # qos = 0, # tls=tls, port=1883, protocol=mqtt.MQTTv311) idx += 1 接收客户端代码: import paho.mqtt.client as mqtt # The callback for when the client receives a CONNACK response from the server. def on_connect(client, userdata, flags, rc): print("Connected with result code "+str(rc)) # The callback for when a PUBLISH message is received from the server. def on_message(client, userdata, msg): #在这里处理业务逻辑 print(msg.topic+" "+str(msg.payload)) client = mqtt.Client() client.on_connect = on_connect client.on_message = on_message client.connect("iot.eclipse.org", 1883, 60)#订阅频道 client.subscribe("paho/temperature") # Blocking call that processes network traffic, dispatches callbacks and # handles reconnecting. # Other loop*() functions are available that give a threaded interface and a # manual interface. client.loop_forever() 然后运行两个客户端,就可以在接收端收到消息了。 MQTT服务器不负责存储数据,需要编写额外的接收客户端来接收数据、分析、入库等。 MQTT服务器用的是iot.eclipse.org,如果碰巧两个人在用同一个频道,那可能收到别人的消息哦~ 如果要搭建自己的MQTT服务器,那么回头再说。 玩一玩就好了,不要给服务器增加太多负担哟~ 参考资料: paho-qtt说明文档 黑夜给了我黑色的眼睛,我却用它寻找光明

优秀的个人博客,低调大师

Android开发者指南(4) —— Application Fundamentals(二)

线程安全方法(Thread-safe methods) 在一些情况下,你所实现的方法有可能会被多于一个的线程所调用,所以它们必须被写成线程安全的。 对于我们上一节所讨论的RPC机制中的可以被远程调用的方法来说,这是必须首先考虑的。如果针对一个IBinder对象中实现的方法的调用源自这个IBinder对象所在的进程时,这个方法将会在调用者的线程中执行。然而,如果这个调用源自其它的进程,则这个方法将会在一个线程池中选出的线程中运行,这个线程池由Android加以管理,并与IBinder存在于同一进程内;这个方法不会在进程的主线程内执行。反过来说,一个服务的onBind()方法应为服务进程的主线程所调用,而实现了由onBind()返回的对象(比如说,一个实现了RPC方法的Stub的子类)的方法将为池中的线程所调用。因为服务可以拥有多于一个的客户端,而同一时间,也会有多个池中的线程调用同一个IBinder方法。因此IBinder方法必须实现为线程安全的。 类似的,一个内容提供者能接受源自其它进程的请求数据。尽管ContentResolver和ContentProvider类隐藏了交互沟通过程的管理细节,ContentProvider会由query(),insert(),delete(),update()和getType()方法来相应这些请求,而这些方法也都是由那个内容提供者的进程中所包涵的线程池提供的,而不是进程的主线程本身。所以这些有可能在同一时间被很多线程调用的方法也必须被实现为线程安全的。 组件生命周期(Component Lifecycles) 应用程序组件有其生命周期──由Android初始化它们以相应intent直到这个实例被摧毁。在此之间,它们有时是激活的有时则相反。或者,如果它是一个activity,则是可为用户所见或者不能。这一节讨论了activity、服务以及广播接收器的生命周期,包括它们在生命周期中的状态、在状态之间转变时通知你的方法、以及当这些进程被关闭或实例被摧毁时,这些状态产生的效果。 Activity生命周期(Activity lifecycle) 一个activity主要有三个状态: *当在屏幕前台时(位于当前任务堆栈的顶部),它是活跃或运行的状态。它就是相应用户操作的activity。 *当它失去焦点但仍然对用户可见时,它处于暂停状态。即是:在它之上有另外一个activity。这个activity也许是透明的,或者未能完全遮蔽全屏,所以被暂停的activity仍对用户可见。暂停的activity仍然是存活状态(它保留着所有的状态和成员信息并连接至窗口管理器),但当系统处于极低内存的情况下,仍然可以杀死这个activity。 *如果它完全被另一个activity覆盖是,它处于停止状态。它仍然保留所有的状态和成员信息。然而它不在为用户可见,所以它的窗口将被隐藏,如果其它地方需要内存,则系统经常会杀死这个activity。 如果一个activity处于暂停或停止状态,系统可以通过要求它结束(调用它的finish()方法)或直接杀死它的进程来将它驱出内存。当它再次为用户可见的时候,它只能完全重新启动并恢复至以前的状态。 当一个activity从这个状态转变到另一个状态时,它被以下列protected方法所通知: void onCreate(Bundle savedInstanceState) void onStart() void onRestart() void onResume() void onPause() void onStop() void onDestroy() 你可以重载所有这些方法以在状态改变时进行合适的工作。所有的activity都必须实现onCreate()用以当对象第一次实例化时进行初始化设置。很多activity会实现onPause()以提交数据变化或准备停止与用户的交互。 调用父类(Calling into the superclass) 所有activity生命周期方法的实现都必须先调用其父类的版本。比如说: 总得来说,这七个方法定义了一个activity完整的生命周期。实现这些方法可以帮助你监察三个嵌套的生命周期循环: *一个activity完整的生命周期自第一次调用onCreate()开始,直至调用onDestroy()为止。activity在onCreate()中设置所有“全局”状态以完成初始化,而在onDestroy()中释放所有系统资源。比如说,如果activity有一个线程在后台运行以从网络上下载数据,它会以onCreate()创建那个线程,而以onDestroy()销毁那个线程。 *一个activity的可视生命周期自onStart()调用开始直到相应的onStop()调用。在此期间,用户可以在屏幕上看到此activity,尽管它也许并不是位于前台或者正在与用户做交互。在这两个方法中,你可以管控用来向用户显示这个activity的资源。比如说,你可以在onStart()中注册一个BroadcastReceiver来监控会影响到你UI的改变,而在onStop()中来取消注册,这时用户是无法看到你的程序显示的内容的。onStart()和onStop()方法可以随着应用程序是否为用户可见而被多次调用。 *一个activity的前台生命周期自onResume()调用起,至相应的onPause()调用为止。在此期间,activity位于前台最上面并与用户进行交互。activity会经常在暂停和恢复之间进行状态转换──比如说当设备转入休眠状态或有新的activity启动时,将调用onPause()方法。当activity获得结果或者接收到新的intent的时候会调用onResume()方法。因此,在这两个方法中的代码应当是轻量级的。 下图展示了上述循环过程以及activity在这个过程之中历经的状态改变。着色的椭圆是activity可以经历的主要状态。矩形框代表了当activity在状态间发生改变的时候,你进行操作所要实现的回调方法。 下表详细描述了这些方法,并在activity的整个生命周期中定位了它们。 方法 描述 是否可被杀死(Killable?) 下一个 onCreate() 在activity第一次被创建的时候调用。这里是你做所有初始化设置的地方──创建视图、绑定数据至列表等。如果曾经有状态记录(参阅后述Saving Activity State。),则调用此方法时会传入一个包含着此activity以前状态的包对象做为参数。 接下来始终遵循调用onStart()。 否 onStart() onRestart() 在activity停止后,在再次启动之前被调用。 接下来始终遵循调用onStart()。 否 onStart() onStart() 当activity正要变得为用户所见时被调用。 当activity转向前台时接下来调用onResume(),在activity变为隐藏时接下来调用onStop()。 否 onResume() 或 onStop() onResume() 在activity开始与用户进行交互之前被调用。此时activity位于堆栈顶部,并接受用户输入。 接下来始终遵循调用onPause()。 否 onPause() onPause() 当系统将要启动另一个activity时调用。此方法主要用来将未保存的变化进行持久化,停止类似动画这样耗费CPU的动作等。这一切动作应该在短时间内完成,因为下一个activity必须等到此方法返回后才会继续。 当activity重新回到前台时接下来调用onResume()。当activity变为用户不可见时接下来调用onStop()。 是 onResume() 或 onStop() onStop() 当activity不再为用户可见时调用此方法。这可能发生在它被销毁或者另一个activity(可能是现存的或者是新的)回到运行状态并覆盖了它。 如果activity再次回到前台跟用户交互则接下来调用onRestart(),如果关闭activity则接下来调用onDestroy()。 是 onRestart() or onDestroy() onDestroy() 在activity销毁前调用。这是activity接收的最后一个调用。这可能发生在activity结束(调用了它的finish()方法)或者因为系统需要空间所以临时的销毁了此acitivity的实例时。你可以用isFinishing()方法来区分这两种情况。 是 无 请注意上表中可被杀死一列。它标示了在方法返回后,还没执行activity的其余代码的任意时间里,系统是否可以杀死包含此activity的进程。三个方法(onPause()、onStop()和onDestroy())被标记为“是”。onPause()是三个中的第一个,它也是唯一一个在进程被杀死之前必然会调用的方法──onStop()和onDestroy()有可能不被执行。因此你应该用onPause()来将所有持久性数据(比如用户的编辑结果)写入存储之中。 在可被杀死一列中标记为“否”的方法在它们被调用时将保护activity所在的进程不会被杀死。所以只有在onPause()方法返回后到onResume()方法被调用时,一个activity才处于可被杀死的状态。在onPause()再次被调用并返回之前,它不会被系统杀死。 如后面一节进程和生命周期所述,即使是在这里技术上没有被定义为“可杀死”的activity仍然有可能被系统杀死──但这仅会发生在实在没有其它方法的极端情况之下。 保存activity状态(Saving activity state) 当系统而不是用户自己出于回收内存的考虑,关闭了一个activity之后。用户会期望当他再次回到那个activity的时候,它仍保持着上次离开时的样子。 为了获取activity被杀死前的状态,你应该为activity实现onSaveInstanceState()方法。Android在activity有可能被销毁之前(即onPause()调用之前)会调用此方法。它会将一个以名称-值对方式记录了activity动态状态的Bundle对象传递给该方法。当activity再次启动时,这个Bundle会传递给onCreate()方法和随着onStart()方法调用的onRestoreInstanceState(),所以它们两个都可以恢复捕获的状态。 与onPause()或先前讨论的其它方法不同,onSaveInstanceState()和onRestoreInstanceState()并不是生命周期方法。它们并不是总会被调用。比如说,Android会在activity易于被系统销毁之前调用onSaveInstanceState(),但用户动作(比如按下了BACK键)造成的销毁则不调用。在这种情况下,用户没打算再次回到这个activity,所以没有保存状态的必要。 因为onSaveInstanceState()不是总被调用,所以你应该只用它来为activity保存一些临时的状态,而不能用来保存持久性数据。而是应该用onPause()来达到这个目的。 服务生命周期(Coordinating activities) 服务以两种方式使用: *它可以启动并运行,直至有人停止了它或它自己停止。在这种方式下,它以调用Context.startService()启动,而以调用Context.stopService()结束。它可以调用Service.stopSelf()或Service.stopSelfResult()来自己停止。不论调用了多少次startService()方法,你只需要调用一次stopService()来停止服务。 *它可以通过自己定义并暴露出来的接口进行程序操作。客户端建立一个到服务对象的连接,并通过那个连接来调用服务。连接以调用Context.bindService()方法建立,以调用Context.unbindService()关闭。多个客户端可以绑定至同一个服务。如果服务此时还没有加载,bindService()会先加载它。 这两种模式并不是完全分离的。你可以绑定至一个用startService()启动的服务。比如说,一个后台音乐播放服务可以调用startService()并传递给它一个包含欲播放的音乐列表的Intent对象来启动。不久,当用户想要对播放器进行控制或者查看当前播放曲目的详情时,会启用一个activity,调用bindService()连接到服务来完成操作。在这种情况下,直到绑定连接关闭stopService()才会真正停止一个服务。 与activity一样,服务也有一系列你可以实现以用于监控其状态变化的生命周期方法。但相对于activity要少一些,只有三个,而且,它们是public属性,并非protected: void onCreate() void onStart(Intent intent) void onDestroy() 倚仗实现这些方法,你监控服务的两个嵌套的生命周期循环: *服务的完整生命周期始于调用onCreate()而终于onDestroy()方法返回。如同activity一样,服务在onCreate()里面进行它自己的初始化,而在onDestroy()里面释放所有资源。比如说,一个音乐回放服务可以在onCreate()中创建播放音乐的线程,而在onDestroy()中停止这个线程。 *服务的活跃生命周期始于调用onStart()。这个方法用于处理传递给startService()的Intent对象。音乐服务会打开Intent来探明将要播放哪首音乐,并开始播放。 服务停止时没有相应的回调方法──不存在onStop()方法。 onCreate()和onDestroy()方法在所有服务中都会被调用,无论它们是由Context.startService()还是由Context.bindService()所启动的。而onStart()仅会被startService()所启用的服务调用。 如果一个服务允许别的进程绑定,则它还会有以下额外的回调方法以供实现: IBinder onBind(Intent intent) boolean onUnbind(Intent intent) void onRebind(Intent intent) 传递给bindService的Intent的对象也会传递给onBind()回调方法,而传递给unbindService()的Intent对象同样传递给onUnbind()。如果服务允许绑定,onBind()将返回一个供客户端与服务进行交互的通讯渠道。如果有新的客户端连接至服务,则onUnbind()方法可以要求调用onRebind()。 下图描绘了服务的回调方法。尽管图中对由startService和startService方法启动的服务做了区分,但要记住,不论一个服务是怎么启动的,它都可能允许客户端的连接,所以任何服务都可以接受onBind()和onUnbind()调用。 广播接收器生命周期(Broadcast receiver lifecycle) 广播接收器只有一个回调方法: void onReceive(Context curContext, Intent broadcastMsg) 当广播消息抵达接收器时,Android调用它的onReceive()方法并将包含消息的Intent对象传递给它。广播接收器仅在它执行这个方法时处于活跃状态。当onReceive()返回后,它即为失活状态。 拥有一个活跃状态的广播接收器的进程被保护起来而不会被杀死。但仅拥有失活状态组件的进程则会在其它进程需要它所占有的内存的时候随时被杀掉。 这种方式引出了一个问题:如果响应一个广播信息需要很长的一段时间,我们一般会将其纳入一个衍生的线程中去完成,而不是在主线程内完成它,从而保证用户交互过程的流畅。如果onReceive()衍生了一个线程并且返回,则包涵新线程在内的整个进程都被会判为失活状态(除非进程内的其它应用程序组件仍处于活跃状态),于是它就有可能被杀掉。这个问题的解决方法是令onReceive()启动一个新服务,并用其完成任务,于是系统就会知道进程中仍然在处理着工作。 下一节中,我们会讨论更多进程易误杀的问题。 进程与生命周期(Processes and lifecycles) Android系统会尽可能长的延续一个应用程序进程,但在内存过低的时候,仍然会不可避免需要移除旧的进程。为决定保留或移除一个进程,Android将每个进程都放入一个“重要性层次”中,依据则是它其中运行着的组件及其状态。重要性最低的进程首先被消灭,然后是较低的,依此类推。重要性共分五层,依据重要性列表如下: 1.前台进程是用户操作所必须的。当满足如下任一条件时,进程被认为是处于前台的: *它运行着正在与用户交互的activity(Activity对象的onResume()方法已被调用)。 *一个正在与用户交互的activity使用着它提供的一个服务。 *它包含着一个正在执行生命周期回调方法(onCreate()、onStart()或onDestroy())的Service对象。 *它包含着一个正在执行onReceive()方法的BroadcastReceiver对象。 任一时间下,仅有少数进程会处于前台,仅当内存实在无法供给它们维持同时运行时才会被杀死。一般来说,在这种情况下,设备已然处于使用虚拟内存的状态,必须要杀死一些前台进程以用户界面保持响应。 2.可视进程没有前台组件,但仍可被用户在屏幕上所见。当满足如下任一条件时,进程被认为是可视的: *它包含着一个不在前台,但仍然为用户可见的activity(它的onPause()方法被调用)。这种情况可能出现在以下情况:比如说,前台activity是一个对话框,而之前的activity位于其下并可以看到。 *它包含了一个绑定至一个可视的activity的服务。 可视进程依然被视为是很重要的,非到不杀死它们便无法维持前台进程运行时,才会被杀死。 3.服务进程是由startService()方法启动的服务,它不会变成上述两类。尽管服务进程不会直接为用户所见,但它们一般都在做着用户所关心的事情(比如在后台播放mp3或者从网上下载东西)。所以系统会尽量维持它们的运行,除非系统内存不足以维持前台进程和可视进程的运行需要。 4.背景进程包含目前不为用户所见的activity(Activity对象的onStop()方法已被调用)。这些进程与用户体验没有直接的联系,可以在任意时间被杀死以回收内存供前台进程、可视进程以及服务进程使用。一般来说,会有很多背景进程运行,所以它们一般存放于一个LRU(最后使用)列表中以确保最后被用户使用的activity最后被杀死。如果一个activity正确的实现了生命周期方法,并捕获了正确的状态,则杀死它的进程对用户体验不会有任何不良影响。 5.空进程不包含任何活动应用程序组件。这种进程存在的唯一原因是做为缓存以改善组件再次于其中运行时的启动时间。系统经常会杀死这种进程以保持进程缓存和系统内核缓存之间的平衡。 Android会依据进程中当前活跃组件的重要程度来尽可能高的估量一个进程的级别。比如说,如果一个进程中同时有一个服务和一个可视的activity,则进程会被判定为可视进程,而不是服务进程。 此外,一个进程的级别可能会由于其它进程依赖于它而升高。一个为其它进程提供服务的进程级别永远高于使用它服务的进程。比如说,如果A进程中的内容提供者为进程B中的客户端提供服务,或进程A中的服务为进程B中的组件所绑定,则A进程最低也会被视为与进程B拥有同样的重要性。 为运行着一个服务的进程重要级别总高于一个背景activity。所以一个activity以启动一个服务的方式启动一个长时间运行过程比简单的衍生一个线程来进行处理要好。尤其是当处理过程比activity本身存在时间要长的情况之下。我们以背景音乐播放和上传一个相机拍摄的图片至网站上为例。使用服务则不论activity发生何事,都至少可以保证操作拥有“服务进程”的权限。如上一节广播接收器生命周期所提到的,这也正是广播接收器使用服务,而不是使用线程来处理耗时任务的原因。 本文转自over140 51CTO博客,原文链接:http://blog.51cto.com/over140/582308,如需转载请自行联系原作者

优秀的个人博客,低调大师

Android开发者指南(29) —— USB Host and Accessory

USB主从设备 Android支持各种USB外围设备,通过两种模式来支持Android USB外设(实现了Android外设协议的硬件):USB外设模式和USB主机模式。在USB外设模式下,外部USB硬件(装有Android的设备要连接的外部设备)充当USB主机。外设的例子包括机器人、扩展插座、诊断和音乐设备、电子报亭、读卡器等其他设备。这种模式给予不具备主机功能的Android设备以与USB硬件交互的能力。Android USB外设必须设计用来与装有Android的设备一起工作,并且必须遵循Android外设通讯协议。在USB主机模式下,装有Android的设备扮演着主机的角色。这种设备的例子包括数码像机,键盘,鼠标和游戏手柄。那些适应面很广的USB设备仍可以与Android应用交互,前提是这些Android应用可以正确的与这些设备通讯。 图1展示了两种模式的异同。当Android设备处于主机模式时,它扮演USB主机角色并为总线供电。当Android设备处于附件模式时,被连接的USB硬件(在这种情况下是一个Android USB附件)扮演主机角色并给总线供电。 图1. USB主从模式 USB外设和主机模式在Android 3.1 (API level 12)或更高的平台中直接支持。USB外设模式作为一个外设库也被回馈到Android 2.3.4 (API level 10)来支持更广泛的设备。设备厂商可以选择是否在设备的系统镜像中包含附加库。 注意:对USB主机和外设模式的支持最终取决于设备的硬件,不管平台的等级(是多少)。你可以通过<uses-feature>元素过滤那些支持USB主机和外设的设备。查看USB外设和主机文档获取更多详细信息。 调试注意事项 当调试那些使用了USB外设和主机特性的应用时,你很有可能把你的USB硬件连接到你的Android设备上,这将阻止你通过USB建立adb到Android设备的连接。你通过网络仍可以访问adb。通过网络连接adb: 通过USB将Android设备连接到电脑。 从SDK的platform-tools目录,在命令行输入adb tcpip 5555 输入:adb connect <设备的IP地址>:5555,你现在将被连接到Android设备并能像adb logcat一样发出通用的adb命令。 要设置你的设备监听USB,输入adb usb。 本文转自over140 51CTO博客,原文链接:http://blog.51cto.com/over140/716803,如需转载请自行联系原作者

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册