精华内容
下载资源
问答
  • 移动端app开发,原生开发与混合开发的区别

    万次阅读 多人点赞 2019-09-26 18:47:01
    目前市场上主流的APP分为三种:原生APP、Web APP(即HTML5)和混合APP三种,相...原生开发(Native App开发),是在Android、IOS等移动平台上利用提供的开发语言、开发类库、开发工具进行App软件开发。比如Android是...

    目前市场上主流的APP分为三种:原生APP、Web APP(即HTML5)和混合APP三种,相对应的定制开发就是原生开发、H5开发和混合开发。那么这三种开发模式究竟有何不同呢?下面我们就分别从这三者各自的优劣势来区分比较吧!
    一、APP原生开发
    原生开发(Native App开发),是在Android、IOS等移动平台上利用提供的开发语言、开发类库、开发工具进行App软件开发。比如Android是利用Java、Eclipse、Android studio;IOS是利用Objective-C 和Xcode进行开发。
    通俗点来讲,原生开发就像盖房子一样,先打地基然后浇地梁、房屋结构、一砖一瓦、钢筋水泥、电路走向等,都是经过精心的设计。原生APP也一样:通过代码从每个页面、每个功能、每个效果、每个逻辑、每个步骤全部用代码写出来,一层层,一段段全用代码写出来。
    优点:
    1、可访问手机所有功能(如GPS、摄像头等)、可实现功能齐全;
    2、运行速度快、性能高,绝佳的用户体验;
    3、支持大量图形和动画,不卡顿,反应快;
    4、兼容性高,每个代码都经过程序员精心设计,一般不会出现闪退的情况,还能防止病毒和漏洞的出现;
    5、比较快捷地使用设备端提供的接口,处理速度上有优势。
    缺点:
    1、开发时间长,快则3个月左右完成,慢则五个月左右;
    2、制作费用高昂,成本较高;
    3、可移植性比较差,一款原生的App,Android和IOS都要各自开发,同样的逻辑、界面要写两套;
    4、内容限制(App Store限制);
    5、获得新版本时需重新下载应用更新。
    二、Web APP (HTML5)开发
    HTML5应用开发,是利用Web技术进行的App开发。Web技术本身需要浏览器的支持才能进行展示和用户交互,因此主要用到的技术是HTML5、Javascript、CSS等。
    优点:
    1、支持设备范围广,可以跨平台,编写的代码可以同时在Android、IOS、Windows上运行;
    2、开发成本低、周期短;
    3、无内容限制;
    4、适合展示有大段文字(如新闻、攻略等),且格式比较丰富(如加粗,字体多样)的页面;
    5、用户可以直接使用新版本(自动更新,不需用户手动更新)。
    缺点:
    1、由于Web技术本身的限制,H5移动应用不能直接访问设备硬件和离线存储,所以在体验和性能上有很大的局限性;
    2、对联网要求高,离线不能做任何操作;
    3、功能有限;
    4、APP反应速度慢,页面切换流畅性较差;
    5、图片和动画支持性不高;
    6、用户体验感较差;
    7、无法调用手机硬件(摄像头、麦克风等)。
    三、混合APP开发(原生+H5)
    混合开发(Hybrid App开发),是指在开发一款App产品的时候,为了提高效率、节省成本而利用原生与H5的开发技术的混合应用。通俗点来说,这就是网页的模式,通常由“HTML5云网站+APP应用客户端”两部份构成。
    混合开发是一种取长补短的开发模式,原生代码部分利用Web View插件或者其它框架为H5提供容器,程序主要的业务实现、界面展示都是利用与H5相关的Web技术进行实现的。比如京东、淘宝、今日头条等APP都是利用混合开发模式而成的。
    优点:
    1、开发效率高,节约时间。同一套代码Android和IOS基本上都可使用;
    2、更新和部署比较方便,每次升级版本只需要在服务器端升级即可,不再需要上传到App Store进行审核;
    3、代码维护方便、版本更新快,节省产品成本;
    4、比web版实现功能多;
    5、可离线运行。
    缺点:
    1、功能/界面无法自定:所有内容都是固定的,不能换界面或增加功能;
    2、加载缓慢/网络要求高:混合APP数据需要全部从服务器调取,每个页面都需要重新下载,因此打开速度慢,网络占用高,缓冲时间长,容易让用户反感;
    3、安全性比较低:代码都是以前的老代码,不能很好地兼容新手机系统,且安全性较低,网络发展这么快,病毒这么多,如果不实时更新,定期检查,容易产生漏洞,造成直接经济损失;
    4、既懂原生开发又懂H5开发的高端人才难找。
    以上就是原生开发、H5开发和混合开发各自的优缺点。相比之下,由于现代人的个性化需求越来越明显,所以原生APP开发也越来越多,定制化的服务更能满足消费者的需求。若您也想要定制一款别开生面的APP,就来找我们吧!

    展开全文
  • 软件开发中原生开发与H5开发和混合开发的区别 目前市场上主流的APP分为三种:原生APP、Web APP(即HTML5)和混合APP三种,相对应的定 制开发就是原生开发、H5开发和混合开发。那么这三种开发模式究竟有何不同呢?...

    软件开发中原生开发与H5开发和混合开发的区别

    目前市场上主流的APP分为三种:原生APP、Web APP(即HTML5)和混合APP三种,相对应的定 制开发就是原生开发、H5开发和混合开发。那么这三种开发模式究竟有何不同呢?下面我们就分别从这三者各自的优劣势来区分比较吧!

    在这里插入图片描述

    一、原生开发

    原生开发(Native App开发),是在Android、IOS等移动平台上利用官方提供的开发语言、开发类库、开发工具进行App开发。比如Android是利用Java、Eclipse、Android studio;IOS是利用Objective-C 和Xcode进行开发。
    通俗点来讲,原生开发就像盖房子一样,先打地基然后浇地梁、房屋结构、一砖一瓦、钢筋水泥、电路走向等,都是经过精心的设计。原生APP也一样:通过代码从每个页面、每个功能、每个效果、每个逻辑、每个步骤全部用代码写出来,一层层,一段段全用代码写出来。

    优点:
    1、可访问手机所有功能(如GPS、摄像头等)、可实现功能最齐全;
    2、运行速度快、性能高,绝佳的用户体验;
    3、支持大量图形和动画,不卡顿,反应快;
    4、兼容性高,每个代码都经过程序员精心设计,一般不会出现闪退的情况,还能防止病毒和漏洞的出现;
    5、比较快捷地使用设备端提供的接口,处理速度上有优势。

    缺点:
    1、开发时间长,快则3个月左右完成,慢则五个月左右;
    2、制作费用高昂,成本较高;
    3、可移植性比较差,一款原生的App,Android和IOS都要各自开发,同样的逻辑、界面要写两套;
    4、内容限制(App Store限制);
    5、必须等下载完毕用户才可以打开,获得新版本时需重新下载应用更新。

    二、Web APP (HTML5)开发

    HTML5应用开发,是利用Web技术进行的App开发,可以在手机端浏览器里面打开的网站就称之为webapp。Web技术本身需要浏览器的支持才能进行展示和用户交互,因此主要用到的技术是HTML、CSS、Javascript以及jQuery、Vue、React等JS框架。

    优点:
    1、支持设备范围广,可以跨平台,编写的代码可以同时在Android、IOS、Windows上运行;
    2、开发成本低、周期短;
    3、无内容限制;
    4、适合展示有大段文字(如新闻、攻略等),且格式比较丰富(如加粗,字体多样)的页面;
    5、用户可以直接使用最新版本(自动更新,不需用户手动更新)。

    缺点:
    1、由于Web技术本身的限制,H5移动应用不能直接访问设备硬件和离线存储,所以在体验和性能上有很大的局限性;
    2、对联网要求高,离线不能做任何操作;
    3、功能有限;
    4、APP反应速度慢,页面切换流畅性较差;
    5、图片和动画支持性不高;
    6、用户体验感较差;
    7、无法调用手机硬件(摄像头、麦克风等)。

    三、混合(原生+H5)开发

    混合开发(Hybrid App开发),是指在开发一款App产品的时候,为了提高效率、节省成本而利用原生与H5的开发技术的混合应用。通俗点来说,这就是网页的模式,通常由“HTML5云网站+APP应用客户端”两部份构成。
    混合开发是一种取长补短的开发模式,原生代码部分利用WebView插件或者其它框架为H5提供容器,程序主要的业务实现、界面展示都是利用与H5相关的Web技术进行实现的。比如京东、淘宝、今日头条等APP都是利用混合开发模式而成的。

    优点:
    1、开发效率高,节约时间。同一套代码Android和IOS基本上都可使用;
    2、更新和部署比较方便,每次升级版本只需要在服务器端升级即可,不再需要上传到App Store进行审核;
    3、代码维护方便、版本更新快,节省产品成本;
    4、比web版实现功能多;
    5、可离线运行。

    缺点:
    1、功能/界面无法自定:所有内容都是固定的,不能换界面或增加功能;
    2、加载缓慢/网络要求高:混合APP数据需要全部从服务器调取,每个页面都需要重新下载,因此打开速度慢,网络占用高,缓冲时间长,容易让用户反感;
    3、安全性比较低:代码都是以前的老代码,不能很好地兼容最新手机系统,且安全性较低,网络发展这么快,病毒这么多,如果不实时更新,定期检查,容易产生漏洞,造成直接经济损失;
    4、既懂原生开发又懂H5开发的高端人才难找。

    目前混合开发有两种开发模式:

    一、原生主导的开发模式:需要安卓和IOS原生开发人员,整个App既有原生开发的页面,也有H5页面,在需要H5页面时由原生开发工程师实现内嵌,笔者最近正在开发的项目就使用这种开发模式。

    二、H5主导的开发模式:只需要H5开发工程师,借助一些封装好的工具实现应用的打包与调用原生设备的功能,如HBuilder的云端打包功能。
    如何辨别原生和H5:

    以最近正在开发的混合APP项目首页为例:

    在这里插入图片描述

    1、看断网的情况
    把手机的网络断掉。然后点开页面。然后可以正常显示的东西就是原生写的。
    显示404或者错误页面的是html页面。

    在这里插入图片描述

    2、看布局边界
    可以打开 开发者选项中的显示布局边界,页面元素很多的情况下布局是一整块的是h5的,布局密密麻麻的是原生控件。页面有布局的是原生的否则为h5页面。(仅针对安卓手机试用)

    3、看复制文章的提示,需要你通过对比才能得出结果。
    比如是文章资讯页面可以长按页面试试,如果出现文字选择、粘贴功能的是H5页面,否则是native原生的页面。有些原生APP开放了复制粘贴功能或者关闭了。而H5的css屏蔽了复制选择功能等等情况。需要通过对目标测试APP进行对比才可知。

    4、看加载的方式
    如果在打开新页面导航栏下面有一条加载的线的话,这个页面就是H5页面,如果没有就是原生的。 微信里面打开我们的H5页面常见的有个绿色的加载线条。

    在这里插入图片描述

    5、看app顶部 导航栏是否会有关闭的操作
    如果APP顶部导航栏当中出现了关闭按钮或者有关闭的图标,那么当前的页面肯定的H5,原生的不会出现(除非设计开发者故意弄的)美团的、大众点评的APP、微信APP当加载h5过多的时候,左上角会出现关闭二字。

    6、判断页面 下拉刷新的时候(前提是要有下拉刷新的功能)
    如果界面没有明显刷新现象的是原生的,如果有明显刷新现象(比如闪一下)的是H5页面(ios和android)。
    比如淘宝的众筹页面。

    7、下拉页面的时候显示网址提供方的一定是H5。

    展开全文
  • 原生开发环境初探

    千次阅读 2019-12-12 19:38:33
    在上一篇“云原生的不同解释及正确含义”里,我们讲到了云原生的引申含义,就是开发环境也是云环境,这样就能保证开发环境和生产环境的一致性,使最终的部署顺利进行。本文就通过具体的例子来探讨云原生开发环境。...

    在上一篇“云原生的不同解释及正确含义”里,我们讲到了云原生的引申含义,就是开发环境也是云环境,这样就能保证开发环境和生产环境的一致性,使最终的部署顺利进行。本文就通过具体的例子来探讨云原生的开发环境。开发流程主要包括编写代码,程序部署和调试几个环节。每一个环节都需要相应的工具来帮助你提高效率。下面我们就来看一下如何搭建开发的云环境以及那些工具能帮你在云环境里提高开发效率。

    开发IDE

    以前的IDE只支持应用程序的开发,但云原生需要同时进行开发环境(容器)的开发,理想的情况是一个IDE能同时支持两者。我用的是Go语言,选择的IDE是Goland(也就是IDEA IntelliJ),它本身是支持k8s的,你只要下载一个插件就行。它支持k8s的自动完成(Auto-complete)等功能。如下图所示,这样你就拥有了同时支持应用程序和k8s的IDE。

    file

    但我不得不说它对k8s的支持很初级,它不能理解k8s对象之间的内在联系。另外,k8s配置文件对格式要求很严,如果空格不对,或格式没有对齐,在部署时会报错。Goland有检查格式的功能,出了问题会报错,但并不是每个错误它都能发现。也就是说当它没有报错时也不能肯定格式就是对的。这已经发生好几次了,IDE没有报错,但部署时有问题。

    关于IntelliJ对k8s的支持功能,请参见IntelliJ IDEA 2018.1: Kubernetes support

    环境搭建

    调式k8s是在Minikube上进行的,而Minikube是安装在Linux虚机上的。这就需要开发环境的宿主机和虚机之间能够共享文件,这样才能方便调试。我的开发环境是Windows,然后在Windows上装了VirtualBox虚拟机,另外还安装了Vagrant(它是管理虚拟机的一个软件)作为界面来管理VirtualBox。

    程序共享

    我的Go应用程序是在Windows上的“C:codesrcgithub.comjfeng45k8sdemo”目录下,通过Vagrant可以把宿主机的目录挂载到虚机上,这样每次在IDE上修改了k8s的配置文件,在虚机上可以直接取到,不需要另外同步。

    在Vagrant中的配置是这样的:

    config.vm.synced_folder "C:/code/src/github.com/jfeng45", "/home/vagrant/jfeng45", id: "jfeng45"

    网络共享

    就是实现宿主机(笔记本)和虚机之间的互相访问,主要是从宿主机访问虚机。我用的是Vagrant, 因此要在Vagran的配置文件(Vagrantfile)里进行配置。网络的配置有不同方式,我配置的是私有网络,这是一种很灵活的方式。它的配置方法是给宿主机和虚机各自设定一个固定的IP地址,这样可以双向互访。

    Vagrant的配置命令:

    “config.vm.network “private_network”, ip: "192.168.50.4”

    数据库共享

    在配置k8s时,一般会把数据库设置成一个服务。如果能在宿主机上访问k8s数据库,就能提前测试数据库,尽早发现数据库的问题。一旦把虚机和宿主机之间的网络联通了,是可以从宿主机直接访问数据库。

    有关环境配置的详情,详情请参阅“通过搭建MySQL掌握k8s(Kubernetes)重要概念(上):网络与持久卷”.

    开发流程

    开发流程通常是这样的。你先在本地的IDE上编写代码(包括应用程序和k8s代码),代码是存储在本地硬盘上的。完成之后,你进入虚机环境,部署k8s集群和应用程序代码,再在k8s集群上运行代码,测试结果。如此反复循环。

    流程示例

    我们通过一个例子来讲解流程。在本地编写完代码之后,就要调试k8s程序。先用Vagrant启动虚机,然后启动Minikube:

    sudo minikube start

    程序结构

    file

    上面是程序的目录结构。“cmd”目录里是主程序,“config”目录是负责程序配置的,“dataservice”是数据访问层,“model”是域模型层,“logs”目录是存储日志的。“script”包含了所有与程序部署相关的文件。其中“database”里面是数据库脚本,“kubernetes”是k8s的所有配置文件,一回儿还会详细讲解。

    file

    上面就是k8s的配置文件目录结构,最外面有两个文件“k8sdemo-config.yaml”和"k8sdemo-secret.yaml"是共享文件,因此放在最外层。里面主要有两个子目录“backend”和“database”分别存后端程序和数据库的配置文件。内部的结构是类似的,都有三个“yaml”文件,“backend-deployment.yaml”是部署配置文件, "backend-service.yaml"是服务配置文件, "backend-volume.yaml"是持久卷配置文件. ".sh"是k8s命令,用来创建k8s对象。“backend”目录还多了一个“docker”子目录用来存储backend应用的Docker镜像,database的镜像文件是直接从Docker的库中取得,因此不需要另外生成镜像文件。

    关于k8s的核心概念,请参阅“通过实例快速掌握k8s(Kubernetes)核心概念”.

    部署和调试应用程序及k8s

    我们的程序有两个服务“k8sdemo-database-service”和“k8sdemo-backend-service”,先要部署“k8sdemo-database-service”,因为它不依赖于其它服务。不过还有些对象是共享的需要先进行调试。有一点需要注意的是由于k8s对象之间是有依赖关系的,在你创建时是需要按照顺序来创建。顺序的部署次序是这样的Secret->ConfigMap->Volume->Deployment->Service。

    部署共享对象:

    cd /home/vagrant/jfeng45/k8sdemo/script/kubernetes
    kubectl apply -f k8sdemo-config.yaml
    kubectl apply -f k8sdemo-secret.yaml

    检查创建情况:

    kubectl describe configMap
    kubectl describe secret

    部署数据库服务:

    cd /home/vagrant/jfeng45/k8sdemo/script/kubernetes/database
    kubectl apply -f database-volume.yaml
    kubectl apply -f database-deployment.yaml
    kubectl apply -f database-service.yaml
    

    数据库创建好了之后,可以在IDE中用程序直接访问虚拟机上的库,这样比较方便。但你需要设置环境变量。在k8s中是由configMap设置的,在Windows里需要单独设置,命令在“windowsEnv.bat”里面。内容如下:

    setx MYSQL_ROOT_PASSWORD root
    setx MYSQL_USER_NAME dbuser
    setx MYSQL_USER_PASSWORD dbuser
    setx MYSQL_DATABASE service_config
    setx MYSQL_HOST 192.168.50.4
    setx MYSQL_PORT 30306

    创建应用程序镜像:

    cd /home/vagrant/jfeng45/k8sdemo/
    docker build -f ./script/kubernetes/backend/docker/Dockerfile-k8sdemo-backend -t k8sdemo-backend .

    部署后端服务

    cd /home/vagrant/jfeng45/k8sdemo/script/kubernetes/backend
    kubectl apply -f backend-volume.yaml
    kubectl apply -f backend-deployment.yaml
    kubectl apply -f backend-service.yaml

    登录容器,并运行程序,查看结果:

    vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/kubernetes/backend$ kubectl exec -ti k8sdemo-backend-deployment-57bcd56f7d-26p5k -- /bin/sh
    ~ # ./main.exe
    time="2019-12-10T06:23:45Z" level=debug msg="connect to database "
    time="2019-12-10T06:23:45Z" level=debug msg="dataSourceName:dbuser:dbuser@tcp(k8sdemo-database-service:3306)/service_config?charset=utf8"
    time="2019-12-10T06:23:45Z" level=debug msg="FindAll()"
    time="2019-12-10T06:23:45Z" level=debug msg="created=2019-10-21"
    time="2019-12-10T06:23:45Z" level=debug msg="find user:{1 Tony IT 2019-10-21}"
    time="2019-12-10T06:23:45Z" level=debug msg="find user list:[{1 Tony IT 2019-10-21}]"
    time="2019-12-10T06:23:45Z" level=debug msg="user lst:[{1 Tony IT 2019-10-21}]"

    上面步骤中的k8s部分并不是每次修改应用程序之后都要运行,通常只需要运行有改动的部分。一般来讲只是部署(Deployment)会有改动,因为程序的Docker镜像变了。即使这样要完成一次调试也有不少步骤。

    有关k8s的核心概念,详情请参阅“通过实例快速掌握k8s(Kubernetes)核心概念”.

    综述:

    从上面的流程可以看出,在本地云环境上进行开发和调试还是比较繁琐的,你需要在宿主机和虚拟机之间进行切换,还要同时对应用程序和k8s进行调试,中间有很多手工操作,要敲入很多命令,怎样才能简化它呢?

    Helm

    k8s的一个痛点就是它有很多组成部分(部署,服务,存储卷等),每个部分都要分别敲入命令进行调试,特别是当出现问题时,你需要反复删除原来的并创建新的。Helm解决了它的这个痛点。Helm是最流行的k8s包管理工具,就像Java中的Maven和Go里面的“Go Module”。它的一个核心概念是“Chart”。有了它之后,你可以把k8s的各个部分作为一个整体来管理,这样就大大减少了工作量。在调试初期,你还是可以对各部分进行单独调试,这样减少复杂度。但一旦成功之后,你就可以把它当成一个整体来操作,这样大大简化了操作。Helm的另一个作用就是对K8s配置的版本进行管理。

    Helm文件结构

    chart里一个很重要的概念就是模板(template),也就是Go语言模板。模板就是里面加入了编程逻辑的k8s文件。这些模板文件在使用时都要先进行模板解析,把其中的程序逻辑转化成对应的编码,最终生成k8s配置文件。

    file

    以上就是Helm自动生成的chart目录结构,在Helm里每个项目叫一个chart,它由下面几个组成部分:

    • "Chart.yaml":存有这个chart的基本信息,
    • "values.yaml":定义模板中要用到的常量。
    • “template”目录:里面存有全部的模板文件,其中最重要的是“deployment.yaml”和“service.yaml”,分别是部署和服务文件. "helpers.tpl"用来定义变量,"ingress.yaml"和"serviceaccount.yaml"分别是对外接口和服务账户,这里暂时没用, “NOTES.txt”是注释文件。
    • “charts”目录: 存有这个chart依赖的所有子chart。

    Chart设计

    现在我们就用一个例子来展示Helm的chart设计。这个例子是一个微服务应用程序,它共有三层: 前端,后端和数据库。

    在k8s中,每一层就是一个单独的服务,它里面有各种配置文件。Helm的优势是把这些不同的服务组成一个Chart来共同管理和调式,方便了许多。键入如下命令创建chart,其中“k8sdemo”是chart的名字,这个名字很重要,服务的名字和label都是由它产生的。

    helm create k8sdemo

    这之后,系统会自动创建前面讲到的chart目录结构。然后就是对已经生成的文件进行修改。

    file

    上面就是最终的chart目录结构图。“chart”是总目录,里面有三个子目录“k8sdemo”,“k8sdemo-backend”,“k8sdemo-database”, 每一个对应一个服务,每个服务都是一个独立的chart,能单独调式部署,chart之间也可以有依赖关系。其中“k8sdemo”是父chart,同时也是前端服务,它的“charts”目录里有它依赖的另外两个服务。“k8sdemo-backend”是后端服务,“k8sdemo-database”是数据库服务。

    安装k8sdemo:

    vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/kubernetes/chart$ helm upgrade k8sdemo ./k8sdemo
    Release "k8sdemo" has been upgraded. Happy Helming!
    NAME: k8sdemo
    LAST DEPLOYED: Fri Nov 29 01:28:55 2019
    NAMESPACE: default
    STATUS: deployed
    REVISION: 2
    NOTES:
    1. Get the application URL by running these commands:
      export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services k8sdemo)
      export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}")
      echo http://$NODE_IP:$NODE_PORT

    获取Pod名称:

    vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/kubernetes/chart$ kubectl get pod
    NAME                                          READY   STATUS    RESTARTS   AGE
    k8sdemo-74cb7b997c-pgcj4                      1/1     Running   0          33s
    k8sdemo-backend-5cd9d79856-dqlmz              1/1     Running   0          33s
    k8sdemo-database-85855485c6-jtksb             1/1     Running   0          33s
    k8sdemo-jenkins-deployment-675dd574cb-r57sb   1/1     Running   3          23d

    运行程序进行测试:

    vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/kubernetes/chart$ kubectl exec -ti k8sdemo-backend-5cd9d79856-dqlmz -- /bin/sh
    ~ # ./main.exe
    time="2019-11-27T07:03:03Z" level=debug msg="connect to database "
    time="2019-11-27T07:03:03Z" level=debug msg="dataSourceName:dbuser:dbuser@tcp(k8sdemo-database-service:3306)/service_config?charset=utf8"
    time="2019-11-27T07:03:03Z" level=debug msg="FindAll()"
    time="2019-11-27T07:03:03Z" level=debug msg="created=2019-10-21"
    time="2019-11-27T07:03:03Z" level=debug msg="find user:{1 Tony IT 2019-10-21}"
    time="2019-11-27T07:03:03Z" level=debug msg="find user list:[{1 Tony IT 2019-10-21}]"
    time="2019-11-27T07:03:03Z" level=debug msg="user lst:[{1 Tony IT 2019-10-21}]"
    ~ #

    由上面可以看出,使用了Helm之后,大大简化了k8s的部署和调试过程。只需一步就能完成所有k8s对象的部署。

    详情请参见用Helm3构建多层微服务

    自动调试工具

    Helm解决了k8s的部署问题,但你修改程序之后,还是要更新Docker镜像,才能部署,部署之后还要测试,比对结果,这里面还是有很多手工操作,有没有工具能自动完成这些工作?确实有这样的工具,而且还有不少,它们的功能也不尽相同。这里面有一类工具是相对来说比较有用的,那就是自动化整个部署、调试流程的。它们的功能和流程一般是这样的。

    它会自动检测程序修改,一旦发现就自动生成Docker镜像,然后调用k8s部署文件把新的镜像文件部署到k8s集群上,再调用测试程序进行测试,并在控制台显示结果。整个过程不需要你敲入一行命令,全部自动执行。这样完全消除了手工操作,使整个流程自动执行。你可能会说你并不想每修改一行程序就进行一下测试,而是当你需要的时候再去测试。这个功能在某些工具里也是可以配置的,你可以配置一个触发器,只有当它触发之后才自动完成上述操作。

    Skaffold配置文件:

    我们现在就用一个例子来具体说明,使用的工具是Skaffold。Skaffold的主要部分是一个配置文件,叫“skaffold.yaml”, 存放在项目的根目录。里面有Skaffold需要的信息,如Docker镜像的文件名,k8s的部署文件等。

    apiVersion: skaffold/v1
    kind: Config
    metadata:
      name: k-sdemo
    build:
      artifacts:
      - image: k8sdemo-backend
        context: .
        docker:
          dockerfile: script/kubernetes/backend/docker/Dockerfile-k8sdemo-backend
    deploy:
      kubectl:
        manifests:
        - script/kubernetes/backend/backend-deployment.yaml
        - script/kubernetes/backend/backend-service.yaml
    

    上面就是这个文件,它看起来很像k8s的配置文件,它的类型是“Config”。里面有两个主要部分,一个是:“build”,负责生成项目的Docker镜像的,另一个是“deploy”,负责把生成的镜像部署到k8s上。

    Skaffold可以帮你自动生成基础配置文件。你可以敲入“skaffold init”,它会问你一些问题,并根据你的回答,自动生成“skaffold.yaml”文件。生成之后,你可以根据需要进行修改。这里面比较重要的就是引用了镜像文件和k8s部署文件。如果你以前已经创建了这些文件,那么你可以复用它们。

    运行Skaffold:

    生成“skaffold.yaml”文件之后,键入如下命令“skaffold dev”,系统会运行“skaffold.yaml”,部署k8s,并开始监控程序的修改。输出如下:

    vagrant@ubuntu-xenial:~/jfeng45/k8sdemo$ skaffold dev
    WARN[0000] Could not get minikube docker env, falling back to local docker daemon: getting minikube env: Running [minikube docker-env --shell none]: stdout , stderr: *
    Listing files to watch...
    - k8sdemo-backend
    Generating tags...
    - k8sdemo-backend -> k8sdemo-backend:05894ca-dirty
    Checking cache...
    - k8sdemo-backend: Not found. Building
    Found [minikube] context, using local docker daemon.
    Building [k8sdemo-backend]...
    Sending build context to Docker daemon  534.5kB
    Step 1/13 : FROM golang:latest as builder
    ---> dc7582e06f8e
    Step 2/13 : WORKDIR /app
    ---> Using cache
    ---> d5d126eaa528
    Step 3/13 : COPY go.mod go.sum ./
    ---> Using cache
    ---> 6ed430911953
    Step 4/13 : RUN go mod download
    ---> Using cache
    ---> bfb89c8b352b
    Step 5/13 : COPY . .
    ---> 6c1f89974762
    Step 6/13 : WORKDIR /app/cmd
    ---> Running in d36e8a412aae
    ---> 9f7f92349811
    Step 7/13 : RUN go build -o main.exe
    ---> Running in 31ff6408dfda
    ---> 31d84d0c860a
    Step 8/13 : FROM alpine:latest
    ---> 965ea09ff2eb
    Step 9/13 : RUN apk --no-cache add ca-certificates
    ---> Using cache
    ---> a27265887a1e
    Step 10/13 : WORKDIR /root/
    ---> Using cache
    ---> b9c048c97f07
    Step 11/13 : RUN mkdir /lib64 && ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2
    ---> Using cache
    ---> 95a2b77e3e0a
    Step 12/13 : COPY --from=builder /app/cmd/main.exe .
    ---> Using cache
    ---> 5ef8db6e073a
    Step 13/13 : CMD exec /bin/sh -c "trap : TERM INT; (while true; do sleep 1000; done) & wait"
    ---> Using cache
    ---> 6f3e1f751ac6
    Successfully built 6f3e1f751ac6
    Successfully tagged k8sdemo-backend:05894ca-dirty
    Tags used in deployment:
    - k8sdemo-backend -> k8sdemo-backend:6f3e1f751ac6ad3c39092a9308f9a6e1d5e087da275349aa3719344785b26f1a
       local images can't be referenced by digest. They are tagged and referenced by a unique ID instead
    Starting deploy...
    - deployment.apps/k8sdemo-backend-deployment created
    - service/k8sdemo-backend-service created
    Watching for changes...

    你如果有测试程序,就可以在控制台输出结果。我没有测试程序,就要登录到Pod上运行程序,查看结果。

    获得Pod名

    vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/kubernetes/backend$ kubectl get pod
    NAME                                          READY   STATUS    RESTARTS   AGE
    k8sdemo-74cb7b997c-8hpdq                      1/1     Running   1          11d
    k8sdemo-backend-5cd9d79856-nwlcl              1/1     Running   1          11d
    k8sdemo-backend-deployment-57bcd56f7d-26p5k   1/1     Running   0          14s
    k8sdemo-database-85855485c6-vnsp4             1/1     Running   1          11d
    k8sdemo-jenkins-deployment-675dd574cb-r57sb   1/1     Running   5          36d

    登录Pod,并运行程序

    vagrant@ubuntu-xenial:~/jfeng45/k8sdemo/script/kubernetes/backend$ kubectl exec -ti k8sdemo-backend-deployment-57bcd56f7d-26p5k -- /bin/sh
    ~ # ./main.exe
    time="2019-12-10T06:23:45Z" level=debug msg="connect to database "
    time="2019-12-10T06:23:45Z" level=debug msg="dataSourceName:dbuser:dbuser@tcp(k8sdemo-database-service:3306)/service_config?charset=utf8"
    time="2019-12-10T06:23:45Z" level=debug msg="FindAll()"
    time="2019-12-10T06:23:45Z" level=debug msg="created=2019-10-21"
    time="2019-12-10T06:23:45Z" level=debug msg="find user:{1 Tony IT 2019-10-21}"
    time="2019-12-10T06:23:45Z" level=debug msg="find user list:[{1 Tony IT 2019-10-21}]"
    time="2019-12-10T06:23:45Z" level=debug msg="user lst skaffold:[{1 Tony IT 2019-10-21}]"

    有关Skaffold的详情,请参见Working With Skaffold

    自动调试工具比较:

    有四个比较流行的 自动调试工具,它们是“Draft”,“Skaffold”,“Garden”,“Tilt”。

    Garden:我最先测试的是“Garden”,因为它功能强大。但测试之后发现它很不灵活,对项目的目录结构有特殊要求。例如,你的项目有三个微服务,那么它会建一个总项目,三个微服务每个是一个子项目,每个子项目里需要一个“Garden”的微服务配置文件,总项目也要一个配置文件,而且文件的名字和位置是固定的。这导致它配置起来很繁琐,而且与一般的程序结构有冲突。“Garden”的设计思想是好的,它想使用一个工具来统一开发和部署。但由于开发和部署差别还是很大的,统一的结果就是不伦不类。它给出的例子也都是很简单的实例,我觉得一旦应用到比较复杂的项目就会很不方便。

    Garden的详情,请参见Introduction

    Tilt:“Tilt”是我第二个测试的,它看起来非常灵活,功能也很强大。但运行之后,它在连接Minikube时出了问题,连接不上。官方安装文档给出的默认的k8s集群是Microk8s。它的文档里也说了支持Minikube,但并没有解释需要做哪些设置,看起来像是不需要设置就可以直接连通,不知道为什么我的Minikube会有问题。当然,也有可能是因为我启动时用的是“minikube start --vm-driver=none”,导致了连接的问题。我想如果花些时间仔细研究,问题应该可以解决,但连接Minikube是整个过程的第一步,一上来就出问题实在让我有些信心不足,就决定先放一放。

    Tilt的详情,请参见Tutorial: The First 15 Minutes

    Skaffold:这是我测试的第三个工具。它功能很强大,也很灵活,虽然也碰到一些问题,但很快就解决了。因此我对Skaffold是很满意的。Skaffold给出的官方安装文档的下载地址是“https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64”。 这个没法访问。你可以在GitHub的release里面下载可执行文件,然后拷贝到“/usr/local/bin/skaffold”目录就可以了。

    Draft:我没有测试Draft。Draft现在已经不再维护了,它的开发者有别的任务,停止了继续开发。Draft应该比较容易使用,但功能不够强大。

    总体评论:总的来说我对Skaffold很满意,它确实大大简化了调试流程。但我觉得这类工具并不像我想像的那么完美。因为每次修改程序之后都要重新生成镜像,这个过程很慢。当然你可以有很多手段来优化他,例如建一个本地镜像库。另外这类工具本身也有优化措施,例如对下载库的优化。但总的来说跟本地环境还是没法比。

    关于这些工具的比较详情,请参见The ultimate guide for local development on Kubernetes: Draft vs Skaffold vs Garden.ioLocal Kubernetes development with Tilt.dev

    开发模式:

    在云原生开发模式下,你可以把项目的运行环境分成两部分。一部分是项目需要调用的服务和资源,这些都是部署在云环境上的(也就是k8s集群)。你可以用Helm创建一个chart,里面包含所有本项目需要调用的k8s服务(包括数据库服务),然后把这个chart部署到k8s集群上,这部分的程序变化频率较低。一旦这些服务中的某些代码变了,你只要重新部署chart就行了。另一部分是项目本身的代码和运行环境,这部分程序变化频率较高。这一部分既可以在k8s上运行,也可以在本地环境运行。它的不同决定了开发模式的不同。

    纯云原生开发模式:

    在这种模式下,除了IDE和代码是在本地,其他的所有东西都是在云环境。当项目代码修改之后,需要创建新的Docker镜像文件,然后把镜像部署到k8s集群上,在k8s集群上进行调试。你可以用前面讲到的自动调试工具来完成这一任务。它的好处是开发环境和生产环境完全兼容,这样保证了在生产环境部署时没有意外。缺点是调试效率稍低。你如果想把IDE和代码都放在云上,也是可以的,本地只要有一个客户端来访问它们就行了。 这时就是纯正的云开发环境,但它的象征意义更大,对实际工作没有太大影响。

    混合开发模式:

    在这种模式下,项目是在本地调试的,而它依赖的其它微服务是部署在云环境上(虚拟机上的k8s上)的。由于本地环境和虚机的网络是联通的,本地环境上运行的代码可以访问虚机上的微服务。数据库也是一样,也是部署在k8s集群上,你可以把它看成一个服务,并通过本地客户端访问数据库上的数据,这时数据库的物理位置对你是透明的,不管是在云上还是在本地都没有区别。当项目的代码修改之后,你在本地运行项目并调试。如果你需要web服务器,对有些语言不成问题,例如Go,它的web服务器就是用本地代码生成的,是程序的一部分。如果你用的是Java,需要单独的服务器,那么你还需要一个本地服务器来部署修改之后的代码。

    这种方式的最大好处就是调试效率很高。因为本项目的代码修改频率是最高的,用这种方式能最大限度地提高它的调试速度。虽然牺牲了一点开发环境和生产环境的兼容性,但这也是可以弥补的。例如,你可以每隔一段时间把本地项目部署到k8s集群上(使用上面提到的调试工具)和其他依赖的服务一起进行整个联调,这时的运行环境就和生产环境一致了。具体的部署频率根据个人和项目来定,可以是每天,也可以是3天或更多。这样既能保证平时调试的速度和效率,又能保证本地开发环境和生产环境的一致性。这种模式在我看来更有优势。

    工具总结:

    本文详细讲解了云原生开发环境以及需要的工具,它包括下面四类:

    • IDE:必不可少,需支持k8s.
    • k8s:是云原生的基石,没有它就没有云原生.
    • Helm:不论什么开发模式,它都是一个不可或缺的工具.
    • 自动调试工具:在纯云原生开发模式下是必不可少的,在混合开发模式下也是需要的,但没有纯云原生开发模式下那么重要。

    源码库

    完整源码的github链接:k8sdemo

    索引

    1. 云原生的不同解释及正确含义
    2. IntelliJ IDEA 2018.1: Kubernetes support
    3. 通过搭建MySQL掌握k8s(Kubernetes)重要概念(上):网络与持久卷
    4. 通过实例快速掌握k8s(Kubernetes)核心概念
    5. 用Helm3构建多层微服务
    6. Working With Skaffold
    7. Introduction
    8. Tutorial: The First 15 Minutes
    9. The ultimate guide for local development on Kubernetes: Draft vs Skaffold vs Garden.io
    10. Local Kubernetes development with Tilt.dev

    不堆砌术语,不罗列架构,不迷信权威,不盲从流行,坚持独立思考

    展开全文
  • 原生App与Web APP优劣势分析

    千次阅读 多人点赞 2019-06-25 10:45:33
    现如今APP开发有两个主流的方向:原生App 以及移动Web App。那么您是否知道这两者有何区别?什么是原生APP,什么是web APP?今天小编在此对二者进行一个对比。 ☛ 什么是原生APP 在智能手机上运行的App应用程序有...

    现如今APP开发有两个主流的方向:原生App 以及移动Web App。那么您是否知道这两者有何区别?什么是原生APP,什么是web APP?今天小编在此对二者进行一个对比。
    在这里插入图片描述
    ☛ 什么是原生APP
    在智能手机上运行的App应用程序有NativeAPP(基于本地操作系统运行)和WebAPP(基于手机浏览器运行),其中NativeApp就是原生App的意思,所以原生App开发也就是指基于本地操作系统的App开发服务。如今市面上多数的APP软件开发都是使用的原生程序编写的应用程序,也就是说大部分的手机APP属于原生APP应用软件。原生APP访问和兼容的能力也比较好,可以支持在线或者离线消息推送或是进行本地资源访问,以及摄像、拨号、蓝牙、功能的调取。原生APP开发有许多的优势,如原生APP是针对不同的平台为用户提供不同的体验、原生应用可以节约宽带成本、访问本地资源、打开的速度更快并为用户提供最佳的用户体验和优质的用户界面等。

    ☛ 什么是web APP
    WebApp是一种框架型APP开发模式(HTML5APP框架开发模式),具有跨平台的优势,该模式通常由“HTML5云网站+APP应用客户端”两部分构成,APP应用客户端只需安装应用的框架部份,而应用的数据则是每次打开APP的时候,去云端取数据呈现给手机用户。

    ☛原生APP和web APP的对比
    在这里插入图片描述

    1、开发方面

    原生APP:
        每一种移动操作系统都需要独立的开发项目,iphone版本、Ipad版本、安卓版本。每种平台都需要独立的开发语言。需要使用各自的软件开发包,开发工具以及各自的控件。开发成本高、开发速度慢、维护成本高。三个平台(IOS、安卓、windows)的规则、推广、运营都不相同。官方应用商店对APP上线审核流程比较复杂而且很慢,会严重影响APP的发布上线。

    web APP:
        因为运行在移动设备的浏览器上,所以只需要一个开发项目。可以通过HTML、CSS或者JavaScript来进行WebAPP的开发。开发成本低、开发速度快。

    2、功能方面

    原生APP:
        原生APP是一个系统性的应用程序,可以类比于电脑上的软件。原生app可以调用移动终端的硬件设备, 比如:麦克风、摄像头、短信、GPS、蓝牙、重力感应等。实现功能丰富

    web APP:
        Web APP可以类比于电脑上的网页。WebAPP更多是页面展示类的APP。只能使用有限的移动硬件设备功能。更多用于页面展示,侧重于简单的交互,无法使用很多硬件设备独特的功能。

    3、应用安装与使用方面

    原生APP:
        需要通过应用商店将原生app下载到手机上或移动终端上。以独立的应用程序运行用户必须手动去下载并安装这些原生App,原生应用可以节约宽带成本,可以访问本地资源、缓存。
    web APP:
        过移动设备上的浏览器访问,软件更新只需要更新服务器就够了,用户层面不需要做任何操作。不需要安装客户端,可以节省手机终端的内存空间。

    4、版本控制方面

    原生APP:
        用户可以自由的选择是否更新软件版本,所以会出现不同用户同时使用不同版本的情况。同时也会导致维护成本比较高。使用旧版本的用户无法体验新版本的完整功能。
    web APP:
        所有用户都是同样的版本,所有用户获得的功能都是相同的。版本更新比较方便,直接在服务器册更新数据即可。一个功能做好了就上线,一天更细几十次都毫无压力。如果客户端只是一个浏览器,那一切都会变得非常简单。另外web统一性高,跨平台使用时开发量少。由于其入口不明显(浏览器导航或者随意点击链接进入),让用户记住的门槛也随之拔高。每次推广导入的流量都可能沦为一次性努力,用户留存低。

    5、加载速度方面

    原生APP:
        原生APP由“云服务器数据+APP应用客户端”两部分构成,APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。访问的时候,不需要重新下载加载应用页面框架,只需要加载数据即可。所以加载速度更快,页面响应更快。
    web APP:
        而WebAPP打开一个页面,都需重新加载页面的所有元素,访问速度受手机终端性能和网络环境的限制,导致加载速度慢,而且操作频繁容易卡死。

    总结:

        原生App偏向于交互,注重用户体验(导航切换、勾选选项、图片、视频等操作),WebAPP偏向与浏览和简单的交互。一些功能需要访问硬件(摄像头、传感器等),使用原生App,WebAPP用于信息展示。成本有限时,核心的功能使用原生APP,周边辅助的功能可以使用WebApp。现状:比较流行的方法就是将原生App和WebApp进行融合,就是说应用大的框架是原生的,其他详细的内容就通过网页封装,这样做的好处就是在方便更新的同时,也能保证核心功能的交互体验。

    展开全文
  • 本文转载自 Android 原生开发、H5、React-Native使用利弊和场景技术分享  由于工作原因,由Android原生开发转向React Native开发,ReactNative是从去年5月份开始至今,最近公司想要使用Android+H5开发,在这里,...
  • 原生开发应用开发 Microsoft阵营的 Winform WinForm是·Net开发平台中对Windows Form的一种称谓。 如果你想深入的美化UI,需要耗费很大的力气,对于目前主流的CSS样式表来讲,美化Winform的界面以及自定义控件是...
  • 原生开发基础

    2021-11-19 17:19:51
    原生开发基础 概念:云原生(Cloud-native)应用开发是一种构建和运行应用以充分利用云计算模型优势的方法,即创建响应式、有弹性且有恢复能力的应用。云原生应用开发使企业能够在现代化的动态环境(如公共云、私有...
  • 最近工作中接触到React-Native框架,对其进行一些技术分析,结合之前了解的H5的一部分,加上自己做了很久的原生开发(十几个android app、sdk,包括2个ios), 总结下目前了解到的这三种移动端应用开发方式的特点和...
  • Qt软件的发展历史及优势特点

    千次阅读 2019-05-25 16:14:09
    使用Qt开发软件,相同的代码可以在任何支持的平台上编译运行,而不需要修改源代码。它会自动根据平台的不同,表现平台特有的图形界面风格。经过多年发展,Qt不但拥有了完备的C++图形库,而且近年来的版本逐渐集成...
  • 原生优势

    千人学习 2016-08-08 09:12:13
    pivotal云原生活动将与您一起遍览云原生软件的源起 、发展以及交付方法。我们将与您分享云原生软件组织的能力和预期成果,内容涵盖基础设施自动化、容器编排和生命周期管理及应用程序框架。
  • 压力测试工具

    万次阅读 多人点赞 2018-12-20 16:06:28
    3.8.2 产品优势... 19 3.8.3 产品功能... 19 3.8.4 计费规则... 20 3.8.5 测试报告... 20 3.8.6 参考文档... 24       性能测试 性能测试是利用产品、人员和流程来降低应用程序...
  • 安卓APP开发优势和概述

    万次阅读 2017-10-23 11:43:47
    一、安卓软件开发概述 Android由Google公司和开放手机联盟领导及开发,主要使用于移动设备,如智能手机和平板电脑。中国大陆地区较多人使用“安卓”或“安致”。安卓APP是一种手机应用软件,是使用在安卓手机上或者...
  • 原生APP又称Native App,该开发针对IOS、Android、Windows等不同的手机操作系统要采用不同的语言和框架进行开发,该模式通常是由“云服务器数据+APP应用客户端”两部份构成,APP应用所有的UI元素、数据内容、逻辑
  • Java框架总结

    万次阅读 多人点赞 2020-01-17 14:14:13
    他很大程度的简化DAO层的编码工作,将软件开发人员从大量相同的数据持久层相关编程工作中解放出来,使开发更对象化了。 透明持久化(persistent)带有持久化状态的、具有业务功能的单线程对象,此对象生存期很短。...
  • CloudOS,一站式云原生开发平台

    千次阅读 2021-11-08 11:42:13
    一站式云原生开发平台**Cloud OS**:包含云原生应用架构设计、在线协同编码开发、基于云原生的API管理和接口测试、多云交付和应用调度、灰度发布、流水线、应用运维、服务治理、多容器集群管理、云边一体化业务交付...
  • 安卓Android苹果IOS双端多用途通讯录短信定位获取系统,hbiulderX打包出来的和原生APP一样 源码适用于:金融业务型公司(当你和客人达成资金担保合作协议,在抄录其50个备用联系人的时候,直接进行读取,省去了一...
  • APP开发模式通常分为Web APP与Native APP原生模式两种,这两种模式均各自有自己的优势,到底是采用Native App开发还是采用Web App开发一直是业界争论的焦点,但是随着HTML5的发展及云服务普及,采用HTML5进行Web App...
  • 第01课:Electron 开发优势

    千次阅读 2020-09-22 12:25:26
    1.1 Node.js,一个让 JavaScript 从丑小鸭变成白天鹅的框架 可能很多读者会感到奇怪,本系列课程...相信做 JavaScript 开发的读者对 Node.js 不陌生,Node.js 诞生于 2009 年,类似于 ASP.NET,是用来开发服务端程...
  • [云原生]~云原生简介

    2019-12-08 21:10:28
    原生的主要特征 进一年我们都在使用云原生框架 SpringCloud微服务开发项目,敏捷快速 部署在容器中,解决部署环境差异 使用DevOps自动部署,减少运维压力 微服务 业务功能单一但完整 只对外提供必要的...
  • Android模拟器

    千次阅读 2019-07-21 15:50:45
    ” 使用Android模拟器开发和调试应用肯定比使用真机方便。但相比XCODE的IOS模拟器,Android SDK自带的AVD实在不争气,不过一些第三方的模拟器却表现不俗! 1、Android SDK自带的AVD模拟器 12年我开始接触Android...
  • 最近工作中接触到React-Native框架,对其进行一些技术分析,结合之前了解的H5的一部分,加上自己做了很久的原生开发(十几个android app、sdk,包括2个ios), 总结下目前了解到的这三种移动端应用开发方式的特点和...
  • 一、移动端开发分为以下几个方向: ...优势:直接安装在手机操作系统中的程序,所以可以操作手机内部的软件或者硬件,而且处理性能比较优秀(相对h5来说) 例如:获取通讯录、读取短信、获取地理位置
  • 与之相随,小程序的开发生态也在蓬勃发展,从最初的微信原生开发,到wepy、mpvue、taro、uni-app等框架依次出现,从刀耕火种演进为现代化开发,生态越来越丰富。 选择多了,问题也就来了,开发小程序,该用原生还是...
  • web app与原生app的区别

    2021-01-04 16:07:45
    之前我学过app的开发,当时Android版本的,知道开发Android app时写的代码。那么问题来了:  html5封装的app与原生态app有什么区别呢?  html5又和app有什么区别呢?  为什么大型网络公司还是倾向于推广原生态app...
  • 原生赋能传统行业软件离线交付

    千次阅读 2021-11-11 11:05:57
    为了防止数据泄露和运行安全考虑,一般情况下网络会采取内外网隔离的策略,以防范不必要的风险,毕竟在安全防护方面,网络物理隔离是网络安全防御最有效的手段,而网络隔离在软件交付过程中,对于外部软件开发厂商来...
  • 最近工作中接触到React-Native框架,对其进行一些技术分析,结合之前了解的H5的一部分,加上自己做了很久的原生开发(十几个android app、sdk,包括2个ios), 总结下目前了解到的这三种移动端应用开发方式的特点和...
  • 整理 |弯月,责编 | 郭芮头图 | CSDN 下载自东方IC出品 | CSDN(ID:CSDNnews)容器的标准化使用改变了软件开发方式,我们迎来了开发运维的时代,基于云原生的开...
  • 为什么说云原生重构了互联网产品开发模式?云原生的概念云计算的前世今生阶段1:虚拟化技术阶段2:虚拟机的市场化应用阶段3:容器化和容器编排的兴起云原生到底是什么?云原生出现的背景云原生解决了哪些问题?不断...
  • 本文针对小白用户对App做一个简单的介绍,介绍了App都有哪些类型,不同的类型app开发需要哪些技术,用户可以根据自己的需求选择不同的App开发,若不懂技术,没有资金怎么开发app。 一 、App有哪些形式? ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 30,435
精华内容 12,174
关键字:

原生开发软件的优势