Android深圳app开发可以用什么语言？目前移动互联网发展迅猛，每个人都希望开发一款app软件。然而，目前主流的app主要分成两类，一类是基于IOS系统的，另一类是基于Android系统的。两个不同系统的app所采用的编程语言是全然不同的。
Android深圳app开发可以用什么语言？
　　Android深圳app开发可以用什么语言？
　　1.Java语言
　　Android手机之上几乎所有的app都是用Java语言撰写的，用java语言研发的软件的程序库、数据库和运行库是Android手机软件的主要特点之一。Java语言本身具备很多优点，因此Android app的开发应用于Java核心类的知识，这也使用Java语言研发的Android软件具备优势。
　　Android app的开发语言包含C语言和其他语言，但主流的开发语言是java语言，这使界面的功能爆发了无停顿的变化。提升软件交互的可能性是Java的最小特点。可说，Android手机之上几乎所有的app都是用Java语言撰写的。
　　2.C语言
　　C语言是一种结构化语言。使用模块化方法编制程序直观，不易检修和保护。C语言具备很弱的表达和处理能力。它不仅具备多样的运算符和数据类型，而且方便完工各种杂乱的数据结构。C语言是最盛行的编程语言之一。它具备功能丰富、表达力弱、使用方便、适用范围大、政策性弱、可移植性糟糕等特点。它既有高阶语言的特点，又有低级语言的特点。它适宜当作一种系统描述语言，既可用来撰写系统软件，也可用来撰写应用软件。
　　3.Sky
　　Google在2015年发行了全新的Android开发语言Sky，以提升app的运行速度和响应速度。天空不局限于平台。它的代码可在Android、IOS和任何结合了dart虚拟机的平台之上行驶。
　　当然，sky如何取代Java沦为Android app开发的主流语言，还存疑观测。目前，Android研发的主流仍然是Java和C语言。

	

————    ↑ 点击蓝色字关注我   ————
Android App完整开发流程
前言
宅在家里躺在床上为国家“做贡献”，这是2020年送给所有人的一大礼物。好多人不敢奢想继续这种不踏实的日子，但一次次的延迟上班，有些人继续“贡献”着自己，有人陆陆续续复工，也有人在战役失去了公司(公司倒闭)。但是，作为讲师，我们可以继续为学生在线直播课程，让我们不再感到“拿了钱不出力”的“委屈”。
由于工作原因，这几天在整理开发一个完整Android App流程，希望也能帮助到大家。
1.开发流程
①项目启动
产品总监确定产品或者项目的方向，简单点说就是我们要做一个什么东西，然后产品经理做相关市场调研，把业务梳理清楚，再交给产品总监审核。
在这个阶段要确定的是我们要做一个什么产品，该产品包含了哪些业务功能、业务逻辑、业务配置。产出是PRD文档。
②产品需求
产品经理根据第一阶段产出的业务逻辑做出产品原型图，交于UI设计师、开发工程师，开评审会，UI设计师和开发总监评审业务功能、评估完成难度与时间。产出是产品原型图。
③设计阶段
主要是UI设计师根据产品原型设计UI界面、UI标注、UI设计规范，开发总监基于效果图，明确业务实现细节，消除对最终成果理解的不一致。产出是UI设计图、标注图等。
④开发阶段
开发总监给各个工程师(后端、前端、App端)分配对象开发任务，产出是产品。
⑤测试阶段
专业的测试人员、产品经理、产品总监、老板，都是产品的测试人员，这个阶段最难过，会听到不同的人说不同的话，好听的难听的好好听着就行。产出是测试用例以及测试结果。
⑥产品上线
如果测试阶段没有问题，开发所有人员来个通宵，最终，开发者或者运营上线就好了。最后，所有开发者早晨六点回家休息，下午正常上班(回家路上两个小时，上班路上两个小时，其实就回家洗漱一下，这就是北京程序员的狗血生活)。
这样一个完成的产品就诞生了。
2.Android开发者都要做什么
上文粗略的概括了App或者产品的开发流程，作为Android开发者，我们都要做什么呢？
①产品研讨，需求确认，需求(带效果图)评审，一直到需求最终落地；(对应上文的第二阶段)
②构思产品，搭建开发框架，使用什么架构呢？MVP，还是MVVM？
③是否需要用到组件化开发？
④抽取共性内容：基类(主题、标题栏、状态栏、侧滑、跳转动画等等)和工具类；
⑤确定用什么网络框架？跟后端、测试确定返回结果类型、字段；
⑥需要用到哪些三方库？确定这些三方库的版本；
⑦配置gradle：配置sdk版本，三方库版本统一管理，是release模式还是debug模式，签名文件等等；
⑧具体开发：开发过程中需要及时跟相关产品，测试，以及后台人员确认；
⑨代码混淆；
⑩apk加固：使用什么加固方式？乐固、360加固还是其他的；
⑪多渠道打包：渠道信息需要提前配置，提前在对应的开发者平台申请好，节省时间；
⑫测试，bug修复，功能点查缺补漏，优化；
⑬验收各个功能模块，配置信息；
⑭验收合格之后，准备好需要上架的安装包，定好时间上线；
⑮上线之后，跑一遍主要流程，线上观察，等待客户反馈；
作为Android开发者，大致就是这些流程，当然了，开发过程中可能会出现各种各样的问题，需要我们在开发过程中细心细心再细心，多测试，出现问题了沉着应对。
最后
最后，希望通过该文章能为大家开发带来一汪清泉。
- end -
作者：Anfly

	

