首页 文章 精选 留言 我的

精选列表

搜索[分区技术],共10000篇文章
优秀的个人博客,低调大师

HBase技术资料下载(持续更新)

标题 下载地址 HBase在车联网中的实践与应用 下载 HBase在爱奇艺的应用实践 下载 HBase2.0重新定义小对象实时存取 下载 HBase基本知识介绍及典型案例分析 下载 HBase Coprocessor 下载 在多租户环境中提高HBase可用性 下载 Quanta:Quora的HBase分层计数系统 下载 HBase中的事务 下载 HBase 高可用HA 下载 HBase In-Memory Compaction 下载 gohbase :HBase go客户端 下载 使用Apache Beam和HBase进行高效数据处理 下载 Democratizing HBase 下载 Apache Spark – Apache HBase Connector 下载 HBase在滴滴的实践 下载 HBase 多租户 下载 HBase 和 Phoenix 的使用 下载 时序及分析在hbase上的使用 下载

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

Android APP全面屏适配技术要点

全面屏的概念 为什么先要解释一下全面屏,因为这个词在现在来讲就是一个伪命题。全面屏字面意思就是手机的正面全部都是屏幕,100%的屏占比。但是现在推出所谓“全面屏”手机的厂商没有一个能达到全面的。 那么下面来说一下Android开发领域对全面屏的理解和定义吧。 一般手机的屏幕纵横比为16:9,如1080x1920、1440x2560等,其比值为1.77,在全面屏手机出现之前,Android中默认的最大屏幕纵横比(maximum aspect ratio)为1.86,即能够兼容16:9的屏幕。 一些手机厂商为了追求更大的屏幕空间以及更极致的用户体验,于是提高了屏幕纵横比,17:9、19:10、18:9、18.5:9的手机开始进入市场,这些手机的屏幕纵横比大大超过了1.86,这些手机被称为全面屏手机。 为何需要适配 我们将targetSdkVersion的值改为小于等于23,运行程序,我们会发现屏幕底部出现一个黑条。 image 如何适配 targetSdkVersion<=23,更大的屏幕纵横比 在Galaxy S8发布之后,Android官方提供了适配方案,即提高App所支持的最大屏幕纵横比,实现很简单,在AndroidManifest.xml中可做如下配置: <meta-data android:name="android.max_aspect" android:value="ratio_float"/> 其中ratio_float为浮点数,官方建议为2.1或更大,因为18.5:9=2.055555555……,如果日后出现纵横比更大的手机,此值将会更大。 <meta-data android:name="android.max_aspect" android:value="2.1" /> max_aspect值也可以在Java代码中动态地设置,通过下面的方法即可实现: public void setMaxAspect() { ApplicationInfo applicationInfo = null; try { applicationInfo = getPackageManager().getApplicationInfo(getPackageName(), PackageManager.GET_META_DATA); } catch (PackageManager.NameNotFoundException e) { e.printStackTrace(); } if(applicationInfo == null){ throw new IllegalArgumentException(" get application info = null "); } applicationInfo.metaData.putString("android.max_aspect", "2.1"); } 如果targetSdkVersion的值的值大于23,那么应该不用设置max_aspect即可。 查看适配之后的截图: image https://android-developers.googleblog.com/2017/03/update-your-app-to-take-advantage-of.html 图片资源适配 我们看一下启动页,在16:9屏幕中适配的图片,到了18:9的屏幕中就会被拉伸了。 16:9屏幕中显示 18:9屏幕中显示 image image 解决这个问题无非就是两种方法,换图片或者是换布局 换图片 不能依赖单一厂商的解决方案,只能从Android系统属性出发。考虑到目前大部分全面屏手机只是在高度上拉长,且大多为6.0英寸左右,像素密度对比xxhdpi并没有多大区别,那我们可以在项目中增加一组资源drawable-xxhdpi-2160x1080 、drawable-long 这样解决图片的拉伸问题,当然这样的方法肯定是不太好的,会增加app的容量。这里就不演示了。 优化布局 当然最好的方法还是用相对布局采用XML的方式,或者.9图的解决方案。 我总结的就是少量多切,尽量减少尺寸对布局的影响。比如这里,使用正方形的切图,让他居中显示,无论屏幕纵横比如何,都不会拉伸这个图片,拉伸的只是背景而已。 image <ImageView android:layout_width="fill_parent" android:layout_height="fill_parent" android:scaleType="fitCenter" android:src="@drawable/bz002"/> 适配前 适配后 image image 全面屏高度问题适配 首先解释一下window,decorview,rootview这几个概念 image Window官方文档:Window public abstract class Window. Abstract base class for a top-level window look and behavior policy. An instance of this class should be used as the top-level view added to the window manager. It provides standard UI policies such as a background, title area, default key processing, etc. The only existing implementation of this abstract class is android.view.PhoneWindow, which you should instantiate when needing a Window. 翻译一下:每一个 Activity 都持有一个 Window 对象,但是 Window 是一个抽象类,这里 Android 为 Window 提供了唯一的实现类 PhoneWindow。也就是说 Activity 中的 window 实例就是一个 PhoneWindow 对象。 但是 PhoneWindow 终究是 Window,它并不具备多少 View 相关的能力。不过 PhoneWindow 中持有一个 Android 中非常重要的一个 View 对象 DecorView. 现在的关系就很明确了,每一个 Activity 持有一个 PhoneWindow 的对象,而一个 PhoneWindow 对象持有一个 DecorView 的实例,所以 Activity 中 View 相关的操作其实大都是通过 DecorView 来完成。 DecorView就可以理解为手机的内屏,就是那块玻璃,可以发光的屏幕。 这里通过代码,打印出我们页面中的高度的各项数据 int decorviewHeight = decorView.getHeight(); int screenHeight = FullScreenManager.getScreenHeight(); int nativeBarHeight = FullScreenManager.getNativeBarHeight(); int contentViewHeight = rootView.getHeight(); int navigationBarHeight1 = FullScreenManager.getNavigationBarHeight(); Log.d("shijiacheng","======================================="); Log.d("shijiacheng","DecorView height: " + decorviewHeight + " px"); Log.d("shijiacheng","Screen height: " + screenHeight + " px"); Log.d("shijiacheng","NativeBar height: " + nativeBarHeight + " px"); Log.d("shijiacheng","ContentView height: " + contentViewHeight + " px"); Log.d("shijiacheng","NavigationBar height: " + navigationBarHeight + " px"); Log.d("shijiacheng","---------------------------------------"); 获取decorView的高度 final View decorView = getWindow().getDecorView(); int decorviewHeight = decorView.getHeight(); 获得屏幕高度 /** * 获得屏幕高度 * @return */ public static int getScreenHeight() { Resources resource = AppContext.getInstance().getResources(); DisplayMetrics displayMetrics = resource.getDisplayMetrics(); return displayMetrics.heightPixels; } 获取状态栏的高度 /** * 获取状态栏的高度 * * @return */ public static int getNativeBarHeight() { Resources resource = AppContext.getInstance().getResources(); int result = 0; int resourceId = resource.getIdentifier("status_bar_height", "dimen", "android"); if (resourceId > 0) { result = resource.getDimensionPixelSize(resourceId); } return result; } 获取contentView的高度 LinearLayout contentView = findViewById(R.id.root); int contentViewHeight = contentView.getHeight(); 获取NavigationBar的高度 public static int getNavigationBarHeight() { Resources resources = AppContext.getInstance().getResources(); int resourceId = resources.getIdentifier("navigation_bar_height","dimen", "android"); int height = resources.getDimensionPixelSize(resourceId); return height; } 为了更加直观的展示各个数据,这里我们使用布局的方式将各个数据展示出来,布局代码比较简单,这里就不展示了。 image 先展示一下正常的屏幕高度的各项数据 10-08 09:52:03.636 23818-23818/? D/shijiacheng: ========================= 10-08 09:52:03.637 23818-23818/? D/shijiacheng: DecorView height: 1280 px 10-08 09:52:03.637 23818-23818/? D/shijiacheng: Screen height: 1280 px 10-08 09:52:03.637 23818-23818/? D/shijiacheng: NativeBar height: 50 px 10-08 09:52:03.637 23818-23818/? D/shijiacheng: ContentView height: 1230 px 10-08 09:52:03.637 23818-23818/? D/shijiacheng: NavigationBar height: 96 px 10-08 09:52:03.637 23818-23818/? D/shijiacheng: ------------------------- image DecorView = Screen height = NativeBar height + ContentView height 看一下小米mix全面屏的情况 2018-10-08 09:54:15.640 /? D/shijiacheng: ========================= 2018-10-08 09:54:15.640 /? D/shijiacheng: DecorView height: 2160 px 2018-10-08 09:54:15.641 /? D/shijiacheng: RootView height: 2094 px 2018-10-08 09:54:15.641 /? D/shijiacheng: Screen height: 2030 px 2018-10-08 09:54:15.641 /? D/shijiacheng: NativeBar height: 66 px 2018-10-08 09:54:15.641 /? D/shijiacheng: ContentView height: 2094 px 2018-10-08 09:54:15.641 /? D/shijiacheng: NavigationBar height: 130 px 2018-10-08 09:54:15.641 /? D/shijiacheng: ------------------------- image 问题出现了,可以发现contentView的高度比screen屏幕的高度还要大,不禁要怀疑,我们的获取屏幕高度的方法在全面屏下计算错误了。 问题1:获取屏幕高度方法计算不准确 我们一直都是使用如下方法进行屏幕高度测量的: public static int getScreenHeight() { Resources resource = AppContext.getInstance().getResources(); DisplayMetrics displayMetrics = resource.getDisplayMetrics(); return displayMetrics.heightPixels; } 但是这个方法却是一个十分古老的方法,没有与时俱进,虽然说在普通屏幕上这种方法没有问题,但是在全面屏手机上来说,这种方法就不灵了。 下面我们就来研究一下获取屏幕尺寸的方法的演进。 获取屏幕宽高 获取屏幕的宽高是我们开发中经常遇到的问题,而且相信大家都已经非常熟悉,最常用的为以下两种: public static int getScreenHeight1(Activity activity) { return activity.getWindowManager().getDefaultDisplay().getHeight(); } public static int getScreenHeight2(Activity activity) { DisplayMetrics displayMetrics = new DisplayMetrics(); activity.getWindowManager().getDefaultDisplay().getMetrics(displayMetrics); return displayMetrics.heightPixels; } 其实以上两种方式是一样的,只不过第二种是把信息封装到 DesplayMetrics中,再从DesplayMetrics得到数据。 在 Android 3.2(Api 13) 之后又提供了如下的一个方法,将数据封装到Point中,然后返回宽度高度信息。 @TargetApi(Build.VERSION_CODES.HONEYCOMB_MR2) public static int getScreenHeight3(Activity activity) { Point point = new Point(); activity.getWindowManager().getDefaultDisplay().getSize(point); return point.y; } 在 Android 4.2(Api17) 之后提供了如下方法,与第三种类似也是将数据封装到Point中,然后返回款高度信息。 @TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1) public static int getScreenHeight4(Activity activity) { Point realSize = new Point(); activity.getWindowManager().getDefaultDisplay().getRealSize(realSize); return realSize.y; } 其实getRealSize这个方法在Android Api15的时候就已经加入了,不过是被隐藏了,通过查阅源码我们可以看到。 image Android Api15 Display.java源码中getRealSize()方法被标记为@hide image 因此,我们可以重写获取高度的方法,适配所有机型,所有系统。 适配所有屏幕的获取屏幕尺寸的方法 public static int[] getScreenSize(Context context) { int[] size = new int[2]; WindowManager w = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE); Display d = w.getDefaultDisplay(); DisplayMetrics metrics = new DisplayMetrics(); d.getMetrics(metrics); // since SDK_INT = 1; int widthPixels = metrics.widthPixels; int heightPixels = metrics.heightPixels; // includes window decorations (statusbar bar/menu bar) if (Build.VERSION.SDK_INT >= 14 && Build.VERSION.SDK_INT < 17) try { widthPixels = (Integer) Display.class.getMethod("getRawWidth").invoke(d); heightPixels = (Integer) Display.class.getMethod("getRawHeight").invoke(d); } catch (Exception ignored) { } // includes window decorations (statusbar bar/menu bar) if (Build.VERSION.SDK_INT >= 17) try { Point realSize = new Point(); Display.class.getMethod("getRealSize", Point.class).invoke(d, realSize); widthPixels = realSize.x; heightPixels = realSize.y; } catch (Exception ignored) { } size[0] = widthPixels; size[1] = heightPixels; return size; } 使用新的获取高度的方法,重新运行程序,运行结果已经正常显示了。 2018-10-08 13:19:32.389 /? D/shijiacheng: ========================== 2018-10-08 13:19:32.390 /? D/shijiacheng: DecorView height: 2160 px 2018-10-08 13:19:32.390 /? D/shijiacheng: Screen height: 2160 px 2018-10-08 13:19:32.390 /? D/shijiacheng: NativeBar height: 66 px 2018-10-08 13:19:32.390 /? D/shijiacheng: ContentView height: 2094 px 2018-10-08 13:19:32.390 /? D/shijiacheng: NavigationBar height: 130 px 2018-10-08 13:19:32.390 /? D/shijiacheng: -------------------------- image 问题2:小米mix切为经典导航键模式下的计算问题 我们在MIUI设置中将全面屏导航样式修改为“经典导航键”样式。 image 重新运行程序,运行结果如下: image 可以发现又出问题了,DecorView = Screen height > NativeBar height + ContentView height 这里不难发现,Screen height将底部虚拟导航栏的高度也算进里面了。 很多情况下,我们都用如下方法获取导航栏的高度: public static int getNavigationBarHeight() { Resources resources = AppContext.getInstance().getResources(); int resourceId = resources.getIdentifier("navigation_bar_height", "dimen", "android"); int height = resources.getDimensionPixelSize(resourceId); return height; } 这种方法得到的导航栏的高度数值是没问题的,但是在全面屏的手机上,即使隐藏了导航栏,也是可以获取到导航栏的高度的。通过上面的logcat日志可以看到,即使没有导航栏,导航栏的高度的计算也是有值的。 适配小米mix虚拟导航栏 小米mix的机型中,我们可以“force_fsg_nav_bar”来判断小米手机是否开启了全面屏手势。 public static int getHeightOfNavigationBar(Context context) { //如果小米手机开启了全面屏手势隐藏了导航栏则返回 0 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1) { if (Settings.Global.getInt(context.getContentResolver(), "force_fsg_nav_bar", 0) != 0) { return 0; } } int realHeight = getScreenSize(context)[1]; Display d = ((WindowManager) context.getSystemService(Context.WINDOW_SERVICE)) .getDefaultDisplay(); DisplayMetrics displayMetrics = new DisplayMetrics(); d.getMetrics(displayMetrics); int displayHeight = displayMetrics.heightPixels; return realHeight - displayHeight; } 因此可以通过这个方法来判断是否显示了底部导航栏,并且可以计算导航栏的高度。 int navigationBarHeight = FullScreenManager.getHeightOfNavigationBar(MainActivity.this); if (navigationBarHeight > 0){ container_navigationview.setVisibility(View.VISIBLE); }else { container_navigationview.setVisibility(View.GONE); } 正常的显示效果如下: 有虚拟导航栏 没有虚拟导航栏 image image 没有虚拟导航栏Log 2018-10-08 13:19:32.389 /? D/shijiacheng: ========================== 2018-10-08 13:19:32.390 /? D/shijiacheng: DecorView height: 2160 px 2018-10-08 13:19:32.390 /? D/shijiacheng: Screen height: 2160 px 2018-10-08 13:19:32.390 /? D/shijiacheng: NativeBar height: 66 px 2018-10-08 13:19:32.390 /? D/shijiacheng: ContentView height: 2094 px 2018-10-08 13:19:32.390 /? D/shijiacheng: NavigationBar height: 0 px 2018-10-08 13:19:32.390 /? D/shijiacheng: -------------------------- 有虚拟导航栏Log 2018-10-08 13:38:03.229 /? D/shijiacheng: ========================== 2018-10-08 13:38:03.230 /? D/shijiacheng: DecorView height: 2160 px 2018-10-08 13:38:03.230 /? D/shijiacheng: Screen height: 2160 px 2018-10-08 13:38:03.230 /? D/shijiacheng: NativeBar height: 66 px 2018-10-08 13:38:03.230 /? D/shijiacheng: ContentView height: 1964 px 2018-10-08 13:38:03.230 /? D/shijiacheng: NavigationBar height: 130 px 2018-10-08 13:38:03.230 /? D/shijiacheng: --------------------------

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