在APP开发中，iOS和Android应该如何选择？iOS和Android是市面上最常见的两种操作系统，所以APP的开发也都是基于这两种系统的。但是，对于很多创业初期的公司来说，同时开发这两种系统的APP，是不太现实的。这个时候大家就面临一个选择：是开发iOS还是Android？我们一起来看看这两种有什么不同。
1.市场占有率
从市场占有率上来说，Android在智能手机市场的占有率远高于iOS，使用人群也更为广泛，尤其是在发展中国家，接受程度更高。但是，iOS平台用户的消费能力普遍要高于Android平台用户。从应用购买到在线零售，甚至是广告，iOS用户的转化率更高，平均消费也更高。所以，只考虑市场份额的话，可以选择Android，如果还考虑其他因素，那我们就需要斟酌了。
2.广告限制
对于很多APP运营商来说，在APP内嵌入广告是一种很常见的盈利模式。Android平台对广告的限制比较宽松，iOS平台内对广告的限制就比较严格，但是iOS平台的用户更有价值，所以，我们应该根据自己想要实现的预期效果来进行选择。
3.开发周期
从开发周期来说，Android应用程序的开发时间比iOS长2-3倍。这是因为Android操作系统种类更多，没有标准，所以开发周期也会延长。但是随着科技的发展，这个问题正在慢慢的消失。
4.审核流程
我们都知道，APP开发完以后，需要上架到应用商店。iOS App Store的审核量流程比较麻烦，审核周期也比较久，可能需要几天。甚至有时候我们提交的APP或被拒绝，这个时候就比较麻烦了，需要修改再进行提交，这就会导致上架的时间更久。
Android商店的APP提交流程则比iOS应用商店要简单得多。Andriod APP通常会在几个小时内发布。并且理论上，Android平台上的应用程序可以随时更新。可以选择的Android商店也很多，我们可以把自己的Android APP同时上传到多个流行的安卓市场。
5.交互体验
IOS平台的交互体验往往比Android好，而且iOS的UI框架更加统一和规范。因此，如果你希望用户体验好，交互体验更为流畅，可以选择iOS开发。如果你希望自己的APP有更加个性化的体验，Android的操作系统种类更多，可以选择Android开发。
总体来说，这两个平台都是可以的，都各有各的优势，在时间和资金都允许的情况下，可以选择两个平台同时开发，付出的越多，收获的也越多。
中犇科技有专业的产品经理，根据客户的需求量身定制开发计划，更有350+技术人员，确保产品高效率高质量的完成。APP开发，找中犇！

	

互联网公司的移动端业务基本都是基于各类App来承载，如果业务种类较多，那么App自身的安全质量(功能设计与编码实现等)保障就是一个比较有挑战的工作。一方面App本身数量较多、更新比较频繁，但是还需要每次针对各个App做到各有侧重的安全保障；另一方面，在人力投入上和其他安全建设方向一样，需要做到尽可能高的投入产出比，避免陷入重复工作困境。那么怎么尽可能以少而优的人力去批量、规模化解决App安全质量保障的问题呢？基于实际工作总结，Android App中的安全问题大部分都集中在容易产生的各类同质安全漏洞上，同时内部的轻量级SDL能力平台也具备了成熟实践的基础，基于这些条件并经过我们一段时间的实践，落地了一套适合大型企业级场景的Android App安全质量保障实践方案，在这里和大家分享交流。
整体上，App安全保障实践方案整体流程如图1.1所示：
图1.1 App安全保障实践流程图
在具体落地层面，要规模化保障App编码层面的安全，还需要解决如下头、尾两个问题
1) 如何确保业务线提交app代码进行白盒漏洞检测？
有两种方法，a)在研发流水线中，拉取提交到仓库的代码进行白盒扫描，检出结果通过漏洞处理平台来流程化的推进修复；b)申请人工评估的项目，业务线需要主动先进行白盒扫描并修复扫描出的典型漏洞，然后在评估申请中填写白盒扫描任务号
2) 如何统计该方案运行实践流程的实际落地效果呢？
白盒扫描的效果可以直接统计，SDL-SDK的使用效果则是通过在代码仓库中进行SDL-SDK的代码特征扫描，来进行SDL-SDK使用覆盖情况的统计
       整体上，此保障实践方案的优点主要有如下几个方面：
1) 业务方直接在编码阶段应用安全代码库、代码提交阶段使用白盒代码自动化安全审计，可以发现并自行解决约70%-80%的典型安全漏洞，避免在开发后期发现进而带来大量的修复与升级工作量2) 针对典型漏洞的安全代码库简单易用，不会增加业务方额外开发量3) 复用编码库，可以提高业务线典型场景的安全编码一致性并提高开发效率
下面主要从安全编码方案(SDL-SDK)和App代码白盒扫描这两个方面，来实例化介绍下具体的技术实现思路与Case。
1安全编码方案(SDL-SDK)
App在编码实现过程中，经常容易产生一些典型安全漏洞，因此设计提供通用型SDL-SDK是可行的方式(为业务方提供一些常见安全功能服务组件，如安全webview、APK应用更新、IPC通信安全等等)。目前SDL-SDK已经在百度的多个核心App中集成使用，SDL-SDK极大的简化业务方相关开发时间/漏洞修复时间，同时也可以显著提高安全性，减少相关漏洞的重复产生。
以Android App中Binder IPC通信为例，应用A通过AIDL接口定义了并通过Service公开了如下接口：getUserInfo，根据用户名返回用户信息(包含手机号等敏感信息)：
interface IMyAidlInterface {
     String getUserInfo(String userName);
 } public class MyBinder extends IMyAidlInterface.Stub{@Overridepublic String getUserInfo(String userName) throws RemoteException {if(userName.equals("zhangsan")){
             String jsonStr = "{'username':'zhangsan', 'telephone':'110','address','某市某区某街道**'}";return jsonStr;
         }return null;
     }
 }