华为快应用引擎技术架构详解

2018 年 3 月华为与小米,Oppo,Vivo 等 9 家手机厂商,联合发布快应用联盟标准。快应用是一种基于手机硬件平台的新型应用形态,无需安装,即点即用,又兼具原生应用体验(性能、系统整合、交互等)。同时,快应用在诞生之初就在开发规范、能力接入、开发者服务等层面实现了手机厂商间的标准化统一,极大地降低开发者的适配成本。 与传统应用相比,快应用具备如下特点: Instant:即点即用,用户无需等待 Everywhere:与手机的使用场景深度整合,入口无处不在(搜索,智能助手,智能推荐,应用市场,浏览器 ……) Efficient:准前端的开发方式,效率高 华为快应用引擎架构简介 上图是快应用的总体框架示意图。最上面是应用形态以及场景入口,中间是快应用引擎,底下是 OS(操作系统) 的基础设施及其硬件。从执行路径层面,有标准的 HTML5 方式支撑通用的 Web 场景(一般通过系统的 Webview 组件或定制的 Webview), 以及 JS(JavaScript)+Native 的方式,支撑更轻量、更快速的体验。 下面将按 3 个层面方面简要介绍快应用引擎的架构。 应用开发(前端框架 + 组件 & API 能力) 快应用的前端设计借鉴并整合了主流前端框架(Vue,React 等)的设计思路:以组件化的方式构建应用,以数据绑定为核心的 MVVM 设计模式,以 V-DOM 的方式提升性能,同时选择了简洁清晰的类 Vue 的模板。同时对布局方面做了相应精简。从新的应用形态、映射原生 UI、能力开放的角度,需要定义一套组件与 API 规范,方便开发这快速开发应用。 系统整合(应用管理,卡片 - 嵌入式 SDK,安全机制等等) 快应用作为完整的应用形态,可以与系统深入整合,如同原生应用一样运行,以及和系统交互。快应用目前有两种形态:全屏方式的独立应用形态与嵌入方式的卡片形态。在独立应用的形态下,给用户的体验就像原生的应用程序,有完整的生命周期管理,页面管理,路由等。快应用可以寄生于安卓的 Activity,页面寄生于 Fragment,并通过独立的后台 Service 进行实例的管控。卡片则是另外一种形态,通过嵌入式 SDK 作为一个独立的局部控件嵌入到系统的各个角落,轻量化的展现动态内容。在安全隔离方面,可通过沙盒机制,进程隔离,权限控制,并结合操作系统层的支持做到较好的安全保障。 性能体验 & 新兴场景 (JavaScript 引擎,渲染引擎,端 - 云 - 芯加速,新兴场景) 在交互体验、资源开销和稳定性等方面,快应用通过引入原生渲染路径,进而实现前端开发方式 + 原生渲染与平台能力有效组合。 不同于其它的应用层的跨平台框架,快应用植根于手机系统,可实现从芯片<-->操作系统<-->云的深度整合。端和云的结合以启动性能加速为例,通过云和端的协同渲染,网络链路层的优化可以大大加速快应用启动速度。同时可以整合硬件平台的特有能力,进一步提升体验。例如可以结合华为手机 AI 芯片,将 NPU 的算力整合到快应用引擎中来,使得 AI 场景(人脸识别、图像超分等)在端侧可以低延时、高性能的执行,同时又有效保护了用户的隐私,并节省带宽。 下面以启动加速作为案例,分享一下体验优化方面做的一些工作。 秒开的用户体验是快应用的核心竞争力之一。Google 的统计表明,页面打开时间超过 3 秒用户会流失 13%,超过 6 秒用户会流失 60%。反过来,打开时间每减少 1 秒可提升 27% 的转化率。目前快应用从用户点击到首页内容完全展示基本需要 2 秒左右甚至更久。 启动流程: 1)首次启动时,用户点击触发快应用包的下载,同时做引擎初始化相关工作。当整包下载与校验完成后,需要展示的第一个页面的 JavaScript 文件才会被加载并开始渲染。这个过程中包下载是瓶颈,从实测数据看,正常网络下 200K 左右的包下载时间至少要 400 毫秒以上,2M 包要 2 秒以上。 2)页面渲染包括 JavaScript 加载、页面与 JavaScript 框架逻辑的执行、布局的运算,最终到原生 UI 控件的绘制。其中,页面内逻辑执行时会有一次或多次的到应用自己的三方服务器的网络请求,请求返还的数据驱动页面的再次渲染,直至首屏内容完全展示。 这里网络请求、JavaScript 执行、排版与绘制并非简单的串行关系,而是并行化地交织在一起影响着整个页面的渲染性能,并与页面设计的逻辑、网络状况与设备运行的状态强相关。 启动性能的优化涉及到的内容较多,这里主要介绍两种优化方案: 流式加载 -- 解决网络延时问题 快应用首次启动需要从云端下载快应用的程序包(RPK),整包下载完成才能进行解压与校验,之后加载并执行相应的 JavaScript 文件。排除服务器端响应速度与网络状况的影响,下载延时与文件包大小成正比。我们引入了端云协同的流式加载方式以减少包延时。 流式加载: 流式加载是将启动所需要的资源在网络流中优先传输,这部分资源传输完后并进行解压与校验,首页的渲染就可以立即执行了。网络流的后续传输仍在持续进行直至下载过程全部完成。首次渲染所需资源往往很小,所以流式加载能明显降低下载延时,包越大效果越明显。流式加载需要解决如下问题: 1)如何决定哪些内容要优先下载? 正常情况下启动所需资源比较固定(公共资源、全局的配置文件、首页 JavaScript 文件与图片等等),这些在应用打包的时候排在文件的前部即可;当首次打开是某个非首页时,我们就需要在传输时将该页面所需资源排列到网络流前部。 2)访问到了某个未下载的资源怎么办? 网络状况是不可控的,存在一定的概率出现延时较高的情况。如果此时从首次打开的 A 页面跳转的 B 页面而 B 页面所需的资源尚未下载完成,则需要在页面跳转的过程进行等待,并向服务发起优先调度 B 页面资源。等 B 页面资源下载完成后,继续页面跳转的过程。 3)签名问题如何解决? 原始的签名方式是对整包进行签名,待整个包下载完成后才能执行校验,这是无法满足流式加载的需求的。为此我们引入了二级校验的方式:对包的不同片段单独生成 hash 值,将所有的 Hash 值拼接成一个 Hash 文件,对该 Hash 文件进行签名。下载时 Hash 文件被优先传输,传输完先校验 Hash 文件的合法性。之后流式加载过程中,无论哪个片段下载完成后,可以立即计算 Hash 值,并与 Hash 文件中相应的 Hash 值进行比对,校验合法性。 快照 -- 解决首屏渲染问题 首页的渲染也是一个比较耗时的过程,要经过 JavaScript 加载、页面与 JavaScript 框架逻辑的执行、布局的运算,最终到原生 UI 控件的绘制。这里我们引入一种快照机制,来加速渲染过程。 快照: 首先,在云端对所需要的页面进行预渲染处理,生成一种渲染的中间格式 -- 快照。它不需要 JavaScript 的运算,解析后可以直接快速地进行页面数据请求、UI 的排版与绘制。快照格式压缩后也非常小,50K 左右的 JavaScript 文件生成快照的大约 3K。 由于快照文件非常小,可以作为快应用的元数据的一部分分发到对应的快应用启动入口。例如应用市场,用户在应用市场搜索到快应用时,快照已经随着快应用的名字,包下载链接等信息一起加载完成。 当快应用首次加载启动时,包的下载地址与快照文件一起传给快应用引擎。引擎在请求下载快应用包的同时,加载解析快照,渲染出首屏。当包下载完成后, 标准的渲染流程在快照的基础上继续执行。 优化效果展示 以“快看漫画”为例,通过这些优化,目前评测下来应用的冷启动时间降低将近一半(从~2 秒到~1 秒),后续会逐步上线并扩展更多场景。 总结 即点即用是应用和服务的趋势。快应用作为一种新型的应用形态,通过结合动态化前端框架,原生渲染能力,以及操作系统和芯片级整合,达到较好的用户体验。当然体验优化,场景扩展永无止境,我们会持续努力,不断探索优化来支撑更好的体验。 2. 如何快速开发一个快应用 华为快应用 IDE 是由华为推出一款针对快应用的集成开发环境,基于快应用厂商联盟标准,提供了快应用开发、构建、调试、测试、发布等能力。 快应用开发流程: 环境准备 准备一台手机、一台 PC(Windows、苹果都可以) 安装快应用 IDE:http://developer.huawei.com/consumer/cn/service/hms/catalog/fastapp.html?page=fastapp_fastapp_devprepare_install_tool 安装完成以后,支持启动 IDE 会看到如下界面: 可以看到,这是典型的 IDE 结构,之后就开始开发一个快应用。 开发一个影评的快应用 新建一个快应用工程,我们使用最基础的 HelloWorld 模板,点击菜单“文件 ->新建项目”,输入项目项目信息即可完成创建。 项目创建完成后,可以看到 IDE 的主要功能布局。这是一个典型的常见 IDE 布局结构:菜单栏、控制栏、资源管理区、代码编辑区、预览区、控制台区,这些都是开发者比较常见的,都很容易上手使用。 开始具体的编码了。这里设计了一个简单的影评应用业务逻辑:应用的首页是电影的列表,点击进去以后,可以查看到相应影评。首先是首页电影列表的开发,我们直接将模板中的 hello.ux 为影评首页,然后新增一个影评的详细子页面,命名为 detail.ux。将所需的图片资源放在 Common 目录下。影评文本写在 ux 源码文件里。这些动作可以通过在资源管理区使用右键中完成。 接下来配置页面与路径,参考标准规范,在工程的 manifest.json 文件的 router 和 display,添加 detail 页面,把 Hello,改成“影评”,同时添加“详情”。 到这里,整个应用的结构已经完成了,下面就是具体的编码了。首页需要展现电影列表,我们这里使用 List[] 数组,使用快应用的 list 组件循环显示影评的图片 $item.image 和标题 $item.title。goDetail() 函数在点击时跳转到影评详情页 detail.ux。这里有惊喜,IDE 的编码辅助上提供了很不错的支持,基于快应用标准,代码的联想、补齐、语法检测与修改意见、定义与引用跳转,都很好的支持了,省去了不少标准语法 check 的工作。 完成影评列表的首页开发,下面就是具体影评的详细页面了。detail.ux 作为详情页,这里使用简单 text 组件显示文本,当前也可以做更多的样式,可以添加图片或电影视频片段等等。我们这里直接写几个影评信息,就完成了详情页的开发了。 接下来就是看运行效果了,点击“预览”控制按钮,在预览区域就能看到运行效果了,可以一边写代码,一边看到实时的运行效果,这个功能很实用,也解决了之前被开发者抱怨没有预览,不便于开发的问题。 编码已经基本完成了,下面试一下调试功能,快应用 IDE 的调试功能提供了 Source 断点调试、Element 元素审查、NetWork 网络抓包、Log 分析等特性。点击调试按钮(快捷键 F5),启动调试进程,如下图,也是典型的 DevTools 方式,比较常用,这里尝试了断点调试与 Inspect。 直接在控制栏,点击“调试”按钮,进入调试。 点击控制栏的“Inspect”,推送的手机运行,会在桌面弹出运行框,这个时候也是可以拔出手机继续使用的。 到这里我们影评快应用的开发已经完成了,继续看 IDE 其他特性。在控制栏有一个测试按钮。点击测试按钮,在登录成功后,在弹出的面板里,点击”按钮”就可以一键生成自动化测试任务。大概 10 分钟左右,测试就完成,还可以查看详细的测试报告。从测试报告可以看出,快应用的测试是在云端进行的,覆盖了主流的机型与安卓版本,测试项也很丰富,每一个测试页面都覆盖到了,可以在报告中看到详细的步骤。这样解决了没有手机覆盖兼容性、测试工作投入大的难题,很实用。 最后发布快应用,可以直接进入这个地址:https://www.quickapp.cn/ 即可在厂商联盟官网上发布这个快应用,绑定完各厂商的开发者帐号后,发布一次即可在所有的联盟的手机厂商上上架使用了。 作者简介 华为快应用团队,负责快应用引擎,快应用 IDE 及云端快应用存储仓库的建设和研发工作,同时为华为的快服务提供基础能力支撑,在整个华为产品生态下全场景的为用户带来即点即用的服务提供支持。 原文发布时间:2018-6-20 原文作者: mp.weixin.qq.com 本文来源掘金如需转载请紧急联系作者

资源下载

更多资源
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部分的功能。

用户登录
用户注册