其他应用则可以随意调用‘getUserInfo’接口，获取用户的敏感信息：
public   void onServiceConnected(ComponentName name, IBinder service) {    myaidlInterface =   IMyAidlInterface.Stub.asInterface(service);    ... ...}...   ...Strign   str = myaidlInterface.getUserInfo("zhangsan");
上述Binder IPC通信就存在典型的安全漏洞，攻击者可以通过调用Service暴露的AIDL接口，进行提权或者窃取用户信息。实际评估中也发现Binder IPC漏洞出现比较高频。另外少部分App使用socket端口通信的方式进行应用间进程通信，同样易产生安全漏洞。
针对上述安全漏洞，在规避/修复上主要需要完善安全可靠的身份校验机制，以确保对外提供服务接口的安全性。IPC通信安全流程如图1.2所示：
图1.2 IPC通信安全流程图
上述技术方案在技术实施的过程中，有如下两点需要注意：
A. 在Server的OnBind函数中，并不能通过“Binder.getCallingPid()”函数来获取调用者的“身份信息”，只能在Binder对外服务”接口的实现类”中进行；
B. Binder对外服务接口有如下两种方式，因此需在重要的AIDL接口和自己实现的onTransaction函数里都要对Client进行身份校验，避免遗漏。
1) AIDL接口；
2) 继承Binder实现并覆写onTransaction函数。
白盒扫描
白盒扫描是基于源码的静态漏洞扫描，其效果和准确性，严格依赖于代码的数据流和控制流分析，目前对于源代码静态扫描，通常可以可以分为三类：纯自研、开源+自研、商业，最终选用何种方式，可以根据团队人数、资金状态等综合考虑来选择。
目前百度的白盒扫描引擎一共支持20+多类Android App漏洞类型扫描，漏洞扫描检出准确率基本在98%以上(以确保准确率为前提，允许存在一些漏报case)，下面以典型的top5类漏洞为例，进行白盒检测思路介绍，并选取“ZIP目录穿越漏洞”为例，进行更加详细的漏洞扫描检测规则设计介绍。
漏洞名称
检测思路
注意事项
Webview File域同源策略绕过
检测WebSetting. setJavaScriptEnabled(true)和WebSetting.setAllowFileAccess(true)是否都为true
setAllowFileAccess默认true，并且注意排除一些case，如：if(url.trim().startsWith("file:"))webView.getSettings().setJavaScriptEnabled(false)
Webview 远程命令执行
1)判断App最低版本是否小于17，然后判断WebSetting. setJavaScriptEnabled是否为true，为true的话进一步判断是否调用addJavascriptInterface添加任何JS和native交互接口，并且移除默认的3个JS交互接口；2)addJavascriptInterface添加JS和native交互接口时，是否对加载的url做校验，未做校验的话则需要判定交互接口是否涉及敏感信息读取或者命令执行
1)域名校验需要时严格的host匹配2)敏感信息接口除了系统API，一些涉及公司数据，要根据公司的业务方现状来定义API
Zip目录穿越
定位API：ZipEntry. getName，然后检测Zip文件解压的源文件是否来自SD卡，确定来自SD卡后，进一步判断是否对解压的文件名进行了“../”过滤
特列：下载外部传入的zip文件url，并保存到私有目录
应用安装/加载签名绕过漏洞
提取应用安装和动态加载的API，对APK的数据流处理进行分析，判断是否对APK进行了签名校验
binder不安全通信
获取所有AIDL接口实现函数和onTransact  ()函数，判断所有实现函数中是否调用了“Binder.getCallingPid()”对调用者进行身份校验
排除Biner service未导出的情况
ZIP目录穿越漏洞检测
漏洞产生原因：
因为ZIP压缩包文件中允许存在“../”的字符串，攻击者可以利用多个“../”在解压时改变ZIP包中某个文件的存放位置，覆盖掉应用原有的文件。如果被覆盖掉的文件是动态链接so、dex或者odex文件，轻则产生本地拒绝服务漏洞，影响应用的可用性，重则可能造成任意代码执行漏洞，危害用户的设备安全和信息安全。
Java代码在解压ZIP文件时，会使用到ZipEntry类的getName()方法，如果ZIP压缩的文件名中包含“../”字符串，该方法返回值里面原样返回，如果没有过滤掉getName()返回值中的“../”字符串，继续解压缩操作，就会覆盖其他目录中的文件。
漏洞演示：
    private void unzip(File zipFile, String destDir) throws IOException {        ZipInputStream zipInputStream = new ZipInputStream(new CheckedInputStream(new FileInputStream(zipFile),new CRC32()));        ZipEntry zipEntry;        while ((zipEntry = zipInputStream.getNextEntry()) != null) {            System.out.println(zipEntry.getName());            File f = new File(destDir + zipEntry.getName());   //未做任何判断和过滤            if(zipEntry.getName().endsWith("/")){                f.mkdirs();            }else {//                f.createNewFile();                FileOutputStream fileOutputStream = new FileOutputStream(f);                byte[] buf = new byte[1024];                int len = -1;                while ((len = zipInputStream.read(buf)) != -1) {  // 直到读到该条目的结尾                    fileOutputStream.write(buf, 0, len);                }                fileOutputStream.flush();                fileOutputStream.close();            }            zipInputStream.closeEntry();  //关闭该条目        }        zipInputStream.close();    }漏洞检测规则：1)通过代码索引，定位到API：“ZipEntry. getName”，然后获取到对象ZipEntry和函数ZipEntry. getName()的返回值；2)判断第1步中的对象ZipEntry的数据流来源，对其进行数据流追踪，判断ZipEntry是否来源于SD卡上的文件，如果是来源于SD卡上的文件，则进行第3步，否则继续查找下一个ZipEntry对象；3)进行API定位：String.contains("../")[通过字符串”../”查找函数contains]，然后获取调用contains方法的对象，如果其是String类型，则对其进行数据流追踪，判断来源是否是“ZipEntry. getName()的返回值”，如果是就判定不存在该漏洞，否则判定存在该漏洞。
漏洞扫描流程如图1.3所示：
图1.3 目录穿越漏洞检测流程图
落地及效果
       在安全解决方案的落地实践上，我们主要聚焦于效能提升的思路来进行推广落地：(1)优先确保解决方案中关键能力的有效性(能解决关键安全问题)；(2)在安全、业务侧的投入成本上要有清晰的收益并清晰的传达到业务侧。
       业务方在平时基本都聚焦在自己的需求研发工作中，在安全问题规避或解决上，业务方希望是能够投入尽可能少的人力或者最好不投入人力。因此对于我们实践方案的落地上，业务方一开始是容易有判断误区的，因为他们不会去细算这里的投入成本，通常习惯性做法就是：把需要安全review的交给安全，然后等着反馈问题并根据建议修复问题，甚至自己直接开发测试上线绕过安全(然后等着线上暴露安全问题，最后专门花人力来修复)。那我们的App安全保障实践方案刚开始落地时就需要做一些针对性运营工作：
1) 第一步：先找协同紧密且业务重要的业务线，针对其App进行试点性落地实践，让业务线负责人和核心研发非常了解保障实践方案的明确安全收益，进而做到落地实践的试点；2) 第二步：基于标杆性试点效果case，进行内部定点的宣传，可以选择App产品和漏洞比较多的部门，可以对SDL-SDK的使用方式、白盒检测能力、相关漏洞危害、‘保障实践方案落地标杆’效果进行宣传，在方案的落地收益上让业务方逐步有认知。3) 另外为了便于根据反馈来进一步完善App安全保障实践方案，需要建立一些咨询、交流可达性比较好的渠道来获取反馈，比如讨论组、‘App安全保障实践方案公开介绍’WIKI等等4) 最后在整体方案落地实践已成熟的情况下，会进一步协同安全管理角色、研发流水线等一道，将方案落地执行以安全质量基准要求的规范方式来运营，以确保公司级App的基础安全质量做到切实保障。
基于我们的运营实践，18年至今App安全保障实践方案取得了很明显的收益：白盒扫描检出效果显著 (数据不便给出)，SDL-SDK已经在10+多个业务线中集成使用。
整体上，一方面节省了安全工程师的时间、提高了工作效率，同时也让安全工程师能够从普遍性安全问题中解脱出来。
总结
本文主要基于我们的实践工作，总结分享了一套适合大规模场景的Android App安全质量保障实践方案。该保障实践方案主要基于安全编码方案(SDL-SDK)和源码白盒扫描，并辅助一些有效的推广运营落地策略，达到了规模化解决Android App安全质量保障的问题。
构建企业级研发安全编码规范
企业级自动化代码安全扫描实战
企业应用指纹平台框架实践
PHP反序列化漏洞的新攻击面